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

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

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

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

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

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

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

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

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

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

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