idnits 2.17.1 draft-mirmin-bfd-extended-00.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2019) is 1879 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFD Working Group G. Mirsky 3 Internet-Draft X. Min 4 Intended status: Standards Track ZTE Corp. 5 Expires: September 6, 2019 March 5, 2019 7 Extended Bidirectional Forwarding Detection 8 draft-mirmin-bfd-extended-00 10 Abstract 12 This document describes a mechanism to extend the capabilities of 13 Bidirectional Forwarding Detection (BFD). These extensions enable 14 BFD to measure performance metrics like packet loss and packet delay. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 6, 2019. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions used in this document . . . . . . . . . . . . . . 2 52 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 53 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 3. Extended BFD Control Message . . . . . . . . . . . . . . . . 3 55 3.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 4 56 3.2. Performance Measurement with Extended BFD Control Message 6 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 60 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 [RFC5880] provided the base specification of Bidirectional Detection 66 (BFD) as the light-weight mechanism to monitor a path continuity 67 between two systems and detect a failure in the data-plane. Since 68 its introduction, BFD became has been broadly deployed. There was a 69 number of attempts to introduce new capabilities in the protocol, 70 some more successful than others. One of the significant obstacles 71 to extending BFD capabilities may be seen in the compact format of 72 the BFD control message. This document introduces an extended BFD 73 control message and describes the use of the new format for new BFD 74 capabilities. 76 2. Conventions used in this document 78 2.1. Terminology 80 BFD: Bidirectional Forwarding Detection 82 G-ACh Generic Associated Channel 84 MTU Maximum Transmission Unit 86 PMTUD Path MTU Discovery 88 p2p: Point-to-Point 90 TLV Type, Length, Value 92 2.2. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 3. Extended BFD Control Message 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | | 106 | BFD Control Message | 107 | | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Guard Word | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | | 112 ~ TLVs ~ 113 | | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 Figure 1: Extended BFD Control Message Format 118 where fields are defined as the following: 120 o BFD control message as defined [RFC5880]. 122 o Guard word - four octets long field to identify the role of the 123 BFD system - sender or responder. 125 o TLVs - variable length field that contains commands and/or data 126 encoded as type-length-value (TLV). 128 If an extended BFD control message encapsulated in IP/UDP, the value 129 of the Total Length in the IP header includes the length of the 130 extended BFD control message while the value of the Length field of 131 the BFD control message equals the value as defined in [RFC5880]. If 132 an extended BFD control message to be used over Generic Associated 133 Channel (G-ACh), e.g., [RFC6428] new code point for G-ACh may be 134 allocated. 136 Figure 2 displays the generic TLV format. A TLV MAY include sub-TLVs 137 that have the same format as presented in Figure 2. 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Type | Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 ~ Value ~ 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Figure 2: General Type-Length-Value Encoding 149 where fields are defined as the following: 151 o Type - two octets long field that defines the encoding of the 152 Value field 154 o Length - two octets long field equals length on the Value field in 155 octets. 157 o Value - depends on the Type. 159 TLVs may be included within other TLVs, in which case the former TLVs 160 are referred to as sub-TLVs. Sub-TLVs have independent types. 162 3.1. Theory of Operation 164 A BFD system, also referred to as a node in this document, that 165 supports extended BFD first MUST discover whether other nodes in the 166 given BFD session support the extended BFD. The node MUST send 167 extended BFD control message initiating the Poll sequence as defined 168 in [RFC5880]. If the remote system fails to respond with the 169 extended BFD control message and the Final flag set, then the 170 initiator node MUST conclude that the BFD peer does not support the 171 use of the extended BFD control messages. 173 The first extended BFD control message SHOULD include the Capability 174 TLV that lists capabilities that may be used at some time during the 175 lifetime of the BFD session. The format of the Capability TLV is 176 presented in Figure 3. 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Type = Capability | Length | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Capability ... 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Figure 3: Capability TLV Format 188 where fields are defined as the following: 190 o Type - TBA1 allocated by IANA Section 4 192 o Length - two octets long field equals length on the Capability 193 field in octets. The value of the Length field MUST be a multiple 194 of 4. 196 o Capability - variable number of octets - 198 Figure 4 presents defined in this document the capabilities that use 199 the extended BFD control message: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | L | D |M| Reserved ... 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 4: Capability Encoding Format 209 where fields are defined as the following: 211 o Loss - two bits size field. The least significant of two bits is 212 set if the node is capable of measuring packet loss using 213 periodically transmitted extended BFD control message. The most 214 significant of two bits is set if the node is capable of measuring 215 packet loss using the Poll sequence with extended BFD control 216 message. 218 o Delay - two bits size field. The least significant of two bits is 219 set if the node is capable of measuring packet delay using 220 periodically transmitted extended BFD control message. The most 221 significant of two bits is set if the node is capable of measuring 222 packet delay using the Poll sequence with extended BFD control 223 message. 225 o MTU- one-bit size field. Set if the node is capable of using the 226 extended BFD control message in Path MTU Discovery (PMTUD). 227 [Ed.note: Definition of the PMTUD using the extended BFD control 228 message is for further version.] 230 o Reserved - MUST be zeroed on transmission and ignored on receipt. 232 The remote BFD node that supports this specification MUST respond to 233 the Capability TLV with the extended BFD control message that 234 includes the Capability TLV listing capabilities the responder 235 supports. The responder MUST set the Final flag in the extended BFD 236 control message 238 3.2. Performance Measurement with Extended BFD Control Message 240 Loss measurement, delay measurement, and loss/delay measurement 241 messages can be used in the extended BFD control message to support 242 one-way and round-trip measurements. All the messages are 243 encapsulated as TLVs with Type values allocated by IANA, Section 4. 245 To perform one-way loss and/or delay measurement the BFD node MAY 246 periodically transmit the extended BFD message with the appropriate 247 TLV in Asynchronous mode. To perform synthetic loss measurement the 248 sender MUST monotonically increment the counter of transmitted test 249 packets. Also, direct-mode loss measurement, as described in 250 [RFC6374], is supported. 252 For the one-way measurement the sender MAY use the Performance Metric 253 TLV (presented in Figure 5) to obtain the measurement report from the 254 receiver. 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Type = Performance Metric | Length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | | 262 ~ Metric Sub-TLVs ~ 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 5: Performance Metric TLV Format 268 where fields are defined as the following: 270 o Type - TBA6 allocated by IANA Section 4 272 o Length - two octets long field equals length on the Metric sub- 273 TLVs field in octets. The value of the Length field MUST be a 274 multiple of 4. 276 o Metric sub-TLVs - various performance metrics directly measured 277 and/or calculated at the receiver encoded as TLV. [Ed.note: 278 Definition of Metric sub-TLVs is for further version.] 280 To measure the round-trip loss and/or delay metrics the BFD node 281 transmits the extended BFD control message with the appropriate TLV 282 with the Poll flag set. Before the transmission of the extended BFD 283 control message, the receiver MUST clear the Poll flag and set the 284 Final flag. 286 4. IANA Considerations 288 IANA is requested to create the Extended BFD Message Types registry. 289 All code points in the range 1 through 32759 in this registry shall 290 be allocated according to the "IETF Review" procedure as specified in 291 [RFC8126]. Code points in the range 32760 through 65279 in this 292 registry shall be allocated according to the "First Come First 293 Served" procedure as specified in [RFC8126]. Remaining code points 294 are allocated according to Table 1: 296 +---------------+-------------------------+-------------------------+ 297 | Value | Description | Reference | 298 +---------------+-------------------------+-------------------------+ 299 | 0 | Reserved | This document | 300 | 1- 32767 | Mandatory TLV, | IETF Review | 301 | | unassigned | | 302 | 32768 - 65279 | Optional TLV, | First Come First Served | 303 | | unassigned | | 304 | 65280 - 65519 | Experimental | This document | 305 | 65520 - 65534 | Private Use | This document | 306 | 65535 | Reserved | This document | 307 +---------------+-------------------------+-------------------------+ 309 Table 1: Extended BFD Type Registry 311 This document defines the following new values in Extended BFD Type 312 registry: 314 +-------+----------------------------+---------------+ 315 | Value | Description | Reference | 316 +-------+----------------------------+---------------+ 317 | TBA1 | Extra Padding | This document | 318 | TBA2 | Capability | This document | 319 | TBA3 | Loss Measurement | This document | 320 | TBA4 | Delay Measurement | This document | 321 | TBA5 | Loss and Delay Measurement | This document | 322 | TBA6 | Performance Metric | This document | 323 +-------+----------------------------+---------------+ 325 Table 2: Extended BFD Types 327 5. Security Considerations 329 This document does not introduce new security aspects but inherits 330 all security considerations from [RFC5880], [RFC6428], and [RFC6374]. 332 6. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 340 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 341 . 343 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 344 Measurement for MPLS Networks", RFC 6374, 345 DOI 10.17487/RFC6374, September 2011, 346 . 348 [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., 349 "Proactive Connectivity Verification, Continuity Check, 350 and Remote Defect Indication for the MPLS Transport 351 Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, 352 . 354 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 355 Writing an IANA Considerations Section in RFCs", BCP 26, 356 RFC 8126, DOI 10.17487/RFC8126, June 2017, 357 . 359 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 360 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 361 May 2017, . 363 Appendix A. Acknowledgements 365 TBD 367 Authors' Addresses 369 Greg Mirsky 370 ZTE Corp. 372 Email: gregimirsky@gmail.com 373 Xiao Min 374 ZTE Corp. 376 Email: xiao.min2@zte.com.cn