idnits 2.17.1 draft-ietf-nsis-rmd-20.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 13) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 115 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 == Line 807 has weird spacing: '...or node is de...' == Line 965 has weird spacing: '...or node is de...' == Line 1835 has weird spacing: '...rameter can b...' -- 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 (06 May 2010) is 5102 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 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: 06 November 2010 Georgios Karagiannis 5 University of Twente 6 Cornelia Kappler 7 DeZem GmbH 8 Tom Phelan 9 Sonus 11 06 May 2010 13 RMD-QOSM - The NSIS 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 November 06, 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 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .5 74 3. Overview of RMD and RMD-QOSM . . . . . . . . . . . . . .. . .6 75 3.1 RMD . . . . . . . . . . . . . . . . . . . . . . . . . . .6 76 3.2 Basic features of RMD-QOSM . . . . . . . . . . . . . . . 9 77 3.2.1 Role of the QNEs . . . . . . . .. . . . . . . . . .9 78 3.2.2 RMD-QOSM/QoS-NSLP signaling . . . . . . . . . . . 10 79 3.2.3 RMD-QOSM Applicability and considerations. . . . .12 80 4. RMD-QOSM, Detailed Description . . . . . . . . . . . .. . . 14 81 4.1 RMD-QSpec Definition . . . . . . . . . . . . . . . . . .14 82 4.1.1 RMD-QOSM QoS Desired and QoS Available . . . . . .15 83 4.1.2 PHR Container . . . . . . . . . . . . . . . . . . 16 84 4.1.3 PDR Container . . . . . . . . . . . . . . . . . .18 85 4.2 Message format . . . . . . . . . . . . . . . . . . . . .21 86 4.3 RMD node state management . . . . . . . . . . . . . . . 21 87 4.3.1 Aggregated versus per flow reservations at the 88 QNE edges . . . . . . . . . . . . . . . . . . . . 21 89 4.3.2 Measurement-based method . . . . . . . . . . . . .23 90 4.3.3 Reservation-based method . .. . . . . . . . . . . 25 91 4.4 Transport of RMD-QOSM messages . . . . . . . . . . . . .26 92 4.5 Edge discovery and addressing of messages . . . . . . . 29 93 4.6 Operation and sequence of events . . . . . . . . . . . .30 94 4.6.1 Basic unidirectional operation . . . . . . . . . .30 95 4.6.1.1 Successful reservation. . . . . . . . . . . .31 96 4.6.1.2 Unsuccessful reservation . . . . . . . . . . 42 97 4.6.1.3 RMD refresh reservation. . . . . . . . . . . 45 98 4.6.1.4 RMD modification of aggregated reservation . 49 99 4.6.1.5 RMD release procedure. . . . . . . . . . . . 50 100 4.6.1.6 Severe congestion handling . . . . . . . . .57 101 4.6.1.7 Admission control using congestion 102 notification based on probing . . . . . . . 63 103 4.6.2 Bidirectional operation . . . . . . . . . . . . . 66 104 4.6.2.1 Successful and unsuccessful reservation . . .69 105 4.6.2.2 Refresh reservation . . . . . . . . . . . . .73 106 4.6.2.3 Modification of aggregated reservation . . . 74 107 4.6.2.4 Release procedure . . . . . . . . . . . . . .74 108 4.6.2.5 Severe congestion handling . . . . . . . . . 75 109 4.6.2.6 Admission control using congestion 110 notification based on probing . . . . . . . .77 111 4.7 Handling of additional errors . . . . . . . . . . . . . 79 112 5. Security Consideration. . . . . . . . . . . . . . . . . . . 79 113 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .85 114 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .86 115 8. Authors` Addresses. . . . . . . . . . . . . . . . . . . . . 87 116 9. Normative References . . . . . . . . . . . . . . . . . . . .88 117 10. Informative References . . . . . . . . . . . . . . . . . . 88 119 1. Introduction 121 This document describes a Next Steps In Signaling (NSIS) QoS model 122 for networks that use the Resource Management in Diffserv (RMD) 123 framework ([RMD1], [RMD2], [RMD3], [RMD4]). RMD adds admission 124 control to Diffserv networks and allows nodes external to the 125 networks to dynamically reserve resources within the Diffserv 126 domains. 128 The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP) 129 [QoS-NSLP] specifies a generic protocol for carrying Quality of 130 Service(QoS) signaling information end-to-end in an IP network. 131 Each network along the end-to-end path is expected to implement a 132 specific QoS Model (QOSM) specified by the QSpec template [QSP-T] 133 that interprets the requests and installs the necessary mechanisms, 134 in a manner that is appropriate to the technology in use in the 135 network, to ensure the delivery of the requested QoS. 136 This document specifies an NSIS QoS Model for RMD networks (RMD- 137 QOSM), and an RMD-specific QSpec (RMD-QSPec) for expressing 138 reservations in a suitable form for simple processing by internal 139 nodes. 141 They are used in combination with the QoS-NSLP to provide 142 QoS signaling service in an RMD network. Figure 1 shows an RMD 143 network with the respective entities. 145 Stateless or reduced state Egress 146 Ingress RMD nodes Node 147 Node (Interior Nodes; I-Nodes) (Stateful 148 (Stateful | | | RMD QoS 149 RMD QoS NLSP | | | NSLP Node) 150 Node) V V V 151 +-------+ Data +------+ +------+ +------+ +------+ 152 |-------|--------|------|------|------|-------|------|---->|------| 153 | | Flow | | | | | | | | 154 |Ingress| |I-Node| |I-Node| |I-Node| |Egress| 155 | | | | | | | | | | 156 +-------+ +------+ +------+ +------+ +------+ 157 =================================================> 158 <================================================= 159 Signaling Flow 161 Figure 1: Actors in the RMD-QOSM 163 Many network scenarios, such as the "Wired Part of Wireless Network" 164 scenario, which is described in section 8.4 of [RFC3726] require that 165 the impact of the used QoS signaling protocol on the network 166 performance should be minimised. In such network scenarios, the 167 performance of each network node that is used in a communication path 168 has an impact on the end-to-end performance. As such, the end-to-end 169 performance of the communication path can be improved by optimizing 170 the performance of the interior nodes. One of the factors that can 171 contribute to this optimization is the minimization of the QoS 172 signalling protocol processing load and the minimization of the 173 number of states on each interior node. 174 Another requirement that is imposed by such network scenarios is that 175 whenever a severe congestion situation occurs in the network, the 176 used QoS signaling protocol shoud be able to solve them. In case of a 177 route change or link failure a severe congestion situation may occur 178 in the network. Typically, routing algorithms are able to adapt and 179 change their routing decisions to reflect changes in the topology and 180 traffic volume. In such situations the re-routed traffic will have to 181 follow a new path. Interior nodes located on this new path may become 182 overloaded, since they suddenly might need to support more traffic 183 than they have capacity for. These severe congestion situations will 184 severely affect the overall performance of the traffic passing 185 through such nodes. 187 RMD-QoSM is an edge-to-edge (intra-domain) QoS Model that in 188 combination with the QoS-NSLP and QSPEC specifications is designed to 189 support the requirements mentioned above: 191 o Minimal Impact on Interior Node Performance; 192 o Increase of scalability; 193 o Ability to deal with severe congestion 195 Internally to the RMD network, RMD-QOSM together with QoS-NSLP 196 [QoS-NSLP] defines a scalable QoS signaling model in which per-flow 197 QoS-NSLP and NTLP states are not stored in Interior nodes but 198 per-flow signaling is performed (see [QoS-NSLP]) at the edges. 200 In the RMD-QOSM, only routers at the edges of a Diffserv domain 201 (Ingress and Egress nodes) support the (QoS-NSLP) stateful 202 operation, see Section 4.7 of [QoS-NSLP]. Interior nodes support 203 either the(QoS-NSLP) stateless operation, or a reduced-state 204 operation with coarser granularity than the edge nodes. 206 After the terminology in Section 2, we give an overview of RMD and 207 the RMD-QOSM in Section 3. This document specifies several RMD- 208 QOSM/QoS-NSLP signaling schemes. In particular, Section 3.2.3 209 identifies which combination of sections are used for the 210 specification of each RMD-QOSM/QoS-NSLP signaling scheme. In Section 211 4 we give a detailed description of the RMD-QOSM, including the role 212 of QNEs, the definition of the QSpec, mapping of QSpec generic 213 parameters onto RMD-QOSM parameters, state management in QNEs, and 214 operation and sequence of events. Section 5 discusses security 215 issues. 217 2. Terminology 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 221 this document are to be interpreted as described in [RFC2119]. 223 The terminology defined by GIST [GIST] and QoS-NSLP [QoS-NSLP] 224 applies to this draft. 226 In addition, the following terms are used: 228 NSIS domain: a NSIS signalling capable domain. 230 RMD domain: a NSIS domain that is capable of supporting the RMD-QOSM 231 signalling and operations. 233 Edge node: a QoS-NSLP node on the boundary of some 234 administrative domain that connects one NSIS domain to a node 235 either in another NSIS domain or in a non NSIS domain. 237 NSIS aware node: a node that is aware of NSIS signalling and RMD- 238 QOSM operations, such as severe congestion detection and DSCP 239 marking. 241 NSIS unaware: a node that is unware of NSIS signalling, but is 242 aware of RMD-QOSM operations such as severe congestion detection 243 and DSCP marking. 245 Ingress node: An edge node in its role in handling the traffic 246 as it enters the NSIS domain. 248 Egress node: An edge node in its role in handling the traffic 249 as it leaves the NSIS domain. 250 Interior node: a node in a NSIS domain that is not an edge node. 252 Congestion: is a temporal network state that occurs when the traffic 253 (or when traffic associated with a particular PHB) passing through a 254 link is slightly higher than the capacity allocated for the link (or 255 allocated for the particular PHB). If no measures are taken than the 256 traffic passing through this link may temporarily slightly degrade in 257 QoS. This type of congestion is usually solved using admission 258 control mechanisms. 260 Severe congestion: Is the congestion situation on a particular link 261 within the RMD domain where a significant increase in its real packet 262 queue situation occurs, such as when due to a link failure re-routed 263 traffic has to be supported by this particular link. 265 3. Overview of RMD and RMD-QOSM 267 3.1. RMD 269 The Differentiated Services (Diffserv) architecture ([RFC2475], 270 [RFC2638]) was introduced as a result of efforts to avoid the 271 scalability and complexity problems of Intserv [RFC1633]. 272 Scalability is achieved by offering services on an aggregate 273 rather than per-flow basis and by forcing as much of the per-flow 274 state as possible to the edges of the network. The service 275 differentiation is achieved using the Differentiated Services (DS) 276 field in the IP header and the Per-Hop Behavior (PHB) as the main 277 building blocks. Packets are handled at each node according to the 278 PHB indicated by the DS field in the message header. 280 The Diffserv architecture does not specify any means for devices 281 outside the domain to dynamically reserve resources or receive 282 indications of network resource availability. In practice, service 283 providers rely on short active time Service Level Agreements (SLAs) 284 that statically define the parameters of the traffic that will be 285 accepted from a customer. 287 RMD was introduced as a method for dynamic reservation of resources 288 within a Diffserv domain. It describes a method that is able to 289 provide admission control for flows entering the domain and a 290 congestion handling algorithm that is able to terminate flows in 291 case of congestion due to a sudden failure (e.g., link, router) 292 within the domain. 294 In RMD, scalability is achieved by separating a fine-grained 295 reservation mechanism used in the edge nodes of a Diffserv domain 296 from a much simpler reservation mechanism needed in the Interior 297 nodes. Typically it is assumed that edge nodes support per- 298 flow QoS states in order to provide QoS guarantees for each flow. 299 Interior nodes use only one aggregated reservation state per traffic 300 class or no states at all. In this way it is possible to handle 301 large numbers of flows in the Interior nodes. Furthermore, due to 302 the limited functionality supported by the Interior nodes, this 303 solution allows fast processing of signaling messages. 305 The possible RMD-QOSM applicabilities are described in Section 306 3.2.3. Two main basic admission control modes are supported: 307 reservation-based and measurement-based admission control that can 308 be used in combination with a severe congestion handling solution. 309 The severe congestion handling solution is used in the situation 310 that a link/node becomes severely congested due to the fact that the 311 traffic supported by a failed link/node is rerouted and has to be 312 processed by this link/node. Furthermore, RMD-QOSM supports both 313 uni-directional and bi-directional reservations. 315 Another important feature of RMD-QOSM is that the intra-domain 316 sessions supported by the edges can be either per flow sessions or 317 per aggregate sessions. In case of the per flow intra-domain 318 sessions, the maintained per flow intra-domain states have a one-to- 319 one dependency to the per flow end-to-end states supported by the 320 same edge. In case of the per-aggregate sessions the maintained per- 321 aggregate states have a one-to-many relationship to the per flow 322 end-to-end states supported by the same edge. 324 In the reservation-based method, each Interior node maintains 325 only one reservation state per traffic class. The Ingress edge 326 nodes aggregate individual flow requests into PHB traffic classes, 327 and signal changes in the class reservations as necessary. The 328 reservation is quantified in terms of resource units (or bandwidth). 329 These resources are requested dynamically per PHB and reserved on 330 demand in all nodes in the communication path from an Ingress node 331 to an Egress node. 333 The measurement-based algorithm continuously measures traffic levels 334 and the actual available resources, and admits flows whose resource 335 needs are within what is available at the time of the request. The 336 measurement based algorithm is used to support a predictive service 337 where the service commitment is somewhat less reliable than the 338 service that can be supported by the reservation based method. 340 A main assumption that is taken by such measurement based admission 341 control mechanisms is that the aggregated PHB traffic passing through 342 an RMD interior node is high and therefore, current measurement 343 characteristics are considered to be an indicator of future load. 344 Once an admission decision is made, no record of the decision need be 345 kept at the interior nodes. The advantage of measurement-based 346 resource management protocols is that they do not require pre- 347 reservation state nor explicit release of the reservations at the 348 interior nodes. Moreover, when the user traffic is variable, 349 measurement based admission control could provide higher network 350 utilization than, e.g., peak-rate reservation. However, this can 351 introduce an uncertainty in the availability of the resources. 352 It is important to emphasize that the RMD measurement based schemes 353 described in this document do not use any refresh procedures, since 354 these approaches are used in stateless nodes, see Section 4.6.1.3. 356 Two types of measurement based admission control schemes are 357 possible: 359 * Congestion notification function based on probing: 361 This method can be used to implement a simple measurement-based 362 admission control within a Diffserv domain. In this scenario the 363 interior nodes are not NSIS aware nodes. In these interior nodes 364 thresholds are set for the traffic belonging to different PHBs in 365 the measurement based admission control function. In this scenario 366 an end-to-end NSIS message is used as a probe packet, meaning that 367 the DSCP field in the header of the IP packet that carries the NSIS 368 message is re-marked when the predefined congestion threshold is 369 exceeded. Note that when the predefined congestion threshold is 370 exceeded all packets are remarked by a node, including NSIS 371 messages. In this way the edges can admit or reject flows that are 372 requesting resources. The frequency and durations that the congestion 373 level is above the threshold resulting in remarking, is tracked and 374 used to influence the admission control decisions. 376 * NSIS measurement-based admission control: 378 In this case the measurement-based admission control functionality 379 is implemented in NSIS aware stateless routers. The main difference 380 between this type of admission control and the congestion 381 notification based on probing is related to the fact that this type 382 of admission control is applied mainly on NSIS aware nodes. 383 With the measurement based scheme the requested peak bandwidth of a 384 flow is carried by the admission control request. The admission 385 decision is considered as positive if the currently carried traffic, 386 as characterized by the measured statistics, plus the requested 387 resources for the new flow exceeds the system capacity with a 388 probability smaller than a value alpha. Otherwise, the admission 389 decision is negative. It is important to emphasize that due to the 390 fact that the RMD interior nodes are stateless, they do not store 391 information of previous admission control requests. 393 This could lead to a situation where the admission control accuracy 394 is decreased when multiple simultaneous flows (sharing a common 395 interior node) are requesting admission control simultaneously. By 396 applying measuring techniques, see e.g., [JaSh97], [GrTs03], which 397 are using current and past information on NSIS sessions that 398 requested resources from an NSIS aware interior node, the decrease in 399 admission control accuracy can be limited. 400 RMD describes the following procedures: 402 * Classification of an individual resource reservation or a resource 403 query into Per Hop Behavior (PHB) groups at the Ingress node of 404 the domain, 406 * Hop-by-hop admission control based on a PHB within the 407 domain. There are two possible modes of operation for internal 408 nodes to admit requests. One mode is the stateless or 409 measurement-based mode, where the resources within the domain are 410 queried. Another mode of operation is the reduced-state 411 reservation or reservation based mode, where the resources within 412 the domain are reserved. 414 * a method to forward the original requests across the domain up to 415 the Egress node and beyond. 417 * a congestion control algorithm that notifies the egress edge nodes 418 about congestion. It is able to terminate the appropriate number 419 of flows in case a of congestion due to a sudden failure (e.g., 420 link or router failure) within the domain. 422 3.2. Basic features of RMD-QOSM 424 3.2.1 Role of the QNEs 426 The protocol model of the RMD-QOSM is shown in Figure 2. The figure 427 shows QNI and QNR nodes, not part of the RMD network, that are the 428 ultimate initiator and receiver of the QoS reservation requests. It 429 also shows QNE nodes that are the Ingress and Egress nodes in the 430 RMD domain (QNE Ingress and QNE Egress), and QNE nodes that are 431 Interior nodes (QNE Interior). 433 All nodes of the RMD domain are usually QoS-NSLP aware nodes. 434 However, in the scenarios where the congestion notification function 435 based on probing is used, then the interior nodes are not NSIS 436 aware. Edge nodes store and maintain QoS-NSLP and NTLP states and 437 therefore are stateful nodes. The NSIS aware Interior nodes are 438 NTLP stateless. Furthermore they are either QoS-NSLP stateless (for 439 NSIS measurement-based operation), or are reduced state nodes 440 storing per PHB aggregated QoS-NSLP states (for reservation-based 441 operation). 443 Note that the RMD domain MAY contain Interior nodes that are 444 not NSIS aware nodes (not shown in the figure). 446 These nodes are assumed to have sufficient capacity for flows that 447 might be admitted. Furthermore, some of these NSIS unaware nodes MAY 448 be used for measuring the traffic congestion level on the data path. 449 These measurements can be used by RMD-QOSM in the congestion control 450 based on probing operation and/or severe congestion operation 451 (see Section 4.6.1.6). 453 |------| |-------| |------| |------| 454 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 455 | QoS | | QoS | | QoS | | QoS | 456 | | |-------| |------| |------| 457 | | |-------| |-------| |-------| |------| | | 458 | | | local |<->| local |<->| local |<->| local| | | 459 | | | QoS | | QoS | | QoS | | QoS | | | 460 | | | | | | | | | | | | 461 | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | 462 |st.ful| |st.ful | |st.less/ |st.less/ |st.ful| |st.ful| 463 | | | | |red.st.| |red.st.| | | | | 464 | | |-------| |-------| |-------| |------| | | 465 |------| |-------| |-------| |-------| |------| |------| 466 ------------------------------------------------------------------ 467 |------| |-------| |-------| |-------| |------| |------| 468 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP | 469 |st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful| 470 |------| |-------| |-------| |-------| |------| |------| 471 QNI QNE QNE QNE QNE QNR 472 (End) (Ingress) (Interior) (Interior) (Egress) (End) 474 st.ful: stateful, st.less: stateless 475 st.less red.st.: stateless or reduced state 477 Figure 2: Protocol model of stateless/reduced state operation 479 3.2.2 RMD-QOSM/QoS-NSLP Signaling 481 The basic RMD-QOSM/QoS-NSLP signaling is shown in Figure 3. The 482 signalling scenarios are accomplished using the QoS-NSLP processing 483 rules defined in [QoS-NSLP], in combination with the RMF triggers 484 sent via the QoS-NSLP-RMF API described in [QoS-NSLP]. 485 Due to the fact that within the RMD domain a different QoS model can 486 be supported than the end-to-end QoS model applied at the edges of 487 the RMD domain, the RMD interior node reduced state reservations can 488 be updated independently of the per-flow end-to-end reservations, see 489 Section 4.7 of [QoS-NSLP]. Therefore, two different RESERVE messages 490 are used within the RMD domain. One RESERVE message that is 491 associated with the per flow end-to-end reservations and is used by 492 the edges of the RMD domain and one that is associated with the 493 reduced state reservations within the RMD domain. 495 A RESERVE message is created by a QNI with an Initiator QSpec 496 describing the reservation and forwarded along the path towards the 497 QNR. 499 When the original RESERVE message arrives at the Ingress node, 500 an RMD-QSpec is constructed based on the initial QSpec in the message 501 (usually the Initiator QSpec). The RMD-QSpec is sent in a intra- 502 domain, independent RESERVE message through the Interior nodes 503 towards the QNR. This intra-domain RESERVE message uses the GIST 504 datagram signaling mechanism. Note that the RMD-QOSM cannot directly 505 specify that the GIST datagram mode SHOULD be used. This can however 506 be notified by using the GIST API Transfer-Attributes, such as 507 unreliable, low level of security and use of local policy. 508 Meanwhile, the original RESERVE message is sent to the Egress node 509 on the path to the QNR using the reliable transport mode of NTLP. 510 Each QoS-NSLP node on the data path processes the intra-domain 511 RESERVE message and checks the availability of resources with either 512 the reservation-based or the measurement-based method. 514 QNE Ingress QNE Interior QNE Interior QNE Egress 515 NTLP stateful NTLP stateless NTLP stateless NTLP stateful 516 | | | | 517 RESERVE | | | | 518 -------->| RESERVE | | | 519 +--------------------------------------------->| 520 | RESERVE` | | | 521 +-------------->| | | 522 | | RESERVE` | | 523 | +-------------->| | 524 | | | RESERVE` | 525 | | +------------->| 526 | | | RESPONSE`| 527 |<---------------------------------------------+ 528 | | | | RESERVE 529 | | | +-------> 530 | | | |RESPONSE 531 | | | |<------- 532 | | | RESPONSE | 533 |<---------------------------------------------+ 534 RESPONSE| | | | 535 <--------| | | | 537 Figure 3: Sender-initiated reservation with Reduced State Interior 538 Nodes 540 When the message reaches the Egress node, and the reservation is 541 successful in each Interior node, an intra-domain (local) RESPONSE` 542 is sent towards the ingress node and the original (end-to-end) 543 RESERVE message is forwarded to the next domain. When the Egress 544 node receives a RESPONSE message from the downstream end, it is 545 forwarded directly to the Ingress node. 546 If an intermediate node cannot accommodate the new request, it 547 indicates this by marking a single bit in the message, and continues 548 forwarding the message until the Egress node is reached. From the 549 Egress node an intra-domain RESPONSE` and an original RESPONSE 550 message are sent directly to the Ingress node. 552 As a consequence in the stateless/reduced state domain only sender- 553 initiated reservation can be performed and functions requiring per 554 flow NTLP or QoS-NSLP states, like summary and reduced refreshes, 555 cannot be used. If per flow identification, is needed, i.e., 556 associating the flow IDs for the reserved resources, Edge nodes act 557 on behalf of Interior nodes. 559 3.2.3 RMD-QOSM Applicability and considerations 561 The RMD-QOSM is a Diffserv-based bandwidth management methodology 562 that is not able to provide a full Diffserv support. 563 The reason of this is that the RMD-QOSM concept can only support the 564 (Expedited Forwarding) EF-like functionality behavior, but is not 565 able to support the full set of (Assured Forwarding) AF-like 566 functionality. The bandwidth information REQUIRED by the EF-like 567 functionality behaviour can be supported by RMD-QOSM carrying the 568 bandwidth information in the parameter, see [QSP-T]. 569 The full set of (Assured Forwarding) AF-like functionality requires 570 information that is specified in two token buckets. The RMD-QOSM is 571 not supporting the use of two token buckets and therefore, it is not 572 able to support the full set of AF-functionality. Note however, 573 that RMD-QOSM could also support a single AF PHB, when the traffic 574 or the upper limit of the traffic can be characterized by a single 575 bandwidth parameter. Moreover, it is considered that in case of 576 tunnelling, the RMD-QOSM supports only the uniform tunnelling mode 577 for Differentiated services, see [RFC2983]. 579 The RMD domain MUST be engineered in such a way that each QNE Ingress 580 maintains information about the smallest MTU that is supported on the 581 links within the RMD domain. 583 A very important consideration on using RMD-QOSM is that within one 584 RMD domain only one of the following RMD-QOSM schemes can be used at 585 a time. Thus a RMD router can never process and use two different 586 RMD-QOSM signaling schemes at the same time. 588 However, all RMD QNEs supporting this specification MUST support the 589 combination the "per flow RMD reservation based" in combination with 590 "severe congestion handling by proportional data packet marking" 591 scheme. If the RMD QNEs support more RMD-QOSM schemes then the 592 operator of that RMD domain MUST pre-configure all the QNE edge nodes 593 within one domain such that the field included in the "PHR 594 container", see Section 4.1.2 and the "PDR Container", see Section 595 4.1.3, will use always the same value, such that within one RMD 596 domain only one of the below described RMD-QOSM schemes is used at a 597 time. 599 The congestion situations, see Section 2, are solved using admission 600 control mechanism, e.g., "per flow congestion notification based on 601 probing", while the severe congestion situations, see Section 2, are 602 solved using the severe congestion handling mechanisms, e.g., "Severe 603 congestion handling by proportional data packet marking". 605 The RMD domain MUST be engineered in such a way that RMD-QOSM 606 messages could be transported using the GIST Query and 607 Data messages in Q-mode, see [GIST]. This means that the Path MTU 608 MUST be engineered in such a way that the RMD-QOSM message are 609 transported without fragmentation. Furthermore, the RMD domain MUST 610 be engineered in such a way to guarantee capacity for the GIST 611 Query and Data messages in Q-mode, within the rate control limits 612 imposed by GIST, see [GIST]. 614 The RMD domain has to be configured such that the GIST context-free 615 flag (C-flag) MUST be set (C=1) for Query messages and Data 616 messages sent in Q-mode, see [GIST]. 618 Moreover, the same deployment issues and extensibility considerations 619 described in [GIST] and [Extens-NSIS] apply to this document. 621 It is important to note that the concepts described in Sections 622 4.6.1.6.2, 4.6.2.5.2, 4.6.1.6.2 and 4.6.2.5.2 contributed to 623 the PCN WG standardisation. 625 The available RMD-QOSM/QoS-NSLP signaling schemes are: 627 * "per flow congestion notification based on probing" (see 628 Sections 4.3.2, 4.6.1.7., 4.6.2.6.). Note that this scheme uses for 629 severe congestion handling the "Severe congestion handling by 630 proportional data packet marking", see Section 4.6.1.6.2, 631 4.6.2.5.2). Furthermore, the interior nodes are considered to be 632 Diffserv aware, but NSIS unaware nodes, see Section 4.3.2. 634 * "per flow RMD NSIS measurement based admission control" (see 635 Sections 4.3.2, 4.6.1, 4.6.2). Note that this scheme uses for 636 severe congestion handling the "Severe congestion handling by 637 proportional data packet marking", see Section 4.6.1.6.2, 638 4.6.2.5.2). Furthermore, the interior nodes are considered to be 639 NSIS aware nodes, see Section 4.3.2. 641 * "per flow RMD reservation based" in combination with "severe 642 congestion handling by the RMD-QOSM refresh procedure" (see 643 Sections 4.3.3, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this 644 scheme uses for severe congestion handling the "Severe congestion 645 handling by the RMD-QOSM refresh" procedure, see Section 4.6.1.6.1, 646 4.6.2.5.1). Furthermore, the intra-domain sessions supported by the 647 edge nodes are per flow sessions, see Section 4.3.3. 649 * "per flow RMD reservation based" in combination with "severe 650 congestion handling by proportional data packet marking" procedure 651 (see Sections 4.3.3, 4.6.1, 4.6.1.6.2, 4.6.2.5.2). Note that 652 this scheme uses for severe congestion handling the "Severe 653 congestion handling by proportional data packet marking" procedure, 654 see Section 4.6.1.6.2, 4.6.2.5.2). Furthermore, the intra-domain 655 sessions supported by the edge nodes are per flow sessions, see 656 Section 4.3.3. 658 * "per aggregate RMD reservation based" in combination with 659 "severe congestion handling by the RMD-QOSM refresh procedure" (see 660 Sections 4.3.1, 4.6.1, 4.6.1.6.1, 4.6.2.5.1). Note that this 661 scheme uses for severe congestion handling the "Severe congestion 662 handling by the RMD-QOSM refresh" procedure, see Section 4.6.1.6.1, 663 4.6.2.5.1). Furthermore, the intra-domain sessions supported by the 664 edge nodes are per aggregate sessions, see Section 4.3.1. Moreover, 665 this scheme can be considered to be a reservation-based scheme, 666 since the RMD interior nodes are reduced-state nodes, i.e., they do 667 not store NTLP/GIST states but they do store per PHB-aggregated 668 QoS-NSLP reservation states. 670 * "per aggregate RMD reservation based" in combination with 671 "severe congestion handling by proportional data packet marking" 672 procedure (see Sections 4.3.1, 4.6.1, 4.6.1.6.2, 4.6.2.5.2). 673 Note that this scheme uses for severe congestion handling the 674 "Severe congestion handling by proportional data packet marking" 675 procedure, see Section 4.6.1.6.2, 4.6.2.5.2). Furthermore, the 676 intra-domain sessions supported by the edge nodes are per aggregate 677 sessions, see Section 4.3.1. Moreover, this scheme can be 678 considered to be a reservation-based scheme, since the RMD interior 679 nodes are reduced-state nodes, i.e., they do not store NTLP/GIST 680 states but they do store per PHB-aggregated QoS-NSLP reservation 681 states. 683 4. RMD-QOSM, Detailed Description 685 This section describes the RMD-QOSM in more detail. In particular, 686 it defines the role of stateless and reduced-state QNEs, the 687 RMD-QOSM QSpec Object, the format of the RMD-QOSM QoS-NSLP messages 688 and how QSpecs are processed and used in different protocol 689 operations. 691 4.1. RMD-QSpec Definition 693 The RMD-QOSM uses the QSpec format specified in [QSP-T]. 694 The Initiator/Local QSPEC bit, i.e., is set to "Local" (i.e., 695 "1") and the is set as follows: 696 * Message Sequence = 0: Sender initiated 697 * Object combination = 0: for RESERVE and 698 for RESPONSE 700 The used by RMD-QOSM is the default version, i.e., 701 "0", see [QSP-T]. The value used by the RMD-QOSM is 702 specified in [QSP-T] and is equal to: "2". 703 The contains the following fields: 705 = 706 The Per Hop Reservation container (PHR container) and 707 the Per Domain Reservation container (PDR container) are specified 708 in Section 4.1.2 and 4.1.3, respectively. The 709 contains the traffic handling directives for intra-domain 710 communication and reservation. The contains 711 additional traffic handling directives that is needed for 712 edge-to-edge communication. The parameter IDs used by the and are assigned by IANA, see Section 6. 715 The RMD-QOSM and , are specified in 716 Section 4.1.1. The RMD-QOSM and and the 717 are used and processed by the Edge and Interior 718 nodes. The field is only processed by Edge nodes. 720 4.1.1. RMD-QOSM QoS Desired and QoS Reserved 722 The RESERVE message contains only the QoS Desired object [QSP-T]. The 723 QoS Reserved object is carried by the RESPONSE message. 725 In RMD-QOSM the and objects contain the 726 following parameters: 728 = 729 = 731 The bit format of the (see [QSP-T] and Figure 4 and 732 Figure 5) and complies to the bit format 733 specified in [QSP-T]. 735 Note that for the RMD-QOSM a reservation established without an 736 parameter is equivalent to a reservation 737 established with an whose value is 1. 739 0 1 740 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | DSCP |0 0 0 0 0 0 0 0 X 0| 743 +---+---+---+---+---+---+---+---+ 745 Figure 4: DSCP parameter 747 0 1 748 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | PHB ID code |0 0 X X| 751 +---+---+---+---+---+---+---+---+ 753 Figure 5: PHB ID Code parameter 755 4.1.2. PHR Container 757 This section describes the parameters used by the PHR container, 758 which are used by the RMD-QOSM functionality available at the 759 Interior nodes. 761 = , , ,, 762 , , ,