NSIS Working Group Attila Bader INTERNET-DRAFT Lars Westberg Ericsson Expires: May 2005 Georgios Karagiannis University of Twente Cornelia Kappler Siemens Tom Phelan Sonus November 15, 2004 RMD-QSP: An NSIS QoS Signaling Policy for Networks Using Resource Management in Diffserv (RMD) 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html" Abstract This document describes an NSIS QoS Signaling Policy 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. RMD complements the Diffserv architecture by pushing complex classification, conditioning and admission control functions to the edges of a Diffserv domain and simplifying the operation of internal nodes. Bader, et al. [Page 1] INTERNET-DRAFT RMD-QSP It allows feedback to systems outside of the Diffserv domain on the availability of resources for individual sessions within the domain while having the availability to aggregate inter domain (end-to-end) resource reservations at the edge of the domain to reduce the burden on internal nodes. The RMD QoS Signaling Policy Model (RMD-QSP) allows devices to use the NSIS QoS-NSLP protocol to signal reservation requests from devices outside the Diffserv domain to edge nodes in the domain, edge nodes have the availability to aggregate the requests and signal the aggregated requests through internal nodes along the data path to the egress edge nodes, and for Egress Edge nodes to signal the original, disaggregated, requests to outside devices. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .3 3. Overview of RMD and RMD-QSP . . . . . . . . . . . . . . . . .4 3.1 RMD . . . . . . . . . . . . . . . . . . . . . . . . . . .4 3.2 RMD-QSP . . . . . . . . . . . . . . . . . . . . . . . . .5 4. RMD QSP, detailed description . . . . . . . . . . . .. . . . 7 4.1 QSpec Definition . . . . . . . . . . . . . . . . . . . . 7 4.1.1 RMD-QSP descriptors . . . . . . . . . . . . . . . .8 4.1.2 PHR RMD-QSP control information . . . . . . . . . .8 4.1.3 PDR RMD-QSP control information . . . . . . . . .10 4.1.4 Mapping of QSpec parameters onto generic QSpec Parameters . . . . . . . . . . . . . . . . .12 4.2 Role of QoS NSLP Entities (QNEs) . . . . . . . . . . . .12 4.3 Message format . . . . . . . . . . . . . . . . . . . . .13 4.4 State management . . . . . . . . . . . . . . . . . . . .14 4.5 Operation and sequence of events . . . . . . . . . . . .16 4.5.1 Edge discovery and addressing of messages . . . . 16 4.5.2 Basic unidirectional operation . . . . . . . . . .16 4.5.2.1 Successful reservation. . . . . . . . . . . .17 4.5.2.2 Unsuccessful reservation . . . . . . . . . . 22 4.5.2.3 RMD refresh reservation. . . . . . . . . . . 24 4.5.2.4 RMD modification of reservation. . . . . . . 28 4.5.2.5 RMD release procedure. . . . . . . . . . . . 28 4.5.2.6 Severe congestion. . . . . . . . . . . . . . 34 4.5.3 Bidirectional operation . . . . . . . . . . . . . 36 4.5.3.1 Successful and unsuccessful reservation . . .37 4.6 Handling of errors . . . . . . . . . . . . . . . . . . .41 5. Security Consideration. . . . . . . . . . . . . . . . . . . 41 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .42 7. Open issues. . . . . . . . . . . . . . . . . . . . . . . . .42 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .42 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 43 10. Normative References . . . . . . . . . . . . . . . . . . . 43 11. Informative References . . . . . . . . . . . . . . . . . . 44 12. Intellectual Property Rights . . . . . . . . . . . . . . . 45 Bader, et al. [Page 2] INTERNET-DRAFT RMD-QSP 1. Introduction This document describes an example of a Next Steps In Signaling (NSIS) Quality of Service Signaling Model for networks that use the Resource Management in Diffserv (RMD) framework ([RMD1], [RMD2], [RMD3],[RMD4]). RMD is a method for devices external to a Diffserv domain to dynamically reserve resources within the Diffserv domain. It describes a procedure that can aggregate individual reservation requests at the Ingress Edge of the domain, two possible modes of operation for internal nodes to admit aggregated requests (a stateless, measurement-based mode, and a reduced-state reservation mode), and a method to forward the original requests across the domain to the Egress Edge and on. The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP) [QoS-NSLP] specifies a generic model for carrying Quality of Service (QoS) signal ing information end-to-end in an IP network. Each network along the end-to-end path is expected to implement a specific QoS Signaling Model (QSP) that installs the necessary state to ensure the requested QoS in a manner that is appropriate to the technology in use in the network. This document specifies the RMD QoS Signaling Policy Model (RMD-QSP), as a specific implementation of a QoS-NSLP QSP, for use in networks that use RMD technology. Internally to the Diffserv network, RMD-QSP uses the stateless/reduced state operation mode of QoS-NSLP and defines a scalable QoS signaling model in which per flow QoS-NSLP and NTLP states are not stored but per flow signaling is performed. In the RMD-QSP, only routers at the edges of a Diffserv domain support the QoS-NSLP stateful operation. Internal routers 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 description of QoS Signaling Policies: After the terminology Section 2, we give an overview of RMD and the RMDQSP in Sec. 3. In Sec. 4 we give a detailed description of the RMD-QSP, including the role of QNEs, the definition of the QSpec, mapping of QSpec generic parameters onto RMDQSP parameters, state management in QNEs, and operation and sequence of events. Sec. 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. Bader, et al. [Page 3] INTERNET-DRAFT RMD-QSP 3. Overview of RMD and RMD-QSP 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 basis rather than per-flow and by forcing as much of the per-flow state as possible to the edges of the network. The service 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 can aggregate individual reservation request at the Ingress Edge of the domain, two possible modes of operation for internal nodes to admit aggregated requests (a stateless, measurement-based mode, and a reduced-state reservation mode), and a method to forward the original requests across the domain to the Egress Edge and on. In RMD, scalability is achieved by separating a complex reservation mechanism used in 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 of a Diffserv domain support per-flow (or aggregated flows) QoS states in order to provide QoS guarantees for each flow (or aggregated flow). Interior nodes use only one aggregated reservation state per traffic class or no states at all. This solution allows fast processing of signaling messages and makes it possible to handle large numbers of flows in the interior nodes. In RMD two basic operation modes are described: a measurement-based admission control and a reservation-based admission control. The measurement-based algorithm uses the requested and available resources as input to query the aggregated reservation state per traffic class in the interior nodes. The advantage of measurement based resource management protocols is that they do not require explicit reservation or release. Moreover, when the user traffic is variable, measurement based admission control could provide higher network utilization than, e.g., peak-rate reservation. However, this requires more complex implementation in interior nodes and introduces an uncertainty of the availability of the resources. Bader, et al. [Page 4] INTERNET-DRAFT RMD-QSP With the reservation-based method, each node in the domain maintains one reservation state per traffic class. 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. 3.2. RMD-QSP RMD-QSP is a QoS-NSLP QoS signaling model for networks that usees RMD technology for processing reservations. In a RMD-QSP domain, an inter-domain (end to end) QoS NSLP message that arrives at the ingress edge generates an additional intra-domain (local) QoS NSLP message containing a RMD QSpec and the inter-domain message is tunneled towards the egress edge. Edge nodes use QoS-NSLP stateful operation and interior nodes use either stateless operation (for measurement-based admission) or reduced state operation (for reservation-based admission). The RMD-QSP uses a simple, hop-by-hop signaling mechanism. The QSpec arrives in an QoS NSLP RESERVE message at the ingress node. The ingress node uses the external QSpec to construct the RMD-QSPec for intra-domain (local) RMD-QSP specific signaling, and sends it in a RESERVE message to the Egress node. Each node on the data path, one after the other, checks the availability of resources with either the reservation-based or the measurement-based method. If an intermediate node cannot accommodate the new request, it indicates it by marking a single bit in the message, and continues forwarding the message. When the message reaches the egress edge node, if no intermediate node has denied the reservation, the generic request is forwarded to the next domain. If an intermediate node has denied the reservation, the reservation is denied. In the simplest case the domain wherein the RMD-QSP is applied is identical to a Diffserv administrative domain. The boundary nodes of the domain are QoS-NSLP aware edge nodes (QNF ingress and QNF Egress Edges) and the interior nodes are QoS-NSLP aware interior nodes (QNF interior). In the interior nodes, RMD-QSP uses the stateless/reduced state operation mode defined in QoS-NSLP. In the edge nodes, RMD-QSP uses the stateful mode of operation. The protocol model of the RMD-QSP is shown in Figure 1. The QNF nodes leading up to the edge of the RMD-QSP domain process the QoS- NSLP messages in a manner appropriate to their QoS technology. At the ingress edge node of the RMD-QSP domain, the inter domain (end-to-end) QoS-NSLP messages trigger the generation of intra-domain (local) RMD-QSP QoS-NSLP messages. The QSpec of the inter domain (end-to-end) QoS-NSLP message is translated into an RMD-QSP QSpec. Bader, et al. [Page 5] INTERNET-DRAFT RMD-QSP |------| |------| |------| |------| | 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 QNF QNF QNF QNF QNR (End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) st.ful: stateful, st.less: stateless st.less red.st.: stateless or reduced state Figure 1 Protocol model of stateless/reduced state operation The original QoS-NSLP messages are sent directly to the next NTLP stateful node, i.e. to the Egress Edge node, see Figure 2. The intra-domain (local) QoS-NSLP messages are processed and interpreted in all interior NSLP routers along the path, hop-by-hop, up to the Egress Edge node. RMD usually performs per flow signaling within the domain. However, RMD can also support per aggregate signaling within the domain. In the reservation-based method interior nodes add and remove the requested resources per PHB. In case of the measurement-based method the availability of resources are checked. In case of unsuccessful reservation in a router, egress nodes are notified by marking the corresponding control field of the Request message. After successful or unsuccessful reservation a RESPONSE message is sent from Egress to Ingress Edge. The RMD reservation method uses soft states: reserved resources should be refreshed periodically. If refresh messages are not arrived within the refresh period the corresponding resource units are removed. Resource units can be removed explicitly as well, by sending Release messages containing the removable resource units. Bader, et al. [Page 6] INTERNET-DRAFT RMD-QSP QNF QNF QNF QNF ingress interior interior egress NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | RESERVE | | | | -------->| RESERVE | | | +--------------------------------------------->| | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +-------------->| | | | | RESERVE' | | | +------------->| | | | | RESERVE | | | +--------> | | | | RESPONSE | | | |<-------- | | | RESPONSE | |<---------------------------------------------+ RESPONSE| | | | <--------| | | | Figure 2: Sender-initiated reservation with Reduced State Interior Nodes 4. RMD-QSP, Detailed Description This section describes RMD-QSP in detail. Particularly, we explain the role of stateless and reduced-state QNEs, define the RMD-QSP QSpec Object, the format of RMD-QSP QoS-NSLP messages, how QSpecs are processed and used, and the protocol operation. 4.1. QSpec Definition This section describes the QSpec that is used by RMD-QSP. The RMD- QSP QSpec object contains three fields, the "RMD-QSP QoS descriptor", the (per hop reservation) "PHR RMD-QSP control information" and the (per domain reservation) "PDR RMD-QSP control information". The "RMD-QSP QoS descriptors" and the "PHR RMD-QSP control information" fields are used and processed by all QoS-NSLP nodes in the edge-to-edge domain, i.e., QNF (edge nodes) and QNF (interior nodes). The "PDR RMD-QSP control information" field is only used and processed by the QNF (edge nodes). The "PHR RMD-QSP control information" field contains the QoS specific control information for intra-domain communication and reservation. The "PDR RMD-QSP control information" contains additional information that is needed by the QNF (edge nodes) and is not available (carried) by the "PHR RMD-QSP control information". RMD-QSP QSpec parameters will be updated in line with QSpec Template draft [QSP-T]. Bader, et al. [Page 7] INTERNET-DRAFT RMD-QSP 4.1.1. RMD-QSP QoS descriptors This section describes the parameters used by the "RMD-QSP QoS descriptors field" field. The RMD QoS Description only contains the object QoS Desired [QSP-T]. It does not contain the objects QoS Available, QoS Reserved or Minimum QoS. = As described in [QSP-T]. 4.1.2. PHR RMD-QSP control information This section describes the parameters used by the "PHR RMD-QSP control information" field. Except these parameters are currently not among the generic parameters defined by . : 4-bit field. This specifies the per hop reservation type. For the reservation based RMD, the value MUST be 1. For the measurement based PHR this value MUST be 2. : 4 bit field, indicating the "PHR RMD-QSP control information" type: PHR_Resource_Request, PHR_Release_Request, PHR_Refresh_Update. It is used to further specify QoS-NSLP RESERVE and RESPONSE messages. "PHR_Resource_Request" (Message Type = 1): initiate or update the traffic class reservation state on all nodes located on the communication path between the QNF(ingress) and QNF(egress) nodes. "PHR_Refresh_Update" (Message Type = 2): refresh the traffic class reservation soft state on all nodes located on the communication path between the QNF(ingress) and QNF(egress) nodes according to a resource reservation request that was successfully processed by the "PHR RMD-QSP control information" functionality during a previous refresh period. "PHR_Release_Request" (Message Type = 3): explicitly release, by subtraction, the reserved resources for a particular flow from a traffic class reservation state. (Severe Congestion): 1 bit. In case of a route change refreshing RESERVE messages follow the new data path, and hence resources are requested there. However, on the new path resources may not be sufficie nt to accommodate the new traffic. Congested interior nodes should notify edge QNFs about the congestion, in order to terminate some of the sessions. The notification of the Bader, et al. [Page 8] INTERNET-DRAFT RMD-QSP egress QNF is carried out by marking either the data packets with dedicated DSCPs or by setting the S Field bit indicating severe congestion in the refresh message. The egress QNF decides which sessions should be terminated and sends a RESPONSE message to the Ingress Edge with the session ID and indicating the severe congestion. Since refresh messages are usually sent less frequently than the data packets a more efficient method for the notification is marking the data packets by changing the DSCP field. : In case of severe congestion the level of overload can be indicated by using e.g. proportional marking if data marking is used. If RMD refresh messages are used, proportional marking is not a feasible solution usually because of the low number of refresh messages. Overload % can be used to indicate the level of Overload %. Note that Overload % should be higher than 0 if S bit is set. If overload in a node is greater than the overload in a previous node then Overload % should be updated. : 1 bit. In case of unsuccessful reservation in an interior QNF, this QNF sets the M bit in order to notify the egress QNF. : 8 bit field. The Hop Count is set to zero when a RESERVE message enters a domain and increased by one at each interior QNF. However when a QNF is reached that does not have sufficient resources to admit the reservation, the M Bit is set, and the Hop Count value is frozen. Hence the Hop Count counts the number of hops where the reservation was successful. In case of an unsuccessful reservation the M Bit is set, and the egress QNF reacts by sending a RESPONSE message containing the Hop Count to the ingress QNF. The ingress QNF uses the Hop Count value to remove the unnecessary reservations by an explicit tearing RESERVE message to the nodes along the path where the reservation has already been made. (Hop Count unset): 1-bit. The QNF(ingress) node MUST set the parameter to 0. This parameter MAY be set to "1" by a node when the node will not increase the value. This is the case when an RMD-QSM reservation-based node is not admitting the "RMDQSM QoS descriptors" and "PHR_Resource_Request" control information fields. Bader, et al. [Page 9] INTERNET-DRAFT RMD-QSP : 1 bit. Indicates bi-directional reservation.