1 / 5

cornelia.kappler at siemens

“A QoS Model for Signaling IntServ Controlled-Load Service with NSIS” draft-kappler-nsis-qosmodel-controlledload-01.txt. cornelia.kappler at siemens.com. What is IntServ Controlled-Load Service?. IntServ Controlled Load Service is (in NSIS terms) a QoS Model

ermin
Download Presentation

cornelia.kappler at siemens

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. “A QoS Model for Signaling IntServ Controlled-Load Service with NSIS” draft-kappler-nsis-qosmodel-controlledload-01.txt cornelia.kappler at siemens.com

  2. What is IntServ Controlled-Load Service? • IntServ Controlled Load Service is (in NSIS terms) a QoS Model • RFC 2210 specifies how to signal for Ctrld Load using RSVP • This ID specifies how to signal for Ctrld Load using NSIS • Controlled-Load Service (RFC 2211) • Provides approximately service of an unloaded best-effort network • QoS parameters signaled are Token Bucket and MTU • Implemented per “network element”, i.e. per-router or per-subnet • Can be used for • Reserving resources per-flow per-router • Admission control at edge of DiffServ domains • Admission control into MPLS clouds • What is Controlled Load specific, what is RSVP specific? • Only Controlled Load specifics need to be reflected in this ID • “extra features” compared to RSVP are in green

  3. How to signal for Controlled-Load Service with NSIS • Role of QNEs • One or more QNE per “network element” • Stateless QNEs? • “Provide approximately service of an unloaded best-effort network” may also be possible with stateless QNEs • QoS-model specific Control Information • <QOSM Hops>? • Even if don’t implement Ctrld Load, all QNEs must be able to interpret all parameters • because all parameters for Ctrld Load are mandatory parameters • <Excess Treatment> may be included • QSPEC Procedures • No restriction, i.e. sender-ini, receiver-ini with all combination of QSPEC objects

  4. How to signal for Controlled-Load Service with NSIS • QSPEC objects: <QoS Desired> = <token bucket>, (<QoS Class>) <QoS Available> = (<bandwidth>,<path latency>,<token bucket>, <QoS Class>), <MTU> <Minimum QoS> = <token bucket> OR <MTU>, (<QoS Class>) <QoS Reserved> = <token bucket> • Of these, only <QoS Desired> and <QoS Reserved> will be used in all procedures • E.g. for sender-initiated reservation can use only <QoS Desired> • May include <QoS Class> to provide for DiffServ domains • In QoS Available, <bandwidth><path latency> are there because this is how RSVP does it. Usage unclear • For admission control? • For parameters appearing in QoS Available and/or Minimum QoS can accept downgrade • In all QSPEC objects, additional parameters may be included

  5. How to signal for Controlled-Load Service with NSIS • How to deal with MTU? • In sender-ini procedures, if reservation fails… • E.g. because of too big <M> (Max packet size)? …how can receive meaningful feedback? • When reservation fails only receive feedback up to failure point • Could include lower bound for <M> in <Minimum QoS> to avoid failure of reservation because of MTU problem • <Minimum QoS> is not necessarily supported by all QNEs • Xiaoming: “I would prefer to remove it from IntServ discussion; instead, PMTU discovery or out-of-band MTU information exchange should be another process instead inside QoS signaling itself.”

More Related