doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc7759.txt b/doc/rfc/rfc7759.txt
new file mode 100644
index 0000000..10f2dd0
--- /dev/null
+++ b/doc/rfc/rfc7759.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     E. Bellagamba
+Request for Comments: 7759
+Category: Standards Track                                      G. Mirsky
+ISSN: 2070-1721                                                 Ericsson
+                                                            L. Andersson
+                                                     Huawei Technologies
+                                                           P. Skoldstrom
+                                                                Acreo AB
+                                                                 D. Ward
+                                                                   Cisco
+                                                                J. Drake
+                                                                 Juniper
+                                                           February 2016
+
+
+                 Configuration of Proactive Operations,
+     Administration, and Maintenance (OAM) Functions for MPLS-Based
+        Transport Networks Using Label Switched Path (LSP) Ping
+
+Abstract
+
+   This specification describes the configuration of proactive MPLS-TP
+   Operations, Administration, and Maintenance (OAM) functions for a
+   given Label Switched Path (LSP) using a set of TLVs that are carried
+   by the LSP Ping protocol.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7759.
+
+
+
+
+
+
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                    [Page 1]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 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
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Conventions Used in This Document ..........................4
+           1.1.1. Terminology .........................................4
+           1.1.2. Requirements Language ...............................5
+   2. Theory of Operations ............................................5
+      2.1. MPLS OAM Configuration Operation Overview ..................5
+           2.1.1. Configuration of BFD Sessions .......................5
+           2.1.2. Configuration of Performance Monitoring .............6
+           2.1.3. Configuration of Fault Management Signals ...........6
+      2.2. MPLS OAM Functions TLV .....................................7
+           2.2.1. BFD Configuration Sub-TLV ...........................9
+           2.2.2. BFD Local Discriminator Sub-TLV ....................11
+           2.2.3. BFD Negotiation Timer Parameters Sub-TLV ...........11
+           2.2.4. BFD Authentication Sub-TLV .........................13
+           2.2.5. Traffic Class Sub-TLV ..............................14
+           2.2.6. Performance Monitoring Sub-TLV .....................14
+           2.2.7. PM Loss Measurement Sub-TLV ........................17
+           2.2.8. PM Delay Measurement Sub-TLV .......................18
+           2.2.9. Fault Management Signal Sub-TLV ....................20
+           2.2.10. Source MEP-ID Sub-TLV .............................21
+   3. Summary of MPLS OAM Configuration Errors .......................22
+   4. IANA Considerations ............................................23
+      4.1. TLV and Sub-TLV Allocation ................................23
+      4.2. MPLS OAM Function Flags Allocation ........................24
+      4.3. OAM Configuration Errors ..................................25
+   5. Security Considerations ........................................26
+   6. References .....................................................26
+      6.1. Normative References ......................................26
+      6.2. Informative References ....................................27
+   Acknowledgements  .................................................28
+   Authors' Addresses ................................................29
+
+
+
+Bellagamba, et al.           Standards Track                    [Page 2]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+1.  Introduction
+
+   The MPLS Transport Profile (MPLS-TP) describes a profile of MPLS that
+   enables operational models typical in transport networks while
+   providing additional Operations, Administration, and Maintenance
+   (OAM), survivability, and other maintenance functions not currently
+   supported by MPLS.  [RFC5860] defines the requirements for the OAM
+   functionality of MPLS-TP.
+
+   This document describes the configuration of proactive MPLS-TP OAM
+   functions for a given Label Switched Path (LSP) using TLVs carried in
+   LSP Ping [RFC4379].  In particular, it specifies the mechanisms
+   necessary to establish MPLS-TP OAM entities at the maintenance points
+   for monitoring and performing measurements on an LSP, as well as
+   defining information elements and procedures to configure proactive
+   MPLS-TP OAM functions running between Label Edge Routers (LERs).
+   Initialization and control of on-demand MPLS-TP OAM functions are
+   expected to be carried out by directly accessing network nodes via a
+   management interface; hence, configuration and control of on-demand
+   OAM functions are out of scope for this document.
+
+   The Transport Profile of MPLS must, by definition [RFC5654], be
+   capable of operating without a control plane.  Therefore, there are a
+   few options for configuring MPLS-TP OAM: without a control plane
+   using a Network Management System (NMS), implementing LSP Ping
+   instead or with a control plane implementing extensions to signaling
+   protocols RSVP Traffic Engineering (RSVP-TE) [RFC3209] and/or
+   Targeted LDP [RFC5036].
+
+   Proactive MPLS-TP OAM is performed by a set of protocols:
+   Bidirectional Forwarding Detection (BFD) [RFC6428] for Continuity
+   Check/Connectivity Verification, the Delay Measurement (DM) protocol
+   [RFC6374], [RFC6375] for delay and delay variation (jitter)
+   measurements, and the Loss Measurement (LM) protocol [RFC6374],
+   [RFC6375] for packet loss and throughput measurements.  Additionally,
+   there are a number of Fault Management Signals that can be configured
+   [RFC6427].
+
+   BFD is a protocol that provides low-overhead, fast detection of
+   failures in the path between two forwarding engines, including the
+   interfaces, data link(s), and to the extent possible, the forwarding
+   engines themselves.  BFD can be used to detect the continuity and
+   mis-connection defects of MPLS-TP point-to-point and might also be
+   extended to support point-to-multipoint LSPs.
+
+   The delay and loss measurements protocols [RFC6374] and [RFC6375] use
+   a simple query/response model for performing both unidirectional and
+   bidirectional measurements that allow the originating node to measure
+
+
+
+Bellagamba, et al.           Standards Track                    [Page 3]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   packet loss and delay in forward, or forward and reverse directions.
+   By timestamping and/or writing current packet counters to the
+   measurement packets (four times, Transmit and Receive in both
+   directions), current delays and packet losses can be calculated.  By
+   performing successive delay measurements, the delay and/or inter-
+   packet delay variation (jitter) can be calculated.  Current
+   throughput can be calculated from the packet loss measurements by
+   dividing the number of packets sent/received with the time it took to
+   perform the measurement, given by the timestamp in the LM header.
+   Combined with a packet generator, the throughput measurement can be
+   used to measure the maximum capacity of a particular LSP.  It should
+   be noted that this document does not specify how to configure
+   on-demand throughput estimates based on saturating the connection as
+   defined in [RFC6371]; rather, it only specifies how to enable the
+   estimation of the current throughput based on loss measurements.
+
+1.1.  Conventions Used in This Document
+
+1.1.1.  Terminology
+
+   BFD - Bidirectional Forwarding Detection
+
+   DM - Delay Measurement
+
+   FMS - Fault Management Signal
+
+   G-ACh - Generic Associated Channel
+
+   LSP - Label Switched Path
+
+   LM - Loss Measurement
+
+   MEP - Maintenance Entity Group End Point
+
+   MPLS - Multi-Protocol Label Switching
+
+   MPLS-TP - MPLS Transport Profile
+
+   NMS - Network Management System
+
+   PM - Performance Monitoring
+
+   RSVP-TE - RSVP Traffic Engineering
+
+   TC - Traffic Class
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                    [Page 4]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+1.1.2.  Requirements Language
+
+   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 RFC 2119 [RFC2119].
+
+2.  Theory of Operations
+
+2.1.  MPLS OAM Configuration Operation Overview
+
+   The MPLS-TP OAM tool set is described in [RFC6669].
+
+   LSP Ping, or alternatively RSVP-TE [RFC7487], can be used to easily
+   enable the different OAM functions by setting the corresponding flags
+   in the MPLS OAM Functions TLV (refer to Section 2.2).  For a more
+   detailed configuration, one may include sub-TLVs for the different
+   OAM functions in order to specify various parameters in detail.
+
+   Typically, intermediate nodes simply forward OAM configuration TLVs
+   to the end node without any processing or modification.  At least one
+   exception to this is if the FMS sub-TLV (refer to Section 2.2.9 ) is
+   present.  This sub-TLV MUST be examined even by intermediate nodes
+   that support this extension.  The sub-TLV MAY be present if a flag is
+   set in the MPLS OAM Functions TLV.
+
+2.1.1.  Configuration of BFD Sessions
+
+   For this specification, BFD MUST run in either one of the two modes:
+
+   o  Asynchronous mode, where both sides are in active mode
+
+   o  Unidirectional mode
+
+   In the simplest scenario, LSP Ping [RFC5884], or alternatively RSVP-
+   TE [RFC7487], is used only to bootstrap a BFD session for an LSP,
+   without any timer negotiation.
+
+   Timer negotiation can be performed either in subsequent BFD control
+   messages (in this case the operation is similar to bootstrapping
+   based on LSP Ping described in [RFC5884]), or directly in the LSP
+   Ping configuration messages.
+
+   When BFD Control packets are transported in the Associated Channel
+   Header (ACH) encapsulation, they are not protected by any end-to-end
+   checksum; only lower layers provide error detection/correction.  A
+   single bit error, e.g., a flipped bit in the BFD State field, could
+   cause the receiving end to wrongly conclude that the link is down and
+   in turn trigger protection switching.  To prevent this from
+
+
+
+Bellagamba, et al.           Standards Track                    [Page 5]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   happening, the BFD Configuration sub-TLV (refer to Section 2.2.1) has
+   an Integrity flag that, when set, enables BFD Authentication using
+   Keyed SHA1 with an empty key (all 0s) [RFC5880].  This would make
+   every BFD Control packet carry a SHA1 hash of itself that can be used
+   to detect errors.
+
+   If BFD Authentication using a pre-shared key/password is desired
+   (i.e., authentication and not only error detection), the BFD
+   Authentication sub-TLV (refer to Section 2.2.4) MUST be included in
+   the BFD Configuration sub-TLV.  The BFD Authentication sub-TLV is
+   used to specify which authentication method that should be used and
+   which pre-shared key/password that should be used for this particular
+   session.  How the key exchange is performed is out of scope of this
+   document.
+
+2.1.2.  Configuration of Performance Monitoring
+
+   It is possible to configure Performance Monitoring functionalities
+   such as Loss, Delay, Delay/Interpacket Delay variation (jitter), and
+   throughput as described in [RFC6374].
+
+   When configuring Performance Monitoring functionalities, it is
+   possible to choose either the default configuration, by only setting
+   the respective flags in the MPLS OAM functions TLV, or a customized
+   configuration.  To customize the configuration, one would set the
+   respective flags in the MPLS OAM functions TLV and include the
+   respective Loss and/or Delay sub-TLVs.
+
+   By setting the PM Loss flag in the MPLS OAM Functions TLV and
+   including the PM Loss sub-TLV (refer to Section 2.2.7), one can
+   configure the measurement interval and loss threshold values for
+   triggering protection.
+
+   Delay measurements are configured by setting the PM Delay flag in the
+   MPLS OAM Functions TLV and by including the PM Delay sub-TLV (refer
+   to Section 2.2.8), one can configure the measurement interval and the
+   delay threshold values for triggering protection.
+
+2.1.3.  Configuration of Fault Management Signals
+
+   To configure Fault Management Signals (FMSs) and their refresh time,
+   the FMS Flag in the MPLS OAM Functions TLV MUST be set and the FMS
+   sub-TLV MUST be included.  When configuring an FMS, an implementation
+   can enable the default configuration by setting the FMS Flag in the
+   OAM Function Flags sub-TLV.  In order to modify the default
+   configuration, the MPLS OAM FMS sub-TLV MUST be included.
+
+
+
+
+
+Bellagamba, et al.           Standards Track                    [Page 6]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   If an intermediate point is meant to originate FMS messages, this
+   means that such an intermediate point is associated with a Server MEP
+   through a co-located MPLS-TP client/server adaptation function, and
+   the Fault Management subscription flag in the MPLS OAM FMS sub-TLV
+   has been set as an indication of the request to create the
+   association at each intermediate node of the client LSP.  The
+   corresponding Server MEP needs to be configured by its own LSP Ping
+   session or, alternatively, via a Network Management System (NMS) or
+   RSVP-TE.
+
+2.2.  MPLS OAM Functions TLV
+
+   The MPLS OAM Functions TLV presented in Figure 1 is carried as a TLV
+   of the MPLS Echo Request/Reply messages [RFC4379].
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  MPLS OAM Func. Type (27)     |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    MPLS OAM Function Flags                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                           sub-TLVs                            ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 1: MPLS OAM Functions TLV Format
+
+   The MPLS OAM Functions TLV contains the MPLS OAM Function Flags
+   field.  The MPLS OAM Function Flags indicate which OAM functions
+   should be activated as well as OAM function-specific sub-TLVs with
+   configuration parameters for the particular function.
+
+   Type: Indicates the MPLS OAM Functions TLV (Section 4).
+
+   Length: The length of the MPLS OAM Function Flags field including the
+   total length of the sub-TLVs in octets.
+
+   MPLS OAM Function Flags: A bitmap numbered from left to right as
+   shown in Figure 2.  These flags are managed by IANA (refer to
+   Section 4.2).  Flags defined in this document are presented in
+   Table 2.  Undefined flags MUST be set to zero and unknown flags MUST
+   be ignored.  The flags indicate what OAM is being configured and
+   direct the presence of optional sub-TLVs as set out below.
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                    [Page 7]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |C|V|F|L|D|T|Unassigned MUST be zero (MBZ)                    |R|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 2: MPLS OAM Function Flags Format
+
+   Sub-TLVs corresponding to the different flags are as follows.  No
+   meaning should be attached to the order of sub-TLVs.
+
+   o  If a flag in the MPLS OAM Function Flags is set and the
+      corresponding sub-TLVs listed below are absent, then this MPLS OAM
+      function MUST be initialized according to its default settings.
+      Default settings of MPLS OAM functions are outside the scope of
+      this document.
+
+   o  If any sub-TLV is present without the corresponding flag being
+      set, the sub-TLV SHOULD be ignored.
+
+   o  BFD Configuration sub-TLV, which MUST be included if either the
+      CC, the CV, or both MPLS OAM Function flags are being set in the
+      MPLS OAM Functions TLV.
+
+   o  Performance Monitoring sub-TLV MUST be used to carry PM Loss sub-
+      TLV and/or PM Delay sub-TLV.  If neither one of these sub-TLVs is
+      present, then Performance Monitoring sub-TLV SHOULD NOT be
+      included.  Empty, i.e., no enclosed sub-TLVs, Performance
+      Monitoring sub-TLV SHOULD be ignored.
+
+   o  PM Loss sub-TLV MAY be included if the PM/Loss OAM Function flag
+      is set.  If the "PM Loss sub-TLV" is not included, default
+      configuration values are used.  Such sub-TLV MAY also be included
+      in case the Throughput function flag is set and there is the need
+      to specify a measurement interval different from the default ones.
+      In fact, the throughput measurement makes use of the same tool as
+      the loss measurement; hence, the same TLV is used.
+
+   o  PM Delay sub-TLV MAY be included if the PM/Delay OAM Function flag
+      is set.  If the "PM Delay sub-TLV" is not included, default
+      configuration values are used.
+
+   o  FMS sub-TLV, that MAY be included if the FMS OAM Function flag is
+      set.  If the "FMS sub-TLV" is not included, default configuration
+      values are used.
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                    [Page 8]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   If all flags in the MPLS OAM Function Flags field have the same value
+   of zero, that MUST be interpreted as meaning that the MPLS OAM
+   Functions TLV is not present in the MPLS Echo Request.  If more than
+   one MPLS OAM Functions TLV is present in the MPLS Echo request
+   packet, then the first TLV SHOULD be processed and the rest ignored.
+   Any parsing error within nested sub-TLVs that is not specified in
+   Section 3 SHOULD be treated as described in [RFC4379].
+
+2.2.1.  BFD Configuration Sub-TLV
+
+   The BFD Configuration sub-TLV, depicted in Figure 3, is defined for
+   BFD OAM-specific configuration parameters.  The "BFD Configuration
+   sub-TLV" is carried as a sub-TLV of the "OAM Functions TLV".
+
+   This TLV accommodates generic BFD OAM information and carries sub-
+   TLVs.
+
+    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 Conf. Sub-type    (100)   |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Vers.|N|S|I|G|U|B|         Reserved (set to all 0s)            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                           sub-TLVs                            ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 3: BFD Configuration Sub-TLV Format
+
+   Sub-type: Indicates a new sub-type, the BFD Configuration sub-TLV
+   (value 100).
+
+   Length: Indicates the length of the Value field in octets.
+
+   Version: Identifies the BFD protocol version.  If a node does not
+   support a specific BFD version, an error must be generated: "OAM
+   Problem/Unsupported BFD Version".
+
+   BFD Negotiation (N): If set, timer negotiation/renegotiation via BFD
+   Control Messages is enabled.  When cleared, it is disabled and timer
+   configuration is achieved using the BFD Negotiation Timer Parameters
+   sub-TLV as described in Section 2.2.3.
+
+   Symmetric session (S): If set, the BFD session MUST use symmetric
+   timing values.  If cleared, the BFD session MAY use any timing values
+   either negotiated or explicitly configured.
+
+
+
+Bellagamba, et al.           Standards Track                    [Page 9]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   Integrity (I): If set, BFD Authentication MUST be enabled.  If the
+   BFD Configuration sub-TLV does not include a BFD Authentication sub-
+   TLV, the authentication MUST use Keyed SHA1 with an empty pre-shared
+   key (all 0s).  If the egress LSR does not support BFD Authentication,
+   an error MUST be generated: "OAM Problem/BFD Authentication
+   unsupported".  If the Integrity flag is clear, then Authentication
+   MUST NOT be used.
+
+   Encapsulation Capability (G): If set, it shows the capability of
+   encapsulating BFD messages into the G-ACh channel.  If both the G bit
+   and U bit are set, configuration gives precedence to the G bit.
+
+   Encapsulation Capability (U): If set, it shows the capability of
+   encapsulating BFD messages into IP/UDP packets.  If both the G bit
+   and U bit are set, configuration gives precedence to the G bit.
+
+   If the egress LSR does not support any of the ingress LSR
+   Encapsulation Capabilities, an error MUST be generated: "OAM Problem/
+   Unsupported BFD Encapsulation format".
+
+   Bidirectional (B): If set, it configures BFD in the Bidirectional
+   mode.  If it is not set, it configures BFD in the unidirectional
+   mode.  In the second case, the source node does not expect any
+   Discriminator values back from the destination node.
+
+   Reserved: Reserved for future specification; set to 0 on transmission
+   and ignored when received.
+
+   The BFD Configuration sub-TLV MUST include the following sub-TLVs in
+   the MPLS Echo Request message:
+
+   o  BFD Local Discriminator sub-TLV, if the B flag is set in the MPLS
+      Echo Request;
+
+   o  BFD Negotiation Timer Parameters sub-TLV, if the N flag is
+      cleared.
+
+   The BFD Configuration sub-TLV MUST include the following sub-TLVs in
+   the MPLS Echo Reply message:
+
+   o  BFD Local Discriminator sub-TLV;
+
+   o  BFD Negotiation Timer Parameters sub-TLV if:
+
+      *  The N and S flags are cleared, or if:
+
+      *  The N flag is cleared and the S flag is set, and the BFD
+         Negotiation Timer Parameters sub-TLV received by the egress
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 10]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+         contains unsupported values.  In this case, an updated BFD
+         Negotiation Timer Parameters sub-TLV, containing values
+         supported by the egress node [RFC7419], is returned to the
+         ingress.
+
+2.2.2.  BFD Local Discriminator Sub-TLV
+
+   The BFD Local Discriminator sub-TLV is carried as a sub-TLV of the
+   "BFD Configuration sub-TLV" and is depicted in Figure 4.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Locl. Discr. Sub-type (101)  |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Local Discriminator                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Figure 4: BFD Local Discriminator Sub-TLV Format
+
+   Sub-type: Indicates a new sub-type, the "BFD Local Discriminator sub-
+   TLV" (value 101).
+
+   Length: Indicates the length of the Value field in octets (4).
+
+   Local Discriminator: A nonzero discriminator value that is unique in
+   the context of the transmitting system that generates it.  It is used
+   to demultiplex multiple BFD sessions between the same pair of
+   systems.
+
+2.2.3.  BFD Negotiation Timer Parameters Sub-TLV
+
+   The BFD Negotiation Timer Parameters sub-TLV is carried as a sub-TLV
+   of the BFD Configuration sub-TLV and is depicted in Figure 5.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Nego. Timer Sub-type (102)    |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Acceptable Min. Asynchronous TX interval              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Acceptable Min. Asynchronous RX interval              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               Required Echo TX Interval                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+         Figure 5: BFD Negotiation Timer Parameters Sub-TLV Format
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 11]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   Sub-type: Indicates a new sub-type, the BFD Negotiation Timer
+   Parameters sub-TLV (value 102).
+
+   Length: Indicates the length of the Value field in octets (12).
+   Acceptable Min. Asynchronous TX interval: If the S (symmetric) flag
+   is set in the BFD Configuration sub-TLV, defined in Section 2.2.1, it
+   expresses the desired time interval (in microseconds) at which the
+   ingress LER intends to both transmit and receive BFD periodic control
+   packets.  If the receiving edge LSR cannot support such a value, it
+   SHOULD reply with an interval greater than the one proposed.
+
+   If the S (symmetric) flag is cleared in the BFD Configuration sub-
+   TLV, this field expresses the desired time interval (in microseconds)
+   at which an edge LSR intends to transmit BFD periodic control packets
+   in its transmitting direction.
+
+   Acceptable Min. Asynchronous RX interval: If the S (symmetric) flag
+   is set in the BFD Configuration sub-TLV, Figure 3, this field MUST be
+   equal to Acceptable Min. Asynchronous TX interval and has no
+   additional meaning respect to the one described for "Acceptable Min.
+   Asynchronous TX interval".
+
+   If the S (symmetric) flag is cleared in the BFD Configuration sub-
+   TLV, it expresses the minimum time interval (in microseconds) at
+   which edge LSRs can receive BFD periodic control packets.  If this
+   value is greater than the value of Acceptable Min. Asynchronous TX
+   interval received from the other edge LSR, such an edge LSR MUST
+   adopt the interval expressed in this Acceptable Min. Asynchronous RX
+   interval.
+
+   Required Echo TX Interval: The minimum interval (in microseconds)
+   between received BFD Echo packets that this system is capable of
+   supporting, less any jitter applied by the sender as described in
+   Section 6.8.9 of [RFC5880].  This value is also an indication for the
+   receiving system of the minimum interval between transmitted BFD Echo
+   packets.  If this value is zero, the transmitting system does not
+   support the receipt of BFD Echo packets.  If the receiving system
+   cannot support this value, the "Unsupported BFD TX Echo rate
+   interval" error MUST be generated.  By default, the value is set to
+   0.
+
+
+
+
+
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 12]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+2.2.4.  BFD Authentication Sub-TLV
+
+   The "BFD Authentication sub-TLV" is carried as a sub-TLV of the "BFD
+   Configuration sub-TLV" and is depicted in Figure 6.
+
+    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 Auth. Sub-type (103)   |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Auth Type   |  Auth Key ID  |         Reserved (0s)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 6: BFD Authentication Sub-TLV Format
+
+   Sub-type: Indicates a new sub-type, the BFD Authentication sub-TLV
+   (value 103).
+
+   Length: Indicates the length of the Value field in octets (4).
+
+   Auth Type: Indicates which type of authentication to use.  The same
+   values as are defined in Section 4.1 of [RFC5880] are used.  Simple
+   Password SHOULD NOT be used if other authentication types are
+   available.
+
+   Auth Key ID: Indicates which authentication key or password
+   (depending on Auth Type) should be used.  How the key exchange is
+   performed is out of scope of this document.  If the egress LSR does
+   not support this Auth Key ID, an "OAM Problem/Mismatch of BFD
+   Authentication Key ID" error MUST be generated.
+
+   Reserved: Reserved for future specification; set to 0 on transmission
+   and ignored when received.
+
+   An implementation MAY change the mode of authentication if an
+   operator re-evaluates the security situation in and around the
+   administrative domain.  If the BFD Authentication sub-TLV is used for
+   a BFD session in Up state, then the Sender of the MPLS LSP Echo
+   Request SHOULD ensure that old and new modes of authentication, i.e.,
+   a combination of Auth.Type and Auth.  Key ID, are used to send and
+   receive BFD control packets, until the Sender can confirm that its
+   peer has switched to the new authentication.
+
+
+
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 13]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+2.2.5.  Traffic Class Sub-TLV
+
+   The Traffic Class sub-TLV is carried as a sub-TLV of the "BFD
+   Configuration sub-TLV" and "Fault Management Signal Sub-TLV"
+   (Section 2.2.9) and is depicted in Figure 7.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Traffic Class Sub-type (104)  |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  TC |                 Reserved (set to all 0s)                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 7: Traffic Class Sub-TLV Format
+
+   Sub-type: Indicates a new sub-type, the "Traffic Class sub-TLV"
+   (value 104).
+
+   Length: Indicates the length of the Value field in octets (4).
+
+   TC: Identifies the Traffic Class (TC) [RFC5462] for periodic
+   continuity monitoring messages or packets with fault management
+   information.
+
+   If the TC sub-TLV is present, then the sender of any periodic
+   continuity monitoring messages or packets with fault management
+   information on the LSP, with a Forwarding Equivalence Class (FEC)
+   that corresponds to the FEC for which fault detection is being
+   performed, MUST use the value contained in the TC field of the sub-
+   TLV as the value of the TC field in the top label stack entry of the
+   MPLS label stack.  If the TC sub-TLV is absent from either "BFD
+   Configuration sub-TLV" or "Fault Management Signal sub-TLV", then
+   selection of the TC value is a local decision.
+
+2.2.6.  Performance Monitoring Sub-TLV
+
+   If the MPLS OAM Functions TLV has any of the L (Loss), D (Delay), and
+   T (Throughput) flags set, the Performance Monitoring sub-TLV MUST be
+   present.  Failure to include the correct sub-TLVs MUST result in an
+   "OAM Problem/PM Configuration Error" being generated.
+
+   The Performance Monitoring sub-TLV provides the configuration
+   information mentioned in Section 7 of [RFC6374].  It includes support
+   for the configuration of quality thresholds and, as described in
+   [RFC6374]:
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 14]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+      ...the crossing of which will trigger warnings or alarms, and
+      result in reporting and exception notification will be integrated
+      into the system-wide network management and reporting framework.
+
+   In case the values need to be different than the default ones, the
+   Performance Monitoring sub-TLV MAY include the following sub-TLVs:
+
+   o  PM Loss sub-TLV, if the L flag is set in the MPLS OAM Functions
+      TLV;
+
+   o  PM Delay sub-TLV, if the D flag is set in the MPLS OAM Functions
+      TLV.
+
+   The Performance Monitoring sub-TLV depicted in Figure 8 is carried as
+   a sub-TLV of the MPLS OAM Functions TLV.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Perf. Monitoring Sub-type (200)|          Length               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     PM Configuration Flags                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                           sub-TLVs                            ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+              Figure 8: Performance Monitoring Sub-TLV Format
+
+   Sub-type: Indicates a new sub-type, the Performance Monitoring sub-
+   TLV (value 200).
+
+   Length: Indicates the length of the Value field in octets, including
+   PM Configuration Flags and optional sub-TLVs.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |D|L|J|Y|K|C|            Reserved (set to all 0s)               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 9: PM Configuration Flags Format
+
+
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 15]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   The PM Configuration Flags format is presented in Figure 9.  For the
+   specific function description, please refer to [RFC6374]:
+
+   D:    Delay inferred/direct (0=INFERRED, 1=DIRECT).  If the egress
+         LSR does not support the specified mode, an "OAM Problem/
+         Unsupported Delay Mode" error MUST be generated.
+
+   L:    Loss inferred/direct (0=INFERRED, 1=DIRECT).  If the egress LSR
+         does not support the specified mode, an "OAM Problem/
+         Unsupported Loss Mode" error MUST be generated.
+
+   J:    Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE).  If the egress
+         LSR does not support Delay variation measurements and the J
+         flag is set, an "OAM Problem/Delay variation unsupported" error
+         MUST be generated.
+
+   Y:    Dyadic (1=ACTIVE, 0=NOT ACTIVE).  If the egress LSR does not
+         support Dyadic mode and the Y flag is set, an "OAM Problem/
+         Dyadic mode unsupported" error MUST be generated.
+
+   K:    Loopback (1=ACTIVE, 0=NOT ACTIVE).  If the egress LSR does not
+         support Loopback mode and the K flag is set, an "OAM Problem/
+         Loopback mode unsupported" error MUST be generated.
+
+   C:    Combined (1=ACTIVE, 0=NOT ACTIVE).  If the egress LSR does not
+         support Combined mode and the C flag is set, an "OAM Problem/
+         Combined mode unsupported" error MUST be generated.
+
+   Reserved:  Reserved for future specification; set to 0 on
+         transmission and ignored when received.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 16]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+2.2.7.  PM Loss Measurement Sub-TLV
+
+   The PM Loss Measurement sub-TLV depicted in Figure 10 is carried as a
+   sub-TLV of the Performance Monitoring sub-TLV.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  PM Loss Sub-type (201)       |          Length               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | OTF |T|B|              Reserved (set to all 0s)               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Measurement Interval                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Test Interval                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Loss Threshold                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+               Figure 10: PM Loss Measurement Sub-TLV Format
+
+   Sub-type: Indicates a new sub-type, the PM Loss Measurement sub-TLV
+   (value 201).
+
+   Length: Indicates the length of the Value field in octets (16).
+
+   OTF: Origin Timestamp Format of the Origin Timestamp field described
+   in [RFC6374].  By default, it is set to IEEE 1588 version 1.  If the
+   egress LSR cannot support this value, an "OAM Problem/Unsupported
+   Timestamp Format" error MUST be generated.
+
+   Configuration Flags, please refer to [RFC6374] for further details:
+
+   T:    Traffic-class-specific measurement indicator.  Set to 1 when
+         the measurement operation is scoped to packets of a particular
+         traffic class (Differentiated Services Code Point value), and 0
+         otherwise.  When set to 1, the Differentiated Services (DS)
+         field of the message indicates the measured traffic class.  By
+         default, it is set to 1.
+
+   B:    Octet (byte) count.  When set to 1, indicates that the Counter
+         1-4 fields represent octet counts.  When set to 0, indicates
+         that the Counter 1-4 fields represent packet counts.  By
+         default, it is set to 0.
+
+   Reserved: Reserved for future specification; set to 0 on transmission
+   and ignored when received.
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 17]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   Measurement Interval: The time interval (in milliseconds) at which
+   Loss Measurement query messages MUST be sent on both directions.  If
+   the edge LSR receiving the Path message cannot support such a value,
+   it SHOULD reply with a higher interval.  By default, it is set to
+   (100) as per [RFC6375].
+
+   Test Interval: Test messages interval in milliseconds as described in
+   [RFC6374].  By default, it is set to (10) as per [RFC6375].
+
+   Loss Threshold: The threshold value of measured lost packets per
+   measurement over which action(s) SHOULD be triggered.
+
+2.2.8.  PM Delay Measurement Sub-TLV
+
+   The "PM Delay Measurement sub-TLV" depicted in Figure 11 is carried
+   as a sub-TLV of the Performance Monitoring sub-TLV.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  PM Delay Sub-type (202)      |          Length               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | OTF |T|B|             Reserved (set to all 0s)                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Measurement Interval                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Test Interval                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Delay Threshold                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+              Figure 11: PM Delay Measurement Sub-TLV Format
+
+   Sub-type: Indicates a new sub-type, the "PM Delay Measurement sub-
+   TLV" (value 202).
+
+   Length: Indicates the length of the Value field in octets (16).
+
+   OTF: Origin Timestamp Format of the Origin Timestamp field described
+   in [RFC6374].  By default, it is set to IEEE 1588 version 1.  If the
+   egress LSR cannot support this value, an "OAM Problem/Unsupported
+   Timestamp Format" error MUST be generated.
+
+
+
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 18]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   Configuration Flags, please refer to [RFC6374] for further details:
+
+   T:    Traffic-class-specific measurement indicator.  Set to 1 when
+         the measurement operation is scoped to packets of a particular
+         traffic class (Differentiated Services Code Point value), and 0
+         otherwise.  When set to 1, the DS field of the message
+         indicates the measured traffic class.  By default, it is set to
+         1.
+
+   B:    Octet (byte) count.  When set to 1, indicates that the Counter
+         1-4 fields represent octet counts.  When set to 0, indicates
+         that the Counter 1-4 fields represent packet counts.  By
+         default, it is set to 0.
+
+   Reserved: Reserved for future specification; set to 0 on transmission
+   and ignored when received.
+
+   Measurement Interval: The time interval (in milliseconds) at which
+   Delay Measurement query messages MUST be sent on both directions.  If
+   the edge LSR receiving the Path message cannot support such a value,
+   it can reply with a higher interval.  By default, it is set to (1000)
+   as per [RFC6375].
+
+   Test Interval: Test messages interval (in milliseconds) as described
+   in [RFC6374].  By default, it is set to (10) as per [RFC6375].
+
+   Delay Threshold: The threshold value of measured two-way delay (in
+   milliseconds) over which action(s) SHOULD be triggered.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 19]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+2.2.9.  Fault Management Signal Sub-TLV
+
+   The FMS sub-TLV depicted in Figure 12 is carried as a sub-TLV of the
+   MPLS OAM Configuration sub-TLV.  When both working and protection
+   paths are configured, both LSPs SHOULD be configured with identical
+   settings of the E flag, T flag, and the refresh timer.  An
+   implementation MAY configure the working and protection LSPs with
+   different settings of these fields in case of 1:N protection.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       FMS Sub-type (300)      |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |E|S|T|            Reserved           |      Refresh Timer      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                           sub-TLVs                            ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Figure 12: Fault Management Signal Sub-TLV Format
+
+   Sub-type: Indicates a new sub-type, the FMS sub-TLV (value 300).
+
+   Length: Indicates the length of the Value field in octets.
+
+   FMS Flags are used to enable the FMS Flags at end point MEPs and the
+   Server MEPs of the links over which the LSP is forwarded.  In this
+   document, only the S flag pertains to Server MEPs.
+
+   The following flags are defined:
+
+   E:    Enable Alarm Indication Signal (AIS) and Lock Report (LKR)
+         signaling as described in [RFC6427].  Default value is 1
+         (enabled).  If the egress MEP does not support FMS Flag
+         generation, an "OAM Problem/Fault management signaling
+         unsupported" error MUST be generated.
+
+   S:    Indicate to a Server MEP that it should transmit AIS and LKR
+         signals on the client LSP.  Default value is 0 (disabled).  If
+         a Server MEP that is capable of generating FMS messages is, for
+         some reason, unable to do so for the LSP being signaled, an
+         "OAM Problem/Unable to create fault management association"
+         error MUST be generated.
+
+   T:    Set timer value, enabled the configuration of a specific timer
+         value.  Default value is 0 (disabled).
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 20]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   Reserved: Bits 4-16 that follow the FMS Flags are reserved for future
+   allocation.  These bits MUST be set to 0 on transmit and ignored on
+   receipt if not allocated.
+
+   Refresh Timer: Indicates the refresh timer of fault indication
+   messages, in seconds.  The value MUST be between 1 to 20 seconds as
+   specified for the Refresh Timer field in [RFC6427].  If the edge LSR
+   receiving the Path message cannot support the value, it SHOULD reply
+   with a higher timer value.
+
+   FMS sub-TLV MAY include Traffic Class sub-TLV (Section 2.2.5).  If
+   the TC sub-TLV is present, the value of the TC field MUST be used as
+   the value of the TC field of an MPLS label stack entry for FMS
+   messages.  If the TC sub-TLV is absent, then selection of the TC
+   value is a local decision.
+
+2.2.10.  Source MEP-ID Sub-TLV
+
+   The Source MEP-ID sub-TLV depicted in Figure 13 is carried as a sub-
+   TLV of the MPLS OAM Functions TLV.
+
+   Note that support of ITU IDs is out of scope.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Source MEP-ID Sub-type (400)  |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Source Node ID                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Tunnel ID           |           LSP ID              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 13: Source MEP-ID Sub-TLV Format
+
+   Sub-type: Indicates a new sub-type, the Source MEP-ID sub-TLV (value
+   400).
+
+   Length: Indicates the length of the Value field in octets (8).
+
+   Source Node ID: 32-bit node identifier as defined in [RFC6370].
+
+   Tunnel ID: A 16-bit unsigned integer unique to the node as defined in
+   [RFC6370].
+
+   LSP ID: A 16-bit unsigned integer unique within the Tunnel_ID as
+   defined in [RFC6370].
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 21]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+3.  Summary of MPLS OAM Configuration Errors
+
+   This is the summary of Return Codes [RFC4379] defined in this
+   document:
+
+   o  If an egress LSR does not support the specified BFD version, an
+      error MUST be generated: "OAM Problem/Unsupported BFD Version".
+
+   o  If an egress LSR does not support the specified BFD Encapsulation
+      format, an error MUST be generated: "OAM Problem/Unsupported BFD
+      Encapsulation format".
+
+   o  If an egress LSR does not support BFD Authentication, and it is
+      requested, an error MUST be generated: "OAM Problem/BFD
+      Authentication unsupported".
+
+   o  If an egress LSR does not support the specified BFD Authentication
+      Type, an error MUST be generated: "OAM Problem/Unsupported BFD
+      Authentication Type".
+
+   o  If an egress LSR is not able to use the specified Authentication
+      Key ID, an error MUST be generated: "OAM Problem/Mismatch of BFD
+      Authentication Key ID".
+
+   o  If PM flags in MPLS OAM Functions TLV don't have corresponding PM
+      sub-TLVs present, an error MUST be generated: "OAM Problem/PM
+      Configuration Error".
+
+   o  If an egress LSR does not support the specified Timestamp Format,
+      an error MUST be generated: "OAM Problem/Unsupported Timestamp
+      Format".
+
+   o  If an egress LSR does not support specified Delay mode, an "OAM
+      Problem/Unsupported Delay Mode" error MUST be generated.
+
+   o  If an egress LSR does not support specified Loss mode, an "OAM
+      Problem/Unsupported Loss Mode" error MUST be generated.
+
+   o  If an egress LSR does not support Delay variation measurements,
+      and it is requested, an "OAM Problem/Delay variation unsupported"
+      error MUST be generated.
+
+   o  If an egress LSR does not support Dyadic mode, and it is
+      requested, an "OAM Problem/Dyadic mode unsupported" error MUST be
+      generated.
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 22]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   o  If an egress LSR does not support Loopback mode, and it is
+      requested, an "OAM Problem/Loopback mode unsupported" error MUST
+      be generated.
+
+   o  If an egress LSR does not support Combined mode, and it is
+      requested, an "OAM Problem/Combined mode unsupported" error MUST
+      be generated.
+
+   o  If an egress LSR does not support Fault Monitoring Signals, and it
+      is requested, an "OAM Problem/Fault management signaling
+      unsupported" error MUST be generated.
+
+   o  If an intermediate Server MEP supports Fault Monitoring Signals,
+      but is unable to create an association, when requested to do so,
+      an "OAM Problem/Unable to create fault management association"
+      error MUST be generated.
+
+   Ingress LSR MAY combine multiple MPLS OAM configuration TLVs and sub-
+   TLVs into single MPLS echo request.  In case an egress LSR doesn't
+   support any of the requested modes, it MUST set the return code to
+   report the first unsupported mode in the list of TLVs and sub-TLVs.
+   And if any of the requested OAM configuration is not supported, the
+   egress LSR SHOULD NOT process OAM Configuration TLVs and sub-TLVs
+   listed in the MPLS echo request.
+
+4.  IANA Considerations
+
+4.1.  TLV and Sub-TLV Allocation
+
+   IANA maintains the "Multi-Protocol Label Switching (MPLS) Label
+   Switched Paths (LSPs) Ping Parameters" registry and, within that
+   registry, a subregistry for TLVs and sub-TLVs.
+
+   IANA has allocated a new MPLS OAM Functions TLV from the Standards
+   Action [RFC5226] range (0-16383) and sub-TLVs as follows from
+   subregistry presented in Table 1, called "Sub-TLVs for TLV Type 27".
+
+   Registration procedures for Sub-TLVs from ranges 0-16383 and
+   32768-49161 are by Standards Action.  Ranges 16384-31743 and
+   49162-64511 are through Specification Required (Experimental RFC
+   Needed).
+
+
+
+
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 23]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   +------+----------+---------------------------------+---------------+
+   | Type | Sub-type | Value Field                     | Reference     |
+   +------+----------+---------------------------------+---------------+
+   | 27   |          | MPLS OAM Functions              | This document |
+   |      | 100      | BFD Configuration               | This document |
+   |      | 101      | BFD Local Discriminator         | This document |
+   |      | 102      | BFD Negotiation Timer           | This document |
+   |      |          | Parameters                      |               |
+   |      | 103      | BFD Authentication              | This document |
+   |      | 104      | Traffic Class                   | This document |
+   |      | 200      | Performance Monitoring          | This document |
+   |      | 201      | PM Loss Measurement             | This document |
+   |      | 202      | PM Delay Measurement            | This document |
+   |      | 300      | Fault Management Signal         | This document |
+   |      | 400      | Source MEP-ID                   | This document |
+   +------+----------+---------------------------------+---------------+
+
+                     Table 1: IANA TLV Type Allocation
+
+4.2.  MPLS OAM Function Flags Allocation
+
+   IANA has created a new registry called the "MPLS OAM Function Flags"
+   registry.  Assignments of bit positions 0 through 31 are via
+   Standards Action.  The new registry is to be populated as follows.
+
+   +------------+--------------------+---------------------------------+
+   |    Bit     | MPLS OAM Function  | Description                     |
+   |  Position  |        Flag        |                                 |
+   +------------+--------------------+---------------------------------+
+   |     0      |         C          | Continuity Check (CC)           |
+   |     1      |         V          | Connectivity Verification (CV)  |
+   |     2      |         F          | Fault Management Signal (FMS)   |
+   |     3      |         L          | Performance Monitoring/Loss     |
+   |            |                    | (PM/Loss)                       |
+   |     4      |         D          | Performance Monitoring/Delay    |
+   |            |                    | (PM/Delay)                      |
+   |     5      |         T          | Throughput Measurement          |
+   |    6-30    |                    | Unassigned (Must be zero)       |
+   |     31     |                    | Reserved                        |
+   +------------+--------------------+---------------------------------+
+
+                     Table 2: MPLS OAM Function Flags
+
+
+
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 24]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+4.3.  OAM Configuration Errors
+
+   IANA maintains a registry "Multi-Protocol Label Switching (MPLS)
+   Label Switched Paths (LSPs) Ping Parameters", and within that
+   registry a subregistry "Return Codes".
+
+   IANA has assigned new Return Codes from the Standards Action range
+   (0-191) as follows:
+
+   +----------------+--------------------------------------+-----------+
+   | Error Value    | Description                          | Reference |
+   | Sub-codes      |                                      |           |
+   +----------------+--------------------------------------+-----------+
+   | 21             | OAM Problem/Unsupported BFD Version  | This      |
+   |                |                                      | document  |
+   | 22             | OAM Problem/Unsupported BFD          | This      |
+   |                | Encapsulation format                 | document  |
+   | 23             | OAM Problem/Unsupported BFD          | This      |
+   |                | Authentication Type                  | document  |
+   | 24             | OAM Problem/Mismatch of BFD          | This      |
+   |                | Authentication Key ID                | document  |
+   | 25             | OAM Problem/Unsupported Timestamp    | This      |
+   |                | Format                               | document  |
+   | 26             | OAM Problem/Unsupported Delay Mode   | This      |
+   |                |                                      | document  |
+   | 27             | OAM Problem/Unsupported Loss Mode    | This      |
+   |                |                                      | document  |
+   | 28             | OAM Problem/Delay variation          | This      |
+   |                | unsupported                          | document  |
+   | 29             | OAM Problem/Dyadic mode unsupported  | This      |
+   |                |                                      | document  |
+   | 30             | OAM Problem/Loopback mode            | This      |
+   |                | unsupported                          | document  |
+   | 31             | OAM Problem/Combined mode            | This      |
+   |                | unsupported                          | document  |
+   | 32             | OAM Problem/Fault management         | This      |
+   |                | signaling unsupported                | document  |
+   | 33             | OAM Problem/Unable to create fault   | This      |
+   |                | management association               | document  |
+   | 34             | OAM Problem/PM Configuration Error   | This      |
+   |                |                                      | document  |
+   +----------------+--------------------------------------+-----------+
+
+                   Table 3: IANA Return Codes Allocation
+
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 25]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+5.  Security Considerations
+
+   The signaling of OAM-related parameters and the automatic
+   establishment of OAM entities introduces additional security
+   considerations to those discussed in [RFC4379].  In particular, a
+   network element could be overloaded if an attacker were to request
+   high-frequency liveliness monitoring of a large number of LSPs,
+   targeting a single network element.  Implementations must be made
+   cognizant of available OAM resources and MAY refuse new OAM
+   configurations that would overload a node.  Additionally, policies to
+   manage OAM resources may be used to provide some fairness in OAM
+   resource distribution among monitored LSPs.
+
+   Security of OAM protocols configured with extensions to LSP Ping
+   described in this document are discussed in [RFC5880], [RFC5884],
+   [RFC6374], [RFC6427], and [RFC6428].
+
+   In order that the configuration of OAM functionality can be achieved
+   securely through the techniques described in this document, security
+   mechanisms must already be in place and operational for LSP Ping.
+   Thus, the exchange of security parameters (such as keys) for use in
+   securing OAM is outside the scope of this document and is assumed to
+   use an off-line mechanism or an established secure key exchange
+   protocol.
+
+   Additional discussion of security for MPLS protocols can be found in
+   [RFC5920].
+
+6.  References
+
+6.1.  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,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+              Label Switched (MPLS) Data Plane Failures", RFC 4379,
+              DOI 10.17487/RFC4379, February 2006,
+              <http://www.rfc-editor.org/info/rfc4379>.
+
+   [RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
+              Sprecher, N., and S. Ueno, "Requirements of an MPLS
+              Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
+              September 2009, <http://www.rfc-editor.org/info/rfc5654>.
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 26]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
+              <http://www.rfc-editor.org/info/rfc5880>.
+
+   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
+              "Bidirectional Forwarding Detection (BFD) for MPLS Label
+              Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
+              June 2010, <http://www.rfc-editor.org/info/rfc5884>.
+
+   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
+              Profile (MPLS-TP) Identifiers", RFC 6370,
+              DOI 10.17487/RFC6370, September 2011,
+              <http://www.rfc-editor.org/info/rfc6370>.
+
+   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
+              Measurement for MPLS Networks", RFC 6374,
+              DOI 10.17487/RFC6374, September 2011,
+              <http://www.rfc-editor.org/info/rfc6374>.
+
+   [RFC6427]  Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
+              Boutros, S., and D. Ward, "MPLS Fault Management
+              Operations, Administration, and Maintenance (OAM)",
+              RFC 6427, DOI 10.17487/RFC6427, November 2011,
+              <http://www.rfc-editor.org/info/rfc6427>.
+
+   [RFC6428]  Allan, D., Ed., Swallow Ed., G., 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,
+              <http://www.rfc-editor.org/info/rfc6428>.
+
+6.2.  Informative References
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+              <http://www.rfc-editor.org/info/rfc3209>.
+
+   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
+              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
+              October 2007, <http://www.rfc-editor.org/info/rfc5036>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 27]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
+              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
+              Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
+              2009, <http://www.rfc-editor.org/info/rfc5462>.
+
+   [RFC5860]  Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
+              "Requirements for Operations, Administration, and
+              Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
+              DOI 10.17487/RFC5860, May 2010,
+              <http://www.rfc-editor.org/info/rfc5860>.
+
+   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
+              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
+              <http://www.rfc-editor.org/info/rfc5920>.
+
+   [RFC6371]  Busi, I., Ed. and D. Allan, Ed., "Operations,
+              Administration, and Maintenance Framework for MPLS-Based
+              Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
+              September 2011, <http://www.rfc-editor.org/info/rfc6371>.
+
+   [RFC6375]  Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and
+              Delay Measurement Profile for MPLS-Based Transport
+              Networks", RFC 6375, DOI 10.17487/RFC6375, September 2011,
+              <http://www.rfc-editor.org/info/rfc6375>.
+
+   [RFC6669]  Sprecher, N. and L. Fang, "An Overview of the Operations,
+              Administration, and Maintenance (OAM) Toolset for MPLS-
+              Based Transport Networks", RFC 6669, DOI 10.17487/RFC6669,
+              July 2012, <http://www.rfc-editor.org/info/rfc6669>.
+
+   [RFC7419]  Akiya, N., Binderberger, M., and G. Mirsky, "Common
+              Interval Support in Bidirectional Forwarding Detection",
+              RFC 7419, DOI 10.17487/RFC7419, December 2014,
+              <http://www.rfc-editor.org/info/rfc7419>.
+
+   [RFC7487]  Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L.,
+              Skoldstrom, P., and D. Ward, "Configuration of Proactive
+              Operations, Administration, and Maintenance (OAM)
+              Functions for MPLS-Based Transport Networks Using RSVP-
+              TE", RFC 7487, DOI 10.17487/RFC7487, March 2015,
+              <http://www.rfc-editor.org/info/rfc7487>.
+
+Acknowledgements
+
+   The authors would like to thank Nobo Akiya, David Allan, and Adrian
+   Farrel for their thorough reviews and insightful comments.
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 28]
+
+RFC 7759           Extensions for MPLS-TP OAM Config.      February 2016
+
+
+Authors' Addresses
+
+   Elisa Bellagamba
+
+   Email: elisa.bellagamba@gmail.com
+
+
+   Gregory Mirsky
+   Ericsson
+
+   Email: Gregory.Mirsky@ericsson.com
+
+
+   Loa Andersson
+   Huawei Technologies
+
+   Email: loa@mail01.huawei.com
+
+
+   Pontus Skoldstrom
+   Acreo AB
+   Electrum 236
+   Kista  164 40
+   Sweden
+
+   Phone: +46 8 6327731
+   Email: pontus.skoldstrom@acreo.se
+
+
+   Dave Ward
+   Cisco
+
+   Email: dward@cisco.com
+
+
+   John Drake
+   Juniper
+
+   Email: jdrake@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+Bellagamba, et al.           Standards Track                   [Page 29]
+