Default cover design. Current Routing Solutions supporting the Interconnection of Carrier IP –based Multimedia Services in North America IPNNI-2014-012 February 2014

Overview The intent of this contribution is to illustrate some of the mechanisms currently in use and/or being deployed to facilitate the exchange of traffic associated with IP –based multimedia services (e.g., VoIP) between North American service providers.

The Challenge, Illustrated SP1 SP2 SBC-1 SBC-2 1 SIP SIP 3 2 4 Mike Pat Routing Service Routing Service Pat (subscriber of SP1) makes a session request (e.g., places a call) to Mike SP1 network provides originating services (if any) and then queries its routing service to obtain an address to which to forward the message. In this case that query returns SBC-2 (the ingress point to the network to whose services, Mike subscribes). Determination of SBC-1 (the egress point from SP1 network, if applicable) is network –specific. SBC-2 admits the message to SP2’s network, forwarding it to an application server. Its means of doing so is network –specific. SP2 network provides terminating services (if any) and then queries its routing service to obtain an address to which to forward the message. In this case the query returns the address of a device with which Mike is registered (or, not shown, a gateway through which that device is reachable).

Solution Description How does SP1’s routing service determine the address to which to send this call? High Level Answer: SP2 associates each subscriber to which it will accept calls in IP format with a “group”, with the intent that the ingress point(s) through which SP2 wishes to receive traffic destined for members of a given group, is the same. The number of groups is expected to be small relative to the number of subscribers. Usually, though not necessarily, groups reflect geography Group Membership (the set of subscribers in each group) may change frequently. SP2 shares with SP1 periodically, data that associates each group with a prioritized list of ingress points to SP2’s network Because this data is relatively static, it need not be exchanged frequently Because the volume of data is small, the exchange need not be automated SP1 has a means to determine in real time, the group to which ‘Mike’ belongs Currently this is accomplished by using constructs defined in public routing data (NPAC and LERG) to define the “groups” (e.g., LRN, CLLI, OCN). SP1 is responsible for obtaining and using that information to determine group membership.

Implementation Example How SP1’s Routing Service obtains the data it requires In this example: SP1 obtains public routing data via a service bureau, and uses a private ENUM server to store data and implement the associated service logic SP2 associates its subscribers with call servers identified in the LERG via CLLI’s. With each CLLI it associates a prioritized list of SBC addresses. Service Bureau NPAC LERG Routing Service SP1 SP2 Switch CLLI Interconnect Address CLLI-1 SBC-Address-List-1 CLLI-2 SBC-Address-List-2 …

Data from Peering Partners Data from Peering Partners Example of SP1’s routing logic real-time service logic performed by SP1’s “routing service” Search for number in registration data Found? No Determine SP to which number is currently assigned Found? Determine how this SP defines groups Yes Found? Yes Yes No No Registration Data Public Routing Data Data from Peering Partners Forward to registered contact address Error: number is invalid No ICA (*); forward to PSTN Determine Group of which number is a member Found? Determine interconnect address for Group Yes Found? Yes Forward to Interconnect Address No No Public Routing Data Data from Peering Partners Number not IP reachable; Forward to PSTN Number not IP reachable; Forward to PSTN (*) ICA = Interconnect Agreement

Final Thoughts What this contribution illustrates, is currently in use in North America. At minimum, it will get us by for a while (long enough to carefully consider solutions that might have broader applicability or scale better) Any such solution needs to be demonstrably better than this (Verizon’s view: International in scope) Strengths Limitations Implementable Now Limited to North America (CC=1) Flexible Limited Scalability (opinions vary) Variability (grouping, handling of exceptions, etc.,) Could potentially be addressed through standardization, e.g., by this body Administrative Overhead and potential for “fat finger” errors (due to manual exchange of data) Could potentially be addressed by publishing interconnect data (mapping of e.g., CLLI or LRN, to URI), in the LERG Reliance on PSTN structures Low Cost High Availability All data required for real time call processing, resides in SP network