From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5977.txt | 7171 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 7171 insertions(+) create mode 100644 doc/rfc/rfc5977.txt (limited to 'doc/rfc/rfc5977.txt') diff --git a/doc/rfc/rfc5977.txt b/doc/rfc/rfc5977.txt new file mode 100644 index 0000000..062bb7c --- /dev/null +++ b/doc/rfc/rfc5977.txt @@ -0,0 +1,7171 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Bader +Request for Comments: 5977 L. Westberg +Category: Experimental Ericsson +ISSN: 2070-1721 G. Karagiannis + University of Twente + C. Kappler + ck technology concepts + T. Phelan + Sonus + October 2010 + + + RMD-QOSM: The NSIS Quality-of-Service Model + for Resource Management in Diffserv + +Abstract + + This document describes a Next Steps in Signaling (NSIS) Quality-of- + Service (QoS) Model for networks that use the Resource Management in + Diffserv (RMD) concept. RMD is a technique for adding admission + control and preemption 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. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5977. + + + +Bader, et al. Experimental [Page 1] + +RFC 5977 RMD-QOSM October 2010 + + +Copyright Notice + + Copyright (c) 2010 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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................4 + 2. Terminology .....................................................6 + 3. Overview of RMD and RMD-QOSM ....................................7 + 3.1. RMD ........................................................7 + 3.2. Basic Features of RMD-QOSM ................................10 + 3.2.1. Role of the QNEs ...................................10 + 3.2.2. RMD-QOSM/QoS-NSLP Signaling ........................11 + 3.2.3. RMD-QOSM Applicability and Considerations ..........13 + 4. RMD-QOSM, Detailed Description .................................15 + 4.1. RMD-QSPEC Definition ......................................16 + 4.1.1. RMD-QOSM and ..........16 + 4.1.2. PHR Container ......................................17 + 4.1.3. PDR Container ......................................20 + 4.2. Message Format ............................................23 + 4.3. RMD Node State Management .................................23 + 4.3.1. Aggregated Operational and Reservation + States at the QNE Edges ............................23 + 4.3.2. Measurement-Based Method ...........................25 + 4.3.3. Reservation-Based Method ...........................27 + 4.4. Transport of RMD-QOSM Messages ............................28 + 4.5. Edge Discovery and Message Addressing .....................31 + 4.6. Operation and Sequence of Events ..........................32 + 4.6.1. Basic Unidirectional Operation .....................32 + 4.6.1.1. Successful Reservation ....................34 + 4.6.1.2. Unsuccessful Reservation ..................46 + 4.6.1.3. RMD Refresh Reservation ...................50 + 4.6.1.4. RMD Modification of Aggregated + Reservations ..............................54 + 4.6.1.5. RMD Release Procedure .....................55 + 4.6.1.6. Severe Congestion Handling ................64 + + + + +Bader, et al. Experimental [Page 2] + +RFC 5977 RMD-QOSM October 2010 + + + 4.6.1.7. Admission Control Using Congestion + Notification Based on Probing .............70 + 4.6.2. Bidirectional Operation ............................73 + 4.6.2.1. Successful and Unsuccessful Reservations ..77 + 4.6.2.2. Refresh Reservations ......................82 + 4.6.2.3. Modification of Aggregated Intra-Domain + QoS-NSLP Operational Reservation States ...82 + 4.6.2.4. Release Procedure .........................83 + 4.6.2.5. Severe Congestion Handling ................84 + 4.6.2.6. Admission Control Using Congestion + Notification Based on Probing .............87 + 4.7. Handling of Additional Errors .............................89 + 5. Security Considerations ........................................89 + 5.1. Introduction ..............................................89 + 5.2. Security Threats ..........................................91 + 5.2.1. On-Path Adversary ..................................92 + 5.2.2. Off-Path Adversary .................................94 + 5.3. Security Requirements .....................................94 + 5.4. Security Mechanisms .......................................94 + 6. IANA Considerations ............................................97 + 6.1. Assignment of QSPEC Parameter IDs .........................97 + 7. Acknowledgments ................................................97 + 8. References .....................................................97 + 8.1. Normative References ......................................97 + 8.2. Informative References ....................................98 + Appendix A. Examples .............................................101 + A.1. Example of a Re-Marking Operation during Severe + Congestion in the Interior Nodes .........................101 + A.2. Example of a Detailed Severe Congestion Operation in the + Egress Nodes .............................................107 + A.3. Example of a Detailed Re-Marking Admission Control + (Congestion Notification) Operation in Interior Nodes ....111 + A.4. Example of a Detailed Admission Control (Congestion + Notification) Operation in Egress Nodes ..................112 + A.5. Example of Selecting Bidirectional Flows for Termination + during Severe Congestion .................................113 + A.6. Example of a Severe Congestion Solution for + Bidirectional Flows Congested Simultaneously on Forward + and Reverse Paths ........................................113 + A.7. Example of Preemption Handling during Admission Control ..117 + A.8. Example of a Retransmission Procedure within the RMD + Domain ...................................................120 + A.9. Example on Matching the Initiator QSPEC to the Local + RMD-QSPEC ................................................122 + + + + + + + +Bader, et al. Experimental [Page 3] + +RFC 5977 RMD-QOSM October 2010 + + +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], and [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) + [RFC5974] specifies a generic protocol for carrying 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 [RFC5975] 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 + + Many network scenarios, such as the "Wired Part of Wireless Network" + scenario, which is described in Section 8.4 of [RFC3726], require + that the impact of the used QoS signaling protocol on the network + performance should be minimized. In such network scenarios, the + performance of each network node that is used in a communication path + + + +Bader, et al. Experimental [Page 4] + +RFC 5977 RMD-QOSM October 2010 + + + has an impact on the end-to-end performance. As such, the end-to-end + performance of the communication path can be improved by optimizing + the performance of the Interior nodes. One of the factors that can + contribute to this optimization is the minimization of the QoS + signaling protocol processing load and the minimization of the number + of states on each Interior node. + + Another requirement that is imposed by such network scenarios is that + whenever a severe congestion situation occurs in the network, the + used QoS signaling protocol should be able to solve them. In the + case of a route change or link failure, a severe congestion situation + may occur in the network. Typically, routing algorithms are able to + adapt and change their routing decisions to reflect changes in the + topology and traffic volume. In such situations, the rerouted + traffic will have to follow a new path. Interior nodes located on + this new path may become overloaded, since they suddenly might need + to support more traffic than for which they have capacity. These + severe congestion situations will severely affect the overall + performance of the traffic passing through such nodes. + + RMD-QOSM is an edge-to-edge (intra-domain) QoS Model that, in + combination with the QoS-NSLP and QSPEC specifications, is designed + to support the requirements mentioned above: + + o Minimal impact on Interior node performance; + + o Increase of scalability; + + o Ability to deal with severe congestion + + Internally to the RMD network, RMD-QOSM together with QoS-NSLP + [RFC5974] defines a scalable QoS signaling model in which per-flow + QoS-NSLP and NSIS Transport Layer Protocol (NTLP) states are not + stored in Interior nodes but per-flow signaling is performed (see + [RFC5974]) at the Edges. + + 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 [RFC5974]. 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. This document specifies several RMD-QOSM/ + QoS-NSLP signaling schemes. In particular, Section 3.2.3 identifies + which combination of sections are used for the specification of each + RMD-QOSM/QoS-NSLP signaling scheme. In Section 4 we give a detailed + description of the RMD-QOSM, including the role of QoS NSIS entities + + + +Bader, et al. Experimental [Page 5] + +RFC 5977 RMD-QOSM October 2010 + + + (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 [RFC2119]. + + The terminology defined by GIST [RFC5971] and QoS-NSLP [RFC5974] + applies to this document. + + In addition, the following terms are used: + + NSIS domain: an NSIS signaling-capable domain. + + RMD domain: an NSIS domain that is capable of supporting the RMD-QOSM + signaling and operations. + + Edge node: a QoS-NSLP node on the boundary of some administrative + domain that connects one NSIS domain to a node in either another NSIS + domain or a non-NSIS domain. + + NSIS-aware node: a node that is aware of NSIS signaling and RMD-QOSM + operations, such as severe congestion detection and Differentiated + Service Code Point (DSCP) marking. + + NSIS-unaware node: a node that is unaware of NSIS signaling, 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 an NSIS domain that is not an Edge node. + + Congestion: a temporal network state that occurs when the traffic (or + when traffic associated with a particular Per-Hop Behavior (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, then the traffic passing through this link may temporarily + slightly degrade in QoS. This type of congestion is usually solved + using admission control mechanisms. + + + +Bader, et al. Experimental [Page 6] + +RFC 5977 RMD-QOSM October 2010 + + + Severe congestion: the congestion situation on a particular link + within the RMD domain where a significant increase in its real packet + queue situation occurs, such as when due to a link failure rerouted + traffic has to be supported by this particular link. + +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 + + + +Bader, et al. Experimental [Page 7] + +RFC 5977 RMD-QOSM October 2010 + + + 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 + unidirectional and bidirectional reservations. + + 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 the 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 the 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. The + measurement-based algorithm is used to support a predictive service + where the service commitment is somewhat less reliable than the + service that can be supported by the reservation-based method. + + A main assumption that is made by such measurement-based admission + control mechanisms is that the aggregated PHB traffic passing through + an RMD Interior node is high and therefore, current measurement + characteristics are considered to be an indicator of future load. + 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. It is + important to emphasize that the RMD measurement-based schemes + described in this document do not use any refresh procedures, since + these approaches are used in stateless nodes; see Section 4.6.1.3. + + + + +Bader, et al. Experimental [Page 8] + +RFC 5977 RMD-QOSM October 2010 + + + 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 + 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 re-marked by a node, including NSIS + messages. In this way, the Edges can admit or reject flows that are + requesting resources. The frequency and duration that the congestion + level is above the threshold resulting in re-marking is tracked and + used to influence the admission control decisions. + + * 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. With the + measurement-based scheme, the requested peak bandwidth of a flow is + carried by the admission control request. The admission decision is + considered as 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 a value alpha. Otherwise, the admission + decision is negative. It is important to emphasize that due to the + fact that the RMD Interior nodes are stateless, they do not store + information of previous admission control requests. + + This could lead to a situation where the admission control accuracy + is decreased when multiple simultaneous flows (sharing a common + Interior node) are requesting admission control simultaneously. By + applying measuring techniques, e.g., see [JaSh97] and [GrTs03], which + use current and past information on NSIS sessions that requested + resources from an NSIS-aware Interior node, the decrease in admission + control accuracy can be limited. RMD describes the following + procedures: + + + + + + +Bader, et al. Experimental [Page 9] + +RFC 5977 RMD-QOSM October 2010 + + + * 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 the 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 QoS NSIS initiator (QNI) and QoS NSIS Receiver (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 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 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). + + + +Bader, et al. Experimental [Page 10] + +RFC 5977 RMD-QOSM October 2010 + + + |------| |-------| |------| |------| + | 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/QoS-NSLP Signaling + + The basic RMD-QOSM/QoS-NSLP signaling is shown in Figure 3. The + signaling scenarios are accomplished using the QoS-NSLP processing + rules defined in [RFC5974], in combination with the Resource + Management Function (RMF) triggers sent via the QoS-NSLP-RMF API + described in [RFC5974]. + + Due to the fact that within the RMD domain a QoS Model that is + different than the end-to-end QoS Model applied at the Edges of the + RMD domain can be supported, the RMD Interior node reduced-state + reservations can be updated independently of the per-flow end-to-end + reservations (see Section 4.7 of [RFC5974]). Therefore, two + different RESERVE messages are used within the RMD domain. One + RESERVE message that is associated with the per-flow end-to-end + reservations and is used by the Edges of the RMD domain and one that + is associated with the reduced-state reservations within the RMD + domain. + + A RESERVE message is created by a QNI with an Initiator QSPEC + describing the reservation and forwarded along the path towards the + QNR. + + + +Bader, et al. Experimental [Page 11] + +RFC 5977 RMD-QOSM October 2010 + + + 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. 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. + + 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 + + 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. + + + +Bader, et al. Experimental [Page 12] + +RFC 5977 RMD-QOSM October 2010 + + + 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 reservations 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 for + 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 + behavior can be supported by RMD-QOSM carrying the bandwidth + information in the parameter (see [RFC5975]). 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. Moreover, it is considered that in case of tunneling, the + RMD-QOSM supports only the uniform tunneling mode for Diffserv (see + [RFC2983]). + + The RMD domain MUST be engineered in such a way that each QNE Ingress + maintains information about the smallest MTU that is supported on the + links within the RMD domain. + + 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, an RMD router can never process and use two different + RMD-QOSM signaling schemes at the same time. + + However, all RMD QNEs supporting this specification MUST support the + combination of the "per-flow RMD reservation-based" and the "severe + congestion handling by proportional data packet marking" scheme. If + the RMD QNEs support more RMD-QOSM schemes, then the operator of that + RMD domain MUST preconfigure all the QNE Edge nodes within one domain + such that the field included in the "PHR container" (Section + + + +Bader, et al. Experimental [Page 13] + +RFC 5977 RMD-QOSM October 2010 + + + 4.1.2) and the "PDR Container" (Section 4.1.3) will always use the + same value, such that within one RMD domain only one of the below + described RMD-QOSM schemes is used at a time. + + The congestion situations (see Section 2) are solved using an + 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 [RFC5971]. 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 [RFC5971]. + + 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 [RFC5971]. + + Moreover, the same deployment issues and extensibility considerations + described in [RFC5971] and [RFC5978] apply to this document. + + 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 standardization. + + 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, and 4.6.2.6). Note that this scheme uses, for + severe congestion handling, the "severe congestion handling by + proportional data packet marking" (see Sections 4.6.1.6.2 and + 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, and 4.6.2). Note that this scheme uses, for + severe congestion handling, the "severe congestion handling by + proportional data packet marking" (see Sections 4.6.1.6.2 and + 4.6.2.5.2). Furthermore, the Interior nodes are considered to be + NSIS-aware nodes (see Section 4.3.2). + + + + + +Bader, et al. Experimental [Page 14] + +RFC 5977 RMD-QOSM October 2010 + + + * "per-flow RMD reservation-based" in combination with the "severe + congestion handling by the RMD-QOSM refresh" procedure (see + Sections 4.3.3, 4.6.1, 4.6.1.6.1, and 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 Sections 4.6.1.6.1 + and 4.6.2.5.1). Furthermore, the intra-domain sessions supported + by the Edge nodes are per-flow sessions (see Section 4.3.3). + + * "per-flow RMD reservation-based" in combination with the "severe + the congestion handling by proportional data packet marking" + procedure (see Sections 4.3.3, 4.6.1, 4.6.1.6.2, and 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 Sections 4.6.1.6.2 and 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 the + "severe congestion handling by the RMD-QOSM refresh" procedure (see + Sections 4.3.1, 4.6.1, 4.6.1.6.1, and 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 Sections 4.6.1.6.1 + and 4.6.2.5.1). Furthermore, the intra-domain sessions supported + by the Edge nodes are per-aggregate sessions (see Section 4.3.1). + Moreover, this scheme can be considered to be a reservation-based + scheme, since the RMD Interior nodes are reduced-state nodes, i.e., + they do not store NTLP/GIST states, but they do store per PHB- + aggregated QoS-NSLP reservation states. + + * "per-aggregate RMD reservation-based" in combination with the + "severe congestion handling by proportional data packet marking" + procedure (see Sections 4.3.1, 4.6.1, 4.6.1.6.2, and 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 Sections 4.6.1.6.2 and 4.6.2.5.2). Furthermore, the + intra-domain sessions supported by the Edge nodes are per-aggregate + sessions (see Section 4.3.1). Moreover, this scheme can be + considered to be a reservation-based scheme, since the RMD Interior + nodes are reduced-state nodes, i.e., they do not store NTLP/GIST + states, but they do store per PHB-aggregated QoS-NSLP reservation + states. + +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. + + + +Bader, et al. Experimental [Page 15] + +RFC 5977 RMD-QOSM October 2010 + + +4.1. RMD-QSPEC Definition + + The RMD-QOSM uses the QSPEC format specified in [RFC5975]. The + Initiator/Local QSPEC bit, i.e., is set to "Local" (i.e., "1") + and the is set as follows: + + * Message Sequence = 0: Sender initiated + * Object combination = 0: for RESERVE and + for RESPONSE + + The used by RMD-QOSM is the default version, i.e., + "0", see [RFC5975]. The value used by the RMD-QOSM is + specified in [RFC5975] and is equal to "2". The contains the following fields: + + = + + The Per-Hop Reservation container (PHR container) and the Per-Domain + Reservation container (PDR container) are specified in Sections 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 are needed for edge-to-edge communication. The parameter IDs + used by the and are assigned by IANA; + see Section 6. + + The RMD-QOSM and , are specified in + Section 4.1.1. The RMD-QOSM and 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 and + + The RESERVE message contains only the object [RFC5975]. + The object is carried by the RESPONSE message. + + In RMD-QOSM, the and objects contain the + following parameters: + + = + = + + The bit format of the (see [RFC5975] and Figures 4 and 5) + and complies with the bit format specified in + [RFC5975]. + + + + + + +Bader, et al. Experimental [Page 16] + +RFC 5977 RMD-QOSM October 2010 + + + 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. + + = , ,