1 / 8

Data Model and Protocol Requirements for DRINKS

Data Model and Protocol Requirements for DRINKS. IETF 72 - Thursday July 31 2008 Tom Creighton - tom_creighton@cable.comcast.com Jean-François Mulé - jfm@cablelabs.com. Agenda. Quick Update on espp Requirements Drinks Data Model

ronni
Download Presentation

Data Model and Protocol Requirements for DRINKS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Data Model and Protocol Requirements forDRINKS IETF 72 - Thursday July 31 2008 Tom Creighton - tom_creighton@cable.comcast.com Jean-François Mulé - jfm@cablelabs.com IETF DRINKS Working Group

  2. Agenda • Quick Update on espp Requirements • Drinks Data Model • Review of Drafts containing input for the “Lookup Function” Data • Discussion on Location Routing Data • Registry-to-registry vs. registry-to-caches • Protocol Requirements • Next Steps IETF DRINKS Working Group

  3. Requirements for provisioning LUF/LRF caches Changes in draft-mule-peppermint-espp-requirements-01 • Terminology • Used speermint terminology for LUF and LRF • Addressed list comments • LRNs -> RNs, prefixes • Service Areas -> Destination Group • Added requirements for Data Model • Data elements required for the SPEERMINT Lookup Function • Allow the Location Routing Function to dynamically determine the target's SIP server outside the provisioning framework. • See more in document The rest of these slides discuss areas where DRINKS Internet-Drafts converge and open some questions for discussion. IETF DRINKS Working Group

  4. Data Model Requirements from I-Ds (1) Destination Group Or Destination Tag FQDN of SIP Service Provider TN Prefix Or Routing Number Telephone Number Ranges/Blocks User Addresses (Non-TN) Areas where we seem to have some consensus in drafts • Classes • Support for wide variety of “destination addresses” • Telephony and non-telephony user addresses • TN Prefixes of variable lengths, routing numbers, number blocks or ranges • Provide means to logically group destination addresses into “Destination Groups” and associate Domains and/or Routes to these groupings • Class attributes • Object Identifiers and for some, a Name attribute • Validity attribute for some object (Not-Before, Not-After) • Object ownership • For TNs, Dial Code or TN type • Etc. IETF DRINKS Working Group

  5. Data Model Requirements from I-Ds (2) FQDN of SIP Service Provider Host Addresses, priority, service type, etc. NAPTR RR to terminating SSP Destination Group Or Destination Tag Areas where we had more discussions (list, hallway)… • Data Model Support for Location Routing data (LRF data) • FQDN of SIP Service Provider -> SIP server location • Next SIP hop(s) in originating domain/terminating domain in the form of full DNS Resource Records or decomposed list of data elements • LRF Data is part of Session Establishment Data and in scope of drinks • 2 requirements Internet-Drafts propose to include it in provisioning scope • Applicable to bilateral exchanges in particular • Proposal: Make the LRF data objects optional to support in provisioning protocol(s) => allows other dynamic lookups of SIP server location Do not provision LRF data: use other discovery mechanisms a la RFC 3263 IETF DRINKS Working Group

  6. Differences between Registry-to-registry vs. registry-to-caches provisioning • Charter has 2 protocols in scope • Registry to Registry • Registry to server caches • Some data elements may be applicable to both protocols, some may only be suited for one • Examples • Validity of a record • May be more suited for registry • A record pushed to a data cache is just valid and it is removed after the validity period • TN type as proposed by some drafts may be used for TN validation; it may be important for some registries but may not be helpful to propagate down to server caches • Questions • How do we want to develop requirements and more importantly, the associated data model(s) and protocol(s)? IETF DRINKS Working Group

  7. Protocol Requirements Areas where we seem to have no discussions • Protocol Operations • Push/Pull support • Add, modify, and delete objects defined in the protocol data model • Some drafts proposed transfer, ported-in, ported-out, and modify operations • Question: are transfer, ported-in/ported-out operations required? • Question: is a modify operation necessary or can we simply use add to update an attribute value? • Query for an instance of each type of object • Multiple clients to provision objects into the same server • Connection-Oriented and File-Oriented Operations • Comments? • Data Presentation Requirements • Other protocol requirements • Security Requirements • Versioning, Capability Exchange, and Extensibility Requirements IETF DRINKS Working Group

  8. Thank You.Q&A IETF DRINKS Working Group

More Related