1 / 11

DRINKS WG draft-mule-drinks-proto-02 77 th IETF – Anaheim March 24, 2010

Data for Reachability of Inter/tra-NetworK SIP (drinks). DRINKS WG draft-mule-drinks-proto-02 77 th IETF – Anaheim March 24, 2010. S. Ali, K. Cartwright, D. Guyton, A. Mayrhofer, J-F. Mulé. Agenda. Changes in draft-02 Discussion on open issues & list comments LUF-only vs. LUF+LRF

dragon
Download Presentation

DRINKS WG draft-mule-drinks-proto-02 77 th IETF – Anaheim March 24, 2010

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 for Reachability of Inter/tra-NetworK SIP (drinks) DRINKS WGdraft-mule-drinks-proto-0277th IETF – AnaheimMarch 24, 2010 S. Ali, K. Cartwright, D. Guyton, A. Mayrhofer, J-F. Mulé

  2. Agenda • Changes in draft-02 • Discussion on open issues & list comments • LUF-only vs. LUF+LRF • Route Object • Target domain • Protocol operations • PSTN related use cases • Next Steps

  3. Scope of protocol document Session Peering Provisioning Protocol (SPPP) *-------------* 1. Provision SED | | -----------------------> | Registry <--> 3. Registry-to-Registry Session Peering | | Data Exchanges Provisioning Protocol *-------------* / \ / 2.Distribute \ / SED \ V “Distribution V Protocols” +----------+ +----------+ |Local Data| |Local Data| |Repository| |Repository| +----------+ +----------+ SED = Session Establishment Data Terminology used in this presentation is from the Speermint WG (LUF, LRF, SF, SED) See RFC 5486

  4. Other Changes in draft-02 • Added explicit support for LUF-resolution:Target Domain data element • Changed Route Group for LRF-resolution to be independent from resolution protocol • URI • DNS RRs TXT, NAPTR, NS • Removed NAPTR and NS objects • Everything else is pretty much unchanged from draft-01 (see IETF#75 slides for overview)

  5. LUF vs. LUF+LRF Resolutionusing data provisioned via SPPP • List comments that the protocol must accommodate entities that use these types of Registries for • LUF-only resolution: public identifier -> Target Domain • LUF+LRF resolution: public identifier -> Target Domain and Route • Draft-02 provides “simplified views” of the data model for LUF and LUF+LRF • Draft-02 introduces a Target Domain

  6. Target Domain data element • What is it? • FQDN that points to the entity that has a Signaling Function (SF) for the public identifier • It is not a Service Provider ID (PSTN SPID) • Where should it belong in the data model? • Public Identifier, Destination Group or Route Group? • Current choice is Route Group to accommodate responses that can vary based on who asks (source-based LUF or LUF+LRF resolution)

  7. Examples LUF LUF + LRF <?xml version="1.0" encoding="UTF-8"?> <addRteGrpsRqst […] <basicRqst> [… same as on left side] </basicRqst> <rteGrp> <base> [… same as on left side] </base> <rteGrpName>route_grp_1</rteGrpName> <targetDomain>ssp1.example.com</targetDomain> <isInSvc>true</isInSvc> <rteRec xsi:type="NAPTRType" ttl="1000" priority="200"> <order>10</order> <pref>100</pref> <flags>u</flags> <svcs>E2U+sip</svcs> <regx> <ere>^(.*)$</ere> <repl>sip:\1;npdi@sbe34-ssp1.example.com;</repl> </regx> </rteRec> <isInSvc>true</isInSvc> </rteGrp> </addRteGrpsRqst> <?xml version="1.0" encoding="UTF-8"?> <addRteGrpsRqst [… ] <basicRqst> <clientTransId>id-12317123</clientTransId> <minorVer>20</minorVer> </basicRqst> <rteGrp> <base> <rantId>registrantID123</rantId> <rarId>registrarId0</rarId> <activDate>2010-05-04T18:13:51.0Z</activDate> <delDate>2010-05-04T18:13:51.0Z</delDate> </base> <rteGrpName>route_grp_1</rteGrpName> <targetDomain>ssp1.example.com</targetDomain> <isInSvc>true</isInSvc> </rteGrp> </addRteGrpsRqst>

  8. Open Issue: Modify operations • Current document has support for add, delete, and get operations • Modify operations are done via add commands • Idea: the SPPP client does a get to get operation and then an add with modified values • The server does not have to check if an object instance exists, it overwrites things • Comments?

  9. Open issues • Protocol Operations • Do we need to add simple LUF-only provisioning operations? • What other operations (add/get/delete) do we need to add to cover 90% of the needs? • What is core protocol vs. features that can be defined later with Schema extensions? • Activation, Deletion dates? • Data Recipient Groups: design team currently reviewing the value of this concept

  10. Open Issue: PSTN related issues • “Carrier-of-record” • Issue: how to represent in the data model the notion of carrier-of-record or who is authoritative for a public identifier? • “SPID” or Service Provider ID • Some want the LUF query to return a SPID so that this protocol can be used with their existing systems • Local Number Portability Use Cases • A new set of use cases are about to be contributed • Need to address these in the protocol

  11. Next Steps • Stabilize the use cases • Get WG feedback on the basic protocol concepts • Goal • Have a protocol document that addresses use cases in April before interim meeting • Review protocol @ interim and then get a stable version by mid-June

More Related