idnits 2.17.00 (12 Aug 2021) /tmp/idnits57079/draft-haas-xiao-bfd-echo-path-mtu-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: ---------------------------------------------------------------------------- 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 (July 11, 2011) is 3960 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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 Bidirectional Forwarding Detection J. Haas, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Informational M. Xiao, Ed. 5 Expires: January 12, 2012 ZTE Corporation 6 July 11, 2011 8 Application of the BFD Echo function for Path MTU Verification or 9 Detection 10 draft-haas-xiao-bfd-echo-path-mtu-01 12 Abstract 14 This document specifies an extended application of the BFD Echo 15 function for path MTU verification or detection, while preserving its 16 original purpose for detecting forwarding failures. This document 17 defines a process to vary the length of some BFD Echo packets 18 periodically to accomplish this Path MTU verification or detection. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 12, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Format of the BFD Echo Packets for Path MTU Verification 59 or Detection . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Extension to BFD Echo Operation . . . . . . . . . . . . . . . . 4 61 6.1. Verification of Path MTU . . . . . . . . . . . . . . . . . 5 62 6.1.1. BFD Echo Packet Transmission . . . . . . . . . . . . . 5 63 6.1.2. BFD Echo Packet Reception . . . . . . . . . . . . . . . 5 64 6.2. Detection of Path MTU . . . . . . . . . . . . . . . . . . . 6 65 6.2.1. BFD Echo Packet Transmission . . . . . . . . . . . . . 6 66 6.2.2. BFD Echo Packet Reception . . . . . . . . . . . . . . . 7 67 6.2.3. Consequent Actions . . . . . . . . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 BFD ([RFC5880]) defines an Echo function as an adjunct to the two 78 operating modes of BFD. When the Echo function is active, a stream 79 of BFD Echo packets is transmitted in such a way as to have the other 80 system loop them back through its forwarding path. If a number of 81 packets of the echoed data stream are not received, to be clearer, if 82 the number of unreceived consecutive Echo packets is more than the 83 value contained in "Detection Multiplier" of the last received BFD 84 Control packet, the BFD session is declared to be down. 86 As also indicated in [RFC5880], "the Echo function has the advantage 87 of truly testing only the forwarding path on the remote system. This 88 may reduce round-trip jitter and thus allow more aggressive Detection 89 Times, as well as potentially detecting some classes of failure that 90 might not otherwise be detected". 92 This document specifies an extended application of the BFD Echo 93 function for path MTU verification or detection, while preserving its 94 original purpose for detecting forwarding failures. This document 95 defines a process to vary the length of some BFD Echo packets 96 periodically to accomplish this Path MTU verification or detection. 98 2. Conventions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Abbreviations 106 BFD: Bidirectional Forwarding Detection 108 ICMPv4: Internet Control Message Protocol version 4 110 ICMPv6: Internet Control Message Protocol version 6 112 LDP: Label Distribution Protocol 114 LSP: Label Switched Path 116 MTU: maximum Transmission Unit 118 MPLS: Multiprotocol Label Switching 120 PE: Provider Edge 122 RSVP: Resource Reservation Protocol 124 4. Deployment Scenario 126 According to [RFC5880] and [RFC5884], the BFD Echo function may be 127 deployed for MPLS LSPs. The extended application of the BFD Echo 128 function for Path MTU verification or detection, which is described 129 in this draft, is also expected to be deployed for MPLS LSPs. 131 The extended application of BFD Echo function can be used either if 132 the MPLS LSP was created statically by manual configuration, or if 133 the MPLS LSP was setup dynamically using a control protocol (e.g. 134 LDP or RSVP). 136 Note that this draft assumes path MTUs of the forward and return are 137 symmetric. This is because by using the BFD Echo function only the 138 minimum of the path MTUs for the two directions can be verified or 139 detected. 141 5. Format of the BFD Echo Packets for Path MTU Verification or 142 Detection 144 As indicated in [RFC5880], "BFD Echo packets are sent in an 145 encapsulation appropriate to the environment. The payload of a BFD 146 Echo packet is a local matter, since only the sending system ever 147 processes the content. The only requirement is that sufficient 148 information is included to demultiplex the received packet to the 149 correct BFD session after it is looped back to the sender. Some form 150 of authentication SHOULD be included, since Echo packets may be 151 spoofed". 153 This document requires the following information to be encoded in the 154 BFD Echo packet: The 4-octet BFD My Discriminator field. The 4-octet 155 BFD Your Discriminator field. The BFD optional Authentication 156 Section if the BFD session has set the Authentication Present flag. 157 A variable length padding field, the value of which is not defined by 158 this specification. 160 The discriminator and authentication fields provide sufficient 161 information for the session to be de-multiplexed upon receipt by the 162 BFD session. The padding field provides the ability to test the the 163 forwarding path to carry packets of a given size. The length of the 164 padding field should account for the overhead of the Echo packet's 165 encapsulation type. 167 6. Extension to BFD Echo Operation 169 As specified in [RFC5880], one end system of the established BFD 170 session may transmit BFD Echo packets if the last BFD Control packet 171 received from the remote system contains a nonzero value in "Required 172 Min Echo RX Interval" and the bfd.SessionState is Up. The interval 173 between transmitted BFD Echo packets is set to the higher one of 174 received "Required Min Echo RX Interval" and the minimum sending 175 period supported by the transmitting system, except that a 25% jitter 176 may be applied to the rate of transmission, such that the actual 177 interval may be between 75% and 100% of the advertised value. 179 As also indicated in [RFC5880], the remote system of the established 180 BFD session will loop all received BFD Echo packets back to the local 181 system, and if there are consecutive more than N (N equals the value 182 contained in "Detection Multiplier" of the last received BFD Control 183 packet) Echo packets not received at the local system, it's judged 184 that a forwarding failure is detected and the BFD session is declared 185 to be down. 187 Some extensions to the BFD Echo operation are needed for the extended 188 application defined in this document. Note that these extended 189 operations will not disrupt the existing application of BFD Echo 190 function to detect forwarding failure of the bidirectional transport 191 path. 193 6.1. Verification of Path MTU 195 After a MPLS LSP is setup, there exists a target path MTU for that 196 LSP. The BFD Echo function can be used to verify the validity of the 197 target path MTU for that LSP. 199 6.1.1. BFD Echo Packet Transmission 201 When transmitting BFD Echo packets, the local system should transmit 202 two kinds of BFD Echo packets alternatively: Unpadded echo packets 203 and padded echo packets. Provided the BFD Detection Multiplier is 204 large enough, the unpadded echo packets are sufficient to keep the 205 BFD Session in the Up state even if the padded packets are dropped 206 due to a Path MTU size failure. Similarly, transmission of the 207 padded BFD Echo packets is used to test desired Path MTU. 209 6.1.2. BFD Echo Packet Reception 211 When receiving BFD Echo packets to achieve forwarding failure 212 detection and path MTU verification, the local system should first 213 demultiplex the received packet to the correct BFD session using the 214 embedded BFD discriminator fields. If Authentication is present, the 215 Authentication procedure should also be applied to the received BFD 216 Echo packets. The procedure for detecting a forwarding failure in 217 [RFC5880] is carried out normally. Additionally, if more than 218 Detection Multiplier consecutive padded Echo packets (i.e. every 219 alternate packet) is not received, the Path MTU is considered to be 220 down. This MAY trigger the detection of the new effective Path MTU. 222 6.2. Detection of Path MTU 224 For the purpose of determining effective Path MTU, a maximum packet 225 length and a minimum packet length of BFD Echo packet should be 226 configured. For example, the target path MTU could be used as the 227 maximum packet length. The minimum packet length is the minimum 228 required path MTU for the applications carried on the LSP. If this 229 minimum value is unknown, the minimum packet length may be configured 230 to the minimum packet length required for the underlying 231 encapsulation type of the BFD Echo Packet. 233 6.2.1. BFD Echo Packet Transmission 235 When transmitting BFD Echo packets to detect both forwarding failure 236 and path MTU, the local system should consecutively transmit BFD Echo 237 packets which are grouped by value N (N equals the value contained in 238 "Detection Multiplier" of the last received BFD Control packet). For 239 the tolerance of possible temporary loss of BFD Echo packets, N MUST 240 be no less than 3. In every group of N Echo packets, the 2nd and the 241 (N-1)th Echo packets should be with a padded Echo packet where the 242 packet length is of a size used to execute a probe operation on the 243 forwarding path. 245 There are two options that may be used for determining the method of 246 selecting the size of the Path MTU probe packets during the Path MTU 247 detection procedure: 249 1. The probe packets are set to a length initialized to the minimum 250 packet length required to be supported by the forwarding path. The 251 value is then increased by a step interval that is user configured 252 until the length of the probe packets reaches the maximum packet 253 length. 255 2. The probe packets are set to a length which provides a binary 256 search of the minimum and the maximum desired packet length. 257 Initially, the minimum packet length is probed. If the forwarding 258 path supports the minimum desired packet length then the maximum 259 packet length is probed. If the probe of the maximum packet length 260 fails, the probe packet size is set to the halfway point between the 261 minimum and maximum packet length and so on per the standard binary 262 search algorithm. In this manner, the effective Path MTU may be 263 determined. 265 6.2.2. BFD Echo Packet Reception 267 The procedure for verifying forwarding detection failures should be 268 followed as per the prior section on verifying path MTU. During Path 269 MTU probe operations, the reception of the different sized padded 270 Echo packets is used as inputs for the probing procedure per the 271 transmission procedures above. The recption of a single padded 272 packet of the probe size is considered sufficient for validation of 273 the probed MTU for that size probe packet. If N consecutive 274 Detection Multiplier probe packets are not detected, the probe for 275 that size packet is considered a failure and the probing procedure 276 reacts accordingly. 278 6.2.3. Consequent Actions 280 After the process of detecting path MTU finished, there are two 281 possible results: One is that the new effective path MTU is detected, 282 the other is that the new effective path MTU can't be detected 283 because it's below the minimum required path MTU for the application 284 carried on the LSP. Different consequent actions would be taken due 285 to the results. 287 If the new effective path MTU is detected, it would be reported to 288 the operator. As specified in section 3 of [RFC3032], the detected 289 path MTU of MPLS LSP MAY be used to dynamically determine the maximum 290 size for fragmentation. It should also be noted that for the MPLS 291 LSPs the potential fragmentation would take place on the inner IP 292 datagram and after that the MPLS label stack entries are appended. 293 Also note that fragmentation and reassembly in network equipment 294 generally requires significantly greater resources than sending a 295 packet as a single unit, so fragmentation and reassembly should be 296 avoided whenever possible. For this reason, when the local system 297 (e.g. an ingress PE) receives a packet which is too big to be 298 encapsulated and transmitted as a single unit over the transport path 299 - i.e. the length of encapsulated packet exceeds the detected path 300 MTU - another approach is to discard the received packet and use 301 techniques (e.g. ICMPv4/ICMPv6) to signal the sources whose packets 302 will be encapsulated in the network to send smaller packets. 304 If the minimum required path MTU for application carried on the LSP 305 is pre-provisioned as the min packet length and the new effective 306 path MTU can't be detected, the consequent action would be to tear 307 the BFD session down just as forwarding failure is detected by the 308 existing application of BFD Echo function. This may trigger 309 protection switching of the LSP. 311 7. Security Considerations 313 To be added in a later version of this document. 315 8. IANA Considerations 317 This document introduces no considerations for IANA. 319 9. Acknowledgements 321 The editors would like to thank Lei Zhang and Xuehui Dai of ZTE 322 Corporation for their valuable input. 324 10. References 326 10.1. Normative References 328 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 329 (BFD)", RFC 5880, June 2010. 331 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 332 "Bidirectional Forwarding Detection (BFD) for MPLS Label 333 Switched Paths (LSPs)", RFC 5884, June 2010. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 10.2. Informative References 340 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 341 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 342 Encoding", RFC 3032, January 2001. 344 Authors' Addresses 346 Jeffrey Haas (editor) 347 Juniper Networks 349 EMail: jhaas@juniper.net 351 Min Xiao (editor) 352 ZTE Corporation 354 EMail: xiao.min2@zte.com.cn