1 / 9

updates to current -04 draft open issues for discussion

QoS-NSLP QSPEC Template draft-ietf-nsis-qspec-04.txt Jerry Ash, Attila B á der, Cornelia Kappler NSIS Interim Meeting, Munich 23 May 2005. updates to current -04 draft open issues for discussion. Updates to Current -04 QSPEC I-D.

sadah
Download Presentation

updates to current -04 draft open issues for discussion

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. QoS-NSLP QSPEC Templatedraft-ietf-nsis-qspec-04.txtJerry Ash, Attila Báder,Cornelia KapplerNSIS Interim Meeting, Munich 23 May 2005 • updates to current -04 draft • open issues for discussion

  2. Updates to Current -04 QSPEC I-D • Section 4.3: example of NSLP/QSPEC operation updated to illustrate: • 2 basic cases • the QNI populates <QoS Desired>, <QoS Available>, & <Minimum QoS> • the QNI only populates <QoS Desired> • the 2 cases in a local QOSM domain of either • stacking a local QSPEC in a local QOSM domain • generating a local RESERVE message at the edge • Illustrate mapping of parameters between QOSMs • the 2 cases where the end-device is either static or mobile

  3. Updates to Current -04 QSPEC I-D • Section 4.4.2: explanation of when QSPEC parameters can be read-only and/or read-write in various QSPEC objects • Section 5: • explain that each optional QSPEC parameter has an associated flag to indicate if any QNE along the data path does not support the optional QSPEC parameter • explain the role of the QOSM ID, QSPEC Object ID, Parameter ID

  4. Updates to Current -04 QSPEC I-D • Section 5.1: Defined <QOSM Hops> & <NON QOSM Hop> parameters (were <NSLP Hops> and <NON NSLP Hop> parameters) • Section 6: Added details for each QSPEC parameter: QSPEC object ID, QSPEC parameter ID, length, mandatory/optional status

  5. Updates to Current -04 QSPEC I-D • Section 6.7, 6.8, 6.9: updated <Path Latency>, <Path Jitter>, & <Path BER> parameters to include QNE procedures for setting the optional parameter flag • Section 6.11: Added new optional parameter flags for each optional QSPEC parameter • Section 7: new Section on QSPEC procedures & examples: • explain treatment of QSPEC objects in NSLP messages for sender- and receiver-initiated reservations • explain procedures for setting optional parameter flag • give QOSM & QSPEC examples of DiffServ Admission Control, IntServ Controlled Load Service, IntServ Guaranteed Service (some text moved from old Appendix A)

  6. Updates to Current -04 QSPEC I-D • Section 7: new Section on QSPEC procedures & examples: • For sender/receiver initiated reservations the following combinations of QSPEC objects are possible • “RSVP style” not covered in current -04 version • Makes processing rules for QoS Avail. more complicated (see below) • 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. Read-only object Inform other end of QoS Avail. „RSVP Style“: c. QoS Avail. | QoS Des., QoS Avail. | QoS Res. Resv. fails if QoS avail. changed since QUERY was sent

  7. Open Issues in Current -04 QSPEC I-D • Need explanation of cryptographic procedures for selective protection of read-only QSPEC parameters • Need expert review of QSPEC object/parameter formats • Section 7.1: need to add procedures for bidirectional reservations & resource queries without reservations • Section 7.2.1: need to add procedures on how to use two token buckets (for DiffServ AFxy PHB) to carry the configuration information needed for RFC 2697 and 2698

  8. Common Issues with QOS-NSLP • Stacking more than 2 QSPECs should be allowed or not (is it a QSPEC problem?) • QoS-NSLP issue 34: how are hop counts (counting (non) QOSM hops and (non) QoS NSLP hops) handled when QSPECs are stacked or messages are tunneled? • QoS-NSLP issue 21: TEAR (tear flag or new tear message) • QSPEC perspective: How is the information that it is “tear” passed to the RMF? • QoS-NSLP Issue 25: Handling an unknown QOSM/no resources: • What happens if QNE does not know QSPEC or does not have resources available? • QSPEC perspective:A QNE always knows QSPEC. It may do not know QOSM in the QSPEC. But then it must be able to interpret the generic parameters. If there are no generic parameters, abort the reservation. • RMF or QoS NSLP Processing is responsible for removing a reservation on previous nodes?

  9. Common Issues with QOS-NSLP • QoS-NSLP Issue 30: ERROR_SPEC • co-ordinate definition of ERROR_SPEC values with I-D authors (NTLP, NSLPs, QSPECs). • many codes QSPEC-specific • propose to have a class for QSPEC-specific errors • each QSPEC specification defines its own error codes and meanings • Issue 32: Last node problem (mobility, rerouting) • last node detection could be needed • a node should be able to find out that it has become a (new) last node on a reservation path • need an error messages to identify • then QSPEC does what’s needed • new problems • if QSPEC wants to tear down reservations, need some way to make sure state is only torn down up to the cross-over node • perhaps need to specify timeout BEFORE state is removed to allow possible new branch to be set up

More Related