idnits 2.17.1 draft-gao-mpls-teas-rsvpte-state-update-01.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 2 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 34 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 105: '... flag set, SHOULD respond with a MES...' RFC 2119 keyword, line 108: '... MUST make use of the Hello session ...' RFC 2119 keyword, line 110: '... failures. MUST implement coupling t...' RFC 2119 keyword, line 113: '...ure, the speaker MUST act as if all th...' RFC 2119 keyword, line 174: '...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 38 has weird spacing: '... months and ...' == Line 39 has weird spacing: '... at any time...' == Line 40 has weird spacing: '...ference mate...' -- The document date (April 30, 2020) is 1456 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 147, but not defined == Missing Reference: 'RFC8174' is mentioned on line 147, but not defined == Unused Reference: 'RFC8370' is defined on line 286, 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: October 30, 2020 6 Fiberhome Telecom LTD 7 April 30, 2020 9 State-updating mechanism in RSVP-TE for MPLS network 10 draft-gao-mpls-teas-rsvpte-state-update-01 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. 17 RSVP takes a "soft state" approach to managing the reservation 18 state in routers and hosts. The use of Refresh messages to cover 19 many possible failures has resulted in a number of operational 20 problems. One problem relates to scaling, another relates to the 21 reliability and latency of RSVP Signaling. 23 This document describes a number of mechanisms that can be used to 24 reduce processing overhead requirements of refresh messages. These 25 extension present no backwards compatibility issues. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other 39 documents at any time. It is inappropriate to use Internet-Drafts 40 as reference material or to cite them other than as "work in 41 progress." 43 Copyright and License Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Terms Used in This Document. . . . . . . . . . . . . . . . 3 63 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Requirements Language. . . . . . . . . . . . . . . . . . . . . 4 65 4. State-updating mechanism in RSVP for MPLS network. . . . . . . 4 66 4.1. Reliable RSVP message delivery . . . . . . . . . . . . . . 5 67 4.2. Hello Extension for tear message . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 Standard RSVP [RFC2205] maintains state via the generation of RSVP 76 refresh messages. Refresh messages are used to both synchronize 77 state between RSVP neighbors and to recover from lost RSVP messages. 78 The use of Refresh messages to cover many possible failures has 79 resulted in a number of operational problems. One problem relates to 80 scaling, another relates to the reliability and latency of RSVP 81 Signaling. 83 The scaling problems are linked to the resource requirements (in 84 terms of processing and memory) of running RSVP. The resource 85 requirements increase proportionally with the number of sessions. 86 Each session requires the generation, transmission, reception and 87 processing of RSVP Path and Resv messages per refresh period. 88 Supporting a large number of sessions, and the corresponding volume 89 of refresh messages, presents a scaling problem. 91 The reliability and latency problem occurs when a non-refresh RSVP 92 message is lost in transmission. Standard RSVP [RFC2205] recovers 93 from a lost message via RSVP refresh messages. In the face of 94 transmission loss of RSVP messages, the end-to-end latency of RSVP 95 signaling is tied to the refresh interval of the node(s) experiencing 96 the loss. When end-to-end signaling is limited by the refresh 97 interval, the delay incurred in the establishment or the change of a 98 reservation may be beyond the range of what is acceptable for some 99 applications. 101 This document proposes to disable RSVP refresh messages to solve 102 soft-state scaling problems. The reliable message delivery mechanism 103 specified in [RFC2961] states that "Nodes receiving a non-out of 104 order message containing a MESSAGE_ID object with the ACK_Desired 105 flag set, SHOULD respond with a MESSAGE_ID_ACK object.". When RSVP 106 refresh messages are disabled, the time to deallocate resources 107 after a tear message is lost is an issue. To solve this problem, 108 MUST make use of the Hello session based on the Node-ID 109 ([RFC3209][RFC4558]) for detection of RSVP-TE signaling adjacency 110 failures. MUST implement coupling the state of individual LSPs 111 with the state of the corresponding RSVP-TE signaling adjacency. 112 When an RSVP-TE speaker detects RSVP-TE signaling adjacency 113 failure, the speaker MUST act as if all the Path and Resv states 114 learned via the failed signaling adjacency have timed out. To 115 avoid compatibility problems, a flag bit in the RSVP message 116 header is extended to disable RSVP refresh messages. 118 2. Terminology 120 2.1. Terms Used in This Document 121 Refresh messages: represent previously advertised state and contain 122 exactly the same objects and same information as a previously 123 transmitted message, and are sent over the same path. Only Path and 124 Resv messages can be refresh messages. Refresh messages are 125 identical to the corresponding previously transmitted message, with 126 some possible exceptions. 128 Trigger messages: Trigger messages are those RSVP messages that 129 advertise state or any other information not previously 130 transmitted. Trigger messages include messages advertising new 131 state, a route change that alters a reservation path, or a 132 modification to an existing RSVP session or reservation. 134 2.2. Abbreviations 136 The following abbreviations are used in this document: 137 RSVP: Resource ReserVation Protocol. 138 RSVP-TE: Resource ReserVation Protocol - Traffic Engineering. 140 3 Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in 145 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 4 State-updating mechanism in RSVP for MPLS network 150 To indicate support for the refresh message disable extensions, an 151 additional capability bit is added to the common RSVP header, which 152 is defined in [RFC2205]. 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Vers | Flags | Msg Type | RSVP Checksum | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Send_TTL | (Reserved) | RSVP Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1 RSVP header 163 Flags: 4 bits 165 0x02: Refresh message disable 167 When set, indicates that this node is willing and capable of 168 supporting the refresh message disable extensions described in 169 this document. This bit is meaningful only between RSVP neighbors. 171 Nodes supporting the refresh message disable extensions must also 172 take care to recognize when a next hop stops sending RSVP messages 173 with the Refresh-Message-Disable bit set. To cover this case, 174 nodes supporting the refresh message disable extensions MUST 175 examine the flags field of each received RSVP message. If the flag 176 changes from indicating support to indicating non-support then, 177 unless configured otherwise, MUST NOT stop state refreshes to that 178 neighbor. 180 Note: Refresh messages can only be disabled if the neighbor node must 181 support both reliable RSVP message delivery in [RFC2961] and Hello message 182 extension in [RFC3209] [RFC4558]. When RSVP refresh messages are disabled, 183 both reliable RSVP message delivery in [RFC2961] and Hello message 184 extension in [RFC3209] [RFC4558] must be enabled. 186 4.1. Reliable RSVP message delivery 188 Refresh messages are used to both synchronize state between RSVP neighbors 189 and to recover from lost RSVP messages. The reliability and latency problem 190 occurs when a non-refresh RSVP message is lost in transmission. 192 An implementation that supports the techniques discussed in this document 193 must support the functionality described in [RFC2961] as follows: 195 o It MUST support reliable delivery of Path/Resv and the 196 corresponding Tear/Err messages (as specified in Section 4 of 197 [RFC2961]). 199 o It MUST support retransmission of all unacknowledged RSVP-TE 200 messages using exponential backoff (as specified in Section 6 of 201 [RFC2961]). 203 4.2. Hello Extension for tear message 205 When RSVP refresh messages are disabled, the time to deallocate resources 206 after a tear message is lost is an issue. To solve this problem, MUST make 207 use of the Hello session based on the Node-ID ([RFC3209][RFC4558]) for 208 detection of RSVP-TE signaling adjacency failures. 210 An implementation that supports the techniques discussed in this document 211 must support the functionality as follows: 213 o MUST make use of the Hello session based on the Node-ID ([RFC3209] 214 [RFC4558]) for detection of RSVP-TE signaling adjacency failures. 215 A default value of 9 seconds is RECOMMENDED by this document for 216 the configurable node hello interval (as opposed to the default 217 value of 5 milliseconds proposed in Section 5.3 of [RFC3209]). 218 The Hello message format is as follows: 219 ::= [ ] 220 221 The HELLO Object formats is as follows: 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Src_Instance | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Dst_Instance | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 2 Format for hello object 232 Src_Instance: 32 bits 234 a 32 bit value that represents the sender's instance. The 235 advertiser maintains a per neighbor representation/value. This 236 value MUST change when the sender is reset, when the node reboots, 237 or when communication is lost to the neighboring node and 238 otherwise remains the same. This field MUST NOT be set to zero 239 (0). 241 Dst_Instance: 32 bits 243 The most recently received Src_Instance value received from the 244 neighbor. This field MUST be set to zero (0) when no value has 245 ever been seen from the neighbor. 247 o MUST implement coupling the state of individual LSPs with the 248 state of the corresponding RSVP-TE signaling adjacency. When an 249 RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the 250 speaker MUST act as if all the Path and Resv states learned via 251 the failed signaling adjacency have timed out. 253 5. Security Considerations 255 This document does not introduce additional security requirements and 256 mechanisms. Implementation of the mechanism follows the security 257 specification of [RFC2205]. 259 6. IANA Considerations 261 This document makes no IANA requests. 263 7. Normative References 265 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 266 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 267 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 268 September 1997, . 270 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 271 and S. Molendini, "RSVP Refresh Overhead Reduction 272 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 3001, 273 . 275 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 276 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 277 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 278 . 280 [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, 281 "Node-ID Based Resource Reservation Protocol (RSVP) Hello: 282 A Clarification Statement", RFC 4558, 283 DOI 10.17487/RFC4558, June 2006, 284 . 286 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., 287 and T. Saad, "Techniques to Improve the Scalability of 288 RSVP-TE Deployments", RFC 8402, DOI 10.17487/RFC8370, 289 May 2018, . 291 Authors' Addresses 293 Jun Gao 294 Fiberhome Telecom LTD. 295 Gaoxin 4th Road 6# 296 Wuhan, Hubei 430079 297 China 299 Email: jgao@fiberhome.com 301 Jinyou Dai 302 Fiberhome Telecom LTD. 303 Gaoxin 4th Road 6# 304 Wuhan, Hubei 430079 305 China 307 Email: djy@fiberhome.com