idnits 2.17.1 draft-ietf-nsis-rmd-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 107 pages 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 IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 March 2010) is 5163 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2215' is mentioned on line 1452, but not defined == Missing Reference: 'RFC5226' is mentioned on line 4013, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Missing Reference: 'I-D.ietf-nsis-qspec' is mentioned on line 4019, but not defined == Unused Reference: 'RFC 2215' is defined on line 4161, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 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 Intended status: Experimental Ericsson 4 Expires: 1 September 2010 Georgios Karagiannis 5 University of Twente 6 Cornelia Kappler 7 DeZem GmbH 8 Tom Phelan 9 Sonus 11 1 March 2010 13 RMD-QOSM - The Resource Management in Diffserv QOS Model 14 16 Abstract 18 This document describes an NSIS QoS Model for networks that use the 19 Resource Management in Diffserv (RMD) concept. RMD is a technique 20 for adding admission control and pre-emption function to 21 Differentiated Services (Diffserv) networks. The RMD QoS Model 22 allows devices external to the RMD network to signal reservation 23 requests to edge nodes in the RMD network. The RMD Ingress edge nodes 24 classify the incoming flows into traffic classes and signals resource 25 requests for the corresponding traffic class along the data path to 26 the Egress edge nodes for each flow. Egress nodes reconstitute the 27 original requests and continue forwarding them along the data path 28 towards the final destination. In addition, RMD defines notification 29 functions to indicate overload situations within the domain to the 30 edge nodes. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on September 1, 2010. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 85 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .5 86 3. Overview of RMD and RMD-QOSM . . . . . . . . . . . . . .. . .6 87 3.1 RMD . . . . . . . . . . . . . . . . . . . . . . . . . . .6 88 3.2 Basic features of RMD-QOSM . . . . . . . . . . . . . . . 9 89 3.2.1 Role of the QNEs . . . . . . . .. . . . . . . . . .9 90 3.2.2 RMD-QOSM/QoS-NSLP signaling . . . . . . . . . . . 10 91 3.2.3 RMD-QOSM Applicability and considerations. . . . .11 92 4. RMD-QOSM, Detailed Description . . . . . . . . . . . .. . . 14 93 4.1 RMD-QSpec Definition . . . . . . . . . . . . . . . . . .14 94 4.1.1 RMD-QOSM QoS Desired and QoS Available . . . . . .14 95 4.1.2 PHR Container . . . . . . . . . . . . . . . . . . 15 96 4.1.3 PDR Container . . . . . . . . . . . . . . . . . .18 97 4.2 Message format . . . . . . . . . . . . . . . . . . . . .20 98 4.3 RMD node state management . . . . . . . . . . . . . . . 20 99 4.3.1 Aggregated versus per flow reservations at the 100 QNE edges . . . . . . . . . . . . . . . . . . . . 20 101 4.3.2 Measurement-based method . . . . . . . . . . . . .22 102 4.3.3 Reservation-based method . .. . . . . . . . . . . 24 103 4.4 Transport of RMD-QOSM messages . . . . . . . . . . . . .25 104 4.5 Edge discovery and addressing of messages . . . . . . . 27 105 4.6 Operation and sequence of events . . . . . . . . . . . .28 106 4.6.1 Basic unidirectional operation . . . . . . . . . .28 107 4.6.1.1 Successful reservation. . . . . . . . . . . .30 108 4.6.1.2 Unsuccessful reservation . . . . . . . . . . 41 109 4.6.1.3 RMD refresh reservation. . . . . . . . . . . 44 110 4.6.1.4 RMD modification of aggregated reservation . 47 111 4.6.1.5 RMD release procedure. . . . . . . . . . . . 48 112 4.6.1.6 Severe congestion handling . . . . . . . . .56 113 4.6.1.7 Admission control using congestion 114 notification based on probing . . . . . . . 62 115 4.6.2 Bidirectional operation . . . . . . . . . . . . . 65 116 4.6.2.1 Successful and unsuccessful reservation . . .68 117 4.6.2.2 Refresh reservation . . . . . . . . . . . . .72 118 4.6.2.3 Modification of aggregated reservation . . . 72 119 4.6.2.4 Release procedure . . . . . . . . . . . . . .73 120 4.6.2.5 Severe congestion handling . . . . . . . . . 74 121 4.6.2.6 Admission control using congestion 122 notification based on probing . . . . . . . .76 123 4.7 Handling of additional errors . . . . . . . . . . . . . 78 124 5. Security Consideration. . . . . . . . . . . . . . . . . . . 78 125 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .82 126 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .83 127 8. Authors` Addresses. . . . . . . . . . . . . . . . . . . . . 83 128 9. Normative References . . . . . . . . . . . . . . . . . . . .84 129 10. Informative References . . . . . . . . . . . . . . . . . . 84 131 1. Introduction 133 This document describes a Next Steps In Signaling (NSIS) QoS model 134 for networks that use the Resource Management in Diffserv (RMD) 135 framework ([RMD1], [RMD2], [RMD3], [RMD4]). RMD adds admission 136 control to Diffserv networks and allows nodes external to the 137 networks to dynamically reserve resources within the Diffserv 138 domains. 140 The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP) 141 [QoS-NSLP] specifies a generic protocol for carrying Quality of 142 Service(QoS) signaling information end-to-end in an IP network. 143 Each network along the end-to-end path is expected to implement a 144 specific QoS Model (QOSM) specified by the QSpec template [QSP-T] 145 that interprets the requests and installs the necessary mechanisms, 146 in a manner that is appropriate to the technology in use in the 147 network, to ensure the delivery of the requested QoS. 148 This document specifies an NSIS QoS Model for RMD networks (RMD- 149 QOSM), and an RMD-specific QSpec (RMD-QSPec) for expressing 150 reservations in a suitable form for simple processing by internal 151 nodes. 153 They are used in combination with the QoS-NSLP to provide 154 QoS signaling service in an RMD network. Figure 1 shows an RMD 155 network with the respective entities. 157 Stateless or reduced state Egress 158 Ingress RMD nodes Node 159 Node (Interior Nodes; I-Nodes) (Stateful 160 (Stateful | | | RMD QoS 161 RMD QoS NLSP | | | NSLP Node) 162 Node) V V V 163 +-------+ Data +------+ +------+ +------+ +------+ 164 |-------|--------|------|------|------|-------|------|---->|------| 165 | | Flow | | | | | | | | 166 |Ingress| |I-Node| |I-Node| |I-Node| |Egress| 167 | | | | | | | | | | 168 +-------+ +------+ +------+ +------+ +------+ 169 =================================================> 170 <================================================= 171 Signaling Flow 173 Figure 1: Actors in the RMD-QOSM 175 Many network scenarios, such as the "Wired Part of Wireless Network" 176 scenario, which is described in section 8.4 of [RFC3726] require that 177 the impact of the used QoS signaling protocol on the network 178 performance should be minimised. In such network scenarios, the 179 performance of each network node that is used in a communication path 180 has an impact on the end-to-end performance. As such, the end-to-end 181 performance of the communication path can be improved by optimizing 182 the performance of the interior nodes. One of the factors that can 183 contribute to this optimization is the minimization of the QoS 184 signalling protocol processing load and the minimization of the 185 number of states on each interior node. 186 Another requirement that is imposed by such network scenarios is that 187 whenever a severe congestion situation occurs in the network, the 188 used QoS signaling protocol shoud be able to solve them. In case of a 189 route change or link failure a severe congestion situation may occur 190 in the network. Typically, routing algorithms are able to adapt and 191 change their routing decisions to reflect changes in the topology and 192 traffic volume. In such situations the re-routed traffic will have to 193 follow a new path. Interior nodes located on this new path may become 194 overloaded, since they suddenly might need to support more traffic 195 than they have capacity for. These severe congestion situations will 196 severely affect the overall performance of the traffic passing 197 through such nodes. 199 RMD-QoSM is an edge-to-edge (intra-domain) QoS Model that in 200 combination with the QoS-NSLP and QSPEC specifications is designed to 201 support the requirements mentioned above: 203 o Minimal Impact on Interior Node Performance; 204 o Increase of scalability; 205 o Ability to deal with severe congestion 207 Internally to the RMD network, RMD-QOSM together with QoS-NSLP 208 [QoS-NSLP] defines a scalable QoS signaling model in which per-flow 209 QoS-NSLP and NTLP states are not stored in Interior nodes but 210 per-flow signaling is performed (see [QoS-NSLP]) at the edges. 212 In the RMD-QOSM, only routers at the edges of a Diffserv domain 213 (Ingress and Egress nodes) support the (QoS-NSLP) stateful 214 operation, see Section 4.7 of [QoS-NSLP]. Interior nodes support 215 either the(QoS-NSLP) stateless operation, or a reduced-state 216 operation with coarser granularity than the edge nodes. 218 After the terminology in Section 2, we give an overview of RMD and 219 the RMD-QOSM in Section 3. This document specifies several RMD- 220 QOSM/QoS-NSLP signaling schemes. In particular, Section 3.2.3 221 identifies which combination of sections are used for the 222 specification of each RMD-QOSM/QoS-NSLP signaling scheme. In Section 223 4 we give a detailed description of the RMD-QOSM, including the role 224 of QNEs, the definition of the QSpec, mapping of QSpec generic 225 parameters onto RMD-QOSM parameters, state management in QNEs, and 226 operation and sequence of events. Section 5 discusses security 227 issues. 229 2. Terminology 231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 233 this document are to be interpreted as described in [RFC2119]. 235 The terminology defined by GIST [GIST] and QoS-NSLP [QoS-NSLP] 236 applies to this draft. 238 In addition, the following terms are used: 240 NSIS domain: a NSIS signalling capable domain. 242 RMD domain: a NSIS domain that is capable of supporting the RMD-QOSM 243 signalling and operations. 245 Edge node: a QoS-NSLP node on the boundary of some 246 administrative domain that connects one NSIS domain to a node 247 either in another NSIS domain or in a non NSIS domain. 249 NSIS aware node: a node that is aware of NSIS signalling and RMD- 250 QOSM operations, such as severe congestion detection and DSCP 251 marking. 253 NSIS unaware: a node that is unware of NSIS signalling, but is 254 aware of RMD-QOSM operations such as severe congestion detection 255 and DSCP marking. 257 Ingress node: An edge node in its role in handling the traffic 258 as it enters the NSIS domain. 260 Egress node: An edge node in its role in handling the traffic 261 as it leaves the NSIS domain. 262 Interior node: a node in a NSIS domain that is not an edge node. 264 Congestion: is a temporal network state that occurs when the traffic 265 (or when traffic associated with a particular PHB) passing through a 266 link is slightly higher than the capacity allocated for the link (or 267 allocated for the particular PHB). If no measures are taken than the 268 traffic passing through this link may temporarily slightly degrade in 269 QoS. This type of congestion is usually solved using admission 270 control mechanisms. 272 Severe congestion: is a congestion that occurs when a node or link 273 fails and the traffic is rerouter through another node or link. If no 274 measures are taken than the node or the link can become severely 275 congested and all traffic passing through the node or link will 276 severely degrade in QoS. This type of congestion cannot be solved 277 using admission control mechanisms. 279 3. Overview of RMD and RMD-QOSM 281 3.1. RMD 283 The Differentiated Services (Diffserv) architecture ([RFC2475], 284 [RFC2638]) was introduced as a result of efforts to avoid the 285 scalability and complexity problems of Intserv [RFC1633]. 286 Scalability is achieved by offering services on an aggregate 287 rather than per-flow basis and by forcing as much of the per-flow 288 state as possible to the edges of the network. The service 289 differentiation is achieved using the Differentiated Services (DS) 290 field in the IP header and the Per-Hop Behavior (PHB) as the main 291 building blocks. Packets are handled at each node according to the 292 PHB indicated by the DS field in the message header. 294 The Diffserv architecture does not specify any means for devices 295 outside the domain to dynamically reserve resources or receive 296 indications of network resource availability. In practice, service 297 providers rely on short active time Service Level Agreements (SLAs) 298 that statically define the parameters of the traffic that will be 299 accepted from a customer. 301 RMD was introduced as a method for dynamic reservation of resources 302 within a Diffserv domain. It describes a method that is able to 303 provide admission control for flows entering the domain and a 304 congestion handling algorithm that is able to terminate flows in 305 case of congestion due to a sudden failure (e.g., link, router) 306 within the domain. 308 In RMD, scalability is achieved by separating a fine-grained 309 reservation mechanism used in the edge nodes of a Diffserv domain 310 from a much simpler reservation mechanism needed in the Interior 311 nodes. Typically it is assumed that edge nodes support per- 312 flow QoS states in order to provide QoS guarantees for each flow. 313 Interior nodes use only one aggregated reservation state per traffic 314 class or no states at all. In this way it is possible to handle 315 large numbers of flows in the Interior nodes. Furthermore, due to 316 the limited functionality supported by the Interior nodes, this 317 solution allows fast processing of signaling messages. 319 The possible RMD-QOSM applicabilities are described in Section 320 3.2.3. Two main basic admission control modes are supported: 321 reservation-based and measurement-based admission control that can 322 be used in combination with a severe congestion handling solution. 323 The severe congestion handling solution is used in the situation 324 that a link/node becomes severely congested due to the fact that the 325 traffic supported by a failed link/node is rerouted and has to be 326 processed by this link/node. Furthermore, RMD-QOSM supports both 327 uni-directional and bi-directional reservations. 329 Another important feature of RMD-QOSM is that the intra-domain 330 sessions supported by the edges can be either per flow sessions or 331 per aggregate sessions. In case of the per flow intra-domain 332 sessions, the maintained per flow intra-domain states have a one-to- 333 one dependency to the per flow end-to-end states supported by the 334 same edge. In case of the per-aggregate sessions the maintained per- 335 aggregate states have a one-to-many relationship to the per flow 336 end-to-end states supported by the same edge. 338 In the reservation-based method, each Interior node maintains 339 only one reservation state per traffic class. The Ingress edge 340 nodes aggregate individual flow requests into PHB traffic classes, 341 and signal changes in the class reservations as necessary. The 342 reservation is quantified in terms of resource units (or bandwidth). 343 These resources are requested dynamically per PHB and reserved on 344 demand in all nodes in the communication path from an Ingress node 345 to an Egress node. 347 The measurement-based algorithm continuously measures traffic levels 348 and the actual available resources, and admits flows whose resource 349 needs are within what is available at the time of the request. 351 Once an admission decision is made, no record of the decision need be 352 kept at the interior nodes. The advantage of measurement-based 353 resource management protocols is that they do not require pre- 354 reservation state nor explicit release of the reservations at the 355 interior nodes. Moreover, when the user traffic is variable, 356 measurement based admission control could provide higher network 357 utilization than, e.g., peak-rate reservation. However, this can 358 introduce an uncertainty in the availability of the resources. 360 Two types of measurement based admission control schemes are 361 possible: 363 * Congestion notification function based on probing: 365 This method can be used to implement a simple measurement-based 366 admission control within a Diffserv domain. In this scenario the 367 interior nodes are not NSIS aware nodes. In these interior nodes 368 thresholds are set for the traffic belonging to different PHBs in 369 the measurement based admission control function. In this scenario 370 an end-to-end NSIS message is used as a probe packet, meaning that 371 the DSCP field in the header of the IP packet that carries the NSIS 372 message is re-marked when the predefined congestion threshold is 373 exceeded. Note that when the predefined congestion threshold is 374 exceeded all packets are remarked by a node, including NSIS 375 messages. In this way the edges can admit or reject flows that are 376 requesting resources. The frequency and durations that the congestion 377 level is above the threshold resulting in remarking, is tracked and 378 used to influence the admission control decisions. 380 * NSIS measurement-based admission control: 382 In this case the measurement-based admission control functionality 383 is implemented in NSIS aware stateless routers. The main difference 384 between this type of admission control and the congestion 385 notification based on probing is related to the fact that this type 386 of admission control is applied mainly on NSIS aware nodes, giving 387 the possibility to apply measuring techniques, see e.g., [JaSh97], 388 [GrTs03], that are using current and past information on NSIS 389 sessions that requested resources from an NSIS aware interior node. 390 The admission decision is positive if the currently carried traffic, 391 as characterized by the measured statistics, plus the requested 392 resources for the new flow exceeds the system capacity with a 393 probability smaller than some alpha. Otherwise, the admission 394 decision is negative. 396 RMD describes the following procedures: 398 * Classification of an individual resource reservation or a resource 399 query into Per Hop Behavior (PHB) groups at the Ingress node of 400 the domain, 402 * Hop-by-hop admission control based on a PHB within the 403 domain. There are two possible modes of operation for internal 404 nodes to admit requests. One mode is the stateless or 405 measurement-based mode, where the resources within the domain are 406 queried. Another mode of operation is the reduced-state 407 reservation or reservation based mode, where the resources within 408 the domain are reserved. 410 * a method to forward the original requests across the domain up to 411 the Egress node and beyond. 413 * a congestion control algorithm that notifies the egress edge nodes 414 about congestion. It is able to terminate the appropriate number 415 of flows in case a of congestion due to a sudden failure (e.g., 416 link or router failure) within the domain. 418 3.2. Basic features of RMD-QOSM 420 3.2.1 Role of the QNEs 422 The protocol model of the RMD-QOSM is shown in Figure 2. The figure 423 shows QNI and QNR nodes, not part of the RMD network, that are the 424 ultimate initiator and receiver of the QoS reservation requests. It 425 also shows QNE nodes that are the Ingress and Egress nodes in the 426 RMD domain (QNE Ingress and QNE Egress), and QNE nodes that are 427 Interior nodes (QNE Interior). 429 All nodes of the RMD domain are usually QoS-NSLP aware nodes. 430 However, in the scenarios where the congestion notification function 431 based on probing is used, then the interior nodes are not NSIS 432 aware. Edge nodes store and maintain QoS-NSLP and NTLP states and 433 therefore are stateful nodes. The NSIS aware Interior nodes are 434 NTLP stateless. Furthermore they are either QoS-NSLP stateless (for 435 NSIS measurement-based operation), or are reduced state nodes 436 storing per PHB aggregated QoS-NSLP states (for reservation-based 437 operation). 439 Note that the RMD domain MAY contain Interior nodes that are 440 not NSIS aware nodes (not shown in the figure). These nodes are 441 assumed to have sufficient capacity for flows that might be 442 admitted. Furthermore, some of these NSIS unaware nodes MAY be used 443 for measuring the traffic congestion level on the data path. These 444 measurements can be used by RMD-QOSM in the congestion control based 445 on probing operation and/or severe congestion operation 446 (see Section 4.6.1.6). 448 |------| |-------| |------| |------| 449 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 450 | QoS | | QoS | | QoS | | QoS | 451 | | |-------| |------| |------| 452 | | |-------| |-------| |-------| |------| | | 453 | | | local |<->| local |<->| local |<->| local| | | 454 | | | QoS | | QoS | | QoS | | QoS | | | 455 | | | | | | | | | | | | 456 | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | 457 |st.ful| |st.ful | |st.less/ |st.less/ |st.ful| |st.ful| 458 | | | | |red.st.| |red.st.| | | | | 459 | | |-------| |-------| |-------| |------| | | 460 |------| |-------| |-------| |-------| |------| |------| 461 ------------------------------------------------------------------ 462 |------| |-------| |-------| |-------| |------| |------| 463 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP | 464 |st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful| 465 |------| |-------| |-------| |-------| |------| |------| 466 QNI QNE QNE QNE QNE QNR 467 (End) (Ingress) (Interior) (Interior) (Egress) (End) 469 st.ful: stateful, st.less: stateless 470 st.less red.st.: stateless or reduced state 472 Figure 2: Protocol model of stateless/reduced state operation 474 3.2.2 RMD-QOSM/QoS-NSLP Signaling 476 The basic RMD-QOSM/QoS-NSLP signaling is shown in Figure 3. The 477 signalling scenarios are accomplished using the QoS-NSLP processing 478 rules defined in [QoS-NSLP], in combination with the RMF triggers 479 sent via the QoS-NSLP-RMF API described in [QoS-NSLP]. A RESERVE 480 message is created by a QNI with an Initiator QSpec describing the 481 reservation and forwarded along the path towards the QNR. When the 482 original RESERVE message arrives at the Ingress node, an RMD-QSpec 483 is constructed based on the initial QSpec in the message (usually 484 the Initiator QSpec). The RMD-QSpec is sent in a intra-domain, 485 independent RESERVE message through the Interior nodes towards the 486 QNR. This intra-domain RESERVE message uses the GIST datagram 487 signaling mechanism. Note that the RMD-QOSM cannot directly specify 488 that the GIST datagram mode SHOULD be used. This can however be 489 notified by using the GIST API Transfer-Attributes, such as 490 unreliable, low level of security and use of local policy. 491 Meanwhile, the original RESERVE message is sent to the Egress node 492 on the path to the QNR using the reliable transport mode of NTLP. 494 Each QoS-NSLP node on the data path processes the intra-domain 495 RESERVE message and checks the availability of resources with either 496 the reservation-based or the measurement-based method. 498 QNE Ingress QNE Interior QNE Interior QNE Egress 499 NTLP stateful NTLP stateless NTLP stateless NTLP stateful 500 | | | | 501 RESERVE | | | | 502 -------->| RESERVE | | | 503 +--------------------------------------------->| 504 | RESERVE` | | | 505 +-------------->| | | 506 | | RESERVE` | | 507 | +-------------->| | 508 | | | RESERVE` | 509 | | +------------->| 510 | | | RESPONSE`| 511 |<---------------------------------------------+ 512 | | | | RESERVE 513 | | | +-------> 514 | | | |RESPONSE 515 | | | |<------- 516 | | | RESPONSE | 517 |<---------------------------------------------+ 518 RESPONSE| | | | 519 <--------| | | | 521 Figure 3: Sender-initiated reservation with Reduced State Interior 522 Nodes 524 When the message reaches the Egress node, and the reservation is 525 successful in each Interior node, an intra-domain (local) RESPONSE` 526 is sent towards the ingress node and the original (end-to-end) 527 RESERVE message is forwarded to the next domain. When the Egress 528 node receives a RESPONSE message from the downstream end, it is 529 forwarded directly to the Ingress node. 531 If an intermediate node cannot accommodate the new request, it 532 indicates this by marking a single bit in the message, and continues 533 forwarding the message until the Egress node is reached. From the 534 Egress node an intra-domain RESPONSE` and an original RESPONSE 535 message are sent directly to the Ingress node. 537 As a consequence in the stateless/reduced state domain only sender- 538 initiated reservation can be performed and functions requiring per 539 flow NTLP or QoS-NSLP states, like summary and reduced refreshes, 540 cannot be used. If per flow identification, is needed, i.e., 541 associating the flow IDs for the reserved resources, Edge nodes act 542 on behalf of Interior nodes. 544 3.2.3 RMD-QOSM Applicability and considerations 546 The RMD-QOSM is a Diffserv-based bandwidth management methodology 547 that is not able to provide a full Diffserv support. 549 The reason of this is that the RMD-QOSM concept can only support the 550 (Expedited Forwarding) EF-like functionality behavior, but is not 551 able to support the full set of (Assured Forwarding) AF-like 552 functionality. The bandwidth information REQUIRED by the EF-like 553 functionality behaviour can be supported by RMD-QOSM carrying the 554 bandwidth information in the parameter, see [QSP-T]. 555 The full set of (Assured Forwarding) AF-like functionality requires 556 information that is specified in two token buckets. The RMD-QOSM is 557 not supporting the use of two token buckets and therefore, it is not 558 able to support the full set of AF-functionality. Note however, 559 that RMD-QOSM could also support a single AF PHB, when the traffic 560 or the upper limit of the traffic can be characterized by a single 561 bandwidth parameter. 563 The RMD domain MUST be engineered in such a way that each QNE Ingress 564 maintains information about the smallest MTU that is supported on the 565 links within the RMD domain. 567 A very important consideration on using RMD-QOSM is that within one 568 RMD domain only one of the following RMD-QOSM schemes can be used at 569 a time. Thus a RMD router can never process and use two different 570 RMD-QOSM signaling schemes at the same time. The operator of an RMD 571 domain has to pre-configure all routers in the domain such that 572 within one RMD domain only one of the below described RMD-QOSM 573 schemes can be used at a time. Note however, that there is no single 574 to implement scheme variant. 576 The congestion situations, see Section 2, are solved using admission 577 control mechanism, e.g., "per flow congestion notification based on 578 probing", while the severe congestion situations, see Section 2, are 579 solved using the severe congestion handling mechanisms, e.g., "Severe 580 congestion handling by proportional data packet marking". 582 The RMD domain MUST be engineered in such a way that RMD-QOSM 583 messages could be transported using the GIST Query and 584 Data messages in Q-mode, see [GIST]. This means that the Path MTU 585 MUST be engineered in such a way that the RMD-QOSM message are 586 transported without fragmentation. Furthermore, the RMD domain MUST 587 be engineered in such a way to guarantee capacity for the GIST 588 Query and Data messages in Q-mode, within the rate control limits 589 imposed by GIST, see [GIST]. 591 The RMD domain has to be configured such that the GIST context-free 592 flag (C-flag) MUST be set (C=1) for Query messages and Data 593 messages sent in Q-mode, see [GIST]. 595 It is important to note that the concepts described in Sections 596 4.6.1.6.2, 4.6.2.5.2, 4.6.1.6.2 and 4.6.2.5.2 contributed to 597 the PCN WG standardisation. 599 The available RMD-QOSM/QoS-NSLP signaling schemes are: 601 * "per flow congestion notification based on probing" (see 602 Sections 4.3.2, 4.6.1.7., 4.6.2.6.). Note that this scheme uses for 603 severe congestion handling the "Severe congestion handling by 604 proportional data packet marking", see Section 4.6.1.6.2, 605 4.6.2.5.2). Furthermore, the interior nodes are considered to be 606 Diffserv aware, but NSIS unaware nodes, see Section 4.3.2. 608 * "per flow RMD NSIS measurement based admission control" (see 609 Sections 4.3.2, 4.6.1, 4.6.2). Note that this scheme uses for 610 severe congestion handling the "Severe congestion handling by 611 proportional data packet marking", see Section 4.6.1.6.2, 612 4.6.2.5.2). Furthermore, the interior nodes are considered to be 613 NSIS aware nodes, see Section 4.3.2. 615 * "per flow RMD reservation based" in combination with "severe 616 congestion handling by the RMD-QOSM refresh procedure" (see 617 Sections 4.3.3, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this 618 scheme uses for severe congestion handling the "Severe congestion 619 handling by the RMD-QOSM refresh" procedure, see Section 4.6.1.6.1, 620 4.6.2.5.1). Furthermore, the intra-domain sessions supported by the 621 edge nodes are per flow sessions, see Section 4.3.3. 623 * "per flow RMD reservation based" in combination with "severe 624 congestion handling by proportional data packet marking" procedure 625 (see Sections 4.3.3, 4.6.1, 4.6.1.6.2, 4.6.2.5.2). Note that 626 this scheme uses for severe congestion handling the "Severe 627 congestion handling by proportional data packet marking" procedure, 628 see Section 4.6.1.6.2, 4.6.2.5.2). Furthermore, the intra-domain 629 sessions supported by the edge nodes are per flow sessions, see 630 Section 4.3.3. 632 * "per aggregate RMD reservation based" in combination with 633 "severe congestion handling by the RMD-QOSM refresh procedure" (see 634 Sections 4.3.1, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this 635 scheme uses for severe congestion handling the "Severe congestion 636 handling by the RMD-QOSM refresh" procedure, see Section 4.6.1.6.1, 637 4.6.2.5.1). Furthermore, the intra-domain sessions supported by the 638 edge nodes are per aggregate sessions, see Section 4.3.1. 640 * "per aggregate RMD reservation based" in combination with 641 "severe congestion handling by proportional data packet marking" 642 procedure (see Sections 4.3.1, 4.6.1, 4.6.1.6.2, 4.6.2.5.2). 643 Note that this scheme uses for severe congestion handling the 644 "Severe congestion handling by proportional data packet marking" 645 procedure, see Section 4.6.1.6.2, 4.6.2.5.2). Furthermore, the 646 intra-domain sessions supported by the edge nodes are per aggregate 647 sessions, see Section 4.3.1. 649 4. RMD-QOSM, Detailed Description 651 This section describes the RMD-QOSM in more detail. In particular, 652 it defines the role of stateless and reduced-state QNEs, the 653 RMD-QOSM QSpec Object, the format of the RMD-QOSM QoS-NSLP messages 654 and how QSpecs are processed and used in different protocol 655 operations. 657 4.1. RMD-QSpec Definition 659 The RMD-QOSM uses the QSpec format specified in [QSP-T]. 660 The Initiator/Local QSPEC bit, i.e., is set to "Local" (i.e., 661 "1") and the is set as follows: 662 * Message Sequence = 0: Sender initiated 663 * Object combination = 0: for RESERVE and 664 for RESPONSE 666 The used by RMD-QOSM is the default version, i.e., 667 "0", see [QSP-T]. The value used by the RMD-QOSM is 668 specified in [QSP-T] and is equal to: "2". 669 The contains the following fields: 671 = 673 The Per Hop Reservation container (PHR container) and 674 the Per Domain Reservation container (PDR container) are specified 675 in Section 4.1.2 and 4.1.3, respectively. The 676 contains the traffic handling directives for intra-domain 677 communication and reservation. The contains 678 additional traffic handling directives that is needed for 679 edge-to-edge communication. The parameter IDs used by the and are assigned by IANA, see Section 6. 682 The RMD-QOSM and , are specified in 683 Section 4.1.1. The RMD-QOSM and and the 684 are used and processed by the Edge and Interior 685 nodes. The field is only processed by Edge nodes. 687 4.1.1. RMD-QOSM QoS Desired and QoS Reserved 689 The RESERVE message contains only the QoS Desired object [QSP-T]. The 690 QoS Reserved object is carried by the RESPONSE message. 692 In RMD-QOSM the and objects contain the 693 following parameters: 695 = 696 = 697 The bit format of the (see [QSP-T] and Figure 4 and 698 Figure 5) and complies to the bit format 699 specified in [QSP-T]. 701 Note that for the RMD-QOSM a reservation established without an 702 parameter is equivalent to a reservation 703 established with an whose value is 1. 705 0 1 706 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | DSCP |0 0 0 0 0 0 0 0 X 0| 709 +---+---+---+---+---+---+---+---+ 711 Figure 4: DSCP parameter 713 0 1 714 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | PHB ID code |0 0 X X| 717 +---+---+---+---+---+---+---+---+ 719 Figure 5: PHB ID Code parameter 721 4.1.2. PHR Container 723 This section describes the parameters used by the PHR container, 724 which are used by the RMD-QOSM functionality available at the 725 Interior nodes. 727 = , , ,, 728 , , ,