1 QoS-NSLP QSPEC Template draft-ietf-nsis-qspec-05.txt Jerry Ash, Attila Bader, Cornelia Kappler NSIS WG Meeting, Paris, 5th Aug 2005 qupdates to current -05 draft qopen issues

2 Updates to Current -05 QSPEC I-D qComprehensive description of QSPEC Procedures v new: –“RSVP style reservation” –“simple resource queries” vNote: bidirectional reservations are not reflected in the QSPEC vSupported by “QSPEC procedure ID” in QSPEC Control Information

3 Updates to Current -05 QSPEC I-D qSec. 7.2 QSPEC Examples vRemoved example for IntServ QSPECs –Reference Controlled Load QOSM Draft instead (draft-kappler-nsis-qosmodel-controlledload) vGive examples of possible QSPECs for DiffServ admission control –Not to be taken as DiffServ QOSMs qPriority Parameter vBroke out Reservation Priority parameter – = –Avoids defining new namespace for SIP resource priority header (RPH) specification –No change in functionality

4 Updates to Current -05 QSPEC I-D Minor issues qRemoved individual MTU parameter as agreed at Interim Meeting (May 2005) vAssume MTU is discovered by another process (e.g. see Path MTU Discovery (PMTUD) WG) vMTU still part of because this is how it is defined by RSVP –Leave as is? qAdded “Tunneled QSPEC Parameter Flag” vWhen a RESERVE is tunneled, internal QNEs cannot update QSPEC information (e.g. expected Path Latency) vIf the QNE at the tunnel egress cannot update the information on behalf of the tunneled domain it raises the “Tunneled QSPEC Parameter Flag” –One for each optional and mandatory parameter vThis is in addition to the “non-support flag” for optional parameters qDefine 2nd token bucket parameters for more precise traffic description vE.g. for DiffServ vThis is an optional parameter –The “first” token bucket is a mandatory parameter vDifferentiate the two token buckets by parameter IDs

5 Updates to Current -05 QSPEC I-D Minor issues cont’ qQSPEC container vCurrent coding: each QOSM parameter consumes at least 8 Bytes | Object ID | Parameter ID | Length (bytes)|ParameterValues| // Parameter Values // vQSPEC container allows more efficient coding, e.g | Object ID = 0 | Parameter ID | Length = 5 | Para 1 | |Para 2 |S|M| Para 5 |U|B| Para 8 | | vIntended for parameters always used together –Because only container can be identified, not individual parameters –Used for token bucket and RMD QOSM

6 Open Issues in Current -05 QSPEC I-D qReview QSPEC object/parameter formats vHelpful input by Chris Lang (GIMPS implementor) –Will slightly reformat to simplify processing qSpecify how to signal QSPEC-specific errors vSuggestion –Signal protocol errors in QoS NSLP and copy erroneous part into ErrorSpec E.g. unknown parameter ID, incorrect parameter length,… –Signal unsuccessful reservations in QoS NSLP Provide more detailed information (which parameter could not be reserved) in QSPEC as flags => Only add “not reserved” flags to QSPEC parameters and leave all other error information in QoS NSLP qProposal to add H priority encodings vRelated to H.323 legacy signaling protocol vSome support for this on the list vNeed to avoid feature creep vIs there support? …and that’s it!

7 backup

8 Updates to Current -05 QSPEC I-D qSection 7: Section on QSPEC procedures & examples : vFor sender/receiver initiated reservations the following combinations of QSPEC objects are possible –The QSPEC objects inserted in the first message uniquely determine the QSPEC objects to be inserted in subsequent messages The presence of QoS Avail. implies that QoS Desired is negotiable. Also collect path properties. Inform other end of QoS Avail. „RSVP Style“: c. QoS Avail. | QoS Des. | QoS Res. Resource Queries QUERY | RESPONSE QoS Avail. | QoS Avail. Read-only object