[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

BFD Working Group                                              G. Mirsky
Internet-Draft                                                    X. Min
Intended status: Standards Track                               ZTE Corp.
Expires: September 6, 2019                                 March 5, 2019


              Extended Bidirectional Forwarding Detection
                      draft-mirmin-bfd-extended-00

Abstract

   This document describes a mechanism to extend the capabilities of
   Bidirectional Forwarding Detection (BFD).  These extensions enable
   BFD to measure performance metrics like packet loss and packet delay.

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 https://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 September 6, 2019.

Copyright Notice

   Copyright (c) 2019 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
   (https://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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Mirsky & Min            Expires September 6, 2019               [Page 1]


Internet-Draft                Extended BFD                    March 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   2
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Extended BFD Control Message  . . . . . . . . . . . . . . . .   3
     3.1.  Theory of Operation . . . . . . . . . . . . . . . . . . .   4
     3.2.  Performance Measurement with Extended BFD Control Message   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   [RFC5880] provided the base specification of Bidirectional Detection
   (BFD) as the light-weight mechanism to monitor a path continuity
   between two systems and detect a failure in the data-plane.  Since
   its introduction, BFD became has been broadly deployed.  There was a
   number of attempts to introduce new capabilities in the protocol,
   some more successful than others.  One of the significant obstacles
   to extending BFD capabilities may be seen in the compact format of
   the BFD control message.  This document introduces an extended BFD
   control message and describes the use of the new format for new BFD
   capabilities.

2.  Conventions used in this document

2.1.  Terminology

   BFD: Bidirectional Forwarding Detection

   G-ACh Generic Associated Channel

   MTU Maximum Transmission Unit

   PMTUD Path MTU Discovery

   p2p: Point-to-Point

   TLV Type, Length, Value








Mirsky & Min            Expires September 6, 2019               [Page 2]


Internet-Draft                Extended BFD                    March 2019


2.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Extended BFD Control Message

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      BFD Control Message                      |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Guard Word                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                            TLVs                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 1: Extended BFD Control Message Format

   where fields are defined as the following:

   o  BFD control message as defined [RFC5880].

   o  Guard word - four octets long field to identify the role of the
      BFD system - sender or responder.

   o  TLVs - variable length field that contains commands and/or data
      encoded as type-length-value (TLV).

   If an extended BFD control message encapsulated in IP/UDP, the value
   of the Total Length in the IP header includes the length of the
   extended BFD control message while the value of the Length field of
   the BFD control message equals the value as defined in [RFC5880].  If
   an extended BFD control message to be used over Generic Associated
   Channel (G-ACh), e.g., [RFC6428] new code point for G-ACh may be
   allocated.

   Figure 2 displays the generic TLV format.  A TLV MAY include sub-TLVs
   that have the same format as presented in Figure 2.





Mirsky & Min            Expires September 6, 2019               [Page 3]


Internet-Draft                Extended BFD                    March 2019


       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                            Value                              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 2: General Type-Length-Value Encoding

   where fields are defined as the following:

   o  Type - two octets long field that defines the encoding of the
      Value field

   o  Length - two octets long field equals length on the Value field in
      octets.

   o  Value - depends on the Type.

   TLVs may be included within other TLVs, in which case the former TLVs
   are referred to as sub-TLVs.  Sub-TLVs have independent types.

3.1.  Theory of Operation

   A BFD system, also referred to as a node in this document, that
   supports extended BFD first MUST discover whether other nodes in the
   given BFD session support the extended BFD.  The node MUST send
   extended BFD control message initiating the Poll sequence as defined
   in [RFC5880].  If the remote system fails to respond with the
   extended BFD control message and the Final flag set, then the
   initiator node MUST conclude that the BFD peer does not support the
   use of the extended BFD control messages.

   The first extended BFD control message SHOULD include the Capability
   TLV that lists capabilities that may be used at some time during the
   lifetime of the BFD session.  The format of the Capability TLV is
   presented in Figure 3.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type  = Capability       |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Capability                          ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 3: Capability TLV Format



Mirsky & Min            Expires September 6, 2019               [Page 4]


Internet-Draft                Extended BFD                    March 2019


   where fields are defined as the following:

   o  Type - TBA1 allocated by IANA Section 4

   o  Length - two octets long field equals length on the Capability
      field in octets.  The value of the Length field MUST be a multiple
      of 4.

   o  Capability - variable number of octets -

   Figure 4 presents defined in this document the capabilities that use
   the extended BFD control message:

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | L | D |M|                       Reserved                    ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 4: Capability Encoding Format

   where fields are defined as the following:

   o  Loss - two bits size field.  The least significant of two bits is
      set if the node is capable of measuring packet loss using
      periodically transmitted extended BFD control message.  The most
      significant of two bits is set if the node is capable of measuring
      packet loss using the Poll sequence with extended BFD control
      message.

   o  Delay - two bits size field.  The least significant of two bits is
      set if the node is capable of measuring packet delay using
      periodically transmitted extended BFD control message.  The most
      significant of two bits is set if the node is capable of measuring
      packet delay using the Poll sequence with extended BFD control
      message.

   o  MTU- one-bit size field.  Set if the node is capable of using the
      extended BFD control message in Path MTU Discovery (PMTUD).
      [Ed.note: Definition of the PMTUD using the extended BFD control
      message is for further version.]

   o  Reserved - MUST be zeroed on transmission and ignored on receipt.

   The remote BFD node that supports this specification MUST respond to
   the Capability TLV with the extended BFD control message that
   includes the Capability TLV listing capabilities the responder




Mirsky & Min            Expires September 6, 2019               [Page 5]


Internet-Draft                Extended BFD                    March 2019


   supports.  The responder MUST set the Final flag in the extended BFD
   control message

3.2.  Performance Measurement with Extended BFD Control Message

   Loss measurement, delay measurement, and loss/delay measurement
   messages can be used in the extended BFD control message to support
   one-way and round-trip measurements.  All the messages are
   encapsulated as TLVs with Type values allocated by IANA, Section 4.

   To perform one-way loss and/or delay measurement the BFD node MAY
   periodically transmit the extended BFD message with the appropriate
   TLV in Asynchronous mode.  To perform synthetic loss measurement the
   sender MUST monotonically increment the counter of transmitted test
   packets.  Also, direct-mode loss measurement, as described in
   [RFC6374], is supported.

   For the one-way measurement the sender MAY use the Performance Metric
   TLV (presented in Figure 5) to obtain the measurement report from the
   receiver.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type  = Performance Metric  |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                       Metric Sub-TLVs                         ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 5: Performance Metric TLV Format

   where fields are defined as the following:

   o  Type - TBA6 allocated by IANA Section 4

   o  Length - two octets long field equals length on the Metric sub-
      TLVs field in octets.  The value of the Length field MUST be a
      multiple of 4.

   o  Metric sub-TLVs - various performance metrics directly measured
      and/or calculated at the receiver encoded as TLV.  [Ed.note:
      Definition of Metric sub-TLVs is for further version.]

   To measure the round-trip loss and/or delay metrics the BFD node
   transmits the extended BFD control message with the appropriate TLV
   with the Poll flag set.  Before the transmission of the extended BFD



Mirsky & Min            Expires September 6, 2019               [Page 6]


Internet-Draft                Extended BFD                    March 2019


   control message, the receiver MUST clear the Poll flag and set the
   Final flag.

4.  IANA Considerations

   IANA is requested to create the Extended BFD Message Types registry.
   All code points in the range 1 through 32759 in this registry shall
   be allocated according to the "IETF Review" procedure as specified in
   [RFC8126].  Code points in the range 32760 through 65279 in this
   registry shall be allocated according to the "First Come First
   Served" procedure as specified in [RFC8126].  Remaining code points
   are allocated according to Table 1:

   +---------------+-------------------------+-------------------------+
   | Value         |       Description       | Reference               |
   +---------------+-------------------------+-------------------------+
   | 0             |         Reserved        | This document           |
   | 1- 32767      |      Mandatory TLV,     | IETF Review             |
   |               |        unassigned       |                         |
   | 32768 - 65279 |      Optional TLV,      | First Come First Served |
   |               |        unassigned       |                         |
   | 65280 - 65519 |       Experimental      | This document           |
   | 65520 - 65534 |       Private Use       | This document           |
   | 65535         |         Reserved        | This document           |
   +---------------+-------------------------+-------------------------+

                    Table 1: Extended BFD Type Registry

   This document defines the following new values in Extended BFD Type
   registry:

          +-------+----------------------------+---------------+
          | Value |        Description         | Reference     |
          +-------+----------------------------+---------------+
          | TBA1  |       Extra Padding        | This document |
          | TBA2  |         Capability         | This document |
          | TBA3  |      Loss Measurement      | This document |
          | TBA4  |     Delay Measurement      | This document |
          | TBA5  | Loss and Delay Measurement | This document |
          | TBA6  |     Performance Metric     | This document |
          +-------+----------------------------+---------------+

                        Table 2: Extended BFD Types








Mirsky & Min            Expires September 6, 2019               [Page 7]


Internet-Draft                Extended BFD                    March 2019


5.  Security Considerations

   This document does not introduce new security aspects but inherits
   all security considerations from [RFC5880], [RFC6428], and [RFC6374].

6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <https://www.rfc-editor.org/info/rfc6374>.

   [RFC6428]  Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed.,
              "Proactive Connectivity Verification, Continuity Check,
              and Remote Defect Indication for the MPLS Transport
              Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011,
              <https://www.rfc-editor.org/info/rfc6428>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Appendix A.  Acknowledgements

   TBD

Authors' Addresses

   Greg Mirsky
   ZTE Corp.

   Email: gregimirsky@gmail.com





Mirsky & Min            Expires September 6, 2019               [Page 8]


Internet-Draft                Extended BFD                    March 2019


   Xiao Min
   ZTE Corp.

   Email: xiao.min2@zte.com.cn















































Mirsky & Min            Expires September 6, 2019               [Page 9]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/