Routing Considerations This presentation has been updated based on discussion during the January 7, 2015 IP-NNI Task Force meeting. This presentation attempts to explore the question of whether or not data can be automatically synchronized between the “routing data” options: Between Per-TN solutions? Between Aggregate solutions? Per-TN  Aggregate?

ENUM Synchronization Problem space is reasonably well understood. Various approaches to synchronization between ENUM databases: Hierarchical - Master/Slave (e.g., DNS) Peer to peer (e.g., “White Spaces”) Important to specify which approach is being proposed for synchronization. Synchronization between ENUM and other per-TN databases should be possible: Mapping may be required If either database applies policy, it complicates the mapping

Per TN Routing Considerations Synchronization between ENUM and NPAC (for URI data) may be possible: NPAC => ENUM is straightforward based on existing mechanisms and “well defined format” ENUM => NPAC Required to allow routing updates from other databases Would require other databases to implement existing NPAC provisioning interfaces Are there regulatory implications?

(authoritative for number portability) NPAC  ENUM Based on existing “well defined format” NPAC (authoritative for number portability) All changes sync ENUM (Alternate Registry) IP-NNI routing change To change information in NPAC, ENUM registry would need to use interface currently used by service providers, and would need to be authorized to do so. Changes limited to numbers “owned” by a given service provider. Assume this interface cannot be used for number porting. Porting Request Would allow routing changes to be input into ENUM registry and propagate to NPAC. Allows “registries” to co-exist with simple well defined rules Routing changes can be input into NPAC or ENUM registry Synchronization is applied without policy Service providers can add policy filter within their own networks (allows each service provider to make their own decisions).

(authoritative for number portability) NPAC  ENUM NPAC (authoritative for number portability) All changes sync ENUM (Alternate Registry) IP-NNI routing change To change information in NPAC, ENUM registry would need to use interface currently used by service providers, and would need to be authorized to do so. Porting Request Other “registry” Fully synchronizes with ENUM registry. Rules for synchronizing with NPAC are the same as for ENUM with NPAC Only the number owner can make changes to IP-NNI routing info.

Information to Synchronize Based on existing “well defined format” NPAC (authoritative for number portability) All changes sync ENUM (Alternate Registry) IP-NNI routing change To change information in NPAC, ENUM registry would need to use interface currently used by service providers, and would need to be authorized to do so. Porting Request Other “registry” Fully synchronizes with ENUM registry. Rules for synchronizing with NPAC are the same as for ENUM with NPAC Only the number owner can make changes to IP-NNI routing info. Would allow routing changes to be input into ENUM registry and propagate to NPAC. Key Questions: What is the core information that would be synchronized? Can we agree on the data fields? Can the contribution from Chris Wendt be used as a starting point?

Aggregate => Per-TN NPAC (authoritative for number portability) All changes sync ENUM (Alternate Registry) IP-NNI routing change To change information in NPAC, ENUM registry would need to use interface currently used by service providers, and would need to be authorized to do so. Porting Request Other “registry” Fully synchronizes with ENUM registry. Rules for synchronizing with NPAC are the same as for ENUM with NPAC Only the number owner can make changes to IP-NNI routing info. “Virtual Registry” Aggregate methods based on PSTN constructs are expanded out for every TN This can then be synchronized with the other registry by anyone who wants to do so (no obligations on anyone) Logically this is nothing more than a TN = SIP URI list Restrictions on changes to routing information after synchronized to ENUM or other registry. (See next slide.) LERG Spreadsheet Napkin …

Aggregate => Per-TN Considerations In this case, the Aggregate data is authoritative, and the Per-TN is a copy. If changes are made directly to the routing data in the Per-TN registry the data could become out of sync with the authoritative Aggregate data. But we have already suggested that changes to routing data in the ENUM database could only be made by the “number owner”. Presumably the “number owner” also owns and controls the Aggregate routing data. Is this enough to guarantee synchronization will be maintained?

Per-TN => Aggregate NPAC (authoritative for number portability) All changes sync ENUM (Alternate Registry) IP-NNI routing change To change information in NPAC, ENUM registry would need to use interface currently used by service providers, and would need to be authorized to do so. Porting Request Other “registry” Fully synchronizes with ENUM registry. Rules for synchronizing with NPAC are the same as for ENUM with NPAC Only the number owner can make changes to IP-NNI routing info. “Virtual Registry” Could “per-TN” providers also provide an alternate interconnection point for each TN that can be stated as a simple rule? See next slide for additional detail. Input into service provider provisioning systems

Per-TN => Aggregate Considerations Per-TN to Aggregate mapping will inevitably “lose something in translation”. Possible approaches include: Group all numbers to the same URI, with an arbitrary designation. The problem is how to maintain synchronization Every change to Per-TN data would need update to Aggregate routing information Use AOCN to identify service provider, and then cycle through URIs associated with given service provider. Best approach will depend on the routing topologies service provider wants to support.

Next Steps Existing Routing document describes Aggregate – Per- TN interworking, but does not address interworking between different Per-TN approaches. Should a discussion of interworking between different Per- TN approaches be added? Section 6 of the Routing document already addresses interworking. Is it adequate, or should concepts from this document be added? Is it practical, and desirable, in the near term, to begin narrowing the list of routing options?