1 / 13

NSLP for Quality of Service

NSLP for Quality of Service. draft-ietf-nsis-qos-nslp- 03 .txt. Sven V an den Bosch (ed) Georgios Karagiannis Andrew McDonald (et al). Changes from –02 version. Addressed comments from early review Added text on receiver-initiated and bi-directional reservations

nicole-morton
Download Presentation

NSLP for Quality of Service

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. NSLP for Quality of Service draft-ietf-nsis-qos-nslp-03.txt Sven Van den Bosch (ed) Georgios Karagiannis Andrew McDonald (et al)

  2. Changes from –02 version • Addressed comments from early review • Added text on receiver-initiated and bi-directional reservations • Extended description of session binding • Added support for fate sharing • Restructured message formats and processing section • Clarified refresh reduction mechanism • Added assumptions on QoS model • Added assumptions on operating environment

  3. Receiver-initiated reservation • Current proposal • Use QUERY to set up reverse path state • Use QUERY to gather path information (OPWA) • Use QUERY to refresh reverse path state • Question 1: Does QUERY need to carry QSPEC? • It is optional in case OPWA is not needed • Question 2: Does QUERY need to carry RESPONSE_REQUEST? • It is not used when QUERY acts as an RSVP PATH message • If ‘no’ on both questions • Do we need a separate (NULL) message for this ‘empty’ QUERY? • Trade-off between QUERY complexity and additional message type • Is the NULL message generally useful across NSLPs? • Question 3: Should GIMPS be responsible for refreshing reverse path state?

  4. Bi-directional reservation • Current situation: two supported mechanisms • Sender-initiated reservation+Receiver-initiated reservation • Two sender-initiated reservations • What happens when following conditions apply • One of the end nodes does not have sufficient information, and • (some part of) the network does not install reverse path state • Question: Do we want to provide a solution for this situation? • Proposed solution: Carry necessary information (opaquely) in forward direction • Bundling of NSLP messages • Provide indication to wait for subsequent NSLP messages before sending?

  5. Session binding (example) • Aggregate reservations • If session B is torn down then session A may be torn down as well but not vice versa QNI QNE QNE QNR End-to-end session = ‘binding session’ SESSION_ID = A End-to-end session = ‘binding session’ SESSION_ID = A BOUND_SESSION_ID = B Aggregate session = ‘bound session’ SESSION_ID = B

  6. Session binding (example) • Bi-directional reservations End-to-end session (XY) SESSION_ID = A BOUND_SESSION_ID = B X QNE QNE Y End-to-end session (YX) SESSION_ID = B BOUND_SESSION_ID = A

  7. Special ‘refresh’ cases • New message with same SESSION_ID and different MRI • Default behaviour: Reservation is replaced • Exception: NO_REPLACE flag set • Enter into resource sharing cases • New message from a bound session • Default behaviour: all binding sessions share fate • Exception: NO_FATE_SHARING flag set • Only end/edge points use fate sharing information

  8. Resource sharing • Current situation • Resource sharing applies to sessions with same SESSION_ID, different MRI and NO_REPLACE flag set • Resource sharing is requested by QoS NSLP processing or RMF; Required information is contained in QSPEC • Question 1: Should it also apply to bound sessions? [Yes] • Question 2: What mathematical operations are useful on two or more reservations? • ADD, SUBTRACT, … • Question 3: Do any of these have impact on QoS NSLP? • If yes, the impact is independent of session binding

  9. Reserve/commit functionality • Alignment needed • QoS NSLP: qualitative (commit flag) • QoS model: quantitative (start/stop timing) • Is this a QoS NSLP issue anyway?

  10. Priority • Mailing list discussion • Reservation priority (preemption) is not a QoSNSLP function (see section 4.5) • Message priority is inscope for the QoS NSLP but relies on GIMPS (see section 7.7) • Question 1: Required number of levels for message priority? • Question 2: Is reservation priority applicable to different NSLPs? Should there be an generic NSLP priority object?

  11. Refresh overhead reduction • Current proposal: • Insert RESPONSE_REQUEST (to confirm state installation) • Refer to reservation with SESSION_ID and RSN • So, still one refreshing RESERVE per reservation • But smaller and possibly easier to process • Question: Should we be able to send a RESERVE without MRI (and only pass MRI over the API)?

  12. Mailing list • Issue on use of SCOPING in RESPONSE • Need to clarify global RII significance versus local RSN significance • Proposed solution • Use SCOPING only in QUERY/RESERVE • make RII a separate object, carried in QUERY/RESERVE and RESPONSE

  13. Next steps • Implement interim meeting outcomes • Complete • Error codes • AAA • Security

More Related