Peppermint BoF Provisioning Protocol Requirements for ENUM-SIP Addressing Servers

1. Peppermint BoFProvisioning Protocol Requirements for ENUM-SIP Addressing Servers draft-mule-peppermint-espp-requirements-00 IETF 71 - Wednesday March 12 2008 Tom Creighton - tom_creighton@cable.comcast.com Jean-François Mulé - jfm@cablelabs.com IETF Peppermint BoF

2. Agenda • Background on the ENUM-SIP Server Provisioning Specification work • Assumptions • Use Case Scenarios • Some Protocol Requirements IETF Peppermint BoF

3. Background on the ENUM-SIP Server Provisioning Protocol Work • Motivated by real-world experience from SIP Service Providers (SSPs) engaged in SIP interconnects • Today, a number of providers use email, fax and flat-files to exchange the data they need to share with other SSPs • Basic problem statement • How can back-office systems or peers provision data to addressing servers? • What data model should be used? • Advertise tuples (TN -> NAPTR), (TN Range or prefix-> NAPTR), or, • Abstract or group data elements to allow flexible provisioning operations, updates and maintenance • Main Motivations • To allow peer-dependent views of session routing data, • to allow multiple server vendors to accept provisioning data from multiple data sources using a common protocol, • to define a common and flexible data model for the data elements that may need to be provisioned. IETF Peppermint BoF

4. Assumptions A session routing function or addressing server provides routing service to various SIP entities A resolution query typically contains a sip or tel URI and the requestor wants to know the next SIP hop to send the SIP request to Various elements provision SIP routes - Route to media gateways to the PSTN - Route to a session peers able to terminate this session to SIP UA IETF Peppermint BoF

5. Use Case Scenarios • Separation of Responsibility • network engineering and planning personnel are responsible for establishing points-of-interconnect (at layer 3 for IP internetworking and layer 5 for SBEs) • telephony personnel are responsible for provisioning telephone numbers of newly added subscribers, or location routing numbers (LRNs), or new TN Ranges or prefix, • other personnel or back-office systems are responsible for provisioning other forms of resolvable addresses (email, instant messaging, etc.). => Need ways to structure the data in ways that facilitates operations, dynamic updates and reconfigurations without affecting all records • Real-time operations and File-based Distribution/Bootstrapping • Backward Compatibility to Legacy Switch Translations • As much as we like URIs and sip URIs in particular in IETF, telephony personnel of SIP Service Providers still talk about TN Ranges, Location Routing Numbers and other legacy PSTN constructs like carrier-of-record IETF Peppermint BoF

6. Requirements • High-Level Requirements • To allow peer-dependent views of session routing data, • To allow multiple server vendors to accept provisioning data from multiple data sources using a common protocol, • To define a common and flexible data model for the data elements that may need to be provisioned. • Data Model Requirements • Support both telephony and non-telephony user addresses • Provide means to logically group public identities into “Service Areas” and associate Routes to these groupings • Capable of supporting a large addressing space • Protocol Operations • Add, modify, and delete objects defined in the protocol data model • Query for an instance of each type of object defined in the data model • Multiple clients to provision objects into the same server • Connection-Oriented and File-Oriented Operations • Data Presentation Requirements • Other protocol requirements • Security Requirements • Versioning, Capability Exchange, and Extensibility Requirements IETF Peppermint BoF

7. Thank You.Q&A IETF Peppermint BoF