160 likes | 168 Views
This document outlines the QSpec template, its processing, applicability, format, security issues, and signaling DiffServ and IntServ with QSpec. It also discusses open issues related to QSpec.
E N D
QSpec Template Draft-qspecteam-nsis-nslp-qspec-00 Jerry Ash, Attila Bader, Chuck Dvorak, Yacine El Mghazli, Cornelia Kappler, Georgios Karagiannis, Andrew Mc Donald, Al Morton, Percy Tarapore, Lars Westberg
Outline • What is the QSpec • Motivation for work on QSpec Template? • How is the QSpec processed? • Applicability • QSpec Format • Security Issues • Signaling DiffServ and IntServ with QSpec • Open Issues
What is the QSpec? • QSpec transported in QoS NSLP messages • Opaque to QoS NSLP • Contains QoS Signaling Model (QSM) specific information • Control Information • QoS Description • QoS Description contains sub-objects for • Traffic characterization (TSpec like) • Description of desired QoS (RSpec like) • Collecting information about resource availability (AdSpec like)
Motivation for work on QSpec Template • Develop QSpec Template in order to • Give guidance for constructing QSMs • Define Generic Parameters • To be used by all QoS Signaling Models if applicable • This way comparison of different QSpecs and QSMs is simplified • May even allow mapping one QSpec / QSM onto the other • Define Optional Parameters • Clarify interfacing QoS NSLP / QSpec • Motivated by IDs on concrete QSMs • draft-ash-nsis-nslp-qos-sig-proof-of-concept-01 • draft-bader-rmd-qos-model-00 • draft-kappler-nsis-qosmodel-controlledload-00
How is the QSpec processed? +---------------+ | Local | |Applications or| |Management (e.g| |for aggregates)| +---------------+ ^ +------------------+ ^ | QSM-specific | V | NSLP Processing | +----------+ +---------+ | | | Resource | | Policy | +------------------+<<<<<<>>>>>>>|Mgmt. Fct.|<<<>>>| Control | | Common NSLP | | | | | | Processing | +----------+ +---------+ | | * ^ +------------------+ * ^ . ^ | * ^ | V . * ^ +----------+ * ^ | NTLP | * ^ |Processing| * V +----------+ * V | | * V ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ . . * V Addition compared to QoS-NSLP Processes QSM Control Information QSM specific entities Processes QSM QoS Description Open issue:Interworking between Common NSLP Processing, QSM specific NSLP Processing and Resource Mgmt Fct.
Applicability • QSpec Template defines generic parameters and optional parameters. • Generic Parameters provide a common language for QSpecs • SHOULD be used for QSpecs if applicable • Definition of parameters similar to the generic ones should be avoided • SHOULD be understood by any QNE • Optional parameters • SHOULD be used for QSpecs if applicable • But QNEs outside a given domain cannot be expected to understand them • QSpecs can define their own, additional parameters • Open issue: • Define minimal subset of generic parameters that MUST be supported? • May be important for interoperability
QSpec Format IOverview • QSpec = <QSM ID> <QSM Control Information> <QoS Description> • QSM ID allows IANA registration of QSpec parameter combinations and identification of known QSMs by Common NSLP Processing • QoS Description and QSM Control Information can contain mutable and immutable parameters • In QoS Description, sub-objects related to TSpec/RSpec/AdSpec from RSVP appear • <mutable QoS Description> = <Resource Availability> • <immutable QoS Description> = <Traffic Characterization>, <QoS Desired>
QSpec Format IIQSM Control Information • Generic Parameters • <TTL> • Mutable • Limits scope of QSpec • (there is a similar scope parameter for QoS NSLP messages) • <QSM unknown> • Mutable • Indicates QSM was not understood by at least one QNE • Open issue • Because generic parameters are defined it may be possible to interpret even an unknown QSM. Do we need this flag? • <Reservation Denied> • Mutable • Indicates unsuccessful reservation at at least one QNE • “uninterpretable QSM” may be “cause code” (alternative to <QSM unknown> ?) • <Service Schedule> • Immutable • Indicates desired start time and end time of reservation • Optional Parameters • E.g. for supporting reduce state (e.g. RMD)
QSpec Format IIIQoS Description • Generic Parameters • Traffic Descriptors • Bandwidth / number of resource units,Token Bucket • QoS Class • DSCP, Y.1541 QoS Class, DS-TE class type • QoS Characterization • Transfer delay, delay variation, packet loss, Bit Error Rate • Excess Treatment • Priority and Reliability • Monitoring Requirements • Optional Parameters • Traffic Descriptors • more complex descriptors, e.g. mutliple token buckets
QSpec Format IVQoS Description / Priority • Generic Parameters • <Setup Priority> • <Holding Priority> • <Reservation Priority> • <Restoration Priority> • Open issue:Where is priority processing located? Is it generic to • NTLP? All NSLPs? QoS NSLP? QSMs? • We believe it is most efficiently processed in the Resource Mgmt Fct. • Therefore we make it a generic QSpec parameter • Making it a generic parameter is a recommendation to implement it in all QSEs
QSpec Format VMapping QoS Description onto sub-object type <Resource <Traffic <QoS Availability> Characterization> Desired> Traffic Descriptors x x x QoS Class x x QoS Charact. x x Excess Treatment x Prio. and Reliability x Service Schedule x Monitoring Requirements x • A QSpec may carry any number of the above sub-objects in any QoS NSLP message • More precise prescriptions / restrictions defined by QoS NSLP and QSMs
Security Issues • QoS NSLP messages may carry a Policy Object • Authorizing QSpec content • Hence specific to QSpec and bound to it • Open issue: • How achieve binding of Policy Object and QSpec? • Policy Object bound to immutable “Traffic Characterization” sub-object? • For binding it to mutable information need to mutate Policy Object as well?
Signaling DiffServ and IntServ with QSpec I • Proof-of-concept test: • Signal Admission Control for DiffServ with <QSpec> = <QSM ID> <QSM unknown?><Reservation denied?> <DSCP><bandwidth> mutable Control Information immutable QoS Description (Traffic Characterization sub-object)
Signaling DiffServ and IntServ with QSpec II • Proof-of-concept test: • Signal IntServ Controlled-Load with <QSpec> = <QSM ID> <QSM unknown?><Reservation denied?> <token bucket><MTU> In what messages the QSpec is used and how QNEs should process it must be fixed in the QSM mutable Control Information immutable QoS Description (Traffic Characterization sub-object)
Open Issues • QSM development guidelines • Clarify relationship of Common NSLP Processing, QSM-specific NSLP Processing and Resource Mgmt. Fct. • Is the QSpec passed to the QSM-specific NSLP Processing first and then to the Resource Mgmt. Fct? • How do QSM-specific NSLP processing and the Resource Mgmt. Fct. influence message processing in common NSLP processing? • Should/can we request that QNEs MUST support a subset of generic parameters? • Is it QSM or QoS Model?
Open Issues • Where is an unknown QSM handled? • Common NSLP processing • e.g. by issuing an error notification) • QSM-specific NSLP processing • e.g. by setting the corresponding flag in the QSM control information? • Note generic parameters contained in an unknown QSM may still be understood by QNEs. Hence it may make sense to process even unknown QSMs. • How is resource sharing handled, respectively, in the common NSLP processing, QSM-specific NSLP processing and resource management function? • Streamline <Service Schedule> QSM control information defined here and the COMMIT flag defined in [QOS-NSLP]