Next Steps in Signaling C. Kappler Internet-Draft Siemens AG Expires: January 16, 2006 X. Fu Univ. Goettingen July 15, 2005 A QoS Model for Signaling IntServ Controlled-Load Service with NSIS draft-kappler-nsis-qosmodel-controlledload-02 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 BCP 79. 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. This Internet-Draft will expire on January 16, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a QoS Model to signal IntServ controlled load service with QoS NSLP. QoS NSLP is QoS Model agnostic. All QoS Model specific information is carried in an opaque object, the QSPEC. This document hence specifies the QSPEC for controlled load service, how the QSPEC must be processed in QoS NSLP nodes, and how QoS NSLP messages must be used. Kappler & Fu Expires January 16, 2006 [Page 1] Internet-Draft Controlle-Load QOSM July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Signaling with QoS NSLP . . . . . . . . . . . . . . . . . . . 3 2.1 QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 QSPEC . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 QoS Model . . . . . . . . . . . . . . . . . . . . . . . . 5 3. IntServ Controlled Load Service . . . . . . . . . . . . . . . 5 4. NSIS QoS Model for IntServ Controlled Load Service . . . . . . 6 4.1 Role of QNEs . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 QSPEC . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1 Controlled Load Service Requirements . . . . . . . . . 7 4.2.2 QOSM ID . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.3 QSPEC Control Information . . . . . . . . . . . . . . 8 4.2.4 QoS Description . . . . . . . . . . . . . . . . . . . 8 4.3 Usage of QoS-NSLP Messages . . . . . . . . . . . . . . . . 9 5. Processing Rules in QNEs . . . . . . . . . . . . . . . . . . . 10 6. Interoperation with Controlled Load Service Specified in RFC2211 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1 Normative References . . . . . . . . . . . . . . . . . . . 14 9.2 Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 A. Appendix -- QSPEC Format for Controlled Load QOSM . . . . . . 17 B. Changes since 01 . . . . . . . . . . . . . . . . . . . . . . . 19 C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20 Kappler & Fu Expires January 16, 2006 [Page 2] Internet-Draft Controlle-Load QOSM July 2005 1. Introduction The QoS NSIS Signaling Layer Protocol, QoS-NSLP [19] defines how to signal for QoS reservations in the Internet. The protocol is not bound to a specific mechanism for achieving QoS, such as IntServ or DiffServ. Rather, the actual QoS information is carried opaquely in the protocol in a separate object, the QSPEC [19]. A method for achieving QoS a for a traffic flow is called QoS model. It is expected that a number of QoS models will be developed for QoS-NSLP. Examples are [6] and [7] and this draft. The purpose of this document is to describe a QoS model for controlled-load service of IntServ [5]. [10] specifies how to signal for controlled-load service with RSVP. This document describes how to signal for the same service with QoS-NSLP. The controlled-load service is rather minimal both in terms of information that is signaled - basically bandwidth in the form of a token bucket - and in terms of prescribed realization of the service in the network. It is therefore suited for a wide range of realizations, such as reserving resources per-flow per-network node [8], achieving QoS in appropriately engineered DiffServ networks with admission control [16], or across IP tunnels or MPLS Label Switched Paths (LSPs) with reserved bandwidths and admission control [14] [17]. The document is structured as follows: It gives a brief overview of QoS-NSLP and the QSPEC, and the content and features of a QoS model as described in [19] and [4]. It then gives a brief overview of the controlled-load service of IntServ. Subsequently, the actual QoS model for controlled-load service is described. 2. Signaling with QoS NSLP 2.1 QoS NSLP QoS NSLP [19] is an NSIS signaling layer protocol for signaling QoS reservations in the Internet. Together with GIMPS [18], it provides functionality similar to RSVP and extends it, e.g. by supporting both sender-initiated and receiver-initiated reservations. QoS-NSLP however does not support multicast. QoS NSLP establishes and maintains reservation state in QoS-NSLP aware nodes, called QNEs, along the path of a data flow. The number or frequency of QNEs is not prescribed. The node initiating a reservation request is called QNI, the node terminating the request is called QNR. QNI and QNR are also QNEs, and are not necessarily the actual sender and receiver of the data flow they are signaling for as they may also be proxying for them. Kappler & Fu Expires January 16, 2006 [Page 3] Internet-Draft Controlle-Load QOSM July 2005 QoS-NSLP defines four message types, RESERVE, QUERY, RESPONSE and NOTIFY. The message type identifies whether a message manipulates state (e.g. RESERVE) or not (e.g. QUERY, RESPONSE). The RESERVE message is used to create, refresh, modify or remove reservation state in QNEs. The QUERY message is used to request information about the data path without making a reservation. This functionality can be used to 'probe' the path for certain characteristics. The RESPONSE message is used to provide information about the results of a previous RESERVE or QUERY message, e.g. confirmation of a successful reservation, error, or for transferring results of a QUERY back towards the querying node. The NOTIFY message is not important in the context of this memo. 2.2 QSPEC QoS NSLP carries QoS Model specific information encapsulated in an opaque object, the QSPEC [4]. The QSPEC thus fulfills a similar purpose as TSpec, RSpec and AdSpec in RSVP [9]. The QSPEC is not interpreted by the QoS NSLP Processing unit on a QNE, but passed as-is to the Resource Management Function RMF on the same node, where it is interpreted. The QSPEC is structured internally into QSPEC Control Information, and QoS Description. o QSPEC Control Information contains parameters that govern the processing of the resource request in the RMF, e.g. information on excess treatment. o QoS Description is composed of QSPEC objects, namely QoS Desired, QoS Available, QoS Reserved and Minimum QoS. A particular QoS Description typically only contains a subset of these objects. * QoS Desired contains parameters describing the QoS desired by a QNI. * QoS Available contains parameters describing the available resources. In the controlled load service QOSM, this QSPEC object is used to collect information on the available bandwidth along a path. * QoS Reserved describes the actual QoS reserved. * Minimum QoS can be included by a QNI together with QoS Desired to signal a range of QoS (between QoS Desired and Minimum QoS) is acceptable. The QSPEC template [4] defines a number of mandatory and optional Kappler & Fu Expires January 16, 2006 [Page 4] Internet-Draft Controlle-Load QOSM July 2005 QSPEC parameters. Mandatory parameters must be interpreted by each QNE, whereas optional parameters can also be ignored. This ensures some degree of interoperability between QoS Models while at the same time providing extensibility and flexibility. In a given QoS Model, new optional parameters may be defined. The QSPEC usually carries a QoS Model identifier, which identifies what QoS Model is being signaled about. This QoS Model defines what parameters must be included in a given QSPEC. However, the QNI may also include additional parameters, in order to give additional information to QNEs that are not supporting this specific QoS Model. 2.3 QoS Model A QoS-enabled domain supports a particular QoS model (QOSM), which is a method to achieve QoS for a traffic flow, such as IntServ Controlled Load or DiffServ [13]. QoS NSLP is independent of the QOSM, just as RSVP [9] is independent of IntServ. A QOSM hence incorporates QoS provisioning methods and a QoS architecture. It however also defines how to use QoS NSLP. It therefore defines the behavior of the resource management function (RMF), including inputs and outputs, and how QSPEC information on traffic description, resources required, resources available, and control information required by the RMF is interpreted. A QOSM also specifies the QSPEC parameters that describe the QoS and how resources will be managed by the RMF. 3. IntServ Controlled Load Service As specified in [5], the controlled-load service defined for IntServ supports applications which are highly sensitive to overload conditions, e.g. real-time applications. The controlled-load service provides to an application approximately the end-to-end service of an unloaded best-effort network. "Unloaded" thereby is used in the sense of "not heavily loaded or congested" rather than in the sense of "no other network traffic whatsoever". The definition of controlled-load service is intentionally imprecise. It implies a very high percentage of transmitted packets will be successfully delivered to the end nodes. Furthermore, the transit delay experienced by a very high percentage of the delivered packets will not greatly exceed the minimum transmit delay experienced by any successfully delivered packet. In other words, a short disruption of the service is viewed as statistical effect which may occur in normal operation. Events of longer duration are indicative of failure to allocate sufficient resources to the controlled-load flow. In order to ensure that the conditions on controlled-load service are Kappler & Fu Expires January 16, 2006 [Page 5] Internet-Draft Controlle-Load QOSM July 2005 met, clients requesting the service provide network elements on the data path with an estimation of the data traffic they are going to generate. When signaling with RSVP, the object carrying this estimation is called TSpec. In return, the service ensures that in each network element on the data path, resources adequate to process traffic falling within this descriptive envelope will be available to the client. This must be accomplished by admission control. The controlled-load service is implemented per-flow in each network element on the data-path. Thereby, a network element may be an individual node such as a router. However, a network element can also be a subnet, e.g. a DiffServ cloud within a larger IntServ network [16]. In this case, the per-flow traffic description (e.g. carried in the RSVP TSpec) together with the DiffServ Code Point (carried e.g. in the DCLASS object [15] of RSVP) is used for admission control into the DiffServ cloud. The DiffServ cloud must ensure it provides controlled-load service. It is also possible to operate controlled-load service over logical links such as IP tunnels [14] or MPLS LSPs [17]. The per-flow traffic descriptor is in this case used for admission control into the tunnel /LSP. 4. NSIS QoS Model for IntServ Controlled Load Service According to [4], a QOSM SHOULD include the following information: o Role of QNEs in this QOSM: E.g. location, frequency, statefulness etc. o QSPEC Definition: A QOSM SHOULD specify the QSPEC, including QSPEC parameters. Furthermore it needs to explain how mandatory QSPEC parameters not used in this QOSM are mapped onto parameters defined therein. o State Management: It describes how QSPEC info is treated and interpreted in the RMF and QOSM specific processing. E.g. admission control, scheduling, policy control, QoS parameter accumulation (e.g. delay). Operation and Sequence of Events, i.e. what QSPEC procedures to use to signal the QOSM. Message Format and QSPEC objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY. Subsequent sections treat these points one-by-one. 4.1 Role of QNEs Controlled-load service network elements can be individual routers or subnets. I.e. it is not necessary for each network node on the data Kappler & Fu Expires January 16, 2006 [Page 6] Internet-Draft Controlle-Load QOSM July 2005 path to interpret the signaling for the service. Rather, dedicated nodes may interpret signaling information and take on responsibility that the subnet they represent delivers adequate service. In fact, this setting maps nicely onto QoS-NSLP - and the NSIS protocol suite in general. In NSIS, QNEs are just required to be located on the data path. However there are no prescriptions regarding their number or frequency. Hence, in the controlled-load QoS model, there must be (at least) one QNE acting on behalf of every network element. E.g. all ingress routers to a DiffServ cloud could be QNEs, performing admission control. If there is more than one QNE per network element, they must be coordinated among themselves to ensure the network element delivers controlled-load service. Controlled Load QNEs are always stateful. 4.2 QSPEC 4.2.1 Controlled Load Service Requirements The controlled-load service QOSM uses Token_Bucket parameters[4], which consist of a token bucket specification plus a peak rate (p), a minimum policed unit (m) and a maximum packet size (M) to describe a data flow's required resources. The token bucket specification includes a bucket rate r and a bucket depth b. The minimum policed unit m is an integer measured in bytes. All IP datagrams of size less than m are counted against the token bucket as being of size m. For more details, including value ranges of the parameters see [10]. The controlled-load service has no required characterization parameters the QNI needs to be informed about, i.e. current measurement and monitoring information need not be exported by QNEs, although individual implementations may do so if they wish. When using RSVP to signal for controlled-load services, the PATH message collects information on MTU and available bandwidth which is used by the receiver to adapt the reservation parameters in the RESERVE message [10][11]. It is hence related to the signaling for Controlled Load rather than to the Controlled Load Service itself. Indeed, While collecting path MTU can be useful for achieving QoS, it is not considered to be part of QoS signaling or QOSMs [4] in NSIS; rather, an independent path MTU discovery mechanism (e.g., [22]) during the flow setup phase is assumed to provide means to learn about the path MTU. Available bandwidth may be collected if desired and used for controlled load service QOSM. 4.2.2 QOSM ID Later versions of this document will define a QOSM ID. Kappler & Fu Expires January 16, 2006 [Page 7] Internet-Draft Controlle-Load QOSM July 2005 4.2.3 QSPEC Control Information QSPEC Control Information for controlled load service QOSM provides information about QOSM support situation along the path followed by a data flow. In addition, information on Excess Treatment (drop or reshape) MAY be included. In RSVP, when non-IntServ hops are discovered on the path, a flag is raised. Additionally, the number of IntServ hops is counted. This way a sender or receiver can determine whether end-to-end QoS could be achieved. The QSPEC template defines a similar parameter, namely the flag. It is set to 1 if a QNE unaware of Controlled Load Service is encountered on the path from the QNI to the QNR. Discussions: per [4], is just a flag; counting the number of non QOSM hops is currently a function of QoS NSLP. Furthermore, Excess Treatment parameter MAY be included in the control information. Current supported values are "reshape" or "drop" and the default value (if the parameter is not included in the Control Information) is "reshape". This parameter is used for a controlled load service implementation to handle the received data traffic belonging to a controlled load flow which is "non-conformant" to the Token Bucket specification reserved. Traffic is considered "non-conformant" when: over time period T, the amount of data received exceeds rT+b; or data rate of the traffic exceeds the peak rate p; or data packet size is larger than M or the QNE's outgoing link MTU 4.2.4 QoS Description QoS Description can be part or all of the following objects: = = = = Among them, at least and MUST be supported by all controlled load service QOSM implementations. Kappler & Fu Expires January 16, 2006 [Page 8] Internet-Draft Controlle-Load QOSM July 2005 is required for receiver-initiated reservations, and MAY be used in sender-initiated reservations. It is used for gathering available bandwidth information along the path. This information can be used by QNI (or QNR, for receiver-initiated reservations) to make an appropriate reservation thereafter, particularly to re-issue a failed reservation. is optional. It always travels together with . It signifies that the QNI can accept a downgrade of resources for particular parameters in the reservation, down to the value of the respective parameter in . For parameters not appearing in , it cannot accept a downgrade. For controlled load service this means if is included, a downgrade of all token bucket parameters is possible. In all QSPEC objects additional parameters MAY be included, as described in [4]. 4.3 Usage of QoS-NSLP Messages QoS-NSLP allows a variety of message sequences for reserving resources ("QSPEC Procedures"). Particularly, sender-initiated, receiver-initiated and bi-directional messages are possible. E.g., in sender-initiated reservations, a RESERVE is issued by the QNI. If the reservation is successful, the QNR replies with a RESPONSE. If the reservation fails, the QNE at which it failed sends a RESPONSE (QoS NSLP is not quite clear on this). The QSPEC template defines what QSPEC objects are carried in which of these messages, and how they are translated from message-to-message. For each of the message patterns defined in QoS NSLP, a variety of QSPEC object usages is possible. o in the simplest message sequence, sender-initiated reservations, the RESERVE may carry just to indicate the exact QoS it wants, and the corresponding RESPONSE carries solely . This implies either the exact resources described in are reserved, or the reservation fails. o A more advanced QNI would include, in addition to , a QSPEC object, or even a . allows collecting path properties, e.g. currently available bandwidth, and signals that (and how much) less resources than are acceptable. The RESPONSE message carries , and additionally copies the QSPEC Object from RESERVE. This information may be of particular interest if a reservation failed. Note however, that since the QNE failing the reservation sends the RESPONSE, no Kappler & Fu Expires January 16, 2006 [Page 9] Internet-Draft Controlle-Load QOSM July 2005 complete e2e information on e.g. bandwidth can be collected and delivered to the QNI. Generally, it needs to be discussed what is the most efficient way of providing feedback to the QNI for sender-initiated reservations. Note that the initial message triggering the signaling exchange fully determines the sequencing of subsequent messages, and also determines what QSPEC objects will be carried in them. That is, while the QNI has freedom in choosing a particular messaging method, the resulting method is also uniquely determined. The controlled load service parameters can be signaled with any of the message exchanges and QSPEC object combinations defined. Note, in contrast, in RSVP only one type of message exchange is defined (receiver-initiated reservations, and the equivalent of = 0>). However, this is a characteristic of RSVP rather than of the controlled load service. 5. Processing Rules in QNEs Admission Control: For controlled-load service, QNEs are required to perform admission control. All resources important to the operation of the network element must be considered when admitting a request. Common examples of such resources include link bandwidth, router or switch port buffer space, and computational capacity of the packet forwarding engine. It is not prescribed how a QNE determines adequate resources are available. It is however required that they make bandwidth greater than the token rate available to the flow in certain situations in order to account for fluctuations. E.g. statistical methods may be used to determine how much bandwidth is necessary. During the admission control, the controlled-load service Token Bucket parameters MUST be met according to the following rule: a Token Bucket A to be allocated for a flow MUST be "as good or better than" or "greater than or equal to" Token Bucket B (which is carried in the received QoS Description, e.g., QoS_Desired, or Minimum_QoS if available), i.e.,: the token bucket rate r for Token Bucket A is greater than or equal to that of Token Bucket B, and the token bucket depth b for Token Bucket A is greater than or equal to that of Token Bucket B, and Kappler & Fu Expires January 16, 2006 [Page 10] Internet-Draft Controlle-Load QOSM July 2005 the peak rate p for Token Bucket A is greater than or equal to that of Token Bucket B, and the minimum policed unit m for Token Bucket A is less than or equal to that of Token Bucket B, and the maximum packet size M of Token Bucket A is greater than or equal to that of Token Bucket B. Remark: these rules come originally from rules for ordering token buckets in [5]. There are no target values for other parameters, e.g. delay or loss, other than providing a service closely equivalent to that provided to best-effort traffic under lightly loaded conditions. Although path MTU discovery is not necessarily part of the controlled load service QOSM, controlled load service QOSM QNEs must reject a service request (by returning an admission control error) if the maximum packet size M signaled in , resp. in if available, is bigger than the MTU of the segment of the path managed by this QNE. Resource requests for new flows are accepted if capacity is available. Reservation modifications are accepted if the new is strictly smaller than the old one. Otherwise they are treated like new reservations from an admission control perspective. Packet Scheduling and Excess Treatment: A QNE MUST ensure the Token Bucket requirements for any individual flow given at setup time are met locally. That is, traffic MUST obey the rule that over all time periods, the amount of data sent does not exceed rT+b. Packets smaller than m are counted as of size m. A basic requirement for packet scheduling is that the QNE MUST ensure the QoS requirements are met for traffic belonging to flows whose traffic are all conformant. In presence of arriving non-conformant traffic, the QNE MUST behave as follows: the QNE MUST continue to provide the contracted QoS for traffic belonging to flows which are all conformant. the QNE SHOULD prevent excess control load traffic from unfailrly impacting the handling of arriving best-effort traffic. Kappler & Fu Expires January 16, 2006 [Page 11] Internet-Draft Controlle-Load QOSM July 2005 While fulfiling the above two requirements, the QNE MUST attempt to forward the excess traffic on a best-effort basis if sufficient resources are available. Several basic approaches are suggested in [5] and reused here, although other alternatives should be possible, if available. A simple approach is the priority mechanism, namely, to let the QNE to process excess controlled-load traffic at a lower priority than the elastic best-effort traffic, especially when the most controlled-load traffic arises from non-rate-adaptive real-time applications. The second approach is that a QNE can maintain separate flow classes (e.g., one for each non-conformant controlled-load traffic, one for inelastic best-effort flows, and another from elastic best-effort flows), where packet scheduling mechanisms like Fair Queueing or Weight Fair Queueing can be used. One implementation, for instance, could allocate each controlled-load flow a 1/N "fair share" percentage of the available best effort bandwidth for its excess traffic. Finally, Random Early Detection (RED) queueing mechanism may be used. 6. Interoperation with Controlled Load Service Specified in RFC2211 Controlled load service QOSM is intended to be consistent with the RSVP/Controlled Load Service specified in [5], although the used signaling protocols are QoS-NSLP and RSVP, respectively. This section discusses the service and parameter mapping between them needed for service mapping. There are following possible parameter mappings: CLS ADSpec => QoS Available (Available Bandwidth) CLS Sender_TSpec + FlowSpec => Token Bucket(s) for QoS Desired (+optionally Minimum QoS) Note that under Controlled-load QOM, there is no MTU discovery as in RSVP/CLS, where path MTU is a mandatory parameter. This could relief the QNE from being overloaded with the orthogonal task of determining path MTU. The ADSpec to QoS Available mapping is probably the easiest, where available bandwidth information along a path would be determined by RSVP Path or QoS-NSLP Query messages. Kappler & Fu Expires January 16, 2006 [Page 12] Internet-Draft Controlle-Load QOSM July 2005 Other QoS parameters, such as RSVP Sender_TSpec and FlowSpec are connected to the two-pass, receiver-initiated reservation procedure and partially the support for multicast in RSVP. In receiver- initiated reservations using QoS-NSLP, both TSpec and FlowSpec are merged in a single RESERVE message, with the flexibility of choosing between a QoS Desired and a Minimum QoS Token Bucket. The FlowSpec is equivalent to QoS Desired (if Minimum QoS is not present) or a Token Bucket between QoS Desired and Minimum QoS (if Minimum QoS is present), reducing the need for another additional reservation process if failing to satisfy the first FlowSpec. However, the Sender_TSpec does not exist in QoS-NSLP Query messages. 7. Security Considerations This Internet Draft raises no new security issues. 8. Conclusions This document describes a QoS Model to signal IntServ controlled load service with QoS NSLP. Up to now, it was only described how to signal for IntServ controlled load service with RSVP. Since no independent document exists that describes IntServ controlled load by its own, i.e. without RSVP, it is sometimes difficult to determined what features are specific to IntServ controlled load, and which features are specific to RSVP: Is it indeed vital for QNIs signaling for controlled load service to be informed about the number of hops not implementing this QOSM? Since the controlled load QOSM exclusivly relies on mandatory parameters it can be expected that all QNEs can make sense of the reservation, independent of whether they explicitly implement controlled load service or not. Of more interest appears the number of non-QoS-NSLP hops (which is collected in the main message body of QoS NSLP rather than in the QSPEC). The QoS NSLP QOSM for controlled load service allows a variety of message exchanges all eventually resulting in a reservation, e.g. sender-initiated, receiver-initiated and bidirectional signaling. The controlled load service when signaled with RSVP was bound to sender-initiated reservations. When signaling with RSVP, it is not possible to define a range of acceptable QoS. Also this seems to be a charcteristic of RSVP rather than a feature of the controlled load service. RSVP allows discovery of path MTU. Since independent mechanisms area exist to this end, this feature has not been reproduced by the Controlled Load QOSM (and QoS NSLP in general) Kappler & Fu Expires January 16, 2006 [Page 13] Internet-Draft Controlle-Load QOSM July 2005 An issue of general interest discovered here concerns feedback of information in sender-initiated scenarios (In receiver-initiated scenarios it does not occurr because path information is collected before the RESERVE is issued). A QNI may include in several parameters, e.g. bandwidth, which it would like to measure along the data path. If the reservation fails, e.g. because the desired bandwidth was to large, the QNE failing the reservation returns a RESPONSE, including the QSPEC object with accumulated information up to this point. The QNI can learn from this why the reservation failed at this particular QNE. However it cannot be sure a subsequent downgraded RESERVE will be more successful. This is because there may be even more difficult conditions (e.g. even less bandwidth) down the path. That is, in sender-initiated scenarios it is not straightforward to receive feedback from a failed reservation that allows to make a good guess at what size of reservation would be more successful. Of course it would be possible for the QNI to issue a QUERY first to find out about a suitable value for, e.g. maximum packet size. However this adds another round-trip time to the reservation, thereby obsoleting one of the main benefits of sender-initiated reservations compared to receiver-initiated ones. Another issue is that may also include . Is it useful for Controlled Load Service QOSM? In this draft, the feedback problem is solved by including a QSPEC object in sender-initated reservations. This gives some flexibility as it implicitly says the QNI would also accept a downgraded reservation, up to the value specified. When the maximum packet size in is set to a very small value reservations are not going to fail because of the MTU problem. Note however as currently specified in [19], the QSPEC object is not necessarily supported by all QNEs. 9. References 9.1 Normative References [1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004. [2] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002. [3] Chaskar, H., "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC 3583, September 2003. Kappler & Fu Expires January 16, 2006 [Page 14] Internet-Draft Controlle-Load QOSM July 2005 [4] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-05 (work in progress), July 2005. [5] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. 9.2 Informative References [6] Bader, A., "RMD-QOSM - The Resource Management in Diffserv QOS Model", draft-ietf-nsis-rmd-03 (work in progress), July 2005. [7] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in progress), May 2005. [8] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [9] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [10] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [11] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997. [12] Shenker, S. and J. Wroclawski, "Network Element Service Specification Template", RFC 2216, September 1997. [13] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [14] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000. [15] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000. [16] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000. [17] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Kappler & Fu Expires January 16, 2006 [Page 15] Internet-Draft Controlle-Load QOSM July 2005 Switching Architecture", RFC 3031, January 2001. [18] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-06 (work in progress), May 2005. [19] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality- of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in progress), February 2005. [20] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in progress), May 2005. [21] "Path Computation Element (pce) Charter, http://www.ietf.org/html.charters/pce-charter.html", 2005. [22] "Path MTU Discovery (pmtud) Charter, http://www.ietf.org/html.charters/pmtud-charter.html", 2005. [23] "IP Flow Information Export (ipfix) Charter, http://www.ietf.org/html.charters/ipfix-charter.html", 2005. [24] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 5.13.0, January 2005. [25] "NGN QoS Framework and Requirements", DTS/TISPAN-05009-NGN. [26] Lee, S., "Applicability Statement of NSIS Protocols in Mobile Environments", draft-ietf-nsis-applicability-mobility-signaling-01 (work in progress), February 2005. [27] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000. [28] Alfano, F., "Diameter Quality of Service Application", draft-alfano-aaa-qosprot-02 (work in progress), February 2005. [29] Farrel, A., "Path Computation Element (PCE) Architecture", draft-ietf-pce-architecture-00 (work in progress), March 2005. [30] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [31] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Kappler & Fu Expires January 16, 2006 [Page 16] Internet-Draft Controlle-Load QOSM July 2005 Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. [32] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004. Authors' Addresses Cornelia Kappler Siemens AG Siemensdamm 62 13627 Berlin Germany Email: cornelia.kappler@siemens.com Xiaoming Fu University of Goettingen Institute for Informatics Lotzestr. 16-18 Goettingen 37083 Germany Email: fu@cs.uni-goettingen.de Appendix A. Appendix -- QSPEC Format for Controlled Load QOSM This section provides an example format for QSPEC used by controlled load QOSM in a successful sender-initiated reservation. Other scenarios can be easily derived by adapting to the QoS-NSLP signaling procedure and used QoS specifications. Kappler & Fu Expires January 16, 2006 [Page 17] Internet-Draft Controlle-Load QOSM July 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |QOSM_ID= TBD | QSPEC_Lenth = 64| NON QOSM Hop | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Obj_ID=0(ctrl) | Obj_Lenth = 4 | Excess treatm.| (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Obj_ID=1(QoSDe)| Obj_Lenth = 24| (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Obj_ID=2(QoSAv)| Obj_Lenth = 8 | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | available bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Obj_ID=4(MiQoS)| Obj_Lenth = 24| (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 1 An Example QSPEC for sender initiated reservation (RESERVE) Kappler & Fu Expires January 16, 2006 [Page 18] Internet-Draft Controlle-Load QOSM July 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |QOSM_ID= TBD | QSPEC_Lenth = 40| NON QOSM Hop | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Obj_ID=0(ctrl) | Obj_Lenth = 4 | Excess treatm.| (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Obj_ID=3(QoSDe)| Obj_Lenth = 24| (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Obj_ID=2(QoSAv)| Obj_Lenth = 8 | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | available bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 2 An Example QSPEC for sender initiated reservation (RESPONSE) Appendix B. Changes since 01 1. Clarifications about path MTU, scheduling/excess treatment and QOSM Hops. 2. Added a section "Interoperation with RFC2211" and QSPEC format as Appendix. Appendix C. Acknowledgements The author would like to thank Andrew McDonald for fruitful discussions. Kappler & Fu Expires January 16, 2006 [Page 19] Internet-Draft Controlle-Load QOSM July 2005 Intellectual Property Statement 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. 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. 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kappler & Fu Expires January 16, 2006 [Page 20]