Network Working Group Jerry Ash Internet Draft AT&T Attila Bader Expiration Date: January 2005 Ericsson Cornelia Kappler Siemens AG July 2004 QoS-NSLP QSpec Template Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of RFC 3668. Internet-Drafts are Working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Ash et al. Expires - January 2005 [Page 1] Internet Draft QoS-NSLP QSpec Template July 2004 Abstract This draft describes a QSpec template for the QoS NSIS Signaling Layer Protocol (QoS NSLP) for signaling QoS reservations in the Internet. A QSpec is transported in QoS-NSLP messages and is opaque to QoS NSLP. It contains the QoS Signaling Model (QSM) Control Information and QoS Description parameters. Control Information is, for example, the scope of a particular QSpec. QoS Description parameters are primary input and output parameters of the Resource Management Function. They include descriptions of the QoS desired and the QoS reserved. QoS Description parameters can also be used for collecting information about resource availability along the path and for signaling a range of acceptable QoS. The QSpec template defines generic parameters that are common to many QSMs. Particularly they are derived from the IntServ and DiffServ QoS Models. They should be used by all QSMs if applicable and must be understood by all QNEs. By identifying the generic parameters we aim to ensure interoperability between different QSMs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Processing of QSpec . . . . . . . . . . . . . . . . . . . . . . 5 4. QSpec Template . . . . . . . . . . . . . . . . . . . . . . . . .6 4.1 Applicability . . . . . . . . . . . . . . . . . . . . . . . . .6 4.2 QSpec Format Overview . . . . . . . . . . . . . . . . . . . . .8 4.2.1 QSM Specific Control Information . . . . . . . . . . . . . . 8 4.2.2 QoS Description . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2.1 QoS Desired . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2.2 QoS Available . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2.3 QoS Reserved . . . . . . . . . . . . . . . . . . . . . . .12 4.2.2.4 Minimum QoS . . . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . .13 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . .13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. Intellectual Property Considerations . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .16 Appendix A Example Qspecs . . . . . . . . . . . . . . . . . . . . 17 A.1 QSpec for Admission Control for DiffServ . . . . . . . . . . .17 A.2 QSpec for IntServ Controlled Load Service . . . . . . . . . . 18 A.3 QSpec for IntServ Guaranteed Load Service . . . . . . . . . . 18 Appendix B QoS Models, QoS Signaling Models and QSpecs . . . . . .19 Disclaimer of Validity and Copyright Statement . . . . . . . . . .20 Ash et al. Expires - January 2005 [Page 2] Internet Draft QoS-NSLP QSpec Template July 2004 1. Introduction The QoS NSLP establishes and maintains state at nodes along the path of a data flow for the purpose of providing forwarding resources (QoS) for that flow [QoS-SIG]. The design of QoS NSLP is conceptually similar to RSVP [RSVP], and meets the requirements of [NSIS-REQ]. QoS NSLP can signal for different QoS Models, i.e. QoS provisioning methods or QoS architectures. It should be able to support, for example, IntServ and signaling for DiffServ admission control, and satisfy the need of more complex control planes such as defined in [Q.2630, Y.1541]. The usage of QoS NSLP to signal for a specific QoS Model is called 'QoS Signaling Model'. Examples of different QSMs for NSIS are specified in [TRQ-QoS-SIG, INTSERV-QoS-SIG, RMD- QoS-SIG]. For more information on QoS Models and QSMs see the Appendix. QSM-specific information is carried in the so-called QSpec object, which travels in QoS-NSLP messages. The format of the QSpec object is QSM specific. The QSpec is opaque to QoS NSLP. It contains two types of information: QSM Control Information and a QoS Description. The QSM control information contains information not related to the actual resource management but rather to message processing. An example of QSM control information is the scope of the QSpec. QSM Control Information must not be confused with the Common Control Information, which is a set of objects defined in QoS NSLP. Whereas QSM Control Information is specific to the QSpec, Common Control Information is specific to the QoS NSLP message. The QoS Description can have sub-objects corresponding to the TSpec, RSpec and AdSpec objects specified in RSVP. This is, the QSpec may contain a description of QoS desired and QoS reserved. It can also collect information about available resources. Going beyond RSVP functionality, the QoS Description also allows indicating a range of acceptable QoS by defining a sub-object denoting minimum QoS. Usage of these sub-objects is not bound to particular message types thus allowing for flexibility. An object collecting information about available resources may travel in any QoS NSLP message, for example a QUERY message or a RESERVE message. Ash et al. Expires - January 2005 [Page 3] Internet Draft QoS-NSLP QSpec Template July 2004 This draft provides a template for QSpec, which is needed in order to help defining individual QSMs and in order to promote interoperability between QSMs. The processing of QSpec is described in more detail in Section 2. The proposed QSpec template is given in Section 3, including an applicability statement. Appendix A proposes preliminary QSpecs for the IntServ Controlled Load and Guaranteed Service QoS Models. Appendix B explains in more detail the relation between QoS Models, QSMs and QSpecs. It also explains the current understanding of the content of a QSM. 2. Terminology Common NSLP Processing: Functions in a QNE that are related to NSLP message processing (common for each QoS model) Generic Parameter: Parameter that MUST be understood by any QNE, and SHOULD be used if applicable Immutable Parameter: Parameter that is set by initiating or responding QNE and is not changed during the processing of QSpec along the path Minimum QoS: Minimum QoS is a functionality that MAY be supported by any QSM: Together with a description of desired QoS, it allows the QNI to specify a QoS range, i.e. an upper and lower bound. If the desired QoS is not available, QNFs are going to decrease the reservation until the minimum QoS is hit. Mutable Parameter: Parameter that can be changed during the processing of QSpec by any QNE along the path Optional Parameter: Parameter that SHOULD be used by QSMs if applicable QoS Description: Container of the QSpec sub-objects, which describes QoS. These parameters are input or output parameters of Resource Management Function QoS Available: Parameters describing the available resources. They are used to collect information along a reservation path. QoS Desired: The description of the desired QoS and/or the traffic for which the sender request reservation. Ash et al. Expires - January 2005 [Page 4] Internet Draft QoS-NSLP QSpec Template July 2004 QoS Model: A methodology to achieve QoS for a traffic flow, e.g. IntServ Controlled Load. QoS Reserved: Describes the reserved resources and related QoS parameters (e.g. Slack Term) QoS Signaling Model (QSM): A signaling model describing how to use QoS NSLP to signal for a specific QoS Model QSM Control Information: Control information that is specific to QSM, and processed in QSM-specific NSLP Processing. QSM-specific NSLP Processing: Functions in a QNE that process QSM Control Information and are specific to each QoS Model. QSpec: QSpec is the object of QoS-NSLP containing all QoS Model specific information. (QSpec) parameter: any parameter appearing in a QSpec, e.g. scope of QSpec or token bucket. QSpec sub-object: Main building blocks of QoS Description containing a parameter set that is input or output of a Resource Management Function operation. Resource Management Function: Functions that are related to resource management, specific to a QoS Model. It processes QoS Description. 3. Processing of QSpec The model of QoS-NSLP message processing is illustrated in Figure 1. A QoS-NSLP message is interpreted in the common NSLP processing of a QNE as described in [QOS-SIG]. The QSpec, however, is opaque to QoS- NSLP, which means that it is not processed in the common NSLP processing but handed over to the QSM-specific NSLP processing and then to the Resource Management Function (RMF). The QSM control information is interpreted and perhaps modified by the QSM-specific NSLP processing, and the QoS description is interpreted and may be modified by the resource management function. Both, QSM-specific NSLP processing and the RMF, may advise the common NSLP processing on how to proceed with the signaling, e.g. to tear down a preempted reservation. From an implementation point of view, the common NSLP processing is the same in each NSIS capable router, whereas QSM- specific NSLP processing and the RMF are QSM specific. Note that the QSM-specific NSLP processing box is an addition to the QoS-NSLP processing model of [QoS-SIG] suggested in this document. Ash et al. Expires - January 2005 [Page 5] Internet Draft QoS-NSLP QSpec Template July 2004 +---------------+ | Local | |Applications or| |Management (e.g| |for aggregates)| +---------------+ ^ ^ V +-------------+ +------------+----------+ +---------+ |Common NSLP | |QSM-specific| Resource | | Policy | | Processing +<<>>>| NSLP |Mgmt. Fct.|<<>| Control | | | | Processing | | | | +-------------+ +------------+----------+ +---------+ . ^ | * ^ | V . * ^ +----------+ * ^ | GIMPS | * ^ |Processing| * V +----------+ * V | | * V +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ . . * V | | * ............................. . . * . Traffic Control . | | * . +---------+. . . * . |Admission|. | | * . | Control |. +----------+ +------------+ . +---------+. -| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | Packet | | Interface | .+----------+ +---------+ =>|Processing|====| Selection |===.| Packet |====| Packet |.=> | | |(Forwarding)| .|Classifier| Scheduler|. +----------+ +------------+ .+----------+ +---------+. Figure 1. Model of QoS-NSLP Processing in a QNE 4. QSpec Template 4.1. Applicability The QSpec template defines a format for the QSpec, as well as a number of generic and optional QSpec parameters. Generic parameters provide a common language for QSM developers to build their QSpecs and are likely to be re-used in several QSMs. Ash et al. Expires - January 2005 [Page 6] Internet Draft QoS-NSLP QSpec Template July 2004 This eases comparing different QSpecs and different QSMs - and possibly simplifies mapping of one into another. Thus developers should avoid defining parameters similar to the generic, standardized ones. All parameters used in DiffServ and IntServ QSMs are generic parameters. A specific QSM may, however, only use a subset or perhaps none of the generic QSpec parameters. For instance, it may only allow the token bucket to be specified. Furthermore, a QSM may define additional parameters. All QNEs must be able to understand the generic parameters. It is important to note this does not imply they must also implement all generic parameters (e.g. token bucket). However they must be able to provide a meaningful mapping to locally used parameters. Hence, to summarize, generic parameters SHOULD be used by QSMs if applicable. Generic parameters MUST be understood by any QNE. QNEs do not need to implement generic parameters. They MUST however be able to provide a meaningful mapping from generic parameters onto local parameters. If they translate generic parameters into local ones they must raise an appropriate flag (tbd). Optional parameters SHOULD be used by QSMs if applicable, and defining optional parameters facilitates interworking. However, QNEs outside the domain employing a particular QSM cannot be expected to understand the optional parameters. A QSpec is specific to a QSM and is identified by a QSM ID carried in QoS NSLP. However, as explained above, the generic parameters contained in a QSpec are understood by any QNE, even if the corresponding QSM is not known. Therefore a QNE SHOULD interpret the generic parameters contained in a QSpec, even if it does not understand the QSM. QoS NSLP provides appropriate error codes to attach to the QSpec which indicate such a translation took place. Hence, generic parameters ease global intelligibility of QoS NSLP messages. It needs to be investigated whether a minimal set of generic QSpec parameters MUST even be implemented in any QNE: this may be important for true interoperability of QSMs. The set of QSpec parameters that MUST be supported could be a subset of the generic ones defined here. This version of the QSpec Template Draft only defines generic parameters. Examples for optional parameters will be provided in the future. Ash et al. Expires - January 2005 [Page 7] Internet Draft QoS-NSLP QSpec Template July 2004 4.2. QSpec Format Overview QSpec = As described above, the QSpec object contains the actual resource description (QoS description) as well as QSM control information. Both QoS description and QSM control information may contain mutable and immutable parameters. Mutable parameters can be changed by any QNE, including by QoS NSIS functions along the signaling path, whereas immutable parameters are fixed by the initiating QNE and/or responding QNEs. An example of a mutable parameter is the path's MTU, an example of an immutable parameter is a token bucket describing the traffic to be sent. 4.2.1. QSM Specific Control Information QSM specific control information is used for QSpec-specific control information and for specific signaling functions not defined in QoS- NSLP. It enables building a new signaling model within a QoS-NSLP signaling framework, see for example [RMD-QoS-SIG] and [RMD-QSM]. Generic parameters: - mutable hop count field, limiting the scope of QSpec to a maximum number of QoS-NSLP hops. must not be confused with the scope of the QoS NSLP message carrying the QSpec. This scope would be coded in the Common Control Information. - = , | immutable parameter, indicating the desired start time and end time of the service, i.e. when is the service available. The values for and respectively can be infinity, in which case the reservation can be ended by the usual tearing RESERVE. The Service Schedule parameter has two-fold use: a. Reservation of resources for the immediate future when the full flow ID (e.g. port number) is still being negotiated. In this time is set to zero. Ash et al. Expires - January 2005 [Page 8] Internet Draft QoS-NSLP QSpec Template July 2004 b. Scheduling of reservations ahead of time to make sure resources will be available. An example is reservation of resources for a video-conference. Also in this case the full flow ID may not be known at the time of reservation. Hence, in both cases the QNI sends an incomplete RESERVE prompting the Resource Management Function to set aside resources without actually configuring the router(s). Router configuration is triggered by a RESERVE containing the full flow ID. Appropriate security measures need to be taken to prevent Denial of Service abuse of this functionality (tbd). It needs to be considered whether Service Schedule should be an optional parameter because supporting it involves some overhead: the RMF needs functionality to set aside resources in advance and configure the router(s) later. Furthermore, for large advance reservations, it may be necessary to "phase out" ongoing reservations much earlier than the actual reservation in order to make sure resources will be available. Note that even reservations that are "scheduled" need to be refreshed just as ongoing reservations. Refresh periods are specific to a particular state in a particular QNE [QoS-SIG]. Hence it is conceivable that QNEs decide locally to make the refresh period for scheduled reservations considerably longer than that for ongoing reservations. - Flag indicating unsuccessful reservation in stateless/reduced state QNEs Since in case of stateless/reduced state QoS-NSLP operation interior nodes do not store per flow information edge nodes should be notified about unsuccessful reservation, see further specification in [RMD-QSM]. - Flag indicating severe congestion in stateless/reduced state QNEs Similarly to unsuccessful reservation, in case of sever congestion this flag may be set in refresh messages. Note that severe congestion notification can be done also by data remarking, see more details in [RMD-QSM]. Note that stateless/reduced state operation mode is used in some DiffServ based QoS signaling models, see for example [RMD-QSM]. These control fields are needed because interior routers do not store per flow QoS-NSLP states and they are used for notifying edge. Ash et al. Expires - January 2005 [Page 9] Internet Draft QoS-NSLP QSpec Template July 2004 4.2.2 QoS Description The QoS Description objects are broken down into the following categories: = On the QSpec template level, the only restriction on object usage is that should always travel together with and/or . Otherwise there is no restriction on how many of these sub-objects a QSpec may carry, nor what type of sub-object is carried in what type of QoS NSLP message. For example, in a receiver-initiated reservation scenario, the initiating QNE may send a QUERY carrying a sub- object to probe the available resources on the path. The same QUERY may carry a sub-object. The responding QNE can re-use the latter objects in the RESERVE message. The QoS NSLP and particularly the QSMs prescribe how the sub-objects in QSpecs are interpreted and used, and therefore restrict this freedom. The union of all the sub-objects identified in this Section can provide all functionality of the objects specified in RSVP IntServ, however it is difficult to provide an exact mapping. In RSVP, the Sender TSpec specifies the traffic an application is going to send (e.g. token bucket). The AdSpec can collect path characteristics (e.g. delay). Both are issued by the sender. The receiver sends the FlowSpec which includes a Receiver TSpec describing the resources reserved using the same parameters as the Sender TSpec, as well as a RSpec which provides additional IntServ QoS Model specific parameters, e.g. Rate and Slack. The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver- initiated signaling employed by RSVP, and the IntServ QoS Model. E.g. to the knowledge of the authors it is not possible for the sender to specify a desired maximum delay except implicitly and mutably by seeding the AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in the receiver-issued RSVP RESERVE message. For this reason our debate at this point let us to a slightly different mapping of necessary functionality to sub-objects, which should result in more flexible signaling models. Particularly, we settled for defining a "QoS Desired" rather than a "Traffic Specification". QoS Desired may in fact just be a description of traffic to be sent, but it may also include more Ash et al. Expires - January 2005 [Page 10] Internet Draft QoS-NSLP QSpec Template July 2004 parameters (e.g. delay) or signal for resources than those derived from an exact traffic description (e.g. a token bucket with a higher peak rate). Furthermore we consider to allow all sub-objects carrying the same parameter types (to be detailed in future versions of this draft). Hence, a QNI could send a RESERVE with QoS Desired containing a particular average bandwidth, and at the same time include a QoS Available sub-object for querying availability of this same parameter. If QoS Desired cannot be reserved, the QNR can use the information collected in QoS Available along the path to signal back to the QNI a more promising value of QoS Desired. The details of such message exchanges need to be fixed elsewhere. 4.2.2.1 = These parameters describe the traffic the QNI is going to inject into the reservation and hence it is immutable. = reserved rate desired =

as defined in [RFC 2210] = An application may like to reserve resources for packets with a particular QoS class, e.g. a DiffServ per-hop behavior (PHB) [DIFFSERV], or DiffServ-enabled traffic engineering (DS-TE) class type [DS-TE]. = Reservation priority is an essential way to differentiate flows for emergency services, ETS, E911, etc., and assign them a higher priority than normal priority flows. Appropriate security measures need to be taken to prevent abuse of this parameter. These are immutable parameters. There has been some debate whether such priority parameters should be generic to all NSLPs, generic to QoS-NSLP, or generic to QSMs, that is, where they should be defined. It is beyond the scope of this document whether the priorities defined here are also useful in other NSLPs. However, we believe in the context of QoS-NSLP that priority is best placed in the QSM and QSpec. The reason is that the Ash et al. Expires - January 2005 [Page 11] Internet Draft QoS-NSLP QSpec Template July 2004 resource management function seems to function more efficiently if priority state is held there rather than in common QoS-NSLP processing of messages (see Figure 1). Only the resource management function knows that resources are not sufficient and that it may be necessary to preempt a reservation. If preemption state was associated with QoS-NSLP state rather than with resource management state, the resource management function would need to negotiate with the common QoS-NSLP processing until the two work out what reservation to preempt. Note that although we locate priority parameters with the QSM, the fact that we make them generic parameters could be seen as a recommendation to implement them in all QNEs (see discussion above). Note that QoS Desired may carry parameters like desired delay or loss parameters, however these are optional parameters and not specified in this document. 4.2.3.2 = These parameters describe the resources currently available on the path and are defined in [RFC 2210, 2212, 2215]. Each QNE must inspect this object. If resources available to this QNE are less than what says currently, the QNE must adapt it accordingly. Hence when the message arrives at the recipient of the message, reflects the bottleneck of the resources currently available on a path. It can be used in a QUERY message, for example, to collect the available resources along a data path. 4.2.3.3 = These parameters describe the QoS reserved by the QNEs down the path. are defined in Sec. 4.2.2.1 above. are defined in [RFC 2212]. These are mutable parameters. 4.2.3.4 = Ash et al. Expires - January 2005 [Page 12] Internet Draft QoS-NSLP QSpec Template July 2004 doesn't have an equivalent in RSVP. It allows the QNI to define a range of acceptable QoS levels by including both the desired QoS value and the minimum acceptable QoS in the same message. The desired QoS is included with a and/or a subobject seeded to the desired QoS value. The minimum acceptable QoS value is coded in the subobject. As the message travels towards the QNR, is updated by QNEs on the path. If its value drops below the value of the reservation failed and can be aborted. When this method is employed it is important that the QNR signals back to the QNI the value attained in the end, because the reservation may need to be adapted accordingly. 5. Security Considerations The Service Schedule and Priority parameters raise possibilities for Denial of Service Attacks. How to deal with this will be handled in future versions of this draft. 6. Open Issues a. A detailed discussion of QSM development guidelines needs to be provided. b. A more detailed specification of the generic parameters needs to be given. c. The relationship of common NSLP processing, QSM-specific NSLP processing and resource management function, as well as how their tasks differ needs, to be described more clearly. For example, how do QSM-specific NSLP processing and the RMF influence message processing in common NSLP processing? d. Should/can we request that QNEs MUST implement a subset of generic parameters? e. May a node compose a QSpec containing more parameters than defined in the QSM it is signaling for, e.g. for later use by other nodes? f. The following optional parameters have been proposed to support other QSMs, and need to be discussed for inclusion in the next revisions of the draft: Ash et al. Expires - January 2005 [Page 13] Internet Draft QoS-NSLP QSpec Template July 2004 i) adding the individual parameters: , , , and to all of the QoS Description categories: ii) Generalize the priority parameter as follows: = Where and are as specified in RFC 3209. g. Do we need an explicit Traffic Specification, or is a that may not exactly describe the issued traffic acceptable? h. Should Service Schedule be an optional parameter because of the overhead it may introduce? 7. Acknowledgements The authors would like to thank Robert Hancock and Sven van den Bosch for their helpful suggestions. 8. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Ash et al. Expires - January 2005 [Page 14] Internet Draft QoS-NSLP QSpec Template July 2004 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 9. References [DIFFSERV] S. Blake et. al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [DS-TE] F. Le Faucheur et. al., Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, July 2003 [KEY] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [INTSERV] B. Braden et. al., "Integrated Services in the Internet Architecture: an Overview," RFC 1633, June 1994. [INTSERV-QoS-SIG] C. Kappler, "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS," work in progress. [NSIS-REQ] M. Brunner et. al., "Requirements for QoS Signaling Protocols", work in progress. [RFC2211] J. Wroclawski, "Specification of the Controlled-Load Network Element Service", RFC 2211, Sept. 1997. [RFC2212} Shenker, S., et. al., "Specification of Guaranteed Quality of Service," September 1997. [RFC2215] S. Shenker and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, Sept. 1997. [RMD-QoS-SIG] A. Bader et. al., "RMD (Resource Management in Diffserv) QoS-NSLP model", work in progress. [RMD-QSM] A. Bader, L. Westberg, G. Karagiannis, C. Kappler and T. Phelan, "Resource Management for DiffServ QoS Signaling Model" , work in progress. [RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification," RFC 2205, September 1997. [RSVP-INTSERV] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [TRQ-QoS-SIG] J. Ash et. al., "NSIS Network Service Layer Protocol QoS Signaling Proof-of-Concept," work in progress. [QoS-SIG] S. Van den Bosch et. al., "NSLP for Quality-of-Service Signaling," work in progress. [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services," May 2002. [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling Protocol - Capability Set 3" Sep. 2003 Ash et al. Expires - January 2005 [Page 15] Internet Draft QoS-NSLP QSpec Template July 2004 10. Authors' Addresses Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-4578 Fax: +1-(732)-368-8659 Email: gash@att.com Attila Bader Traffic Lab Ericsson Research Ericsson Hungary Ltd. Laborc u. 1 H-1037 Budapest Hungary EMail: Attila.Bader@ericsson.com Chuck Dvorak AT&T Room 2A37 180 Park Avenue, Building 2 Florham Park, NJ 07932 Phone: + 1 973-236-6700 Fax:+1 973-236-7453 E-mail: cdvorak@att.com Yacine El Mghazli Alcatel Route de Nozay 91460 Marcoussis cedex FRANCE Phone: +33 1 69 63 41 87 Email: yacine.el_mghazli@alcatel.fr Cornelia Kappler Siemens AG Siemensdamm 62 Berlin 13627 Germany Email: cornelia.kappler@siemens.com Georgios Karagiannis University of Twente Ash et al. Expires - January 2005 [Page 16] Internet Draft QoS-NSLP QSpec Template July 2004 P.O. BOX 217 7500 AE Enschede The Netherlands EMail: g.karagiannis@ewi.utwente.nl Andrew McDonald Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK EMail: andrew.mcdonald@roke.co.uk Al Morton AT&T Room D3-3C06 200 S. Laurel Avenue Middletown, NJ 07748 Phone: + 1 732 420-1571 Fax: +.1 732 368-1192 E-mail: acmorton@att.com Percy Tarapore AT&T Room D1-3D33 200 S. Laurel Avenue Middletown, NJ 07748 Phone: + 1 732 420-4172 E-mail: tarapore@.att.com Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm, Sweden EMail: Lars.Westberg@ericsson.com Appendix A: Example QSpecs Note the mere definition of QSpecs is not sufficient for determining how to signal for DiffServ and IntServ respectively. Rather, the full QSM needs to be defined. A.1 QSpec for Admission Control for DiffServ QSpec for Diffserv QSM in general may be provided in future versions of this draft. A QSpec for a DiffServ QSM, RMD is partically included in [RMD-QSM]. Ash et al. Expires - January 2005 [Page 17] Internet Draft QoS-NSLP QSpec Template July 2004 A.2 QSpec for IntServ Controlled Load Service The QoS Model for IntServ Controlled Load is defined in [RFC2211]. The QSpec can be derived from usage of RSVP to signal for this QoS Model, as defined in [RSVP-INTSERV] and [RFC2215]. The QSpec for IntServ Controlled Load is composed of the subobjects and , as well as . Which sub-object is present in a particular QSpec depends on the message type (RESERVE, QUERY etc) in which the QSpec travels. Details must be provided in a corresponding QSM. Parameters in the QSpec are as follows: = = = A.3 QSpec for IntServ Guaranteed Services The QoS Model is defined in [RFC 2212]. The required parameters to achieve guarantied service with RSVP are specified in [RFC 2210] and [RFC 2215]. The QSpec for guarantied services is the following: = = This sub-object contains token bucket parameters defined in [RFC 2210]. Equivalent to TSpec defined in RSVP. = These parameters are defined in [RFC 2212] and [RFC 2215]. This sub- object is equivalent to AdSpec of RSVP. = Requested Rate and Slack Term defined in [RFC 2212], equivalent to RSpec of RSVP. Note that the Guarantied Services QoS Model only works with receiver initiated reservation signaling, because and are derived Ash et al. Expires - January 2005 [Page 18] Internet Draft QoS-NSLP QSpec Template July 2004 from parameters contained in , and may be updated on the return paths. Appendix B: QoS Models, QoS Signaling Models and QSpecs This section gives a description of QoS models, QSMs and QSpecs and explains what is the relation between them. Once these descriptions are contained in a stable form in the appropriate IDs this Appendix will be removed. QoS NSLP is a generic QoS Signaling Protocol that can signal for many QoS Models. A QoS Model is a particular QoS provisioning method or QoS architecture such a IntServ Controlled Load, Guaranteed Service. DiffServ, or RMD for DiffServ. The definition of the QoS Model is independent from the definition of QoS NSLP. Existing QoS Models do not specify how to use QoS NSLP to signal for them. Therefore, we need to define the QoS Signaling Models (QSMs), specific to each QoS Model, which describes the QoS Model specific signaling functions. QoS Signaling Model are defined for "Resource Management in DiffServ" in [RMD-QSM] and for IntServ Controlled Load in [INTSERV-QoS-SIG]. A QSM should include the following information: - Role of QNEs in this QoS Model: E.g. location, frequency, statefulness... - QSpec Definition: A QSM should specify the QSpec, including generic and optional parameters. Furthermore it needs to explain how generic parameters not used in this QSM are mapped onto parameters defined therein. - Message Format Objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY - State Management It describes how QSpec info is treated and interpreted in the Resource Management Function and QSM specific processing. E.g. admission control, scheduling, policy control, QoS parameter accumulation (e.g. delay)à - Operation and Sequence of Events Usage of QoS-NSLP messages to signal the QoS model. Ash et al. Expires - January 2005 [Page 19] Internet Draft QoS-NSLP QSpec Template July 2004 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Ash et al. Expires - January 2005 [Page 20]