90 likes | 170 Views
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
E N D
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 • 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
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”
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?
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
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.
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?
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?
Next Steps • Bit-level format of generic parameters • With guidance from RSVP people • Include a worked example • Along the lines of “Toms example”