Bidirectional Forwarding Detection                          J. Haas, Ed.
Internet-Draft                                          Juniper Networks
Intended status: Informational                              M. Xiao, Ed.
Expires: January 12, 2012                                ZTE Corporation
                                                           July 11, 2011


   Application of the BFD Echo function for Path MTU Verification or
                               Detection
                  draft-haas-xiao-bfd-echo-path-mtu-01

Abstract

   This document specifies an extended application of the BFD Echo
   function for path MTU verification or detection, while preserving its
   original purpose for detecting forwarding failures.  This document
   defines a process to vary the length of some BFD Echo packets
   periodically to accomplish this Path MTU verification or detection.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 12, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Haas & Xiao             Expires January 12, 2012                [Page 1]


Internet-Draft         BFD Echo Path MTU Detection             July 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Deployment Scenario . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Format of the BFD Echo Packets for Path MTU Verification
       or Detection  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   6.  Extension to BFD Echo Operation . . . . . . . . . . . . . . . . 4
     6.1.  Verification of Path MTU  . . . . . . . . . . . . . . . . . 5
       6.1.1.  BFD Echo Packet Transmission  . . . . . . . . . . . . . 5
       6.1.2.  BFD Echo Packet Reception . . . . . . . . . . . . . . . 5
     6.2.  Detection of Path MTU . . . . . . . . . . . . . . . . . . . 6
       6.2.1.  BFD Echo Packet Transmission  . . . . . . . . . . . . . 6
       6.2.2.  BFD Echo Packet Reception . . . . . . . . . . . . . . . 7
       6.2.3.  Consequent Actions  . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8


























Haas & Xiao             Expires January 12, 2012                [Page 2]


Internet-Draft         BFD Echo Path MTU Detection             July 2011


1.  Introduction

   BFD ([RFC5880]) defines an Echo function as an adjunct to the two
   operating modes of BFD.  When the Echo function is active, a stream
   of BFD Echo packets is transmitted in such a way as to have the other
   system loop them back through its forwarding path.  If a number of
   packets of the echoed data stream are not received, to be clearer, if
   the number of unreceived consecutive Echo packets is more than the
   value contained in "Detection Multiplier" of the last received BFD
   Control packet, the BFD session is declared to be down.

   As also indicated in [RFC5880], "the Echo function has the advantage
   of truly testing only the forwarding path on the remote system.  This
   may reduce round-trip jitter and thus allow more aggressive Detection
   Times, as well as potentially detecting some classes of failure that
   might not otherwise be detected".

   This document specifies an extended application of the BFD Echo
   function for path MTU verification or detection, while preserving its
   original purpose for detecting forwarding failures.  This document
   defines a process to vary the length of some BFD Echo packets
   periodically to accomplish this Path MTU verification or detection.

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Abbreviations

   BFD: Bidirectional Forwarding Detection

   ICMPv4: Internet Control Message Protocol version 4

   ICMPv6: Internet Control Message Protocol version 6

   LDP: Label Distribution Protocol

   LSP: Label Switched Path

   MTU: maximum Transmission Unit

   MPLS: Multiprotocol Label Switching

   PE: Provider Edge

   RSVP: Resource Reservation Protocol



Haas & Xiao             Expires January 12, 2012                [Page 3]


Internet-Draft         BFD Echo Path MTU Detection             July 2011


4.  Deployment Scenario

   According to [RFC5880] and [RFC5884], the BFD Echo function may be
   deployed for MPLS LSPs.  The extended application of the BFD Echo
   function for Path MTU verification or detection, which is described
   in this draft, is also expected to be deployed for MPLS LSPs.

   The extended application of BFD Echo function can be used either if
   the MPLS LSP was created statically by manual configuration, or if
   the MPLS LSP was setup dynamically using a control protocol (e.g.
   LDP or RSVP).

   Note that this draft assumes path MTUs of the forward and return are
   symmetric.  This is because by using the BFD Echo function only the
   minimum of the path MTUs for the two directions can be verified or
   detected.

5.  Format of the BFD Echo Packets for Path MTU Verification or
    Detection

   As indicated in [RFC5880], "BFD Echo packets are sent in an
   encapsulation appropriate to the environment.  The payload of a BFD
   Echo packet is a local matter, since only the sending system ever
   processes the content.  The only requirement is that sufficient
   information is included to demultiplex the received packet to the
   correct BFD session after it is looped back to the sender.  Some form
   of authentication SHOULD be included, since Echo packets may be
   spoofed".

   This document requires the following information to be encoded in the
   BFD Echo packet: The 4-octet BFD My Discriminator field.  The 4-octet
   BFD Your Discriminator field.  The BFD optional Authentication
   Section if the BFD session has set the Authentication Present flag.
   A variable length padding field, the value of which is not defined by
   this specification.

   The discriminator and authentication fields provide sufficient
   information for the session to be de-multiplexed upon receipt by the
   BFD session.  The padding field provides the ability to test the the
   forwarding path to carry packets of a given size.  The length of the
   padding field should account for the overhead of the Echo packet's
   encapsulation type.

6.  Extension to BFD Echo Operation

   As specified in [RFC5880], one end system of the established BFD
   session may transmit BFD Echo packets if the last BFD Control packet
   received from the remote system contains a nonzero value in "Required



Haas & Xiao             Expires January 12, 2012                [Page 4]


Internet-Draft         BFD Echo Path MTU Detection             July 2011


   Min Echo RX Interval" and the bfd.SessionState is Up.  The interval
   between transmitted BFD Echo packets is set to the higher one of
   received "Required Min Echo RX Interval" and the minimum sending
   period supported by the transmitting system, except that a 25% jitter
   may be applied to the rate of transmission, such that the actual
   interval may be between 75% and 100% of the advertised value.

   As also indicated in [RFC5880], the remote system of the established
   BFD session will loop all received BFD Echo packets back to the local
   system, and if there are consecutive more than N (N equals the value
   contained in "Detection Multiplier" of the last received BFD Control
   packet) Echo packets not received at the local system, it's judged
   that a forwarding failure is detected and the BFD session is declared
   to be down.

   Some extensions to the BFD Echo operation are needed for the extended
   application defined in this document.  Note that these extended
   operations will not disrupt the existing application of BFD Echo
   function to detect forwarding failure of the bidirectional transport
   path.

6.1.  Verification of Path MTU

   After a MPLS LSP is setup, there exists a target path MTU for that
   LSP.  The BFD Echo function can be used to verify the validity of the
   target path MTU for that LSP.

6.1.1.  BFD Echo Packet Transmission

   When transmitting BFD Echo packets, the local system should transmit
   two kinds of BFD Echo packets alternatively: Unpadded echo packets
   and padded echo packets.  Provided the BFD Detection Multiplier is
   large enough, the unpadded echo packets are sufficient to keep the
   BFD Session in the Up state even if the padded packets are dropped
   due to a Path MTU size failure.  Similarly, transmission of the
   padded BFD Echo packets is used to test desired Path MTU.

6.1.2.  BFD Echo Packet Reception

   When receiving BFD Echo packets to achieve forwarding failure
   detection and path MTU verification, the local system should first
   demultiplex the received packet to the correct BFD session using the
   embedded BFD discriminator fields.  If Authentication is present, the
   Authentication procedure should also be applied to the received BFD
   Echo packets.  The procedure for detecting a forwarding failure in
   [RFC5880] is carried out normally.  Additionally, if more than
   Detection Multiplier consecutive padded Echo packets (i.e. every
   alternate packet) is not received, the Path MTU is considered to be



Haas & Xiao             Expires January 12, 2012                [Page 5]


Internet-Draft         BFD Echo Path MTU Detection             July 2011


   down.  This MAY trigger the detection of the new effective Path MTU.

6.2.  Detection of Path MTU

   For the purpose of determining effective Path MTU, a maximum packet
   length and a minimum packet length of BFD Echo packet should be
   configured.  For example, the target path MTU could be used as the
   maximum packet length.  The minimum packet length is the minimum
   required path MTU for the applications carried on the LSP.  If this
   minimum value is unknown, the minimum packet length may be configured
   to the minimum packet length required for the underlying
   encapsulation type of the BFD Echo Packet.

6.2.1.  BFD Echo Packet Transmission

   When transmitting BFD Echo packets to detect both forwarding failure
   and path MTU, the local system should consecutively transmit BFD Echo
   packets which are grouped by value N (N equals the value contained in
   "Detection Multiplier" of the last received BFD Control packet).  For
   the tolerance of possible temporary loss of BFD Echo packets, N MUST
   be no less than 3.  In every group of N Echo packets, the 2nd and the
   (N-1)th Echo packets should be with a padded Echo packet where the
   packet length is of a size used to execute a probe operation on the
   forwarding path.

   There are two options that may be used for determining the method of
   selecting the size of the Path MTU probe packets during the Path MTU
   detection procedure:

   1.  The probe packets are set to a length initialized to the minimum
   packet length required to be supported by the forwarding path.  The
   value is then increased by a step interval that is user configured
   until the length of the probe packets reaches the maximum packet
   length.

   2.  The probe packets are set to a length which provides a binary
   search of the minimum and the maximum desired packet length.
   Initially, the minimum packet length is probed.  If the forwarding
   path supports the minimum desired packet length then the maximum
   packet length is probed.  If the probe of the maximum packet length
   fails, the probe packet size is set to the halfway point between the
   minimum and maximum packet length and so on per the standard binary
   search algorithm.  In this manner, the effective Path MTU may be
   determined.







Haas & Xiao             Expires January 12, 2012                [Page 6]


Internet-Draft         BFD Echo Path MTU Detection             July 2011


6.2.2.  BFD Echo Packet Reception

   The procedure for verifying forwarding detection failures should be
   followed as per the prior section on verifying path MTU.  During Path
   MTU probe operations, the reception of the different sized padded
   Echo packets is used as inputs for the probing procedure per the
   transmission procedures above.  The recption of a single padded
   packet of the probe size is considered sufficient for validation of
   the probed MTU for that size probe packet.  If N consecutive
   Detection Multiplier probe packets are not detected, the probe for
   that size packet is considered a failure and the probing procedure
   reacts accordingly.

6.2.3.  Consequent Actions

   After the process of detecting path MTU finished, there are two
   possible results: One is that the new effective path MTU is detected,
   the other is that the new effective path MTU can't be detected
   because it's below the minimum required path MTU for the application
   carried on the LSP.  Different consequent actions would be taken due
   to the results.

   If the new effective path MTU is detected, it would be reported to
   the operator.  As specified in section 3 of [RFC3032], the detected
   path MTU of MPLS LSP MAY be used to dynamically determine the maximum
   size for fragmentation.  It should also be noted that for the MPLS
   LSPs the potential fragmentation would take place on the inner IP
   datagram and after that the MPLS label stack entries are appended.
   Also note that fragmentation and reassembly in network equipment
   generally requires significantly greater resources than sending a
   packet as a single unit, so fragmentation and reassembly should be
   avoided whenever possible.  For this reason, when the local system
   (e.g. an ingress PE) receives a packet which is too big to be
   encapsulated and transmitted as a single unit over the transport path
   - i.e. the length of encapsulated packet exceeds the detected path
   MTU - another approach is to discard the received packet and use
   techniques (e.g.  ICMPv4/ICMPv6) to signal the sources whose packets
   will be encapsulated in the network to send smaller packets.

   If the minimum required path MTU for application carried on the LSP
   is pre-provisioned as the min packet length and the new effective
   path MTU can't be detected, the consequent action would be to tear
   the BFD session down just as forwarding failure is detected by the
   existing application of BFD Echo function.  This may trigger
   protection switching of the LSP.






Haas & Xiao             Expires January 12, 2012                [Page 7]


Internet-Draft         BFD Echo Path MTU Detection             July 2011


7.  Security Considerations

   To be added in a later version of this document.

8.  IANA Considerations

   This document introduces no considerations for IANA.

9.  Acknowledgements

   The editors would like to thank Lei Zhang and Xuehui Dai of ZTE
   Corporation for their valuable input.

10.  References

10.1.  Normative References

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "Bidirectional Forwarding Detection (BFD) for MPLS Label
              Switched Paths (LSPs)", RFC 5884, June 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.

Authors' Addresses

   Jeffrey Haas (editor)
   Juniper Networks

   EMail: jhaas@juniper.net


   Min Xiao (editor)
   ZTE Corporation

   EMail: xiao.min2@zte.com.cn






Haas & Xiao             Expires January 12, 2012                [Page 8]