Routing Considerations This presentation has been updated based

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?

NPAC ENUM Based on existing “well defined format” NPAC All changes sync ENUM (authoritative for number portability) Porting Request (Alternate Registry) 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. Would allow routing changes to be input into ENUM registry and propagate to NPAC. IP-NNI routing change Changes limited to numbers “owned” by a given service provider. Assume this interface cannot be used for number porting. • 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).

NPAC ENUM NPAC All changes sync ENUM (authoritative for number portability) Porting Request (Alternate Registry) 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. Other “registry” IP-NNI routing change • 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 All changes sync ENUM (authoritative for number portability) Porting Request (Alternate Registry) 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. Would allow routing changes to be input into ENUM registry and propagate to NPAC. IP-NNI routing change 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. 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 All changes sync ENUM (authoritative for number portability) Porting Request (Alternate Registry) 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. IP-NNI routing change 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 LERG Spreadsheet … Napkin Restrictions on changes to routing information after synchronized to ENUM or other registry. (See next slide. )

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 All changes sync ENUM (authoritative for number portability) Porting Request (Alternate Registry) 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. Other “registry” IP-NNI routing change • 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?