idnits 2.17.1 draft-ietf-nsis-rmd-04.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 2667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2657. ** 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 1 instance 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: The QNE Interior node detecting severe congestion marks data packets passing the node. For the severe congestion marking, two additional DSCPs SHOULD be allocated for each traffic class. One MAY be used to indicate that the packet passed a congested node. The other DSCP MUST be used to indicate the degree of congestion by marking the bytes proportionally to the degree of congestion. Note, however, that 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, if one DSCP is allocated for severe congestion indication for each AF classes, independently from dropping precedence. Assuming 4 AF classes and 1 EF class, the number of DSCPs used for severe congestion is 5. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2005) is 6759 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: 'RFC 3175' is mentioned on line 1197, but not defined == Unused Reference: 'RFC2119' is defined on line 2576, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 2588, but no explicit reference was found in the text == Unused Reference: 'RFC3175' is defined on line 2596, but no explicit reference was found in the text == Unused Reference: 'RMD4' is defined on line 2628, but no explicit reference was found in the text == Unused Reference: 'RSVP-DOI' is defined on line 2631, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-06 ** 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 (~~), 15 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS Working Group Attila Bader 2 INTERNET-DRAFT Lars Westberg 3 Ericsson 4 Expires: 24 May 2006 Georgios Karagiannis 5 University of Twente 6 Cornelia Kappler 7 Siemens 8 Tom Phelan 9 Sonus 10 October 24, 2005 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 May 24, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 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 to Differentiated Services (Diffserv) 49 networks. The RMD QoS Model allows devices external to the 50 RMD network to signal reservation requests to edge nodes in the RMD 51 network. The RMD Ingress edge nodes classify the incoming flows into 52 traffic classes and signals resource requests for the corresponding 53 traffic class along the data path to the Egress edge nodes for each 54 flow. Egress nodes reconstitute the original requests and continue 55 forwarding them along the data path towards the final destination. 56 In addition, RMD defines notification functions to indicate overload 57 situations within the domain to the edge nodes. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .3 63 3. Overview of RMD and RMD-QOSM . . . . . . . . . . . . . .. . .4 64 3.1 RMD . . . . . . . . . . . . . . . . . . . . . . . . . . .4 65 3.2 Basic features of RMD-QOSM . . . . . . . . . . . . . . . 6 66 3.2.1 Role of the QNEs . . . . . . . .. . . . . . . . . .6 67 3.2.2 RMD-QOSM signaling . . . . . . . . . . . . . . . . 7 68 4. RMD-QOSM, Detailed Description . . . . . . . . . . . .. . . .8 69 4.1 RMD-QSpec Definition . . . . . . . . . . . . . . . . . . 8 70 4.1.1 RMD-QOSM QoS Description . . . . . . . . . . . . .9 71 4.1.2 PHR RMD-QOSM control information . . . . . . . . . 9 72 4.1.3 PDR RMD-QOSM control information . . . . . . . . 11 73 4.1.4 Mapping of QSpec parameters onto generic 74 QSpec Parameters . . . . . . . . . . . . . . . . .12 75 4.2 Message format . . . . . . . . . . . . . . . . . . . . .13 76 4.3 RMD node state management . . . . . . . . . . . . . . . 14 77 4.3.1 Aggregated versus per flow reservations at the 78 QNE edges . . . . . . . . . . . . . . . . . . . . 14 79 4.3.2 Measurement-based method . . . . . . . . . . . . .15 80 4.3.3 Reservation-based method . .. . . . . . . . . . . 15 81 4.4 Transport of RMD-QOSM messages . . . . . . . . . . . . .16 82 4.5 Edge discovery and addressing of messages . . . . . . . 16 83 4.6 Operation and sequence of events . . . . . . . . . . . .16 84 4.6.1 Basic unidirectional operation . . . . . . . . . .17 85 4.6.1.1 Successful reservation. . . . . . . . . . . .17 86 4.6.1.2 Unsuccessful reservation . . . . . . . . . . 22 87 4.6.1.3 RMD refresh reservation. . . . . . . . . . . 24 88 4.6.1.4 RMD modification of aggregated reservation . 27 89 4.6.1.5 RMD release procedure. . . . . . . . . . . . 28 90 4.6.1.6 Severe congestion handling . . . . . . . . .34 91 4.6.2 Bidirectional operation . . . . . . . . . . . . . 38 92 4.6.2.1 Successful and unsuccessful reservation . . .39 93 4.6.2.2 Refresh reservation . . . . . . . . . . . . .43 94 4.6.2.3 Modification of aggregated reservation . . . 44 95 4.6.2.4 Release procedure . . . . . . . . . . . . . .45 96 4.6.2.5 Severe congestion handling . . . . . . . . . 45 97 4.7 Handling of additional errors . . . . . . . . . . . . . 49 98 5. Security Consideration. . . . . . . . . . . . . . . . . . . 49 99 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .53 100 7. Open issues. . . . . . . . . . . . . . . . . . . . . . . . .53 101 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .53 102 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 54 103 10. Normative References . . . . . . . . . . . . . . . . . . . 55 104 11. Informative References . . . . . . . . . . . . . . . . . . 55 105 12. Intellectual Property Rights . . . . . . . . . . . . . . . 57 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 GIMPS [GIMPS] 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. The measurement- 235 based algorithm continuously measures traffic levels and the actual 236 available resources, and admits flows whose resource needs are 237 within what is available at the time of the request. Once 238 an admission decision is made, no record of the decision need be 239 kept. The advantage of measurement-based resource management 240 protocols is that they do not require pre-reservation state or 241 explicit release of the reservations. Moreover, when the user 242 traffic is variable, measurement based admission control could 243 provide higher network utilization than, e.g., peak-rate 244 reservation. However, this can introduce an uncertainty in the 245 availability of the resources. 247 With the reservation-based method, each Interior node maintains 248 only one reservation state per traffic class. The Ingress edge 249 nodes aggregate individual flow requests into classes, and signal 250 changes in the class reservations as necessary. The reservation is 251 quantified in terms of resource units. These resources are 252 requested dynamically per PHB and reserved on demand in all nodes in 253 the communication path from an Ingress node to an Egress node. 255 RMD describes the following procedures: 257 * classification of individual resource reservation or resource 258 query into Per Hop Behavior groups (PHB) at the Ingress node of 259 the domain, 261 * hop-by-hop admission control based on per PHB within the 262 domain. There are two possible modes of operation for internal 263 nodes to admit requests. One mode is the stateless or 264 measurement-based mode, where the resources within the domain are 265 queried. Another mode of operation is the reduced-state 266 reservation or reservation based mode, where the resources within 267 the domain are reserved. 269 * a method to forward the original requests across the domain up to 270 the Egress node and beyond. 272 * a congestion control algorithm that notifies the egress edge nodes 273 about congestion. It is able to terminate the appropriate number 274 of flows in case a of congestion due to a sudden failure (e.g., 275 link or router failure) within the domain. 277 3.2. Basic features of RMD-QOSM 279 3.2.1 Role of the QNEs 281 The protocol model of the RMD-QOSM is shown in Figure 2. The figure 282 shows QNI and QNR nodes, not part of the RMD network, that are the 283 ultimate initiator and receiver of the QoS reservation requests. It 284 also shows QNE nodes that are the Ingress and Egress nodes in the 285 RMD domain (QNE Ingress and QNE Egress), and QNE nodes that are 286 Interior nodes (QNE Interior). 288 All nodes of the RMD domain are QoS-NSLP aware nodes. Edge nodes 289 store and maintain QoS-NSLP and NTLP states and therefore are 290 stateful nodes. The Interior nodes are NTLP stateless. Furthermore 291 they are either QoS-NSLP stateless (for measurement-based 292 operation), or are reduced state nodes storing per PHB aggregated 293 QoS-NSLP states (for reservation-based operation). 295 Note that the RMD-QOSM domain MAY contain Interior nodes that are 296 not NSIS aware nodes (not shown in the figure). These nodes are 297 assumed to have sufficient capacity for flows that might be 298 admitted. Furthermore, some of these NSIS unaware nodes MAY be used 299 for measuring the traffic congestion level on the data path. These 300 measurements can be used by RMD-QOSM in the congestion control 301 operation (see Section 4.6.1.6). 303 |------| |-------| |------| |------| 304 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 305 | QoS | | QoS | | QoS | | QoS | 306 | | |-------| |------| |------| 307 | | |-------| |-------| |-------| |------| | | 308 | | | local |<->| local |<->| local |<->| local| | | 309 | | | QoS | | QoS | | QoS | | QoS | | | 310 | | | | | | | | | | | | 311 | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | 312 |st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful| 313 | | | | |red.st.| |red.st.| | | | | 314 | | |-------| |-------| |-------| |------| | | 315 |------| |-------| |-------| |-------| |------| |------| 316 ------------------------------------------------------------------ 317 |------| |-------| |-------| |-------| |------| |------| 318 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP | 319 |st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful| 320 |------| |-------| |-------| |-------| |------| |------| 321 QNI QNE QNE QNE QNE QNR 322 (End) (Ingress) (Interior) (Interior) (Egress) (End) 324 st.ful: stateful, st.less: stateless 325 st.less red.st.: stateless or reduced state 327 Figure 2: Protocol model of stateless/reduced state operation 329 3.2.2 RMD-QOSM signaling 331 The basic RMD-QOSM signaling is shown in Figure 3. A RESERVE 332 message is created by a QNI with an Initiator QSpec describing the 333 reservation and forwarded along the path towards the QNR. When the 334 original RESERVE message arrives at the Ingress node, an RMD-QSpec 335 is constructed based on the top-most QSPEC in the message (usually 336 the Initiator QSPEC). The RMD-QSpec is sent in a local, independent 337 RESERVE message through the Interior nodes towards the QNR. This 338 local RESERVE message uses the NTLP hop-by-hop datagram signaling 339 mechanism. Meanwhile, the original RESERVE message is sent to the 340 Egress node on the path to the QNR using the reliable transport mode 341 of NTLP. 343 Each QoS NSLP node on the data path processes the local RESERVE 344 message and checks the availability of resources with either the 345 reservation-based or the measurement-based method. When the message 346 reaches the Egress node, and the reservation is successful in each 347 Interior nodes, the original RESERVE message is forwarded to the 348 next domain. When the Egress node receives a RESPONSE message from 349 the downstream end, it is forwarded directly to the Ingress node. 351 If an intermediate node cannot accommodate the new request, it 352 indicates this by marking a single bit in the message, and continues 353 forwarding the message until the Egress node is reached. From the 354 Egress node a RESPONSE message is sent directly the Ingress node. 356 QNE QNE QNE QNE 357 Ingress Interior Interior Egress 358 NTLP stateful NTLP stateless NTLP stateless NTLP stateful 359 | | | | 360 RESERVE | | | | 361 -------->| RESERVE | | | 362 +--------------------------------------------->| 363 | RESERVE' | | | 364 +-------------->| | | 365 | | RESERVE' | | 366 | +-------------->| | 367 | | | RESERVE' | 368 | | +------------->| 369 | | | | RESERVE 370 | | | +-------> 371 | | | |RESPONSE 372 | | | |<------- 373 | | | RESPONSE | 374 |<---------------------------------------------+ 375 RESPONSE| | | | 376 <--------| | | | 378 Figure 3: Sender-initiated reservation with Reduced State Interior 379 Nodes 381 As a consequence in the stateless/reduced state domain only sender- 382 initiated reservation can be performed and functions requiring per 383 flow NTLP or QoS-NSLP states, like summary refreshes, cannot be 384 used. One of the basic features of RMD is that, if per flow 385 identification, is needed, i.e. associating the flows IDs for the 386 reserved resources, Edge nodes act on behalf of Interior nodes. 388 4. RMD-QOSM, Detailed Description 390 This section describes RMD-QOSM in more detail. In particular, 391 it defines the role of stateless and reduced-state QNEs, the 392 RMD-QOSM QSpec Object, the format of RMD-QOSM QoS-NSLP messages 393 and how QSpecs are processed and used in different protocol 394 operations. 396 4.1. RMD-QSpec Definition 398 The RMD-QOSM QSpec object contains three fields, the "RMD-QOSM QoS 399 Description", the Per Hop Reservation "PHR RMD-QOSM control 400 information" container (PHR container) and the Per Domain Reservation 401 "PDR RMD-QOSM control information" container (PDR container). The 402 "RMD-QOSM QoS Description" field and the PHR container are used and 403 processed by edge and Interior nodes. The PDR container field is 404 only processed by edge nodes. The PHR container contains the QoS 405 specific control information for intra-domain communication and 406 reservation. The PDR container contains additional information that 407 is needed for edge-to-edge communication. 409 4.1.1. RMD-QOSM QoS Description 411 This section describes the parameters used by the "RMD-QOSM QoS 412 Description" field. The RMD-QOSM QoS Description only contains the 413 QoS Desired object [QSP-T]. It does not contain the QoS Available, 414 QoS Reserved or Minimum QoS objects. 416 = 418 = 420 The bit format of the and conform to the 421 bit format specified in [QSP-T] and can be seen in Figure 4 and 422 Figure 5, respectively. 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 |1|E|N|T| 3 |r|r|r|r| 1 || 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Bandwidth (32-bit IEEE floating point number) | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 4: Bandwidth parameter 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 |1|E|N|T| 7 |r|r|r|r| 1 | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | DSCP |0 0 0 0 0 0 0 0 0 0| Reserved | 440 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 441 Figure 5: PHB_Class parameter 443 4.1.2. PHR RMD-QOSM control information container (PHR container) 445 This section describes the parameters used by the PHR container. 447 = , ,, 448 , ,