idnits 2.17.1 draft-ietf-nsis-rmd-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4389. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that in the above described case, the QNE egress uses, if available, the tunnelled end-to-end parameter, which can be strictly interpreted. Therefore, the "R" flag and the non-QOSM-hop "Q" flag MUST not be set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the end-to-end QSpec carries the parameter, then the QNE ingress and QNE egress nodes MUST control the excess traffic that is entering or leaving the RMD domain in accordance to the parameter. Note that the RMD-QSpec does not carry the parameter. However, by using the parameter the RMD domain uses the excess treatment procedures specified by the particular PHB standard. Therefore, in this case the "R" flag in the carried by the tunneled end to end QSpec MUST not be set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * the SCOPING flag MUST not be set, meaning that a default scoping of the message is used. Therefore, the QNE Edges MUST be configured as RMD boundary nodes and the QNE Interior nodes MUST be configured as Interior (intermediary) nodes; == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * If the QNE Ingress uses per flow intra-domain QoS-NSLP operational states, see Section 4.3.2, 4.3.3, then the object MUST not included in this message. If the QNE Edge nodes maintain intra-domain aggregated QoS-NSLP operational states, see Section 4.3.1, then the MUST be included in this message, see [QoS-NSLP]. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The end-to-end RESERVE message is generated/forwarded further upstream according to the [QoS-NSLP] and [QSP-T] specifications. Note that if the tunneled end-to-end QSpec contains one or more parameters with the "R" flag and "Q" flag set then also the "R" flag and "Q" flag contained in the end-to-end QSpec, which is carried by the generated/forwarded end-to-end RESERVE message MUST be set. Furthermore, the "B" (BREAK) QoS-NSLP flag in the end to end RESERVE message MUST not be set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This procedure is applied to all RMD mechanisms that maintain reservation states. If a refresh RESERVE message does not arrive at a QNE Interior node within the refresh time-out period then the resources associated with this message are removed. This soft state behavior provides certain robustness for the system ensuring that unused resources are not reserved for long time. Resources can be removed by an explicit release at any time. However, in the situation that an end-to-end (tear) RESERVE is retransmitted, see Section 5.2.4 in [QoS-NSLP], then this message MUST not initiate an intra-domain (tear) RESERVE message. This is because the RMF values related to the end-to-end (tear) RESERVE message have been already released during the process of the original (initial) end-to-end (tear) RESERVE message. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * The object MUST not be included in this message. This is because the QNE Ingress node does not need to receive a response from the QNE Egress node; == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Interior node detecting severe congestion remarks data packets passing the node. For this remarking, two additional DSCPs can be allocated for each traffic class. One DSCP MAY be used to indicate that the packet passed a congested node. This type of DSCP is denoted in this document as "affected DSCP" and is used to indicate that a packet passed through a severe congested node. The use of this DSCP type eliminates the possibility that, due to e.g. ECMP (Equal Cost Multiple Paths) enabled routing, the egress node either does not detect packets passed a severe congested node or erroneously detects packets that actually did not pass the severe congested node. Note that this type of DSCP MUST only be used if all the nodes within the RMD domain are configured to use it. Otherwise, this type of DSCP MUST not be applied. The other DSCP MUST be used to indicate the degree of congestion by marking the bytes proportionally to the degree of congestion. This type of DSCP is denoted in this document as "encoded DSCP". == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that QNE egress SHOULD restore the original DSCP values of the remarked packets, otherwise multiple actions for the same event might occur. However, this value MAY be left in its remarking form if there is an SLA agreement between domains that a downstream domain handles the remarking problem. Note that the break "B" flag carried by the end-to-end RESERVE message MUST not be set. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2006) is 6367 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'QOS-NSLP' is mentioned on line 1671, but not defined == Unused Reference: 'RFC2119' is defined on line 3715, but no explicit reference was found in the text == Unused Reference: 'RFC2961' is defined on line 3739, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. 'QoS-NSLP') -- No information found for draft-ietf-nsis-QSpec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'QSP-T' Summary: 4 errors (**), 0 flaws (~~), 15 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS Working Group Attila Bader 2 INTERNET-DRAFT Lars Westberg 3 Ericsson 4 Expires: 23 April 2007 Georgios Karagiannis 5 University of Twente 6 Cornelia Kappler 7 Siemens 8 Tom Phelan 9 Sonus 11 October 23, 2006 13 RMD-QOSM - The Resource Management in Diffserv QOS Model 14 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 23, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 This document describes an NSIS QoS Model for networks that use the 48 Resource Management in Diffserv (RMD) concept. RMD is a technique 49 for adding admission control and preemption function to 50 Differentiated Services (Diffserv) networks. The RMD QoS Model 51 allows devices external to the RMD network to signal reservation 52 requests to edge nodes in the RMD network. The RMD Ingress edge nodes 53 classify the incoming flows into traffic classes and signals resource 54 requests for the corresponding traffic class along the data path to 55 the Egress edge nodes for each flow. Egress nodes reconstitute the 56 original requests and continue forwarding them along the data path 57 towards the final destination. In addition, RMD defines notification 58 functions to indicate overload situations within the domain to the 59 edge nodes. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .5 65 3. Overview of RMD and RMD-QOSM . . . . . . . . . . . . . .. . .5 66 3.1 RMD . . . . . . . . . . . . . . . . . . . . . . . . . . .5 67 3.2 Basic features of RMD-QOSM . . . . . . . . . . . . . . . 8 68 3.2.1 Role of the QNEs . . . . . . . .. . . . . . . . . .8 69 3.2.2 RMD-QOSM signaling . . . . . . . . . . . . . . . . 9 70 3.2.3 RMD-QOSM Applicability and considerations. . . . .11 71 4. RMD-QOSM, Detailed Description . . . . . . . . . . . .. . . 12 72 4.1 RMD-QSpec Definition . . . . . . . . . . . . . . . . . .12 73 4.1.1 RMD-QOSM QoS Description . . . . . . . . . . . . 13 74 4.1.2 PHR RMD-QOSM control information . . . . . . . . .14 75 4.1.3 PDR RMD-QOSM control information . . . . . . . . 15 76 4.2 Message format . . . . . . . . . . . . . . . . . . . . .18 77 4.3 RMD node state management . . . . . . . . . . . . . . . 18 78 4.3.1 Aggregated versus per flow reservations at the 79 QNE edges . . . . . . . . . . . . . . . . . . . . 18 80 4.3.2 Measurement-based method . . . . . . . . . . . . .20 81 4.3.3 Reservation-based method . .. . . . . . . . . . . 22 82 4.4 Transport of RMD-QOSM messages . . . . . . . . . . . . .23 83 4.5 Edge discovery and addressing of messages . . . . . . . 25 84 4.6 Operation and sequence of events . . . . . . . . . . . .26 85 4.6.1 Basic unidirectional operation . . . . . . . . . .26 86 4.6.1.1 Successful reservation. . . . . . . . . . . .27 87 4.6.1.2 Unsuccessful reservation . . . . . . . . . . 37 88 4.6.1.3 RMD refresh reservation. . . . . . . . . . . 41 89 4.6.1.4 RMD modification of aggregated reservation . 44 90 4.6.1.5 RMD release procedure. . . . . . . . . . . . 45 91 4.6.1.6 Severe congestion handling . . . . . . . . .52 92 4.6.1.7 Admission control using congestion 93 notification based on probing . . . . . . . 58 94 4.6.2 Bidirectional operation . . . . . . . . . . . . . 61 95 4.6.2.1 Successful and unsuccessful reservation . . .63 96 4.6.2.2 Refresh reservation . . . . . . . . . . . . .66 97 4.6.2.3 Modification of aggregated reservation . . . 67 98 4.6.2.4 Release procedure . . . . . . . . . . . . . .68 99 4.6.2.5 Severe congestion handling . . . . . . . . . 68 100 4.6.2.6 Admission control using congestion 101 notification based on probing . . . . . . . .71 102 4.7 Handling of additional errors . . . . . . . . . . . . . 73 103 5. Security Consideration. . . . . . . . . . . . . . . . . . . 73 104 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .76 105 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .76 106 8. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 77 107 9. Normative References . . . . . . . . . . . . . . . . . . . .78 108 10. Informative References . . . . . . . . . . . . . . . . . . 78 110 1. Introduction 112 This document describes a Next Steps In Signaling (NSIS) QoS model 113 for networks that use the Resource Management in Diffserv (RMD) 114 framework ([RMD1], [RMD2], [RMD3], [RMD4]). RMD adds admission 115 control to Diffserv networks and allows nodes external to the 116 networks to dynamically reserve resources within the Diffserv 117 domains. 119 The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP) 120 [QoS-NSLP] specifies a generic protocol for carrying Quality of 121 Service(QoS) signaling information end-to-end in an IP network. 122 Each network along the end-to-end path is expected to implement a 123 specific QoS Model (QOSM) specified by the QSpec template [QSP-T] 124 that interprets the requests and installs the necessary mechanisms, 125 in a manner that is appropriate to the technology in use in the 126 network, to ensure the delivery of the requested QoS. 128 This document specifies an NSIS QoS Model for RMD networks (RMD- 129 QOSM), and an RMD-specific QSpec (RMD-QSPec) for expressing 130 reservations in a suitable form for simple processing by internal 131 nodes. They are used in combination with the QoS-NSLP to provide 132 QoS signaling service in an RMD network. Figure 1 shows an RMD 133 network with the respective entities. 135 Stateless or reduced state Egress 136 Ingress RMD nodes Node 137 Node (Interior Nodes; I-Nodes) (Stateful 138 (Stateful | | | RMD QoS 139 RMD QoS NLSP | | | NSLP Node) 140 Node) V V V 141 +-------+ Data +------+ +------+ +------+ +------+ 142 |-------|--------|------|------|------|-------|------|---->|------| 143 | | Flow | | | | | | | | 144 |Ingress| |I-Node| |I-Node| |I-Node| |Egress| 145 | | | | | | | | | | 146 +-------+ +------+ +------+ +------+ +------+ 147 =================================================> 148 <================================================= 149 Signaling Flow 151 FIGURE 1: Actors in the RMD-QOSM 153 Internally to the RMD network, RMD-QOSM defines a scalable QoS 154 signaling model in which per-flow QoS-NSLP and NTLP states are not 155 stored in Interior nodes but per-flow signaling is performed (see 156 [QoS-NSLP]). 158 In the RMD-QOSM, only routers at the edges of a Diffserv domain 159 (Ingress and Egress nodes) support the (QoS-NSLP) stateful 160 operation, see Section 4.7 of [QoS-NSLP]. Interior nodes support 161 either the(QoS-NSLP) stateless operation, or a reduced-state 162 operation with coarser granularity than the edge nodes. 164 The remainder of this draft is structured following the suggestions 165 in Appendix A of [QSP-T] for the description of QoS Models 166 and QSPECs and their relation. 168 After the terminology in Section 2, we give an overview of RMD and 169 the RMD-QOSM in Section 3. In Section 4 we give a detailed 170 description of the RMD-QOSM, including the role of QNEs, the 171 definition of the QSpec, mapping of QSpec generic parameters onto 172 RMD-QOSM parameters, state management in QNEs, and operation and 173 sequence of events. Section 5 discusses security issues. 175 2. Terminology 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 178 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 179 in this document are to be interpreted as described in RFC 2119. 181 The terminology defined by GIST [GIST] and QoS-NSLP [QoS-NSLP] 182 applies to this draft. 184 In addition, the following terms are used: 186 Edge node: a QoS-NSLP node on the boundary of some 187 administrative domain. 189 Ingress node: An edge node that handles the traffic as it enters the 190 domain. 192 Egress node: An edge node that handles the traffic as it leaves the 193 domain. 195 Interior nodes: the set of QOS-NSLP nodes which form an 196 administrative domain, excluding the edge nodes. 198 3. Overview of RMD and RMD-QOSM 200 3.1. RMD 202 The Differentiated Services (Diffserv) architecture ([RFC2475], 203 [RFC2638]) was introduced as a result of efforts to avoid the 204 scalability and complexity problems of Intserv [RFC1633]. 205 Scalability is achieved by offering services on an aggregate 206 rather than per-flow basis and by forcing as much of the per-flow 207 state as possible to the edges of the network. The service 208 differentiation is achieved using the Differentiated Services (DS) 209 field in the IP header and the Per-Hop Behavior (PHB) as the main 210 building blocks. Packets are handled at each node according to the 211 PHB indicated by the DS field in the message header. 213 The Diffserv architecture does not specify any means for devices 214 outside the domain to dynamically reserve resources or receive 215 indications of network resource availability. In practice, service 216 providers rely on short active time Service Level Agreements (SLAs) 217 that statically define the parameters of the traffic that will be 218 accepted from a customer. 220 RMD was introduced as a method for dynamic reservation of resources 221 within a Diffserv domain. It describes a method that is able to 222 provide admission control for flows entering the domain and a 223 congestion handling algorithm that is able to terminate flows in 224 case of congestion due to a sudden failure (e.g., link, router) 225 within the domain. 227 In RMD, scalability is achieved by separating a fine-grained 228 reservation mechanism used in the edge nodes of a Diffserv domain 229 from a much simpler reservation mechanism needed in the Interior 230 nodes. Typically it is assumed that edge nodes support per- 231 flow QoS states in order to provide QoS guarantees for each flow. 232 Interior nodes use only one aggregated reservation state per traffic 233 class or no states at all. In this way it is possible to handle 234 large numbers of flows in the Interior nodes. Furthermore, due to 235 the limited functionality supported by the Interior nodes, this 236 solution allows fast processing of signaling messages. 238 The possible RMD-QOSM explicabilities are described in Section 239 3.2.3. Two main basic admission control modes are supported: 240 reservation-based and measurement-based admission control that can 241 be used in combination with a severe congestion handling solution. 242 The severe congestion handling solution is used in the situation 243 when a link/node becomes severely congested due to the fact that the 244 traffic supported by a failed link/node is rerouted and has to be 245 processed by this link/node. Furthermore, RMD-QOSM supports both 246 uni-directional and bi-directional reservations. 248 Another important feature of RMD-QOSM is that the intra-domain 249 sessions supported by the edges can be either per flow sessions or 250 per aggregate sessions. In case of the per flow intra-domain 251 sessions, the maintained per flow intra-domain states have a one-to- 252 one dependency to the per flow end-to-end states supported by the 253 same edge. In case of the per-aggregate sessions the maintained per- 254 aggregate states have a one-to-many relationship to the per flow 255 end-to-end states supported by the same edge. 257 In the reservation-based method, each Interior node maintains 258 only one reservation state per traffic class. The Ingress edge 259 nodes aggregate individual flow requests into PHB traffic classes, 260 and signal changes in the class reservations as necessary. The 261 reservation is quantified in terms of resource units (or bandwidth). 262 These resources are requested dynamically per PHB and reserved on 263 demand in all nodes in the communication path from an Ingress node 264 to an Egress node. 266 The measurement-based algorithm continuously measures traffic levels 267 and the actual available resources, and admits flows whose resource 268 needs are within what is available at the time of the request. Once 269 an admission decision is made, no record of the decision need be 270 kept. The advantage of measurement-based resource management 271 protocols is that they do not require pre-reservation state nor 272 explicit release of the reservations. Moreover, when the user 273 traffic is variable, measurement based admission control could 274 provide higher network utilization than, e.g., peak-rate 275 reservation. However, this can introduce an uncertainty in the 276 availability of the resources. 278 Two types of measurement based admission control schemes are 279 possible: 281 * Congestion notification function based on probing: 283 This method can be used to implement a simple measurement-based 284 admission control within a Diffserv domain. In this scenario the 285 interior nodes are not NSIS aware nodes. In these interior nodes 286 thresholds are set for the traffic belonging to different PHBs in 287 the measurement based admission control function. In this scenario 288 an end-to-end NSIS message is used as a probe packet, meaning that 289 the DSCP field in the header of the IP packet that carries the NSIS 290 message is re-marked when the predefined congestion threshold is 291 exceeded. Note that when the predefined congestion threshold is 292 exceeded all packets are remarked by a node, including NSIS 293 messages. In this way the edges can admit or reject flows that are 294 requesting resources. The rate of the re-marked data packets is used 295 to detect a congestion situation that can influence the admission 296 control decisions. 298 * NSIS measurement-based admission control: 300 In this case the measurement-based admission control functionality 301 is implemented in NSIS aware stateless routers. The main difference 302 between this type of admission control and the congestion 303 notification based on probing is related to the fact that this type 304 of admission control is applied mainly on NSIS aware nodes, giving 305 the possibility to apply measuring techniques, see e.g., [JaSh97], 306 [GrTs03], that are using current and past information on NSIS 307 sessions that requested resources from an NSIS aware interior node. 308 The admission decision is positive if the currently carried traffic, 309 as characterized by the measured statistics, plus the requested 310 resources for the new flow exceeds the system capacity with a 311 probability smaller than some alpha. Otherwise, the admission 312 decision is negative. 314 RMD describes the following procedures: 316 * Classification of an individual resource reservation or a resource 317 query into Per Hop Behavior (PHB) groups at the Ingress node of 318 the domain, 320 * Hop-by-hop admission control based on a PHB within the 321 domain. There are two possible modes of operation for internal 322 nodes to admit requests. One mode is the stateless or 323 measurement-based mode, where the resources within the domain are 324 queried. Another mode of operation is the reduced-state 325 reservation or reservation based mode, where the resources within 326 the domain are reserved. 328 * a method to forward the original requests across the domain up to 329 the Egress node and beyond. 331 * a congestion control algorithm that notifies the egress edge nodes 332 about congestion. It is able to terminate the appropriate number 333 of flows in case a of congestion due to a sudden failure (e.g., 334 link or router failure) within the domain. 336 3.2. Basic features of RMD-QOSM 338 3.2.1 Role of the QNEs 340 The protocol model of the RMD-QOSM is shown in Figure 2. The figure 341 shows QNI and QNR nodes, not part of the RMD network, that are the 342 ultimate initiator and receiver of the QoS reservation requests. It 343 also shows QNE nodes that are the Ingress and Egress nodes in the 344 RMD domain (QNE Ingress and QNE Egress), and QNE nodes that are 345 Interior nodes (QNE Interior). 347 All nodes of the RMD domain are usually QoS-NSLP aware nodes. 348 However, in the scenarios where the congestion notification function 349 based on probing is used, then the interior nodes are not NSIS 350 aware. Edge nodes store and maintain QoS-NSLP and NTLP states and 351 therefore are stateful nodes. The NSIS aware Interior nodes are 352 NTLP stateless. Furthermore they are either QoS-NSLP stateless (for 353 NSIS measurement-based operation), or are reduced state nodes 354 storing per PHB aggregated QoS-NSLP states (for reservation-based 355 operation). 357 |------| |-------| |------| |------| 358 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 359 | QoS | | QoS | | QoS | | QoS | 360 | | |-------| |------| |------| 361 | | |-------| |-------| |-------| |------| | | 362 | | | local |<->| local |<->| local |<->| local| | | 363 | | | QoS | | QoS | | QoS | | QoS | | | 364 | | | | | | | | | | | | 365 | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | 366 |st.ful| |st.ful | |st.less/ |st.less/ |st.ful| |st.ful| 367 | | | | |red.st.| |red.st.| | | | | 368 | | |-------| |-------| |-------| |------| | | 369 |------| |-------| |-------| |-------| |------| |------| 370 ------------------------------------------------------------------ 371 |------| |-------| |-------| |-------| |------| |------| 372 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP | 373 |st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful| 374 |------| |-------| |-------| |-------| |------| |------| 375 QNI QNE QNE QNE QNE QNR 376 (End) (Ingress) (Interior) (Interior) (Egress) (End) 378 st.ful: stateful, st.less: stateless 379 st.less red.st.: stateless or reduced state 381 Figure 2: Protocol model of stateless/reduced state operation 383 Note that the RMD domain may contain Interior nodes that are 384 not NSIS aware nodes (not shown in the figure). These nodes are 385 assumed to have sufficient capacity for flows that might be 386 admitted. Furthermore, some of these NSIS unaware nodes may be used 387 for measuring the traffic congestion level on the data path. These 388 measurements can be used by RMD-QOSM in the congestion control based 389 on probing operation and/or severe congestion operation 390 (see Section 4.6.1.6). 392 3.2.2 RMD-QOSM Signaling 394 The basic RMD-QOSM signaling is shown in Figure 3. A RESERVE 395 message is created by a QNI with an Initiator QSpec describing the 396 reservation and forwarded along the path towards the QNR. When the 397 original RESERVE message arrives at the Ingress node, an RMD-QSpec 398 is constructed based on the top-most QSpec in the message (usually 399 the Initiator QSpec). The RMD-QSpec is sent in a intra-domain, 400 independent RESERVE message through the Interior nodes towards the 401 QNR. This intra-domain RESERVE message uses the GIST datagram 402 signaling mechanism. Note that the RMD-QOSM cannot directly specify 403 that the GIST datagram mode should be used. This can however be 404 notified by using the GIST API Transfer-Attributes, such as 405 unreliable, low level of security and use of local policy. 406 Meanwhile, the original RESERVE message is sent to the Egress node 407 on the path to the QNR using the reliable transport mode of NTLP. 409 QNE QNE QNE QNE 410 Ingress Interior Interior Egress 411 NTLP stateful NTLP stateless NTLP stateless NTLP stateful 412 | | | | 413 RESERVE | | | | 414 -------->| RESERVE | | | 415 +--------------------------------------------->| 416 | RESERVE' | | | 417 +-------------->| | | 418 | | RESERVE' | | 419 | +-------------->| | 420 | | | RESERVE' | 421 | | +------------->| 422 | | | | RESERVE 423 | | | +-------> 424 | | | |RESPONSE 425 | | | |<------- 426 | | | RESPONSE | 427 |<---------------------------------------------+ 428 RESPONSE| | | | 429 <--------| | | | 431 Figure 3: Sender-initiated reservation with Reduced State Interior 432 Nodes 434 Each QoS-NSLP node on the data path processes the intra-domain 435 RESERVE message and checks the availability of resources with either 436 the reservation-based or the measurement-based method. When the 437 message reaches the Egress node, and the reservation is successful 438 in each Interior nodes, the original (end-to-end) RESERVE message is 439 forwarded to the next domain. When the Egress node receives a 440 RESPONSE message from the downstream end, it is forwarded directly 441 to the Ingress node. 443 If an intermediate node cannot accommodate the new request, it 444 indicates this by marking a single bit in the message, and continues 445 forwarding the message until the Egress node is reached. From the 446 Egress node a RESPONSE message is sent directly the Ingress node. 448 As a consequence in the stateless/reduced state domain only sender- 449 initiated reservation can be performed and functions requiring per 450 flow NTLP or QoS-NSLP states, like summary refreshes, cannot be 451 used. If per flow 452 identification, is needed, i.e., associating the flow IDs for the 453 reserved resources, Edge nodes act on behalf of Interior nodes. 455 3.2.3 RMD-QOSM Applicability and considerations 457 The RMD-QOSM is a Diffserv-based bandwidth management methodology 458 that is not able to provide a full Diffserv support. The reason of 459 this is that the RMD-QOSM concept can only support the (Expedited 460 Forwarding) EF-like functionality behavior, where the required 461 bandwidth can be signaled in the parameter. The RMD- 462 QOSM is not able to support the full set of (Assured Forwarding) AF- 463 like functionality where multiple PHBs/DSCPs are used. This is 464 because the signaled parameter should contain two 465 token buckets needed to signal AF in full generality. Note however, 466 that RMD-QOSM could also support a single AF PHB, when the traffic 467 or the upper limit of the traffic can be characterized by a single 468 bandwidth parameter. 470 A very important consideration on using RMD-QOSM is that within one 471 RMD domain only one of the following RMD-QOSM schemes can be used at 472 a time. Thus a RMD router can never process and use two different 473 RMD-QOSM signaling schemes at the same time. The operator of an RMD 474 domain has to pre-configure all routers in the domain such that 475 within one RMD domain only one of the below described RMD-QOSM 476 schemes can be used at a time. 478 The available RMD-QOSM signaling schemes are: 480 * per flow congestion notification based on probing (see 481 Sections 4.3.2, 4.6.1.7, 4.6.2.6). Note that this scheme uses for 482 severe congestion handling the Severe congestion handling by 483 proportional data packet marking, see Section 4.6.1.6.2, 484 4.6.2.5.2) 486 * per flow RMD NSIS measurement based admission control (see 487 Sections 4.3.2, 4.6.1, 4.6.2). Note that this scheme uses for 488 severe congestion handling the Severe congestion handling by 489 proportional data packet marking, see Section 4.6.1.6.2, 490 4.6.2.5.2) 492 * per flow RMD reservation based in combination with severe 493 congestion handling by the RMD-QOSM refresh procedure (see 494 Sections 4.3.3, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this 495 scheme uses for severe congestion handling the Severe congestion 496 handling by the RMD-QOSM refresh procedure, see Section 4.6.1.6.1, 497 4.6.2.5.1) 499 * per flow RMD reservation based in combination with severe 500 congestion handling by proportional data packet marking procedure 501 (see Sections 4.3.3, 4.6.1, 4.6.1.6.2, 4.6.2.5.2). Note that 502 this scheme uses for severe congestion handling the Severe 503 congestion handling by proportional data packet marking procedure, 504 see Section 4.6.1.6.2, 4.6.2.5.2) 506 * per aggregate RMD reservation based in combination with 507 severe congestion handling by the RMD-QOSM refresh procedure (see 508 Sections 4.3.1, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this 509 scheme uses for severe congestion handling the Severe congestion 510 handling by the RMD-QOSM refresh procedure, see Section 4.6.1.6.1, 511 4.6.2.5.1) 513 * per aggregate RMD reservation based in combination with 514 severe congestion handling by proportional data packet marking 515 procedure (see Sections 4.3.1, 4.6.1, 4.6.1.6.2, 4.6.2.5.2). 516 Note that this scheme uses for severe congestion handling the 517 Severe congestion handling by proportional data packet marking 518 procedure, see Section 4.6.1.6.2, 4.6.2.5.2) 520 4. RMD-QOSM, Detailed Description 522 This section describes the RMD-QOSM in more detail. In particular, 523 it defines the role of stateless and reduced-state QNEs, the 524 RMD-QOSM QSpec Object, the format of the RMD-QOSM QoS-NSLP messages 525 and how QSpecs are processed and used in different protocol 526 operations. 528 4.1. RMD-QSpec Definition 530 The RMD-QOSM uses the QSpec format specified in [QSP-T]. 532 The and used by the RMD-QOSM are 533 assigned by IANA, see Section 6. The 534 contains the following fields: 536 = 538 The Per Hop Reservation container (PHR container) and 539 the Per Domain Reservation container (PDR container) are specified 540 in Section 4.1.2 and 4.1.3, respectively. The 541 contains the QoS specific control information for intra-domain 542 communication and reservation. The contains 543 additional control information that is needed for edge-to-edge 544 communication. The parameter IDs used by the and 545 are assigned by IANA, see Section 6. For clarity 546 Reasons we will assigned temporarily, the following names to the PHR 547 and PDR containers: 548 * PHR_1 to PHR_3 for the 549 * PDR_4 to PDR_10 for the 550 After IANA assigns the proper values to the PHR and PDR containers, 551 then the above list has to be replaced accordingly. 553 The when used with RMD-QOSM contains the that is specified in Section 4.1.1. The field, the are used and 556 processed by the Edge and Interior nodes. The field 557 is only processed by Edge nodes. 559 4.1.1. RMD-QOSM QoS Description 561 The RMD-QOSM QoS Description carried by the RESERVE message only 562 contains the QoS Desired object [QSP-T]. The QoS Reserved object is 563 carried by the RESPONSE message. 565 = for RESERVE 567 = for RESPONSE 569 = 571 = 573 The bit format of the , (see 574 Figure 4 and Figure 5) and complies to the bit 575 format specified in [QSP-T]. Note that for the RMD-QOSM a 576 reservation established without an parameter is 577 equivalent to a reservation established with an 578 whose value is 1. 580 0 1 581 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | DSCP |0 0 0 0 0 0 0 0 X 0| 584 +---+---+---+---+---+---+---+---+ 586 Figure 4: DSCP parameter 588 0 1 589 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | PHB ID code |0 0 X 0| 592 +---+---+---+---+---+---+---+---+ 594 Figure 5: PHB ID Code parameter 596 4.1.2. PHR Container 598 This section describes the parameters used by the PHR container. 600 = , ,, 601 , ,