1 / 9

QSpec Template

QSpec Template. draft-ietf-nsis-nslp-qspec-01. Jerry Ash, Attila Bader, Chuck Dvorak, Yacine El Mghazli, Cornelia Kappler, Georgios Karagiannis, Andrew Mc Donald, Al Morton, Percy Tarapore, Lars Westberg. Outline. Introduction – What is a QSpec

mills
Download Presentation

QSpec Template

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. QSpec Template draft-ietf-nsis-nslp-qspec-01 Jerry Ash, Attila Bader, Chuck Dvorak, Yacine El Mghazli, Cornelia Kappler, Georgios Karagiannis, Andrew Mc Donald, Al Morton, Percy Tarapore, Lars Westberg

  2. Outline • Introduction – What is a QSpec • Problem: How can we achieve QSpec interoperability between domains?Discussion: • What are generic parameters? • What about optional / QSP-specific parameters? • Motivation for “Initiator QSpec” • How does QNI know what QSP to signal for? • Other, minor open issues • Next Steps

  3. Introduction – What is a QSpec? • QoS NSLP can signal for different QoS Models • IntServ, DiffServ,… • QoS Signaling Policy (QSPs) describe how to use QoS NSLP to signal for a specific QoS Model • Formerly QSPs were called QSM (but this was considered confusing) • QSP specific information transported in QSpec object in QoS NSLP • <QSpec> = <RMF Control Information><QoS Description> • <QoS Description> = <QoS Desired><QoS Available><QoS Reserved><Minimum QoS> • QoS Description contains generic parameters,optional parameters and QSP specific parameters • Generic Parameters are all parameters needed to signal for DiffServ and IntServ QoS Models • E.g. token bucket • “Generic parameters MUST be understood but don’t need to be implemented”

  4. Discussion: What are generic parameters • Generic parameters are restricted to parameters standardized to signal for IntServ and DiffServ QoS Models • Hence only a handful of parameters are generic • “pure DiffServ” only uses DSCPs -> no further need for signaling… • …but augment with admission control as described in RFC 2996 or in draft-bader-nsis-rmd-diffserv-qsm-01 • What does it mean “Generic parameters MUST be understood but don’t need to be implemented”? • A QSP must provide a meaningful mapping of all generic parameters • E.g. DiffServ QSP • May need only <bandwidth><QoS Class>… • Note: DiffServ QSP is not yet defined • …but knows how to map from <token bucket> onto <bandwidth> • E.g. if bandwidth is not signaled, map token bucket peak rate = bandwidth • Should QSpec Template precisely define “meaningful mapping”? • OR: Do we require generic parameters MUST be implemented by all QSPs?

  5. Discussion: What about optional / QSP-specific parameters? • There are more QoS Models besides IntServ and DiffServ • E.g. ITU-T, 3GPP,… • Generic parameters are not sufficient for them • They need different / more parameters • Define in QSpec Template commonly used parameters as “optional parameters” • Only serves to unify coding of these parameters, e.g. Bit Error Rate • Each QSP is free to define additional parameters as “QSP specific parameters” • Note: This does not complicate the protocol for QNEs supporting IntServ/DiffServ QoS Models since they only interpret generic parameters

  6. Discussion:Motivation for “Initiator QSpec” Generic Parameters Optional Parameters QSP ID 1 QSP 1 specific Parameters QSP ID 2 QSP 2 specific Parameters • QNI inserts “Initiator QSpec” which cannot be changed containing • Generic parameters • any subset of generic parameters the QNI considers useful, i.e. “may use” • <token bucket>|<peak bandwidth>|<QoS class><token bucket>|… • Generic parameters are understood everywhere • Optional parameters • One (or two??) sets of QSP-specific parameters • E.g. one for the ingress access (e.g. UMTS) and one for the egress access (e.g. WiMAX) – in case it is a “finicky application” in the QNI that wants to prescribe exactly what should happen • Therefore a QSpec can be parsed even if QSP unknown • Allows some flexibility in what to include in a QSpec • Avoids translation between QSpecs • A domain may do a QSP-specific interpretation of the Initiator QSpec and stack it on top. But must be removed at domain border.

  7. Discussion: How does QNI know what QSP to signal for? • QNI inserts Initiator QSpec typically containing parameters necessary for local QSP / QSP of adjacent domain • Can add more generic / optional parameters if it likes to, in case they are needed in domains downstream • E.g. add <token bucket> to RMD QSP • Should it be possible to query for QSPs supported along the path?

  8. Discussion:Other, minor open issues • Generic parameters for excess treatment? • Service Schedule as optional parameter? • How code <QoS Class> (PHBs, DSCPs,…) • <QSP Hops> / <NonQSP Hops> useful? • Aim for mapping of SIP parameters (bandwidth / codec) to generic parameters? • Only allow discrete set?

  9. Next Steps • Bit-level format of generic parameters • With guidance from RSVP people • Include a worked example • Along the lines of “Toms example”

More Related