1 QSpec Template Jerry Ash, Attila Bader, Chuck Dvorak, Yacine El Mghazli, Cornelia Kappler, Georgios Karagiannis, Andrew Mc Donald, Al Morton, Percy Tarapore, Lars Westberg Draft-qspecteam-nsis-nslp-qspec-00

2 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

3 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)

4 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

5 How is the QSpec processed? Addition compared to QoS-NSLP Processes QSM Control Information | 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 Processes QSM QoS Description QSM specific entities Open issue: Interworking between Common NSLP Processing, QSM specific NSLP Processing and Resource Mgmt Fct.

6 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

7 QSpec Format I Overview QSpec = 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 = =,

8 QSpec Format II QSM Control Information Generic Parameters Mutable Limits scope of QSpec (there is a similar scope parameter for QoS NSLP messages) 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? Mutable Indicates unsuccessful reservation at at least one QNE “uninterpretable QSM” may be “cause code” (alternative to ?) Immutable Indicates desired start time and end time of reservation Optional Parameters E.g. for supporting reduce state (e.g. RMD)

9 QSpec Format III QoS 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

10 QSpec Format IV QoS Description / Priority Generic Parameters 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

11 QSpec Format V Mapping 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

12 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?

13 Signaling DiffServ and IntServ with QSpec I Proof-of-concept test: Signal Admission Control for DiffServ with = mutable Control Information immutable QoS Description (Traffic Characterization sub-object)

14 Signaling DiffServ and IntServ with QSpec II Proof-of-concept test: Signal IntServ Controlled-Load with = 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)

15 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?

16 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 QSM control information defined here and the COMMIT flag defined in [QOS-NSLP]