idnits 2.17.1 draft-ietf-nsis-rmd-05.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3096. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3080. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3086. ** 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 3 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 'SHOULD not' in this paragraph: * the SCOPING flag SHOULD not be set, meaning that a default scoping of the message is used. Therefore, the QNE edges MUST be configured as 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: It is RECOMMENDED that the total number of additional DSCPs within a RMD domain, needed for severe congestion handling MUST not exceed the limit of 16. One possible solution for reducing the number of DSCP, for example, is to allocate one DSCP for severe congestion indication for each of the AF classes, independently from their dropping precedence. Assuming 4 AF classes and 1 EF class, and using one DSCP per traffic class then the number of DSCPs used in this situation for severe congestion is 5. If two additional DSCP's are used then the total number in this case is 10. -- 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 (January 17, 2006) is 6673 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: 'RMD-QSPEC' is mentioned on line 684, but not defined == Missing Reference: 'RFC 3175' is mentioned on line 1326, but not defined == Unused Reference: 'RFC2119' is defined on line 2997, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 3017, but no explicit reference was found in the text == Unused Reference: 'RFC3175' is defined on line 3025, but no explicit reference was found in the text == Unused Reference: 'RMD4' is defined on line 3057, but no explicit reference was found in the text == Unused Reference: 'RSVP-DOI' is defined on line 3060, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-08 ** 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' == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-05 == Outdated reference: A later version (-01) exists of draft-tschofenig-rsvp-doi-00 Summary: 4 errors (**), 0 flaws (~~), 16 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: 17 June 2006 Georgios Karagiannis 5 University of Twente 6 Cornelia Kappler 7 Siemens 8 Tom Phelan 9 Sonus 10 January 17, 2006 12 RMD-QOSM - The Resource Management in Diffserv QOS Model 13 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress". 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 17, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document describes an NSIS QoS Model for networks that use the 47 Resource Management in Diffserv (RMD) concept. RMD is a technique 48 for adding admission control and preemption function to 49 Differentiated Services (Diffserv) networks. The RMD QoS Model 50 allows devices external to the RMD network to signal reservation 51 requests to edge nodes in the RMD network. The RMD Ingress edge nodes 52 classify the incoming flows into traffic classes and signals resource 53 requests for the corresponding traffic class along the data path to 54 the Egress edge nodes for each flow. Egress nodes reconstitute the 55 original requests and continue forwarding them along the data path 56 towards the final destination. In addition, RMD defines notification 57 functions to indicate overload situations within the domain to the 58 edge nodes. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .4 64 3. Overview of RMD and RMD-QOSM . . . . . . . . . . . . . .. . .4 65 3.1 RMD . . . . . . . . . . . . . . . . . . . . . . . . . . .4 66 3.2 Basic features of RMD-QOSM . . . . . . . . . . . . . . . 7 67 3.2.1 Role of the QNEs . . . . . . . .. . . . . . . . . .7 68 3.2.2 RMD-QOSM signaling . . . . . . . . . . . . . . . . 8 69 4. RMD-QOSM, Detailed Description . . . . . . . . . . . .. . . .9 70 4.1 RMD-QSpec Definition . . . . . . . . . . . . . . . . . . 9 71 4.1.1 RMD-QOSM QoS Description . . . . . . . . . . . . .9 72 4.1.2 PHR RMD-QOSM control information . . . . . . . . .10 73 4.1.3 PDR RMD-QOSM control information . . . . . . . . 12 74 4.2 Message format . . . . . . . . . . . . . . . . . . . . .14 75 4.3 RMD node state management . . . . . . . . . . . . . . . 15 76 4.3.1 Aggregated versus per flow reservations at the 77 QNE edges . . . . . . . . . . . . . . . . . . . . 15 78 4.3.2 Measurement-based method . . . . . . . . . . . . .16 79 4.3.3 Reservation-based method . .. . . . . . . . . . . 16 80 4.4 Transport of RMD-QOSM messages . . . . . . . . . . . . .17 81 4.5 Edge discovery and addressing of messages . . . . . . . 18 82 4.6 Operation and sequence of events . . . . . . . . . . . .18 83 4.6.1 Basic unidirectional operation . . . . . . . . . .18 84 4.6.1.1 Successful reservation. . . . . . . . . . . .19 85 4.6.1.2 Unsuccessful reservation . . . . . . . . . . 25 86 4.6.1.3 RMD refresh reservation. . . . . . . . . . . 28 87 4.6.1.4 RMD modification of aggregated reservation . 31 88 4.6.1.5 RMD release procedure. . . . . . . . . . . . 32 89 4.6.1.6 Severe congestion handling . . . . . . . . .39 90 4.6.1.7 Admission control using congestion 91 notification based on probing . . . . . . . 44 92 4.6.2 Bidirectional operation . . . . . . . . . . . . . 46 93 4.6.2.1 Successful and unsuccessful reservation . . .48 94 4.6.2.2 Refresh reservation . . . . . . . . . . . . .53 95 4.6.2.3 Modification of aggregated reservation . . . 54 96 4.6.2.4 Release procedure . . . . . . . . . . . . . .54 97 4.6.2.5 Severe congestion handling . . . . . . . . . 55 98 4.7 Handling of additional errors . . . . . . . . . . . . . 58 99 5. Security Consideration. . . . . . . . . . . . . . . . . . . 59 100 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .62 101 7. Open issues. . . . . . . . . . . . . . . . . . . . . . . . .62 102 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .62 103 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 63 104 10. Normative References . . . . . . . . . . . . . . . . . . . 64 105 11. Informative References . . . . . . . . . . . . . . . . . . 64 106 12. Intellectual Property Rights . . . . . . . . . . . . . . . 65 108 1. Introduction 110 This document describes a Next Steps In Signaling (NSIS) QoS model 111 for networks that use the Resource Management in Diffserv (RMD) 112 framework ([RMD1], [RMD2], [RMD3]). RMD adds admission control to 113 Diffserv networks and allows nodes external to the networks to 114 dynamically reserve resources within the Diffserv domains. 116 The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP) 117 [QoS-NSLP] specifies a generic model for carrying Quality of Service 118 (QoS) signaling information end-to-end in an IP network. Each 119 network along the end-to-end path is expected to implement a 120 specific QoS Model (QOSM) that interprets the requests and installs 121 the necessary mechanisms, in a manner that is appropriate to the 122 technology in use in the network, to ensure the delivery of the 123 requested QoS. 125 This document specifies an NSIS QoS Model for RMD networks (RMD- 126 QOSM), and an RMD-specific QSpec (RMD-QSPec) for expressing 127 reservations in a suitable form for simple processing by internal 128 nodes. They are used in combination with the QoS-NSLP to provide 129 QoS signaling service in an RMD network. Figure 1 shows an RMD 130 network with the respective entities. 132 Stateless or reduced state Egress 133 Ingress RMD nodes Node 134 Node (Interior Nodes; I-Nodes) (Stateful 135 (Stateful | | | RMD QoS 136 RMD QoS NLSP | | | NSLP Node) 137 Node) V V V 138 +-------+ Data +------+ +------+ +------+ +------+ 139 |-------|--------|------|------|------|-------|------|---->|------| 140 | | Flow | | | | | | | | 141 |Ingress| |I-Node| |I-Node| |I-Node| |Egress| 142 | | | | | | | | | | 143 +-------+ +------+ +------+ +------+ +------+ 144 =================================================> 145 <================================================= 146 Signaling Flow 148 FIGURE 1: Actors in the RMD QOSM 150 Internally to the RMD network, RMD-QOSM defines a scalable QoS 151 signaling model in which per-flow QoS-NSLP and NTLP states are not 152 stored in Interior nodes but per-flow signaling is performed (see 153 [QoS-NSLP]). 155 In the RMD-QOSM, only routers at the edges of a Diffserv domain 156 (Ingress and Egress nodes) support the QoS-NSLP stateful operation. 157 Interior nodes support either the QoS-NSLP stateless operation, or a 158 reduced-state operation with coarser granularity than the edge nodes. 160 The remainder of this draft is structured following the suggestions 161 in Appendix B of [QSP-T] for the description of QoS Signaling 162 Policies. 164 After the terminology in Section 2, we give an overview of RMD and 165 the RMD-QOSM in Section 3. In Section 4 we give a detailed 166 description of the RMD-QOSM, including the role of QNEs, the 167 definition of the QSpec, mapping of QSpec generic parameters onto 168 RMD-QOSM parameters, state management in QNEs, and operation and 169 sequence of events. Section 5 discusses security issues. 171 2. Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 174 NOT", "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 175 in this document are to be interpreted as described in RFC 2119. 177 The terminology defined by GIMPS [GIMPS] and QoS-NSLP [QoS-NSLP] 178 applies to this draft. 180 In addition, the following terms are used: 182 Edge node: an (NSIS-capable) node on the boundary of some 183 administrative domain. 185 Ingress node: An edge node that handles the traffic as it enters the 186 domain. 188 Egress node: An edge node that handles the traffic as it leaves the 189 domain. 191 Interior nodes: the set of (NSIS-capable) nodes which form an 192 administrative domain, excluding the edge nodes. 194 3. Overview of RMD and RMD-QOSM 196 3.1. RMD 198 The Differentiated Services (Diffserv) architecture ([RFC2475], 199 [RFC2638]) was introduced as a result of efforts to avoid the 200 scalability and complexity problems of Intserv [RFC1633]. 201 Scalability is achieved by offering services on an aggregate 202 rather than per-flow basis and by forcing as much of the per-flow 203 state as possible to the edges of the network. The service 204 differentiation is achieved using the Differentiated Services (DS) 205 field in the IP header and the Per-Hop Behavior (PHB) as the main 206 building blocks. Packets are handled at each node according to the 207 PHB indicated by the DS field in the message header. 209 The Diffserv architecture does not specify any way for devices 210 outside the domain to dynamically reserve resources or receive 211 indications of network resource availability. In practice, service 212 providers rely on subscription-time Service Level Agreements (SLAs) 213 that statically define the parameters of the traffic that will be 214 accepted from a customer. 216 RMD was introduced as a method for dynamic reservation of resources 217 within a Diffserv domain. It describes a method that is able to 218 provide admission control for flows entering the domain and a 219 congestion handling algorithm that is able to terminate flows in 220 case of congestion due to a sudden failure (e.g., link, router) 221 within the domain. 223 In RMD, scalability is achieved by separating a fine-grained 224 reservation mechanism used in the edge nodes of a Diffserv domain 225 from a much simpler reservation mechanism needed in the Interior 226 nodes. In particular, it is assumed that edge nodes support per- 227 flow QoS states in order to provide QoS guarantees for each flow. 228 Interior nodes use only one aggregated reservation state per traffic 229 class or no states at all. In this way it is possible to handle 230 large numbers of flows in the Interior nodes. Furthermore, due to 231 the limited functionality supported by the Interior nodes, this 232 solution allows fast processing of signaling messages. 234 In RMD two basic admission control modes are described: measurement- 235 based and reservation-based admission control. 237 The measurement-based algorithm continuously measures traffic levels 238 and the actual available resources, and admits flows whose resource 239 needs are within what is available at the time of the request. Once 240 an admission decision is made, no record of the decision need be 241 kept. The advantage of measurement-based resource management 242 protocols is that they do not require pre-reservation state or 243 explicit release of the reservations. Moreover, when the user 244 traffic is variable, measurement based admission control could 245 provide higher network utilization than, e.g., peak-rate 246 reservation. However, this can introduce an uncertainty in the 247 availability of the resources. 249 Two types of measurement based admission control schemes are 250 possible: 252 * The congestion notification function based on probing: 253 can be used to implement a simple measurement-based admission 254 control within a Diffserv domain. In this scenario the interior 255 nodes are not necessarily NSIS aware nodes. In these interior nodes 256 located along the data path, thresholds are set in the measurement 257 based admission control function for the traffic belonging to 258 different PHBs. In this scenario an end-to-end NSIS message, can be 259 used as a probe packet, meaning that the DSCP field in the header 260 of the IP packet that carries the NSIS message will be re-marked 261 when the predefined congestion threshold is exceeded. In this way 262 the edges can admit or reject flows that are requesting resources. 264 * NSIS measurement-based admission control, where the measurement 265 based admission control functionality is implemented in NSIS aware 266 stateless routers. The main difference between this type of 267 admission control and the congestion notification based on probing 268 is related to the fact that this type of admission control is 269 applied mainly on NSIS aware nodes, giving the possibility to apply 270 measuring techniques, see e.g., [JaSh97], [GrTs03], that are using 271 current and past information on NSIS sessions that requested 272 resources from an NSIS aware interior node. The admission decision 273 is positive if the currently carried traffic, as characterized by 274 the measured statistics, plus the requested resources for the new 275 flow do exceed the system capacity with a probability smaller than 276 some ?. Otherwise, the admission decision is negative. 278 In the reservation-based method, each Interior node maintains 279 only one reservation state per traffic class. The Ingress edge 280 nodes aggregate individual flow requests into classes, and signal 281 changes in the class reservations as necessary. The reservation is 282 quantified in terms of resource units. These resources are 283 requested dynamically per PHB and reserved on demand in all nodes in 284 the communication path from an Ingress node to an Egress node. 286 RMD describes the following procedures: 288 * classification of individual resource reservation or resource 289 query into Per Hop Behavior groups (PHB) at the Ingress node of 290 the domain, 292 * hop-by-hop admission control based on per PHB within the 293 domain. There are two possible modes of operation for internal 294 nodes to admit requests. One mode is the stateless or 295 measurement-based mode, where the resources within the domain are 296 queried. Another mode of operation is the reduced-state 297 reservation or reservation based mode, where the resources within 298 the domain are reserved. 300 * a method to forward the original requests across the domain up to 301 the Egress node and beyond. 303 * a congestion control algorithm that notifies the egress edge nodes 304 about congestion. It is able to terminate the appropriate number 305 of flows in case a of congestion due to a sudden failure (e.g., 306 link or router failure) within the domain. 308 3.2. Basic features of RMD-QOSM 310 3.2.1 Role of the QNEs 312 The protocol model of the RMD-QOSM is shown in Figure 2. The figure 313 shows QNI and QNR nodes, not part of the RMD network, that are the 314 ultimate initiator and receiver of the QoS reservation requests. It 315 also shows QNE nodes that are the Ingress and Egress nodes in the 316 RMD domain (QNE Ingress and QNE Egress), and QNE nodes that are 317 Interior nodes (QNE Interior). 319 All nodes of the RMD domain are mainly QoS-NSLP aware nodes. Edge 320 nodes store and maintain QoS-NSLP and NTLP states and therefore are 321 stateful nodes. The NSIS aware Interior nodes are NTLP stateless. 322 Furthermore they are either QoS-NSLP stateless (for NSIS measurement- 323 based operation), or are reduced state nodes storing per PHB 324 aggregated QoS-NSLP states (for reservation-based operation). 326 |------| |-------| |------| |------| 327 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 328 | QoS | | QoS | | QoS | | QoS | 329 | | |-------| |------| |------| 330 | | |-------| |-------| |-------| |------| | | 331 | | | local |<->| local |<->| local |<->| local| | | 332 | | | QoS | | QoS | | QoS | | QoS | | | 333 | | | | | | | | | | | | 334 | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | 335 |st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful| 336 | | | | |red.st.| |red.st.| | | | | 337 | | |-------| |-------| |-------| |------| | | 338 |------| |-------| |-------| |-------| |------| |------| 339 ------------------------------------------------------------------ 340 |------| |-------| |-------| |-------| |------| |------| 341 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP | 342 |st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful| 343 |------| |-------| |-------| |-------| |------| |------| 344 QNI QNE QNE QNE QNE QNR 345 (End) (Ingress) (Interior) (Interior) (Egress) (End) 347 st.ful: stateful, st.less: stateless 348 st.less red.st.: stateless or reduced state 350 Figure 2: Protocol model of stateless/reduced state operation 351 Note that the RMD-QOSM domain MAY contain Interior nodes that are 352 not NSIS aware nodes (not shown in the figure). These nodes are 353 assumed to have sufficient capacity for flows that might be 354 admitted. Furthermore, some of these NSIS unaware nodes MAY be used 355 for measuring the traffic congestion level on the data path. These 356 measurements can be used by RMD-QOSM in the congestion control based 357 on probing operation and/or severe congestion operation 358 (see Section 4.6.1.6). 360 3.2.2 RMD-QOSM signaling 362 The basic RMD-QOSM signaling is shown in Figure 3. A RESERVE 363 message is created by a QNI with an Initiator QSpec describing the 364 reservation and forwarded along the path towards the QNR. When the 365 original RESERVE message arrives at the Ingress node, an RMD-QSpec 366 is constructed based on the top-most QSPEC in the message (usually 367 the Initiator QSPEC). The RMD-QSpec is sent in a local, independent 368 RESERVE message through the Interior nodes towards the QNR. This 369 local RESERVE message uses the NTLP hop-by-hop datagram signaling 370 mechanism. Meanwhile, the original RESERVE message is sent to the 371 Egress node on the path to the QNR using the reliable transport mode 372 of NTLP. 374 QNE QNE QNE QNE 375 Ingress Interior Interior Egress 376 NTLP stateful NTLP stateless NTLP stateless NTLP stateful 377 | | | | 378 RESERVE | | | | 379 -------->| RESERVE | | | 380 +--------------------------------------------->| 381 | RESERVE' | | | 382 +-------------->| | | 383 | | RESERVE' | | 384 | +-------------->| | 385 | | | RESERVE' | 386 | | +------------->| 387 | | | | RESERVE 388 | | | +-------> 389 | | | |RESPONSE 390 | | | |<------- 391 | | | RESPONSE | 392 |<---------------------------------------------+ 393 RESPONSE| | | | 394 <--------| | | | 396 Figure 3: Sender-initiated reservation with Reduced State Interior 397 Nodes 399 Each QoS-NSLP node on the data path processes the local RESERVE 400 message and checks the availability of resources with either the 401 reservation-based or the measurement-based method. When the message 402 reaches the Egress node, and the reservation is successful in each 403 Interior nodes, the original RESERVE message is forwarded to the 404 next domain. When the Egress node receives a RESPONSE message from 405 the downstream end, it is forwarded directly to the Ingress node. 407 If an intermediate node cannot accommodate the new request, it 408 indicates this by marking a single bit in the message, and continues 409 forwarding the message until the Egress node is reached. From the 410 Egress node a RESPONSE message is sent directly the Ingress node. 412 As a consequence in the stateless/reduced state domain only sender- 413 initiated reservation can be performed and functions requiring per 414 flow NTLP or QoS-NSLP states, like summary refreshes, cannot be 415 used. One of the basic features of RMD is that, if per flow 416 identification, is needed, i.e. associating the flows IDs for the 417 reserved resources, Edge nodes act on behalf of Interior nodes. 419 4. RMD-QOSM, Detailed Description 421 This section describes RMD-QOSM in more detail. In particular, 422 it defines the role of stateless and reduced-state QNEs, the 423 RMD-QOSM QSpec Object, the format of RMD-QOSM QoS-NSLP messages 424 and how QSpecs are processed and used in different protocol 425 operations. 427 4.1. RMD-QSpec Definition 429 The RMD-QOSM QSpec object contains three fields, the "RMD-QOSM QoS 430 Description", the Per Hop Reservation "PHR RMD-QOSM control 431 information" container (PHR container) and the Per Domain Reservation 432 "PDR RMD-QOSM control information" container (PDR container). The 433 "RMD-QOSM QoS Description" field and the PHR container are used and 434 processed by edge and Interior nodes. The PDR container field is 436 only processed by edge nodes. The PHR container contains the QoS 437 specific control information for intra-domain communication and 438 reservation. The PDR container contains additional information that 439 is needed for edge-to-edge communication. 441 4.1.1. RMD-QOSM QoS Description 443 This section describes the parameters used by the "RMD-QOSM QoS 444 Description" field. The RMD-QOSM QoS Description only contains the 445 QoS Desired object [QSP-T]. It does not contain the QoS Available, 446 QoS Reserved or Minimum QoS objects. 448 = 450 = 452 The bit format of the and conform to the 453 bit format specified in [QSP-T] and can be seen in Figure 4 and 454 Figure 5, respectively. 456 0 1 2 3 457 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 |1|E|N|T| 3 |r|r|r|r| 1 || 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Bandwidth (32-bit IEEE floating point number) | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 4: Bandwidth parameter 466 0 1 2 3 467 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 |1|E|N|T| 7 |r|r|r|r| 1 | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | DSCP |0 0 0 0 0 0 0 0 0 0| Reserved | 472 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 473 Figure 5: PHB_Class parameter 475 4.1.2. PHR container 477 This section describes the parameters used by the PHR container. 479 = , ,, 480 , ,