idnits 2.17.1 draft-gao-mpls-teas-rsvpte-state-update-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 6) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 35 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** 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. RFC 2119 keyword, line 109: '... flag set, SHOULD respond with a MES...' RFC 2119 keyword, line 112: '... MUST make use of the Hello session ...' RFC 2119 keyword, line 114: '... failures. MUST implement coupling t...' RFC 2119 keyword, line 117: '...ure, the speaker MUST act as if all th...' RFC 2119 keyword, line 178: '...efresh message disable extensions MUST...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 42 has weird spacing: '... months and ...' == Line 43 has weird spacing: '... at any time...' == Line 44 has weird spacing: '...ference mate...' -- The document date (January 10, 2022) is 837 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: 'RFC2119' is mentioned on line 151, but not defined == Missing Reference: 'RFC8174' is mentioned on line 151, but not defined == Unused Reference: 'RFC8370' is defined on line 290, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gao 3 INTERNET-DRAFT J. Dai 4 Intended Status: Proposed Standard 5 Expires: July 10, 2022 6 Fiberhome Telecom LTD 7 January 10, 2022 9 State-updating mechanism in RSVP-TE for MPLS network 10 draft-gao-mpls-teas-rsvpte-state-update-04 12 Abstract 14 RSVP-TE has the following advantages: source routing capability, 15 and the ability to reserve resources hop by hop along the LSP path. 16 The two advantages are used by Deterministic Networking (DetNet) 17 to provide DetNet Quality of Service (QoS) in a fully distributed 18 control plane utilizing dynamic signaling protocols or in a 19 Combined Control Plane (partly centralized, partly distributed). 21 RSVP takes a "soft state" approach to manage the reservation 22 state in routers and hosts. The use of 'Refresh messages' to cover 23 many possible failures has resulted in a number of operational 24 problems. One problem relates to scaling, another relates to the 25 reliability and latency of RSVP Signaling. 27 This document describes a number of mechanisms that can be used to 28 reduce processing overhead requirements of refresh messages. These 29 extension present no backwards compatibility issues. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six 42 months and may be updated, replaced, or obsoleted by other 43 documents at any time. It is inappropriate to use Internet-Drafts 44 as reference material or to cite them other than as "work in 45 progress." 47 Copyright and License Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Terms Used in This Document. . . . . . . . . . . . . . . . 3 67 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Requirements Language. . . . . . . . . . . . . . . . . . . . . 4 69 4. State-updating mechanism in RSVP for MPLS network. . . . . . . 4 70 4.1. Reliable RSVP message delivery . . . . . . . . . . . . . . 5 71 4.2. Hello Extension for tear message . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 Standard RSVP [RFC2205] maintains state via the generation of RSVP 80 refresh messages. Refresh messages are used to both synchronize 81 state between RSVP neighbors and to recover from lost RSVP messages. 82 The use of Refresh messages to cover many possible failures has 83 resulted in a number of operational problems. One problem relates to 84 scaling, another relates to the reliability and latency of RSVP 85 Signaling. 87 The scaling problems are linked to the resource requirements (in 88 terms of processing and memory) of running RSVP. The resource 89 requirements increase proportionally with the number of sessions. 90 Each session requires the generation, transmission, reception and 91 processing of RSVP Path and Resv messages per refresh period. 92 Supporting a large number of sessions, and the corresponding volume 93 of refresh messages, presents a scaling problem. 95 The reliability and latency problem occurs when a non-refresh RSVP 96 message is lost in transmission. Standard RSVP [RFC2205] recovers 97 from a lost message via RSVP refresh messages. In the face of 98 transmission loss of RSVP messages, the end-to-end latency of RSVP 99 signaling is tied to the refresh interval of the node(s) experiencing 100 the loss. When end-to-end signaling is limited by the refresh 101 interval, the delay incurred in the establishment or the change of a 102 reservation may be beyond the range of what is acceptable for some 103 applications. 105 This document proposes to disable RSVP refresh messages to solve 106 soft-state scaling problems. The reliable message delivery mechanism 107 specified in [RFC2961] states that "Nodes receiving a non-out of 108 order message containing a MESSAGE_ID object with the ACK_Desired 109 flag set, SHOULD respond with a MESSAGE_ID_ACK object.". When RSVP 110 refresh messages are disabled, the time to deallocate resources 111 after a tear message is lost is an issue. To solve this problem, 112 MUST make use of the Hello session based on the Node-ID 113 ([RFC3209][RFC4558]) for detection of RSVP-TE signaling adjacency 114 failures. MUST implement coupling the state of individual LSPs 115 with the state of the corresponding RSVP-TE signaling adjacency. 116 When an RSVP-TE speaker detects RSVP-TE signaling adjacency 117 failure, the speaker MUST act as if all the Path and Resv states 118 learned via the failed signaling adjacency have timed out. To 119 avoid compatibility problems, a flag bit in the RSVP message 120 header is extended to disable RSVP refresh messages. 122 2. Terminology 124 2.1. Terms Used in This Document 125 Refresh messages: represent previously advertised state and contain 126 exactly the same objects and same information as a previously 127 transmitted message, and are sent over the same path. Only Path and 128 Resv messages can be refresh messages. Refresh messages are 129 identical to the corresponding previously transmitted message, with 130 some possible exceptions. 132 Trigger messages: Trigger messages are those RSVP messages that 133 advertise state or any other information not previously 134 transmitted. Trigger messages include messages advertising new 135 state, a route change that alters a reservation path, or a 136 modification to an existing RSVP session or reservation. 138 2.2. Abbreviations 140 The following abbreviations are used in this document: 141 RSVP: Resource ReserVation Protocol. 142 RSVP-TE: Resource ReserVation Protocol - Traffic Engineering. 144 3 Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in 149 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 150 capitals, as shown here. 152 4 State-updating mechanism in RSVP for MPLS network 154 To indicate support for the refresh message disable extensions, an 155 additional capability bit is added to the common RSVP header, which 156 is defined in [RFC2205]. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Vers | Flags | Msg Type | RSVP Checksum | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Send_TTL | (Reserved) | RSVP Length | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 1 RSVP header 167 Flags: 4 bits 169 0x02: Refresh message disable 171 When set, indicates that this node is willing and capable of 172 supporting the refresh message disable extensions described in 173 this document. This bit is meaningful only between RSVP neighbors. 175 Nodes supporting the refresh message disable extensions must also 176 take care to recognize when a next hop stops sending RSVP messages 177 with the Refresh-Message-Disable bit set. To cover this case, 178 nodes supporting the refresh message disable extensions MUST 179 examine the flags field of each received RSVP message. If the flag 180 changes from indicating support to indicating non-support then, 181 unless configured otherwise, MUST NOT stop state refreshes to that 182 neighbor. 184 Note: Refresh messages can only be disabled if the neighbor node must 185 support both reliable RSVP message delivery in [RFC2961] and Hello message 186 extension in [RFC3209] [RFC4558]. When RSVP refresh messages are disabled, 187 both reliable RSVP message delivery in [RFC2961] and Hello message 188 extension in [RFC3209] [RFC4558] must be enabled. 190 4.1. Reliable RSVP message delivery 192 Refresh messages are used to both synchronize state between RSVP neighbors 193 and to recover from lost RSVP messages. The reliability and latency problem 194 occurs when a non-refresh RSVP message is lost in transmission. 196 An implementation that supports the techniques discussed in this document 197 must support the functionality described in [RFC2961] as follows: 199 o It MUST support reliable delivery of Path/Resv and the 200 corresponding Tear/Err messages (as specified in Section 4 of 201 [RFC2961]). 203 o It MUST support retransmission of all unacknowledged RSVP-TE 204 messages using exponential backoff (as specified in Section 6 of 205 [RFC2961]). 207 4.2. Hello Extension for tear message 209 When RSVP refresh messages are disabled, the time to deallocate resources 210 after a tear message is lost is an issue. To solve this problem, MUST make 211 use of the Hello session based on the Node-ID ([RFC3209][RFC4558]) for 212 detection of RSVP-TE signaling adjacency failures. 214 An implementation that supports the techniques discussed in this document 215 must support the functionality as follows: 217 o MUST make use of the Hello session based on the Node-ID ([RFC3209] 218 [RFC4558]) for detection of RSVP-TE signaling adjacency failures. 219 A default value of 9 seconds is RECOMMENDED by this document for 220 the configurable node hello interval (as opposed to the default 221 value of 5 milliseconds proposed in Section 5.3 of [RFC3209]). 222 The Hello message format is as follows: 223 ::= [ ] 224 225 The HELLO Object formats is as follows: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Src_Instance | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Dst_Instance | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 2 Format for hello object 236 Src_Instance: 32 bits 238 a 32 bit value that represents the sender's instance. The 239 advertiser maintains a per neighbor representation/value. This 240 value MUST change when the sender is reset, when the node reboots, 241 or when communication is lost to the neighboring node and 242 otherwise remains the same. This field MUST NOT be set to zero 243 (0). 245 Dst_Instance: 32 bits 247 The most recently received Src_Instance value received from the 248 neighbor. This field MUST be set to zero (0) when no value has 249 ever been seen from the neighbor. 251 o MUST implement coupling the state of individual LSPs with the 252 state of the corresponding RSVP-TE signaling adjacency. When an 253 RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the 254 speaker MUST act as if all the Path and Resv states learned via 255 the failed signaling adjacency have timed out. 257 5. Security Considerations 259 This document does not introduce additional security requirements and 260 mechanisms. Implementation of the mechanism follows the security 261 specification of [RFC2205]. 263 6. IANA Considerations 265 This document makes no IANA requests. 267 7. Normative References 269 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 270 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 271 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 272 September 1997, . 274 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 275 and S. Molendini, "RSVP Refresh Overhead Reduction 276 Extensions", RFC 2961, DOI 10.17487/RFC2961, November 0301, 277 . 279 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 280 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 281 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 282 . 284 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 285 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 286 A Clarification Statement", RFC 4558, 287 DOI 10.17487/RFC4558, June 2006, 288 . 290 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., 291 and T. Saad, "Techniques to Improve the Scalability of 292 RSVP-TE Deployments", RFC 8402, DOI 10.17487/RFC8370, 293 May 2018, . 295 Authors' Addresses 297 Jun Gao 298 Fiberhome Telecom LTD. 299 Gaoxin 4th Road 6# 300 Wuhan, Hubei 430079 301 China 303 Email: jgao@fiberhome.com 305 Jinyou Dai 306 Fiberhome Telecom LTD. 307 Gaoxin 4th Road 6# 308 Wuhan, Hubei 430079 309 China 311 Email: djy@fiberhome.com