NSIS Working Group Attila Bader INTERNET-DRAFT Lars Westberg Ericsson Expires: 24 May 2006 Georgios Karagiannis University of Twente Cornelia Kappler Siemens Tom Phelan Sonus October 24, 2005 RMD-QOSM - The Resource Management in Diffserv QOS Model 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 May 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes an NSIS QoS Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to edge nodes in the RMD network. The RMD Ingress edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress edge nodes for each Bader, et al. [Page 1] INTERNET-DRAFT RMD-QOSM flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the edge nodes. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .3 3. Overview of RMD and RMD-QOSM . . . . . . . . . . . . . .. . .4 3.1 RMD . . . . . . . . . . . . . . . . . . . . . . . . . . .4 3.2 Basic features of RMD-QOSM . . . . . . . . . . . . . . . 6 3.2.1 Role of the QNEs . . . . . . . .. . . . . . . . . .6 3.2.2 RMD-QOSM signaling . . . . . . . . . . . . . . . . 7 4. RMD-QOSM, Detailed Description . . . . . . . . . . . .. . . .8 4.1 RMD-QSpec Definition . . . . . . . . . . . . . . . . . . 8 4.1.1 RMD-QOSM QoS Description . . . . . . . . . . . . .9 4.1.2 PHR RMD-QOSM control information . . . . . . . . . 9 4.1.3 PDR RMD-QOSM control information . . . . . . . . 11 4.1.4 Mapping of QSpec parameters onto generic QSpec Parameters . . . . . . . . . . . . . . . . .12 4.2 Message format . . . . . . . . . . . . . . . . . . . . .13 4.3 RMD node state management . . . . . . . . . . . . . . . 14 4.3.1 Aggregated versus per flow reservations at the QNE edges . . . . . . . . . . . . . . . . . . . . 14 4.3.2 Measurement-based method . . . . . . . . . . . . .15 4.3.3 Reservation-based method . .. . . . . . . . . . . 15 4.4 Transport of RMD-QOSM messages . . . . . . . . . . . . .16 4.5 Edge discovery and addressing of messages . . . . . . . 16 4.6 Operation and sequence of events . . . . . . . . . . . .16 4.6.1 Basic unidirectional operation . . . . . . . . . .17 4.6.1.1 Successful reservation. . . . . . . . . . . .17 4.6.1.2 Unsuccessful reservation . . . . . . . . . . 22 4.6.1.3 RMD refresh reservation. . . . . . . . . . . 24 4.6.1.4 RMD modification of aggregated reservation . 27 4.6.1.5 RMD release procedure. . . . . . . . . . . . 28 4.6.1.6 Severe congestion handling . . . . . . . . .34 4.6.2 Bidirectional operation . . . . . . . . . . . . . 38 4.6.2.1 Successful and unsuccessful reservation . . .39 4.6.2.2 Refresh reservation . . . . . . . . . . . . .43 4.6.2.3 Modification of aggregated reservation . . . 44 4.6.2.4 Release procedure . . . . . . . . . . . . . .45 4.6.2.5 Severe congestion handling . . . . . . . . . 45 4.7 Handling of additional errors . . . . . . . . . . . . . 49 5. Security Consideration. . . . . . . . . . . . . . . . . . . 49 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .53 7. Open issues. . . . . . . . . . . . . . . . . . . . . . . . .53 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .53 Bader, et al. [Page 2] INTERNET-DRAFT RMD-QOSM 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 54 10. Normative References . . . . . . . . . . . . . . . . . . . 55 11. Informative References . . . . . . . . . . . . . . . . . . 55 12. Intellectual Property Rights . . . . . . . . . . . . . . . 57 1. Introduction This document describes a Next Steps In Signaling (NSIS) QoS model for networks that use the Resource Management in Diffserv (RMD) framework ([RMD1], [RMD2], [RMD3]). RMD adds admission control to Diffserv networks and allows nodes external to the networks to dynamically reserve resources within the Diffserv domains. The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP) [QoS-NSLP] specifies a generic model for carrying Quality of Service (QoS) signaling information end-to-end in an IP network. Each network along the end-to-end path is expected to implement a specific QoS Model (QOSM) that interprets the requests and installs the necessary mechanisms, in a manner that is appropriate to the technology in use in the network, to ensure the delivery of the requested QoS. This document specifies an NSIS QoS Model for RMD networks (RMD- QOSM), and an RMD-specific QSpec (RMD-QSPec) for expressing reservations in a suitable form for simple processing by internal nodes. They are used in combination with the QoS-NSLP to provide QoS signaling service in an RMD network. Figure 1 shows an RMD network with the respective entities. Stateless or reduced state Egress Ingress RMD nodes Node Node (Interior Nodes; I-Nodes) (Stateful (Stateful | | | RMD QoS RMD QoS NLSP | | | NSLP Node) Node) V V V +-------+ Data +------+ +------+ +------+ +------+ |-------|--------|------|------|------|-------|------|---->|------| | | Flow | | | | | | | | |Ingress| |I-Node| |I-Node| |I-Node| |Egress| | | | | | | | | | | +-------+ +------+ +------+ +------+ +------+ =================================================> <================================================= Signaling Flow FIGURE 1: Actors in the RMD QOSM Internally to the RMD network, RMD-QOSM defines a scalable QoS signaling model in which per-flow QoS-NSLP and NTLP states are not stored in Interior nodes but per-flow signaling is performed (see [QoS-NSLP]). Bader, et al. [Page 3] INTERNET-DRAFT RMD-QOSM In the RMD-QOSM, only routers at the edges of a Diffserv domain (Ingress and Egress nodes) support the QoS-NSLP stateful operation. Interior nodes support either the QoS-NSLP stateless operation, or a reduced-state operation with coarser granularity than the edge nodes. The remainder of this draft is structured following the suggestions in Appendix B of [QSP-T] for the description of QoS Signaling Policies. After the terminology in Section 2, we give an overview of RMD and the RMD-QOSM in Section 3. In Section 4 we give a detailed description of the RMD-QOSM, including the role of QNEs, the definition of the QSpec, mapping of QSpec generic parameters onto RMD-QOSM parameters, state management in QNEs, and operation and sequence of events. Section 5 discusses security issues. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The terminology defined by GIMPS [GIMPS] and QoS-NSLP [QoS-NSLP] applies to this draft. In addition, the following terms are used: Edge node: an (NSIS-capable) node on the boundary of some administrative domain. Ingress node: An edge node that handles the traffic as it enters the domain. Egress node: An edge node that handles the traffic as it leaves the domain. Interior nodes: the set of (NSIS-capable) nodes which form an administrative domain, excluding the edge nodes. 3. Overview of RMD and RMD-QOSM 3.1. RMD The Differentiated Services (Diffserv) architecture ([RFC2475], [RFC2638]) was introduced as a result of efforts to avoid the scalability and complexity problems of Intserv [RFC1633]. Scalability is achieved by offering services on an aggregate rather than per-flow basis and by forcing as much of the per-flow state as possible to the edges of the network. The service Bader, et al. [Page 4] INTERNET-DRAFT RMD-QOSM differentiation is achieved using the Differentiated Services (DS) field in the IP header and the Per-Hop Behavior (PHB) as the main building blocks. Packets are handled at each node according to the PHB indicated by the DS field in the message header. The Diffserv architecture does not specify any way for devices outside the domain to dynamically reserve resources or receive indications of network resource availability. In practice, service providers rely on subscription-time Service Level Agreements (SLAs) that statically define the parameters of the traffic that will be accepted from a customer. RMD was introduced as a method for dynamic reservation of resources within a Diffserv domain. It describes a method that is able to provide admission control for flows entering the domain and a congestion handling algorithm that is able to terminate flows in case of congestion due to a sudden failure (e.g., link, router) within the domain. In RMD, scalability is achieved by separating a fine-grained reservation mechanism used in the edge nodes of a Diffserv domain from a much simpler reservation mechanism needed in the Interior nodes. In particular, it is assumed that edge nodes support per- flow QoS states in order to provide QoS guarantees for each flow. Interior nodes use only one aggregated reservation state per traffic class or no states at all. In this way it is possible to handle large numbers of flows in the Interior nodes. Furthermore, due to the limited functionality supported by the Interior nodes, this solution allows fast processing of signaling messages. In RMD two basic admission control modes are described: measurement- based and reservation-based admission control. The measurement- based algorithm continuously measures traffic levels and the actual available resources, and admits flows whose resource needs are within what is available at the time of the request. Once an admission decision is made, no record of the decision need be kept. The advantage of measurement-based resource management protocols is that they do not require pre-reservation state or explicit release of the reservations. Moreover, when the user traffic is variable, measurement based admission control could provide higher network utilization than, e.g., peak-rate reservation. However, this can introduce an uncertainty in the availability of the resources. With the reservation-based method, each Interior node maintains only one reservation state per traffic class. The Ingress edge nodes aggregate individual flow requests into classes, and signal changes in the class reservations as necessary. The reservation is quantified in terms of resource units. These resources are requested dynamically per PHB and reserved on demand in all nodes in the communication path from an Ingress node to an Egress node. Bader, et al. [Page 5] INTERNET-DRAFT RMD-QOSM RMD describes the following procedures: * classification of individual resource reservation or resource query into Per Hop Behavior groups (PHB) at the Ingress node of the domain, * hop-by-hop admission control based on per PHB within the domain. There are two possible modes of operation for internal nodes to admit requests. One mode is the stateless or measurement-based mode, where the resources within the domain are queried. Another mode of operation is the reduced-state reservation or reservation based mode, where the resources within the domain are reserved. * a method to forward the original requests across the domain up to the Egress node and beyond. * a congestion control algorithm that notifies the egress edge nodes about congestion. It is able to terminate the appropriate number of flows in case a of congestion due to a sudden failure (e.g., link or router failure) within the domain. 3.2. Basic features of RMD-QOSM 3.2.1 Role of the QNEs The protocol model of the RMD-QOSM is shown in Figure 2. The figure shows QNI and QNR nodes, not part of the RMD network, that are the ultimate initiator and receiver of the QoS reservation requests. It also shows QNE nodes that are the Ingress and Egress nodes in the RMD domain (QNE Ingress and QNE Egress), and QNE nodes that are Interior nodes (QNE Interior). All nodes of the RMD domain are QoS-NSLP aware nodes. Edge nodes store and maintain QoS-NSLP and NTLP states and therefore are stateful nodes. The Interior nodes are NTLP stateless. Furthermore they are either QoS-NSLP stateless (for measurement-based operation), or are reduced state nodes storing per PHB aggregated QoS-NSLP states (for reservation-based operation). Note that the RMD-QOSM domain MAY contain Interior nodes that are not NSIS aware nodes (not shown in the figure). These nodes are assumed to have sufficient capacity for flows that might be admitted. Furthermore, some of these NSIS unaware nodes MAY be used for measuring the traffic congestion level on the data path. These measurements can be used by RMD-QOSM in the congestion control operation (see Section 4.6.1.6). Bader, et al. [Page 6] INTERNET-DRAFT RMD-QOSM |------| |-------| |------| |------| | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | | QoS | | QoS | | QoS | | QoS | | | |-------| |------| |------| | | |-------| |-------| |-------| |------| | | | | | local |<->| local |<->| local |<->| local| | | | | | QoS | | QoS | | QoS | | QoS | | | | | | | | | | | | | | | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | |st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful| | | | | |red.st.| |red.st.| | | | | | | |-------| |-------| |-------| |------| | | |------| |-------| |-------| |-------| |------| |------| ------------------------------------------------------------------ |------| |-------| |-------| |-------| |------| |------| | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP | |st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful| |------| |-------| |-------| |-------| |------| |------| QNI QNE QNE QNE QNE QNR (End) (Ingress) (Interior) (Interior) (Egress) (End) st.ful: stateful, st.less: stateless st.less red.st.: stateless or reduced state Figure 2: Protocol model of stateless/reduced state operation 3.2.2 RMD-QOSM signaling The basic RMD-QOSM signaling is shown in Figure 3. A RESERVE message is created by a QNI with an Initiator QSpec describing the reservation and forwarded along the path towards the QNR. When the original RESERVE message arrives at the Ingress node, an RMD-QSpec is constructed based on the top-most QSPEC in the message (usually the Initiator QSPEC). The RMD-QSpec is sent in a local, independent RESERVE message through the Interior nodes towards the QNR. This local RESERVE message uses the NTLP hop-by-hop datagram signaling mechanism. Meanwhile, the original RESERVE message is sent to the Egress node on the path to the QNR using the reliable transport mode of NTLP. Each QoS NSLP node on the data path processes the local RESERVE message and checks the availability of resources with either the reservation-based or the measurement-based method. When the message reaches the Egress node, and the reservation is successful in each Interior nodes, the original RESERVE message is forwarded to the next domain. When the Egress node receives a RESPONSE message from the downstream end, it is forwarded directly to the Ingress node. If an intermediate node cannot accommodate the new request, it indicates this by marking a single bit in the message, and continues forwarding the message until the Egress node is reached. From the Egress node a RESPONSE message is sent directly the Ingress node. Bader, et al. [Page 7] INTERNET-DRAFT RMD-QOSM QNE QNE QNE QNE Ingress Interior Interior Egress NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | RESERVE | | | | -------->| RESERVE | | | +--------------------------------------------->| | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +------------->| | | | | RESERVE | | | +-------> | | | |RESPONSE | | | |<------- | | | RESPONSE | |<---------------------------------------------+ RESPONSE| | | | <--------| | | | Figure 3: Sender-initiated reservation with Reduced State Interior Nodes As a consequence in the stateless/reduced state domain only sender- initiated reservation can be performed and functions requiring per flow NTLP or QoS-NSLP states, like summary refreshes, cannot be used. One of the basic features of RMD is that, if per flow identification, is needed, i.e. associating the flows IDs for the reserved resources, Edge nodes act on behalf of Interior nodes. 4. RMD-QOSM, Detailed Description This section describes RMD-QOSM in more detail. In particular, it defines the role of stateless and reduced-state QNEs, the RMD-QOSM QSpec Object, the format of RMD-QOSM QoS-NSLP messages and how QSpecs are processed and used in different protocol operations. 4.1. RMD-QSpec Definition The RMD-QOSM QSpec object contains three fields, the "RMD-QOSM QoS Description", the Per Hop Reservation "PHR RMD-QOSM control information" container (PHR container) and the Per Domain Reservation "PDR RMD-QOSM control information" container (PDR container). The "RMD-QOSM QoS Description" field and the PHR container are used and processed by edge and Interior nodes. The PDR container field is Bader, et al. [Page 8] INTERNET-DRAFT RMD-QOSM only processed by edge nodes. The PHR container contains the QoS specific control information for intra-domain communication and reservation. The PDR container contains additional information that is needed for edge-to-edge communication. 4.1.1. RMD-QOSM QoS Description This section describes the parameters used by the "RMD-QOSM QoS Description" field. The RMD-QOSM QoS Description only contains the QoS Desired object [QSP-T]. It does not contain the QoS Available, QoS Reserved or Minimum QoS objects. = = The bit format of the and conform to the bit format specified in [QSP-T] and can be seen in Figure 4 and Figure 5, respectively. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|E|N|T| 3 |r|r|r|r| 1 || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Bandwidth parameter 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|E|N|T| 7 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSCP |0 0 0 0 0 0 0 0 0 0| Reserved | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 5: PHB_Class parameter 4.1.2. PHR RMD-QOSM control information container (PHR container) This section describes the parameters used by the PHR container. = , ,, , ,