1 / 16

QoS NSLP draft-ietf-nsis-qos-nslp-07.txt

QoS NSLP draft-ietf-nsis-qos-nslp-07.txt. Jukka Manner (ed), Georgios Karagiannis, Andrew McDonald , Sven van den Bosch. Resolved issues. Issue: Should there be an explicit ‘refresh’ indication? E.g. to prioritise existing reservations over new reservations

elam
Télécharger la présentation

QoS NSLP draft-ietf-nsis-qos-nslp-07.txt

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 NSLPdraft-ietf-nsis-qos-nslp-07.txt Jukka Manner (ed), Georgios Karagiannis, Andrew McDonald, Sven van den Bosch

  2. Resolved issues • Issue: Should there be an explicit ‘refresh’ indication? • E.g. to prioritise existing reservations over new reservations • Resolution: No explicit indication added • Main problem is one of policing the indication • Issue: Should there be a separate message for TEAR (instead of flag in a RESERVE message)? • Resolution: Keep it as flag in a RESERVE message • Most of the processing is the same • Issue: What should happen when a ‘tear’ is received for an unknown reservation? • Resolution: Drop the message

  3. Other updates • ‘QoS NSLP’/’RMF’ interactions • Conceptual model in figure 1 shows ‘QoS NSLP’ interacting with ‘NTLP’ and ‘RMF’ • Previous text suggested that the only thing that could pass between ‘QoS NSLP’ and ‘RMF’ was the QSpec • Clarified that the QSpec is not the only information relevant to admission control, policy control, packet classifier setup, etc • However, do not intend to define that interface (no ‘NSLP-RMF API’) • Multiple QSpecs • Previously allowed arbitrary stacking of QSpecs • Now limited to a stack of at most two • One end-to-end and one for local QoS model • Miscellaneous editorial work

  4. Sequence number handling • Includes issues of node failure and restart handling • Discussion thread now on mailing list • Choice between circular and linear sequence space • Current suggestion: circular, wrapping as in RFC1982 • Addition of an epoc identifier

  5. Security • Protocol components for authentication and authorisation • Add further discussion of use of GIMPS GIST channel security • Tokens • Need to work out what to specify • Reuse existing work? • E.g. POLICY_DATA from RSVP • Specify something new? • Leave it for now and specify as a later extension?

  6. Receiver initiation

  7. How do you perform receiver-initiated reservations? • Agree with application peer that it wants QoS reservation • Also an issue with RSVP • Agree with application peer who is going to initiate it • RSVP doesn’t have to worry about this • If receiver is initiating, need to be able to send NTLP messages upstream, so need to establish reverse path state • RSVP does this with PATH messages • Send RESERVE • RESV in RSVP

  8. Alternative approaches? • Roland’s suggestion • Various issues due to end-to-end messages (not hop-by-hop) • GIST upstream query?

  9. Fundamental question • How much do you rely on upper layer protocol interactions in the background?

  10. Packet classifiers • What extra pieces are needed beyond the flow identification information in the MRI? • Which bits of the MRI can be ignored by the packet classifier? • A first attempt included in -07 • Provides flags to indicate which parts of the MRI are to be used for packet classification • Does not address all the issues of the Flow-ID draft • Is the current attempt correct? Is it sufficient? • How far should we go? • Are there fields we should add that we can’t get from the MRI? • However, there are issues of message routing and NAT to consider

  11. Last node issues • Path extension

  12. Last node issues • Path extension

  13. Last node issues • Path extension • Path truncation

  14. Last node issues • Path extension • Path truncation Rerouting description needs expanding

  15. Error handling • Suggestion at Interim: • Share error classes between NSLPs • E.g. Information, Protocol Error • Share error codes between NSLPs • E.g. bad object length, resources not available • Then have NSLP-specific information • E.g. related to NSLP-specific objects or NSLP-specific resource management • How should this be structured? • May have additional information in the QSpec • E.g. indicating which parts of the resource request could not be met (such as bandwidth or delay) • See also John’s draft on extensibility • Where should any codes shared between NSLPs be defined?

  16. Other issues • Hop counts • Formatting of objects and message header • Tunnelling case needs further analysis • See draft-shen-nsis-tunnel-00.txt

More Related