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

2. 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.

3. 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).

4. 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.

5. 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 …

6. 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

7. 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