idnits 2.17.1 draft-ietf-nsis-rmd-06.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 3133. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3109. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3116. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3122. ** 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 (February 14, 2006) is 6617 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 688, but not defined == Missing Reference: 'RFC 3175' is mentioned on line 1364, but not defined == Unused Reference: 'RFC2119' is defined on line 3025, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 3045, but no explicit reference was found in the text == Unused Reference: 'RFC3175' is defined on line 3053, but no explicit reference was found in the text == Unused Reference: 'RMD4' is defined on line 3093, but no explicit reference was found in the text == Unused Reference: 'RSVP-DOI' is defined on line 3096, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. 'QoS-NSLP') -- No information found for draft-ietf-nsis-QSpec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'QSP-T' == Outdated reference: A later version (-01) exists of draft-tschofenig-rsvp-doi-00 Summary: 4 errors (**), 0 flaws (~~), 14 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: 14 July 2006 Georgios Karagiannis 5 University of Twente 6 Cornelia Kappler 7 Siemens 8 Tom Phelan 9 Sonus 10 February 14, 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 July 14, 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. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .62 102 8. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 62 103 9. Normative References . . . . . . . . . . . . . . . . . . . .63 104 10. Informative References . . . . . . . . . . . . . . . . . . 64 105 11. Intellectual Property Rights . . . . . . . . . . . . . . . 65 107 1. Introduction 109 This document describes a Next Steps In Signaling (NSIS) QoS model 110 for networks that use the Resource Management in Diffserv (RMD) 111 framework ([RMD1], [RMD2], [RMD3]). RMD adds admission control to 112 Diffserv networks and allows nodes external to the networks to 113 dynamically reserve resources within the Diffserv domains. 115 The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP) 116 [QoS-NSLP] specifies a generic model for carrying Quality of Service 117 (QoS) signaling information end-to-end in an IP network. Each 118 network along the end-to-end path is expected to implement a 119 specific QoS Model (QOSM) that interprets the requests and installs 120 the necessary mechanisms, in a manner that is appropriate to the 121 technology in use in the network, to ensure the delivery of the 122 requested QoS. 124 This document specifies an NSIS QoS Model for RMD networks (RMD- 125 QOSM), and an RMD-specific QSpec (RMD-QSPec) for expressing 126 reservations in a suitable form for simple processing by internal 127 nodes. They are used in combination with the QoS-NSLP to provide 128 QoS signaling service in an RMD network. Figure 1 shows an RMD 129 network with the respective entities. 131 Stateless or reduced state Egress 132 Ingress RMD nodes Node 133 Node (Interior Nodes; I-Nodes) (Stateful 134 (Stateful | | | RMD QoS 135 RMD QoS NLSP | | | NSLP Node) 136 Node) V V V 137 +-------+ Data +------+ +------+ +------+ +------+ 138 |-------|--------|------|------|------|-------|------|---->|------| 139 | | Flow | | | | | | | | 140 |Ingress| |I-Node| |I-Node| |I-Node| |Egress| 141 | | | | | | | | | | 142 +-------+ +------+ +------+ +------+ +------+ 143 =================================================> 144 <================================================= 145 Signaling Flow 147 FIGURE 1: Actors in the RMD-QOSM 149 Internally to the RMD network, RMD-QOSM defines a scalable QoS 150 signaling model in which per-flow QoS-NSLP and NTLP states are not 151 stored in Interior nodes but per-flow signaling is performed (see 152 [QoS-NSLP]). 154 In the RMD-QOSM, only routers at the edges of a Diffserv domain 155 (Ingress and Egress nodes) support the QoS-NSLP stateful operation. 156 Interior nodes support either the QoS-NSLP stateless operation, or a 157 reduced-state operation with coarser granularity than the edge nodes. 159 The remainder of this draft is structured following the suggestions 160 in Appendix B of [QSP-T] for the description of QoS Signaling 161 Policies. 163 After the terminology in Section 2, we give an overview of RMD and 164 the RMD-QOSM in Section 3. In Section 4 we give a detailed 165 description of the RMD-QOSM, including the role of QNEs, the 166 definition of the QSpec, mapping of QSpec generic parameters onto 167 RMD-QOSM parameters, state management in QNEs, and operation and 168 sequence of events. Section 5 discusses security issues. 170 2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 173 NOT", "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 174 in this document are to be interpreted as described in RFC 2119. 176 The terminology defined by GIST [GIST] and QoS-NSLP [QoS-NSLP] 177 applies to this draft. 179 In addition, the following terms are used: 181 Edge node: an (NSIS-capable) node on the boundary of some 182 administrative domain. 184 Ingress node: An edge node that handles the traffic as it enters the 185 domain. 187 Egress node: An edge node that handles the traffic as it leaves the 188 domain. 190 Interior nodes: the set of (NSIS-capable) nodes which form an 191 administrative domain, excluding the edge nodes. 193 3. Overview of RMD and RMD-QOSM 195 3.1. RMD 197 The Differentiated Services (Diffserv) architecture ([RFC2475], 198 [RFC2638]) was introduced as a result of efforts to avoid the 199 scalability and complexity problems of Intserv [RFC1633]. 200 Scalability is achieved by offering services on an aggregate 201 rather than per-flow basis and by forcing as much of the per-flow 202 state as possible to the edges of the network. The service 203 differentiation is achieved using the Differentiated Services (DS) 204 field in the IP header and the Per-Hop Behavior (PHB) as the main 205 building blocks. Packets are handled at each node according to the 206 PHB indicated by the DS field in the message header. 208 The Diffserv architecture does not specify any way for devices 209 outside the domain to dynamically reserve resources or receive 210 indications of network resource availability. In practice, service 211 providers rely on subscription-time Service Level Agreements (SLAs) 212 that statically define the parameters of the traffic that will be 213 accepted from a customer. 215 RMD was introduced as a method for dynamic reservation of resources 216 within a Diffserv domain. It describes a method that is able to 217 provide admission control for flows entering the domain and a 218 congestion handling algorithm that is able to terminate flows in 219 case of congestion due to a sudden failure (e.g., link, router) 220 within the domain. 222 In RMD, scalability is achieved by separating a fine-grained 223 reservation mechanism used in the edge nodes of a Diffserv domain 224 from a much simpler reservation mechanism needed in the Interior 225 nodes. In particular, it is assumed that edge nodes support per- 226 flow QoS states in order to provide QoS guarantees for each flow. 227 Interior nodes use only one aggregated reservation state per traffic 228 class or no states at all. In this way it is possible to handle 229 large numbers of flows in the Interior nodes. Furthermore, due to 230 the limited functionality supported by the Interior nodes, this 231 solution allows fast processing of signaling messages. 233 In RMD two basic admission control modes are described: measurement- 234 based and reservation-based admission control. 236 The measurement-based algorithm continuously measures traffic levels 237 and the actual available resources, and admits flows whose resource 238 needs are within what is available at the time of the request. Once 239 an admission decision is made, no record of the decision need be 240 kept. The advantage of measurement-based resource management 241 protocols is that they do not require pre-reservation state or 242 explicit release of the reservations. Moreover, when the user 243 traffic is variable, measurement based admission control could 244 provide higher network utilization than, e.g., peak-rate 245 reservation. However, this can introduce an uncertainty in the 246 availability of the resources. 248 Two types of measurement based admission control schemes are 249 possible: 251 * Congestion notification function based on probing: 253 This method can be used to implement a simple measurement-based 254 admission control within a Diffserv domain. In this scenario the 255 interior nodes are not necessarily NSIS aware nodes. In these 256 interior nodes located along the data path, thresholds are set in 257 the measurement based admission control function for the traffic 258 belonging to different PHBs. In this scenario an end-to-end NSIS 259 message, can be used as a probe packet, meaning that the DSCP field 260 in the header of the IP packet that carries the NSIS message will 261 be re-marked when the predefined congestion threshold is exceeded. 262 In this way the edges can admit or reject flows that are requesting 263 resources. 265 * NSIS measurement-based admission control: 267 In this case the measurement-based admission control functionality 268 is implemented in NSIS aware stateless routers. The main difference 269 between this type of admission control and the congestion 270 notification based on probing is related to the fact that this type 271 of admission control is applied mainly on NSIS aware nodes, giving 272 the possibility to apply measuring techniques, see e.g., [JaSh97], 273 [GrTs03], that are using current and past information on NSIS 274 sessions that requested resources from an NSIS aware interior node. 275 The admission decision is positive if the currently carried traffic, 276 as characterized by the measured statistics, plus the requested 277 resources for the new flow do exceed the system capacity with a 278 probability smaller than some alpha. Otherwise, the admission 279 decision is negative. 281 In the reservation-based method, each Interior node maintains 282 only one reservation state per traffic class. The Ingress edge 283 nodes aggregate individual flow requests into classes, and signal 284 changes in the class reservations as necessary. The reservation is 285 quantified in terms of resource units. These resources are 286 requested dynamically per PHB and reserved on demand in all nodes in 287 the communication path from an Ingress node to an Egress node. 289 RMD describes the following procedures: 291 * classification of individual resource reservation or resource 292 query into Per Hop Behavior groups (PHB) at the Ingress node of 293 the domain, 295 * hop-by-hop admission control based on per PHB within the 296 domain. There are two possible modes of operation for internal 297 nodes to admit requests. One mode is the stateless or 298 measurement-based mode, where the resources within the domain are 299 queried. Another mode of operation is the reduced-state 300 reservation or reservation based mode, where the resources within 301 the domain are reserved. 303 * a method to forward the original requests across the domain up to 304 the Egress node and beyond. 306 * a congestion control algorithm that notifies the egress edge nodes 307 about congestion. It is able to terminate the appropriate number 308 of flows in case a of congestion due to a sudden failure (e.g., 309 link or router failure) within the domain. 311 3.2. Basic features of RMD-QOSM 313 3.2.1 Role of the QNEs 315 The protocol model of the RMD-QOSM is shown in Figure 2. The figure 316 shows QNI and QNR nodes, not part of the RMD network, that are the 317 ultimate initiator and receiver of the QoS reservation requests. It 318 also shows QNE nodes that are the Ingress and Egress nodes in the 319 RMD domain (QNE Ingress and QNE Egress), and QNE nodes that are 320 Interior nodes (QNE Interior). 322 All nodes of the RMD domain are mainly QoS-NSLP aware nodes. Edge 323 nodes store and maintain QoS-NSLP and NTLP states and therefore are 324 stateful nodes. The NSIS aware Interior nodes are NTLP stateless. 325 Furthermore they are either QoS-NSLP stateless (for NSIS measurement- 326 based operation), or are reduced state nodes storing per PHB 327 aggregated QoS-NSLP states (for reservation-based operation). 329 |------| |-------| |------| |------| 330 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 331 | QoS | | QoS | | QoS | | QoS | 332 | | |-------| |------| |------| 333 | | |-------| |-------| |-------| |------| | | 334 | | | local |<->| local |<->| local |<->| local| | | 335 | | | QoS | | QoS | | QoS | | QoS | | | 336 | | | | | | | | | | | | 337 | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | 338 |st.ful| |st.ful | |st.less/ |st.less/ |st.ful| |st.ful| 339 | | | | |red.st.| |red.st.| | | | | 340 | | |-------| |-------| |-------| |------| | | 341 |------| |-------| |-------| |-------| |------| |------| 342 ------------------------------------------------------------------ 343 |------| |-------| |-------| |-------| |------| |------| 344 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP | 345 |st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful| 346 |------| |-------| |-------| |-------| |------| |------| 347 QNI QNE QNE QNE QNE QNR 348 (End) (Ingress) (Interior) (Interior) (Egress) (End) 350 st.ful: stateful, st.less: stateless 351 st.less red.st.: stateless or reduced state 353 Figure 2: Protocol model of stateless/reduced state operation 354 Note that the RMD-QOSM domain MAY contain Interior nodes that are 355 not NSIS aware nodes (not shown in the figure). These nodes are 356 assumed to have sufficient capacity for flows that might be 357 admitted. Furthermore, some of these NSIS unaware nodes MAY be used 358 for measuring the traffic congestion level on the data path. These 359 measurements can be used by RMD-QOSM in the congestion control based 360 on probing operation and/or severe congestion operation 361 (see Section 4.6.1.6). 363 3.2.2 RMD-QOSM signaling 365 The basic RMD-QOSM signaling is shown in Figure 3. A RESERVE 366 message is created by a QNI with an Initiator QSpec describing the 367 reservation and forwarded along the path towards the QNR. When the 368 original RESERVE message arrives at the Ingress node, an RMD-QSpec 369 is constructed based on the top-most QSPEC in the message (usually 370 the Initiator QSPEC). The RMD-QSpec is sent in a local, independent 371 RESERVE message through the Interior nodes towards the QNR. This 372 local RESERVE message uses the NTLP hop-by-hop datagram signaling 373 mechanism. Meanwhile, the original RESERVE message is sent to the 374 Egress node on the path to the QNR using the reliable transport mode 375 of NTLP. 377 QNE QNE QNE QNE 378 Ingress Interior Interior Egress 379 NTLP stateful NTLP stateless NTLP stateless NTLP stateful 380 | | | | 381 RESERVE | | | | 382 -------->| RESERVE | | | 383 +--------------------------------------------->| 384 | RESERVE' | | | 385 +-------------->| | | 386 | | RESERVE' | | 387 | +-------------->| | 388 | | | RESERVE' | 389 | | +------------->| 390 | | | | RESERVE 391 | | | +-------> 392 | | | |RESPONSE 393 | | | |<------- 394 | | | RESPONSE | 395 |<---------------------------------------------+ 396 RESPONSE| | | | 397 <--------| | | | 399 Figure 3: Sender-initiated reservation with Reduced State Interior 400 Nodes 402 Each QoS-NSLP node on the data path processes the local RESERVE 403 message and checks the availability of resources with either the 404 reservation-based or the measurement-based method. When the message 405 reaches the Egress node, and the reservation is successful in each 406 Interior nodes, the original RESERVE message is forwarded to the 407 next domain. When the Egress node receives a RESPONSE message from 408 the downstream end, it is forwarded directly to the Ingress node. 410 If an intermediate node cannot accommodate the new request, it 411 indicates this by marking a single bit in the message, and continues 412 forwarding the message until the Egress node is reached. From the 413 Egress node a RESPONSE message is sent directly the Ingress node. 415 As a consequence in the stateless/reduced state domain only sender- 416 initiated reservation can be performed and functions requiring per 417 flow NTLP or QoS-NSLP states, like summary refreshes, cannot be 418 used. One of the basic features of RMD is that, if per flow 419 identification, is needed, i.e. associating the flows IDs for the 420 reserved resources, Edge nodes act on behalf of Interior nodes. 422 4. RMD-QOSM, Detailed Description 424 This section describes RMD-QOSM in more detail. In particular, 425 it defines the role of stateless and reduced-state QNEs, the 426 RMD-QOSM QSpec Object, the format of RMD-QOSM QoS-NSLP messages 427 and how QSpecs are processed and used in different protocol 428 operations. 430 4.1. RMD-QSpec Definition 432 The QSpec object of RMD-QOSM contains three fields, the "RMD-QOSM QoS 433 Description", the Per Hop Reservation container (PHR container) and 434 the Per Domain Reservation container (PDR container). The 435 "RMD-QOSM QoS Description" field and the PHR container are used and 436 processed by the Edge and Interior nodes. The PDR container field is 437 only processed by Edge nodes. The PHR container contains the QoS 438 specific control information for intra-domain communication and 439 reservation. The PDR container contains additional control 440 information that is needed for edge-to-edge communication. 442 4.1.1. RMD-QOSM QoS Description 444 The RMD-QOSM QoS Description only contains the QoS Desired object 445 [QSP-T]. It does not contain the QoS Available, QoS Reserved or 446 Minimum QoS objects. 448 = 450 = 452 The bit format of the (see Figure 4), (see 453 Figure 5) and are conform to the bit format 454 specified in [QSP-T]. Note that for the RMD-QOSM a reservation 455 established without an parameter is equivalent 456 to a reservation established with an Admission Priority> whose 457 Admission Priority value is 1. 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 |1|E|N|T| 3 |r|r|r|r| 1 || 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Bandwidth (32-bit IEEE floating point number) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Figure 4: Bandwidth parameter 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 |1|E|N|T| 7 |r|r|r|r| 1 | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | DSCP |0 0 0 0 0 0 0 0 0 0| Reserved | 475 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 477 Figure 5: PHB_Class parameter 479 4.1.2. PHR container 481 This section describes the parameters used by the PHR container. 483 = , ,, 484 , ,