170 likes | 256 Views
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?
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]