idnits 2.17.1 draft-ietf-nsis-rmd-00.txt: -(1762): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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.a on line 21. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2303. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 8) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 45 pages 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. ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 370: '...sed RMD, the value MUST be 1. For the...' RFC 2119 keyword, line 371: '...rement based PHR this value MUST be 2....' RFC 2119 keyword, line 449: '...NF(ingress) node MUST set the ...' RFC 2119 keyword, line 450: '.... This parameter MAY be set to "1" by ...' RFC 2119 keyword, line 575: '... Every edge node MUST be configured to...' (2 more instances...) 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 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 (November 15, 2004) is 7100 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) == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-04 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-03 -- No information found for draft-ash-nsis-nslp-QSpec - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 7 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: May 2005 Georgios Karagiannis 5 University of Twente 6 Cornelia Kappler 7 Siemens 8 Tom Phelan 9 Sonus 10 November 15, 2004 12 RMD-QSP: An NSIS QoS Signaling Policy for Networks Using 13 Resource Management in Diffserv (RMD) 14 16 Status of this memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of RFC 3668. 23 "Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-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 a "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html" 38 Abstract 40 This document describes an NSIS QoS Signaling Policy model for 41 networks that use the Resource Management in Diffserv (RMD) 42 concept. RMD is a technique for adding admission control to 43 Differentiated Services (Diffserv) networks. RMD complements 44 the Diffserv architecture by pushing complex classification, 45 conditioning and admission control functions to the edges of a 46 Diffserv domain and simplifying the operation of internal nodes. 48 It allows feedback to systems outside of the Diffserv domain on 49 the availability of resources for individual sessions within the 50 domain while having the availability to aggregate inter domain 51 (end-to-end) resource reservations at the edge of the domain to 52 reduce the burden on internal nodes. The RMD QoS Signaling Policy 53 Model (RMD-QSP) allows devices to use the NSIS QoS-NSLP protocol to 54 signal reservation requests from devices outside the Diffserv domain 55 to edge nodes in the domain, edge nodes have the availability to 56 aggregate the requests and signal the aggregated requests 57 through internal nodes along the data path to the egress edge 58 nodes, and for Egress Edge nodes to signal the original, 59 disaggregated, requests to outside devices. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .3 65 3. Overview of RMD and RMD-QSP . . . . . . . . . . . . . . . . .4 66 3.1 RMD . . . . . . . . . . . . . . . . . . . . . . . . . . .4 67 3.2 RMD-QSP . . . . . . . . . . . . . . . . . . . . . . . . .5 68 4. RMD QSP, detailed description . . . . . . . . . . . .. . . . 7 69 4.1 QSpec Definition . . . . . . . . . . . . . . . . . . . . 7 70 4.1.1 RMD-QSP descriptors . . . . . . . . . . . . . . . .8 71 4.1.2 PHR RMD-QSP control information . . . . . . . . . .8 72 4.1.3 PDR RMD-QSP control information . . . . . . . . .10 73 4.1.4 Mapping of QSpec parameters onto generic 74 QSpec Parameters . . . . . . . . . . . . . . . . .12 75 4.2 Role of QoS NSLP Entities (QNEs) . . . . . . . . . . . .12 76 4.3 Message format . . . . . . . . . . . . . . . . . . . . .13 77 4.4 State management . . . . . . . . . . . . . . . . . . . .14 78 4.5 Operation and sequence of events . . . . . . . . . . . .16 79 4.5.1 Edge discovery and addressing of messages . . . . 16 80 4.5.2 Basic unidirectional operation . . . . . . . . . .16 81 4.5.2.1 Successful reservation. . . . . . . . . . . .17 82 4.5.2.2 Unsuccessful reservation . . . . . . . . . . 22 83 4.5.2.3 RMD refresh reservation. . . . . . . . . . . 24 84 4.5.2.4 RMD modification of reservation. . . . . . . 28 85 4.5.2.5 RMD release procedure. . . . . . . . . . . . 28 86 4.5.2.6 Severe congestion. . . . . . . . . . . . . . 34 87 4.5.3 Bidirectional operation . . . . . . . . . . . . . 36 88 4.5.3.1 Successful and unsuccessful reservation . . .37 89 4.6 Handling of errors . . . . . . . . . . . . . . . . . . .41 90 5. Security Consideration. . . . . . . . . . . . . . . . . . . 41 91 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .42 92 7. Open issues. . . . . . . . . . . . . . . . . . . . . . . . .42 93 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .42 94 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 43 95 10. Normative References . . . . . . . . . . . . . . . . . . . 43 96 11. Informative References . . . . . . . . . . . . . . . . . . 44 97 12. Intellectual Property Rights . . . . . . . . . . . . . . . 45 99 1. Introduction 101 This document describes an example of a Next Steps In Signaling 102 (NSIS) Quality of Service Signaling Model for networks that use the 103 Resource Management in Diffserv (RMD) framework ([RMD1], [RMD2], 104 [RMD3],[RMD4]). RMD is a method for devices external to a Diffserv 105 domain to dynamically reserve resources within the Diffserv domain. 106 It describes a procedure that can aggregate individual reservation 107 requests at the Ingress Edge of the domain, two possible modes of 108 operation for internal nodes to admit aggregated requests (a 109 stateless, measurement-based mode, and a reduced-state reservation 110 mode), and a method to forward the original requests across the 111 domain to the Egress Edge and on. 113 The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP) 114 [QoS-NSLP] specifies a generic model for carrying Quality of Service 115 (QoS) signal 116 ing information end-to-end in an IP network. Each 117 network along the end-to-end path is expected to implement a 118 specific QoS Signaling Model (QSP) that installs the necessary state 119 to ensure the requested QoS in a manner that is appropriate to the 120 technology in use in the network. 122 This document specifies the RMD QoS Signaling Policy Model 123 (RMD-QSP), as a specific implementation of a QoS-NSLP QSP, for use 124 in networks that use RMD technology. Internally to the Diffserv 125 network, RMD-QSP uses the stateless/reduced state operation mode of 126 QoS-NSLP and defines a scalable QoS signaling model in which per 127 flow QoS-NSLP and NTLP states are not stored but per flow signaling 128 is performed. 130 In the RMD-QSP, only routers at the edges of a Diffserv domain 131 support the QoS-NSLP stateful operation. Internal routers support 132 either the QoS-NSLP stateless operation, or a reduced-state 133 operation with coarser granularity than the edge nodes. 135 The remainder of this draft is structured following the suggestions 136 in Appendix B of [QSP-T] for description of QoS Signaling Policies: 137 After the terminology Section 2, we give an overview of RMD and the 138 RMDQSP in Sec. 3. In Sec. 4 we give a detailed description of the 139 RMD-QSP, including the role of QNEs, the definition of the QSpec, 140 mapping of QSpec generic parameters onto RMDQSP parameters, state 141 management in QNEs, and operation and sequence of events. Sec. 5 142 discusses security issues. 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 147 NOT", "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 148 in this document are to be interpreted as described in RFC 2119. 150 3. Overview of RMD and RMD-QSP 152 3.1. RMD 154 The Differentiated Services (Diffserv) architecture ([RFC2475], 155 [RFC2638]) was introduced as a result of efforts to avoid the 156 scalability and complexity problems of Intserv [RFC1633]. 157 Scalability is achieved by offering services on an aggregate basis 158 rather than per-flow and by forcing as much of the per-flow state as 159 possible to the edges of the network. The service differentiation 160 is achieved using the Differentiated Services (DS) field in the IP 161 header and the Per-Hop Behavior (PHB) as the main building blocks. 162 Packets are handled at each node according to the PHB indicated by 163 the DS field in the message header. 165 The Diffserv architecture does not specify any way for devices 166 outside the domain to dynamically reserve resources or receive 167 indications of network resource availability. In practice, service 168 providers rely on subscription-time Service Level Agreements (SLAs) 169 that statically define the parameters of the traffic that will be 170 accepted from a customer. 172 RMD was introduced as a method for dynamic reservation of resources 173 within a Diffserv domain. It describes a method that can aggregate 174 individual reservation request at the Ingress Edge of the domain, 175 two possible modes of operation for internal nodes to admit 176 aggregated requests (a stateless, measurement-based mode, and a 177 reduced-state reservation mode), and a method to forward the 178 original requests across the domain to the Egress Edge and on. 180 In RMD, scalability is achieved by separating a complex reservation 181 mechanism used in edge nodes of a Diffserv domain from a much 182 simpler reservation mechanism needed in the interior nodes. In 183 particular, it is assumed that edge nodes of a Diffserv domain 184 support per-flow (or aggregated flows) QoS states in order to 185 provide QoS guarantees for each flow (or aggregated flow). Interior 186 nodes use only one aggregated reservation state per traffic class or 187 no states at all. This solution allows fast processing of signaling 188 messages and makes it possible to handle large numbers of flows in 189 the interior nodes. 191 In RMD two basic operation modes are described: a measurement-based 192 admission control and a reservation-based admission control. The 193 measurement-based algorithm uses the requested and available 194 resources as input to query the aggregated reservation state per 195 traffic class in the interior nodes. The advantage of measurement 196 based resource management protocols is that they do not require 197 explicit reservation or release. Moreover, when the user traffic is 198 variable, measurement based admission control could provide higher 199 network utilization than, e.g., peak-rate reservation. However, 200 this requires more complex implementation in interior nodes and 201 introduces an uncertainty of the availability of the resources. 203 With the reservation-based method, each node in the domain maintains 204 one reservation state per traffic class. The reservation is 205 quantified in terms of resource units. These resources are 206 requested dynamically per PHB and reserved on demand in all nodes in 207 the communication path from an ingress node to an egress node. 209 3.2. RMD-QSP 211 RMD-QSP is a QoS-NSLP QoS signaling model for networks that usees 212 RMD technology for processing reservations. In a RMD-QSP domain, an 213 inter-domain (end to end) QoS NSLP message that arrives at the 214 ingress edge generates an additional intra-domain (local) QoS NSLP 215 message containing a RMD QSpec and the inter-domain message is 216 tunneled towards the egress edge. Edge nodes use QoS-NSLP stateful 217 operation and interior nodes use either stateless operation 218 (for measurement-based admission) or reduced state operation (for 219 reservation-based admission). 221 The RMD-QSP uses a simple, hop-by-hop signaling mechanism. The QSpec 222 arrives in an QoS NSLP RESERVE message at the ingress node. The 223 ingress node uses the external QSpec to construct the RMD-QSPec for 224 intra-domain (local) RMD-QSP specific signaling, and sends it in a 225 RESERVE message to the Egress node. Each node on the data path, one 226 after the other, checks the availability of resources with either 227 the reservation-based or the measurement-based method. If an 228 intermediate node cannot accommodate the new request, it indicates 229 it by marking a single bit in the message, and continues forwarding 230 the message. When the message reaches the egress edge node, if no 231 intermediate node has denied the reservation, the generic request is 232 forwarded to the next domain. If an intermediate node has denied 233 the reservation, the reservation is denied. 235 In the simplest case the domain wherein the RMD-QSP 236 is applied is identical to a Diffserv administrative domain. The 237 boundary nodes of the domain are QoS-NSLP aware edge nodes (QNF 238 ingress and QNF Egress Edges) and the interior nodes are QoS-NSLP 239 aware interior nodes (QNF interior). In the interior nodes, RMD-QSP 240 uses the stateless/reduced state operation mode defined in QoS-NSLP. 241 In the edge nodes, RMD-QSP uses the stateful mode of operation. 243 The protocol model of the RMD-QSP is shown in Figure 1. The QNF 244 nodes leading up to the edge of the RMD-QSP domain process the QoS- 245 NSLP messages in a manner appropriate to their QoS technology. At 246 the ingress edge node of the RMD-QSP domain, the inter domain 247 (end-to-end) QoS-NSLP messages trigger the generation of 248 intra-domain (local) RMD-QSP QoS-NSLP messages. The QSpec of the 249 inter domain (end-to-end) QoS-NSLP message is translated into an 250 RMD-QSP QSpec. 252 |------| |------| |------| |------| 253 | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | 254 | QoS | | QoS | | QoS | | QoS | 255 | | |------| |------| |------| 256 | | |------| |-------| |-------| |------| | | 257 | | | local|<->| local |<->| local |<->| local| | | 258 | | | QoS | | QoS | | QoS | | QoS | | | 259 | | | | | | | | | | | | 260 | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | 261 |st.ful| |st.ful| |st.less| |st.less| |st.ful| |st.ful| 262 | | | | |red.st.| |red.st.| | | | | 263 | | |------| |-------| |-------| |------| | | 264 |------| |------| |-------| |-------| |------| |------| 265 ----------------------------------------------------------------- 266 |------| |------| |-------| |-------| |------| |------| 267 | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP | 268 |st.ful| |st.ful| |st.less| |st.less| |st.ful| |st.ful| 269 |------| |------| |-------| |-------| |------| |------| 270 QNI QNF QNF QNF QNF QNR 271 (End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) 273 st.ful: stateful, st.less: stateless 274 st.less red.st.: stateless or reduced state 276 Figure 1 Protocol model of stateless/reduced state operation 278 The original QoS-NSLP messages are sent directly to the next NTLP 279 stateful node, i.e. to the Egress Edge node, see Figure 2. The 280 intra-domain (local) QoS-NSLP messages are processed and 281 interpreted in all interior NSLP routers along the path, hop-by-hop, 282 up to the Egress Edge node. 284 RMD usually performs per flow signaling within the domain. However, 285 RMD can also support per aggregate signaling within the domain. In 286 the reservation-based method interior nodes add and remove the 287 requested resources per PHB. In case of the measurement-based 288 method the availability of resources are checked. In case of 289 unsuccessful reservation in a router, egress nodes are notified by 290 marking the corresponding control field of the Request message. 291 After successful or unsuccessful reservation a RESPONSE message is 292 sent from Egress to Ingress Edge. 294 The RMD reservation method uses soft states: reserved resources 295 should be refreshed periodically. If refresh messages are not 296 arrived within the refresh period the corresponding resource units 297 are removed. Resource units can be removed explicitly as well, by 298 sending Release messages containing the removable resource units. 300 QNF QNF QNF QNF 301 ingress interior interior egress 302 NTLP stateful NTLP stateless NTLP stateless NTLP stateful 303 | | | | 304 RESERVE | | | | 305 -------->| RESERVE | | | 306 +--------------------------------------------->| 307 | RESERVE' | | | 308 +-------------->| | | 309 | | RESERVE' | | 310 | +-------------->| | 311 | | | RESERVE' | 312 | | +------------->| 313 | | | | RESERVE 314 | | | +--------> 315 | | | | RESPONSE 316 | | | |<-------- 317 | | | RESPONSE | 318 |<---------------------------------------------+ 319 RESPONSE| | | | 320 <--------| | | | 322 Figure 2: Sender-initiated reservation with Reduced State Interior 323 Nodes 325 4. RMD-QSP, Detailed Description 327 This section describes RMD-QSP in detail. Particularly, we explain 328 the role of stateless and reduced-state QNEs, define the RMD-QSP 329 QSpec Object, the format of RMD-QSP QoS-NSLP messages, how QSpecs 330 are processed and used, and the protocol operation. 332 4.1. QSpec Definition 334 This section describes the QSpec that is used by RMD-QSP. The RMD- 335 QSP QSpec object contains three fields, the "RMD-QSP QoS 336 descriptor", the (per hop reservation) "PHR RMD-QSP control 337 information" and the (per domain reservation) "PDR RMD-QSP control 338 information". The "RMD-QSP QoS descriptors" and the "PHR RMD-QSP 339 control information" fields are used and processed by all QoS-NSLP 340 nodes in the edge-to-edge domain, i.e., QNF (edge nodes) and QNF 341 (interior nodes). The "PDR RMD-QSP control information" field is 342 only used and processed by the QNF (edge nodes). The "PHR RMD-QSP 343 control information" field contains the QoS specific control 344 information for intra-domain communication and reservation. The 345 "PDR RMD-QSP control information" contains additional information 346 that is needed by the QNF (edge nodes) and is not available 347 (carried) by the "PHR RMD-QSP control information". RMD-QSP QSpec 348 parameters will be updated in line with 349 QSpec Template draft [QSP-T]. 351 4.1.1. RMD-QSP QoS descriptors 353 This section describes the parameters used by the "RMD-QSP QoS 354 descriptors field" field. The RMD QoS Description only contains the 355 object QoS Desired [QSP-T]. It does not contain the objects QoS 356 Available, QoS Reserved or Minimum QoS. 358 = 360 As described in [QSP-T]. 362 4.1.2. PHR RMD-QSP control information 364 This section describes the parameters used by the "PHR RMD-QSP 365 control information" field. Except these parameters are 366 currently not among the generic parameters defined by . 368 : 369 4-bit field. This specifies the per hop reservation type. 370 For the reservation based RMD, the value MUST be 1. For the 371 measurement based PHR this value MUST be 2. 373 : 374 4 bit field, indicating the "PHR RMD-QSP control information" 375 type: PHR_Resource_Request, PHR_Release_Request, 376 PHR_Refresh_Update. It is used to further specify QoS-NSLP 377 RESERVE and RESPONSE messages. 379 "PHR_Resource_Request" (Message Type = 1): initiate or update 380 the traffic class reservation state on all nodes located on 381 the communication path between the QNF(ingress) and 382 QNF(egress) nodes. 384 "PHR_Refresh_Update" (Message Type = 2): refresh the traffic 385 class reservation soft state on all nodes located on the 386 communication path between the QNF(ingress) and QNF(egress) 387 nodes according to a resource reservation request that was 388 successfully processed by the "PHR RMD-QSP control 389 information" functionality during a previous refresh period. 391 "PHR_Release_Request" (Message Type = 3): explicitly release, 392 by subtraction, the reserved resources for a particular flow 393 from a traffic class reservation state. 395 (Severe Congestion): 396 1 bit. In case of a route change refreshing RESERVE messages 397 follow the new data path, and hence resources are requested 398 there. However, on the new path resources may not be 399 sufficie 400 nt to accommodate the new traffic. Congested interior 401 nodes should notify edge QNFs about the congestion, in order 402 to terminate some of the sessions. The notification of the 403 egress QNF is carried out by marking either the data packets 404 with dedicated DSCPs or by setting the S Field bit indicating 405 severe congestion in the refresh message. The egress QNF 406 decides which sessions should be terminated and sends a 407 RESPONSE message to the Ingress Edge with the session ID and 408 indicating the severe congestion. Since refresh messages are 409 usually sent less frequently than the data packets a more 410 efficient method for the notification is marking the data 411 packets by changing the DSCP field. 413 : 415 In case of severe congestion the level of overload can be 416 indicated by using e.g. proportional marking if data marking 417 is used. If RMD refresh messages are used, proportional 418 marking is not a feasible solution usually because of the low 419 number of refresh messages. Overload % can be used to 420 indicate the level of Overload %. Note that Overload % should 421 be higher than 0 if S bit is set. If overload in a node is 422 greater than the overload in a previous node then Overload % 423 should be updated. 425 : 427 1 bit. In case of unsuccessful reservation in an interior 428 QNF, this QNF sets the M bit in order to notify the egress 429 QNF. 431 : 433 8 bit field. The Hop Count is set to zero when a RESERVE 434 message enters a domain and increased by one at each interior 435 QNF. However when a QNF is reached that does not have 436 sufficient resources to admit the reservation, the M Bit is 437 set, and the Hop Count value is frozen. Hence the Hop Count 438 counts the number of hops where the reservation was 439 successful. In case of an unsuccessful reservation the M Bit 440 is set, and the egress QNF reacts by sending a RESPONSE 441 message containing the Hop Count to the ingress QNF. The 442 ingress QNF uses the Hop Count value to remove the unnecessary 443 reservations by an explicit tearing RESERVE message to the 444 nodes along the path where the reservation has already been 445 made. 447 (Hop Count unset): 449 1-bit. The QNF(ingress) node MUST set the parameter to 450 0. This parameter MAY be set to "1" by a node when the node 451 will not increase the value. This is the case when 452 an RMD-QSM reservation-based node is not admitting the "RMDQSM 453 QoS descriptors" and "PHR_Resource_Request" control 454 information fields. 456 : 1 bit. Indicates bi-directional reservation. 458