1 / 17

Introduction

An NSLP for Quality of Service Slides: http://users.skynet.be/besvand1/draft-ietf-nsis-qos-nslp-01-ietf58.ppt. Georgios Karagiannis , Andrew McDonald , Sven V an den Bosch, Attila Bader , Maarten Buchli , Hannes Tschofenig, Robert Hancock Cornelia Kappler, Eric Waegeman , Lars Westberg

kelli
Download Presentation

Introduction

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. An NSLP for Quality of ServiceSlides: http://users.skynet.be/besvand1/draft-ietf-nsis-qos-nslp-01-ietf58.ppt Georgios Karagiannis, Andrew McDonald, Sven Van den Bosch,Attila Bader, Maarten Buchli, Hannes Tschofenig, Robert Hancock Cornelia Kappler, Eric Waegeman, Lars Westberg IETF#58 – Minneapolis November 2003

  2. Introduction • NSIS needs to specify a signalling layer protocol for signalling ‘Quality of Service’ • IETF 57: 3 (independent) individual submissions • draft-buchli-nsis-nslp-00.txtdraft-mcdonald-nsis-qos-nslp-00.txtdraft-westberg-proposal-for-rsvpv2-nslp-00.txt • WG decided to have joint WG QoS NSLP draft • Draft-ietf-nsis-qos-nslp-00.txt • Draft-ietf-nsis-qos-nslp-01.txt

  3. Draft overview • Key Components: • Interchangeable QoS Models • Small set of message types • State changing: RESERVE • Non-state changing: QUERY, RESPONSE, NOTIFY • Draft also: • Gives a basic outline of operation • Gives specific requirements on NTLP functionality

  4. Basic protocol structure • Draft focuses on header and Common Control Information header Common Control Info QoS-model specific Control Info QSpec Policy

  5. Message semantics & types • RESERVE: Messages affecting state installation at NSLP • Reserve, Refresh, Commit, Modify, Tear • QUERY: Message collecting path characteristics • Query • RESPONSE: Message responding to RESERVE or QUERY • Ack, Nack, Query_reply • NOTIFY: Unsolicited NSLP messages • Notify

  6. QSpec vs QoS model • QoS model: Mechanism for providing QoS as a whole • Examples: IntServ, DiffServ, RMD • Local or global • QSpec: Set of parameters and values describing requested resources (for flows with QoS requirements) • Two options: by example or by template (currently proposed) • Open issues • How to document QoS models? • Default QoS model? • How to handle local QoS implementations? • Stack new Qspec at edge of QoS model domain? • RMF Interpretation of QSpec in each QNE? • What if you get an unknown QoS model?

  7. Control Information • Indicates how the message should be handled by QNE • 2 kinds • common CI (useful for many QoS models): one, applies to whole message • ResponseRequest • RSN • QoS-model specific CI (only for QoS model specific stuff): one per QSpec • TTL? • Requestor IP address?

  8. Scoping • Restrict the propagation of messages to QNEs • Downstream: limit QUERY on path-characteristics to “sub”-path • Upstream: avoid propagation of RESPONSE beyond requestor • Not for NOTIFY: independent decision per hop • Scoping is done by introducing Control Information • 'back to me' (RII), 'next hop' and 'whole path‘ seem obvious • Open issues: • Are there others that seem useful? • “as far as my QoS model is supported”, “only in AS x”, “until three hops away” • Are they adequately covered by QoS-model specific CI?

  9. Some NTLP requirements • Support for stateless/reduced state operation: OK • Support for SII • Detecting change of NSLP peer: OK • Explicit routing: not necessarily supported • Should be available over API • Last node detection needs to be made explicit • Performance requirements • Partly addressed by messaging associations (parallel ones can handle signalling message priority) • Fast rerouting discovery (NSLP responsible for new reservation) • API impact: expressed as a hint but may be overruled in some cases

  10. Mailing list issues • Adressed in –01 • RSN versus Session ID • session IDs still need to be present and aren't replaced by RSNs. • how QoS-NSLP could react once it notes that it maintains stale state. • Message types • Why not only RESERVE and RESPONSE? • Clarified figure 1 is not an implementation restriction

  11. Mailing list issues (2) • Left for –0x • Summary refreshes: include which objects? Only previous RSN? • Statemaintenance requirements table • SSM support? • QoS model (example, template) -> see previous slides • Nesting of QoS models • Stacking of Qspecs/CI • Relation to/overlap with tunnel management

  12. Provide comments!

  13. Backup Slides Yet more detail

  14. RESERVE • Unique properties: • Processing it changes signalling application state; in particular authorisation matters more for RESERVE than other messages • Requires associated lifetime • Idempotent: only care about the latest in sequence • Contains: • QSpec object • Flags (Tear bit, New/Old state, …) • Source Identification Information (SII): keeps track of upstream (stateful) neighbour(s) • Locally significant Reservation Sequence Number (RSN): indicates order of state modifying actions • Sent peer-to-peer

  15. QUERY • Gathers information along the data path • Does not change reservation state • Does not cause NSLP state to be installed • Contains ResponseRequest object • May be scoped

  16. RESPONSE • Provides information about the effect/result of a previous QoS-NSLP message • Referenced by Response Identification Info (RII) • Upstream forwarding does not imply existence of reverse path state • Direct passing may be achieved locally by keeping track of Source Identification Info (SII)

  17. NOTIFY • Used to convey information, typically error conditions • Sent asynchronously • Does not refer to installed state • Does not trigger or mandate any action

More Related