NSIS Working Group Attila Bader INTERNET-DRAFT Lars Westberg Intended status: Informational Ericsson Expires: 13 January 2010 Georgios Karagiannis University of Twente Cornelia Kappler DeZem GmbH Tom Phelan Sonus 13 July 2009 RMD-QOSM - The Resource Management in Diffserv QOS Model Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Intended status: Informational RFC Bader, et al. [Page 1] INTERNET-DRAFT RMD-QOSM 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 and pre-emption function 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 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 . . . . . . . . . . . . . . . . . . . . . . . . .5 3. Overview of RMD and RMD-QOSM . . . . . . . . . . . . . .. . .5 3.1 RMD . . . . . . . . . . . . . . . . . . . . . . . . . . .6 3.2 Basic features of RMD-QOSM . . . . . . . . . . . . . . . 9 3.2.1 Role of the QNEs . . . . . . . .. . . . . . . . . .9 3.2.2 RMD-QOSM/QoS-NSLP signaling . . . . . . . . . . . 10 3.2.3 RMD-QOSM Applicability and considerations. . . . .12 4. RMD-QOSM, Detailed Description . . . . . . . . . . . .. . . 13 4.1 RMD-QSpec Definition . . . . . . . . . . . . . . . . . .13 4.1.1 RMD-QOSM object contribution . . . . . . . . . . .14 4.1.2 PHR Container . . . . . . . . . . . . . . . . . . 15 4.1.3 PDR Container . . . . . . . . . . . . . . . . . .16 4.2 Message format . . . . . . . . . . . . . . . . . . . . .19 4.3 RMD node state management . . . . . . . . . . . . . . . 19 4.3.1 Aggregated versus per flow reservations at the QNE edges . . . . . . . . . . . . . . . . . . . . 19 4.3.2 Measurement-based method . . . . . . . . . . . . .21 4.3.3 Reservation-based method . .. . . . . . . . . . . 23 4.4 Transport of RMD-QOSM messages . . . . . . . . . . . . .24 4.5 Edge discovery and addressing of messages . . . . . . . 26 4.6 Operation and sequence of events . . . . . . . . . . . .27 4.6.1 Basic unidirectional operation . . . . . . . . . .27 4.6.1.1 Successful reservation. . . . . . . . . . . .28 4.6.1.2 Unsuccessful reservation . . . . . . . . . . 38 Bader, et al. [Page 2] INTERNET-DRAFT RMD-QOSM 4.6.1.3 RMD refresh reservation. . . . . . . . . . . 42 4.6.1.4 RMD modification of aggregated reservation . 45 4.6.1.5 RMD release procedure. . . . . . . . . . . . 46 4.6.1.6 Severe congestion handling . . . . . . . . .53 4.6.1.7 Admission control using congestion notification based on probing . . . . . . . 59 4.6.2 Bidirectional operation . . . . . . . . . . . . . 62 4.6.2.1 Successful and unsuccessful reservation . . .64 4.6.2.2 Refresh reservation . . . . . . . . . . . . .67 4.6.2.3 Modification of aggregated reservation . . . 68 4.6.2.4 Release procedure . . . . . . . . . . . . . .69 4.6.2.5 Severe congestion handling . . . . . . . . . 69 4.6.2.6 Admission control using congestion notification based on probing . . . . . . . .72 4.7 Handling of additional errors . . . . . . . . . . . . . 74 5. Security Consideration. . . . . . . . . . . . . . . . . . . 75 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .78 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .78 8. Authors` Addresses. . . . . . . . . . . . . . . . . . . . . 79 9. Normative References . . . . . . . . . . . . . . . . . . . .80 10. Informative References . . . . . . . . . . . . . . . . . . 80 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], [RMD4]). 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 protocol 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) specified by the QSpec template [QSP-T] 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. Bader, et al. [Page 3] INTERNET-DRAFT RMD-QOSM 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 together with QoS-NSLP [QoS-NSLP] 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]). In the RMD-QOSM, only routers at the edges of a Diffserv domain (Ingress and Egress nodes) support the (QoS-NSLP) stateful operation, see Section 4.7 of [QoS-NSLP]. Interior nodes support either the(QoS-NSLP) stateless operation, or a reduced-state operation with coarser granularity than the edge nodes. 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. Bader, et al. [Page 4] INTERNET-DRAFT RMD-QOSM 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 [RFC2119]. The terminology defined by GIST [GIST] and QoS-NSLP [QoS-NSLP] applies to this draft. In addition, the following terms are used: NSIS domain: a NSIS signalling capable domain. RMD domain: a NSIS domain that is capable of supporting the RMD-QOSM signalling and operations. Edge node: a QoS-NSLP node on the boundary of some administrative domain that connects one NSIS domain to a node either in another NSIS domain or in a non NSIS domain. NSIS aware node: a node that is aware of NSIS signalling and RMD- QOSM operations, such as severe congestion detection and DSCP marking. NSIS unaware: a node that is unware of NSIS signalling, but is aware of RMD-QOSM operations such as severe congestion detection and DSCP marking. Ingress node: An edge node in its role in handling the traffic as it enters the NSIS domain. Egress node: An edge node in its role in handling the traffic as it leaves the NSIS domain. Interior node: a node in a NSIS domain that is not an edge node. Congestion: is a temporal network state that occurs when the traffic (or when traffic associated with a particular PHB) passing through a link is slightly higher than the capacity allocated for the link (or allocated for the particular PHB). If no measures are taken than the traffic passing through this link may temporarily slightly degrade in QoS. This type of congestion is usually solved using admission control mechanisms. Severe congestion: is a congestion that occurs when a node or link fails and the traffic is rerouter through another node or link. If no measures are taken than the node or the link can become severely congested and all traffic passing through the node or link will severely degrade in QoS. This type of congestion cannot be solved using admission control mechanisms. Bader, et al. [Page 5] INTERNET-DRAFT RMD-QOSM 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 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 means for devices outside the domain to dynamically reserve resources or receive indications of network resource availability. In practice, service providers rely on short active 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. Typically 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. The possible RMD-QOSM applicabilities are described in Section 3.2.3. Two main basic admission control modes are supported: reservation-based and measurement-based admission control that can be used in combination with a severe congestion handling solution. The severe congestion handling solution is used in the situation that a link/node becomes severely congested due to the fact that the traffic supported by a failed link/node is rerouted and has to be processed by this link/node. Furthermore, RMD-QOSM supports both uni-directional and bi-directional reservations. Bader, et al. [Page 6] INTERNET-DRAFT RMD-QOSM Another important feature of RMD-QOSM is that the intra-domain sessions supported by the edges can be either per flow sessions or per aggregate sessions. In case of the per flow intra-domain sessions, the maintained per flow intra-domain states have a one-to- one dependency to the per flow end-to-end states supported by the same edge. In case of the per-aggregate sessions the maintained per- aggregate states have a one-to-many relationship to the per flow end-to-end states supported by the same edge. In the reservation-based method, each Interior node maintains only one reservation state per traffic class. The Ingress edge nodes aggregate individual flow requests into PHB traffic classes, and signal changes in the class reservations as necessary. The reservation is quantified in terms of resource units (or bandwidth). 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. 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 at the interior nodes. The advantage of measurement-based resource management protocols is that they do not require pre-reservation state nor explicit release of the reservations at the interior nodes. 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. Two types of measurement based admission control schemes are possible: * Congestion notification function based on probing: This method can be used to implement a simple measurement-based admission control within a Diffserv domain. In this scenario the interior nodes are not NSIS aware nodes. In these interior nodes thresholds are set for the traffic belonging to different PHBs in the measurement based admission control function. In this scenario an end-to-end NSIS message is used as a probe packet, meaning that the DSCP field in the header of the IP packet that carries the NSIS message is re-marked when the predefined congestion threshold is exceeded. Note that when the predefined congestion threshold is exceeded all packets are remarked by a node, including NSIS messages. In this way the edges can admit or reject flows that are requesting resources. The rate of the re-marked data packets is used to detect a congestion situation that can influence the admission control decisions. Bader, et al. [Page 7] INTERNET-DRAFT RMD-QOSM * NSIS measurement-based admission control: In this case the measurement-based admission control functionality is implemented in NSIS aware stateless routers. The main difference between this type of admission control and the congestion notification based on probing is related to the fact that this type of admission control is applied mainly on NSIS aware nodes, giving the possibility to apply measuring techniques, see e.g., [JaSh97], [GrTs03], that are using current and past information on NSIS sessions that requested resources from an NSIS aware interior node. The admission decision is positive if the currently carried traffic, as characterized by the measured statistics, plus the requested resources for the new flow exceeds the system capacity with a probability smaller than some alpha. Otherwise, the admission decision is negative. RMD describes the following procedures: * Classification of an individual resource reservation or a resource query into Per Hop Behavior (PHB) groups at the Ingress node of the domain, * Hop-by-hop admission control based on a 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). Bader, et al. [Page 8] INTERNET-DRAFT RMD-QOSM All nodes of the RMD domain are usually QoS-NSLP aware nodes. However, in the scenarios where the congestion notification function based on probing is used, then the interior nodes are not NSIS aware. Edge nodes store and maintain QoS-NSLP and NTLP states and therefore are stateful nodes. The NSIS aware Interior nodes are NTLP stateless. Furthermore they are either QoS-NSLP stateless (for NSIS measurement-based operation), or are reduced state nodes storing per PHB aggregated QoS-NSLP states (for reservation-based operation). Note that the RMD 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 based on probing operation and/or severe congestion operation (see Section 4.6.1.6). |------| |-------| |------| |------| | 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 Bader, et al. [Page 9] INTERNET-DRAFT RMD-QOSM 3.2.2 RMD-QOSM/QoS-NSLP Signaling The basic RMD-QOSM/QoS-NSLP signaling is shown in Figure 3. The signalling scenarios are accomplished using the QoS-NSLP processing rules defined in [QoS-NSLP], in combination with the RMF triggers sent via the QoS-NSLP-RMF API described in [QoS-NSLP]. 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 initial QSpec in the message (usually the Initiator QSpec). The RMD-QSpec is sent in a intra-domain, independent RESERVE message through the Interior nodes towards the QNR. This intra-domain RESERVE message uses the GIST datagram signaling mechanism. Note that the RMD-QOSM cannot directly specify that the GIST datagram mode SHOULD be used. This can however be notified by using the GIST API Transfer-Attributes, such as unreliable, low level of security and use of local policy. Meanwhile, the original RESERVE message is sent to the Egress node on the path to the QNR using the reliable transport mode of NTLP. QNE Ingress QNE Interior QNE Interior QNE Egress NTLP stateful NTLP stateless NTLP stateless NTLP stateful | | | | RESERVE | | | | -------->| RESERVE | | | +--------------------------------------------->| | RESERVE` | | | +-------------->| | | | | RESERVE` | | | +-------------->| | | | | RESERVE` | | | +------------->| | | | RESPONSE`| |<---------------------------------------------+ | | | | RESERVE | | | +-------> | | | |RESPONSE | | | |<------- | | | RESPONSE | |<---------------------------------------------+ RESPONSE| | | | <--------| | | | Figure 3: Sender-initiated reservation with Reduced State Interior Nodes Bader, et al. [Page 10] INTERNET-DRAFT RMD-QOSM Each QoS-NSLP node on the data path processes the intra-domain 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 node, an intra-domain (local) RESPONSE` is sent towards the ingress node and the original (end-to-end) 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 an intra-domain RESPONSE` and an original RESPONSE message are sent directly to the Ingress node. 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 and reduced refreshes, cannot be used. If per flow identification, is needed, i.e., associating the flow IDs for the reserved resources, Edge nodes act on behalf of Interior nodes. 3.2.3 RMD-QOSM Applicability and considerations The RMD-QOSM is a Diffserv-based bandwidth management methodology that is not able to provide a full Diffserv support. The reason of this is that the RMD-QOSM concept can only support the (Expedited Forwarding) EF-like functionality behavior, but is not able to support the full set of (Assured Forwarding) AF-like functionality. The bandwidth information REQUIRED by the EF-like functionality behaviour can be supported by RMD-QOSM carrying the bandwidth information in the parameter, see [QSP-T]. The full set of (Assured Forwarding) AF-like functionality requires information that is specified in two token buckets. The RMD-QOSM is not supporting the use of two token buckets and therefore, it is not able to support the full set of AF-functionality. Note however, that RMD-QOSM could also support a single AF PHB, when the traffic or the upper limit of the traffic can be characterized by a single bandwidth parameter. A very important consideration on using RMD-QOSM is that within one RMD domain only one of the following RMD-QOSM schemes can be used at a time. Thus a RMD router can never process and use two different RMD-QOSM signaling schemes at the same time. The operator of an RMD domain has to pre-configure all routers in the domain such that within one RMD domain only one of the below described RMD-QOSM schemes can be used at a time. Note however, that there is no single to implement scheme variant. Bader, et al. [Page 11] INTERNET-DRAFT RMD-QOSM The congestion situations, see Section 2, are solved using admission control mechanism, e.g., "per flow congestion notification based on probing", while the severe congestion situations, see Section 2, are solved using the severe congestion handling mechanisms, e.g., "Severe congestion handling by proportional data packet marking". The RMD domain MUST be engineered in such a way that RMD-QOSM messages could be transported using the GIST Query and Data messages in Q-mode, see [GIST]. This means that the Path MTU MUST be engineered in such a way that the RMD-QOSM message are transported without fragmentation. Furthermore, the RMD domain MUST be engineered in such a way to guarantee capacity for the GIST Query and Data messages in Q-mode, within the rate control limits imposed by GIST, see [GIST]. The RMD domain has to be configured such that the GIST context-free flag (C-flag) MUST be set (C=1) for Query messages and Data messages sent in Q-mode, see [GIST]. It is important to note that the concepts described in Sections 4.6.1.6.2, 4.6.2.5.2, 4.6.1.6.2 and 4.6.2.5.2 contributed to the PCN WG standardisation. The available RMD-QOSM/QoS-NSLP signaling schemes are: * "per flow congestion notification based on probing" (see Sections 4.3.2, 4.6.1.7., 4.6.2.6.). Note that this scheme uses for severe congestion handling the "Severe congestion handling by proportional data packet marking", see Section 4.6.1.6.2, 4.6.2.5.2). Furthermore, the interior nodes are considered to be Diffserv aware, but NSIS unaware nodes, see Section 4.3.2. * "per flow RMD NSIS measurement based admission control" (see Sections 4.3.2, 4.6.1, 4.6.2). Note that this scheme uses for severe congestion handling the "Severe congestion handling by proportional data packet marking", see Section 4.6.1.6.2, 4.6.2.5.2). Furthermore, the interior nodes are considered to be NSIS aware nodes, see Section 4.3.2. * "per flow RMD reservation based" in combination with "severe congestion handling by the RMD-QOSM refresh procedure" (see Sections 4.3.3, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this scheme uses for severe congestion handling the "Severe congestion handling by the RMD-QOSM refresh" procedure, see Section 4.6.1.6.1, 4.6.2.5.1). Furthermore, the intra-domain sessions supported by the edge nodes are per flow sessions, see Section 4.3.3. Bader, et al. [Page 12] INTERNET-DRAFT RMD-QOSM * "per flow RMD reservation based" in combination with "severe congestion handling by proportional data packet marking" procedure (see Sections 4.3.3, 4.6.1, 4.6.1.6.2, 4.6.2.5.2). Note that this scheme uses for severe congestion handling the "Severe congestion handling by proportional data packet marking" procedure, see Section 4.6.1.6.2, 4.6.2.5.2). Furthermore, the intra-domain sessions supported by the edge nodes are per flow sessions, see Section 4.3.3. * "per aggregate RMD reservation based" in combination with "severe congestion handling by the RMD-QOSM refresh procedure" (see Sections 4.3.1, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this scheme uses for severe congestion handling the "Severe congestion handling by the RMD-QOSM refresh" procedure, see Section 4.6.1.6.1, 4.6.2.5.1). Furthermore, the intra-domain sessions supported by the edge nodes are per aggregate sessions, see Section 4.3.1. * "per aggregate RMD reservation based" in combination with "severe congestion handling by proportional data packet marking" procedure (see Sections 4.3.1, 4.6.1, 4.6.1.6.2, 4.6.2.5.2). Note that this scheme uses for severe congestion handling the "Severe congestion handling by proportional data packet marking" procedure, see Section 4.6.1.6.2, 4.6.2.5.2). Furthermore, the intra-domain sessions supported by the edge nodes are per aggregate sessions, see Section 4.3.1. 4. RMD-QOSM, Detailed Description This section describes the 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 the RMD-QOSM QoS-NSLP messages and how QSpecs are processed and used in different protocol operations. 4.1. RMD-QSpec Definition The RMD-QOSM uses the QSpec format specified in [QSP-T]. The flag is set to "Local" (i.e., "1") and the is set as follows: * Message Sequence = 0: Sender initiated * Object combination = 1: for RESERVE and for RESPONSE The used by RMD-QOSM is the default version, see [QSP-T]. The used by the RMD-QOSM is assigned by IANA, see Section 6. The contains the following fields: = Bader, et al. [Page 13] INTERNET-DRAFT RMD-QOSM The Per Hop Reservation container (PHR container) and the Per Domain Reservation container (PDR container) are specified in Section 4.1.2 and 4.1.3, respectively. The contains the traffic handling directives for intra-domain communication and reservation. The contains additional traffic handling directives that is needed for edge-to-edge communication. The parameter IDs used by the and are assigned by IANA, see Section 6. For clarity Reasons we will assigned temporarily, the following names to the PHR and PDR containers: * PHR_1 to PHR_3 for the * PDR_4 to PDR_10 for the After IANA assigns the proper ID values to the PHR and PDR containers, then the above list has to be replaced accordingly. The "RMD-QOSM object combination", i.e., and , is specified in Section 4.1.1. The "RMD- QOSM QoS object combination" and the are used and processed by the Edge and Interior nodes. The field is only processed by Edge nodes. 4.1.1. RMD-QOSM object combination The "RMD-QOSM object combination" carried by the RESERVE message only contains the QoS Desired object [QSP-T]. The QoS Reserved object is carried by the RESPONSE message. "RMD-QOSM object combination" = for RESERVE "RMD-QOSM object combination" = for RESPONSE = = The bit format of the (see [QSP-T] and Figure 4 and Figure 5) and complies to the bit format specified in [QSP-T]. The bit format used for the parameter is shown below and it is identical to the peak rate (p) parameter format specified in [QSP-T]. Note that after IANA assigns the proper ID value to the parameter then the Bandwdith_ID term has to be replaced accordingly. 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|0|r| Bandwidth_IDID |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter format Bader, et al. [Page 14] INTERNET-DRAFT RMD-QOSM Note that for the RMD-QOSM a reservation established without an parameter is equivalent to a reservation established with an whose value is 1. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSCP |0 0 0 0 0 0 0 0 X 0| +---+---+---+---+---+---+---+---+ Figure 4: DSCP parameter 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHB ID code |0 0 X X| +---+---+---+---+---+---+---+---+ Figure 5: PHB ID Code parameter 4.1.2. PHR Container This section describes the parameters used by the PHR container, which are used by the RMD-QOSM functionality available at the Interior nodes. = , , ,, , , ,