diff options
Diffstat (limited to 'doc/rfc/rfc7487.txt')
| -rw-r--r-- | doc/rfc/rfc7487.txt | 1795 |
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc7487.txt b/doc/rfc/rfc7487.txt new file mode 100644 index 0000000..19bdf74 --- /dev/null +++ b/doc/rfc/rfc7487.txt @@ -0,0 +1,1795 @@ + + + + + + +Internet Engineering Task Force (IETF) E. Bellagamba +Request for Comments: 7487 A. Takacs +Category: Standards Track G. Mirsky +ISSN: 2070-1721 Ericsson + L. Andersson + Huawei Technologies + P. Skoldstrom + Acreo AB + D. Ward + Cisco + March 2015 + + + Configuration of + Proactive Operations, Administration, and Maintenance (OAM) Functions + for MPLS-Based Transport Networks Using RSVP-TE + +Abstract + + This specification describes the configuration of proactive MPLS + Transport Profile (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 GMPLS RSVP-TE protocol + based on the OAM Configuration Framework for GMPLS RSVP-TE. + +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/rfc7487. + + + + + + + + + + + + + +Bellagamba, et al. Standards Track [Page 1] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +Copyright Notice + + Copyright (c) 2015 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bellagamba, et al. Standards Track [Page 2] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Conventions Used in This Document ..........................5 + 1.1.1. Terminology .........................................5 + 1.1.2. Requirements Language ...............................6 + 2. Overview of MPLS OAM for Transport Applications .................6 + 3. Theory of Operations ............................................7 + 3.1. MPLS-TP OAM Configuration Operation Overview ...............7 + 3.1.1. Configuration of BFD Sessions .......................8 + 3.1.2. Configuration of Performance Monitoring .............8 + 3.1.3. Configuration of Fault Management Signals ...........9 + 3.2. MPLS OAM Configuration Sub-TLV .............................9 + 3.2.1. CV Flag Rules of Use ...............................11 + 3.3. BFD Configuration Sub-TLV .................................12 + 3.3.1. BFD Identifiers Sub-TLV ............................14 + 3.3.2. Negotiation Timer Parameters Sub-TLV ...............15 + 3.3.3. BFD Authentication Sub-TLV .........................16 + 3.3.4. Traffic Class Sub-TLV ..............................17 + 3.4. Performance Monitoring Sub-TLV ............................17 + 3.4.1. MPLS OAM PM Loss Sub-TLV ...........................19 + 3.4.2. MPLS OAM PM Delay Sub-TLV ..........................21 + 3.5. MPLS OAM FMS Sub-TLV ......................................22 + 4. Summary of MPLS OAM Configuration Errors .......................23 + 5. IANA Considerations ............................................25 + 5.1. MPLS OAM Type .............................................25 + 5.2. MPLS OAM Configuration Sub-TLV ............................25 + 5.3. MPLS OAM Configuration Sub-TLV Types ......................26 + 5.4. BFD Configuration Sub-TLV Types ...........................26 + 5.5. Performance Monitoring Sub-TLV Types ......................27 + 5.6. New RSVP-TE Error Codes ...................................28 + 6. Security Considerations ........................................28 + 7. References .....................................................29 + 7.1. Normative References ......................................29 + 7.2. Informative References ....................................30 + Acknowledgements ..................................................31 + Contributors ......................................................31 + Authors' Addresses ................................................32 + + + + + + + + + + + + + +Bellagamba, et al. Standards Track [Page 3] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +1. Introduction + + This document describes the configuration of proactive MPLS-TP OAM + functions for a given LSP using TLVs that use GMPLS RSVP-TE + [RFC3473]. [RFC7260] defines use of GMPLS RSVP-TE for the + configuration of OAM functions in a technology-agnostic way. This + document specifies the additional 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. + + MPLS-TP, the Transport Profile of MPLS, must, by definition + [RFC5654], be capable of operating without a control plane. + Therefore, there are several options for configuring MPLS-TP OAM + without a control plane by using either a Network Management System + (NMS), an LSP Ping, or signaling protocols such as RSVP-TE in the + control plane. + + MPLS-TP describes a profile of MPLS that enables operational models + typical in transport networks while providing additional OAM + survivability and other maintenance functions not currently supported + by MPLS. [RFC5860] defines the requirements for the OAM + functionality of MPLS-TP. + + Proactive MPLS-TP OAM is performed by three different protocols: + Bidirectional Forwarding Detection (BFD) [RFC6428] for Continuity + Check / Connectivity Verification, the Delay Measurement (DM) + protocol [RFC6374] for delay and delay variation (jitter) + measurements, and the Loss Measurement (LM) protocol [RFC6374] 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 track the liveliness and to + detect the data plane failures of MPLS-TP point to point and might + also be extended to support point-to-multipoint connections. + + The delay and loss measurement protocols [RFC6374] use a simple + query/response model for performing bidirectional measurements that + allows the originating node to measure packet loss and delay in both + directions. By timestamping and/or writing current packet counters + + + +Bellagamba, et al. Standards Track [Page 4] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + to the measurement packets four times (Tx and Rx in both directions), + current delays and packet losses can be calculated. By performing + successive delay measurements, the 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 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 here we are not + configuring on-demand throughput estimates based on saturating the + connection as defined in [RFC6371]. Rather, we only enable the + estimation of the current throughput based on loss measurements. + +1.1. Conventions Used in This Document + +1.1.1. Terminology + + AIS - Alarm Indication Signal + + BFD - Bidirectional Forwarding Detection + + CC - Continuity Check + + CV - Connectivity Verification + + DM - Delay Measurement + + FMS - Fault Management Signal + + G-ACh - Generic Associated Channel + + GMPLS - Generalized Multi-Protocol Label Switching + + LDI - Link Down Indication + + LER - Label Edge Router + + LKR - Lock Report + + LM - Loss Measurement + + LOC - Loss Of Continuity + + LSP - Label Switched Path + + LSR - Label Switching Router + + MEP - Maintenance Entity Group End Point + + + +Bellagamba, et al. Standards Track [Page 5] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + MIP - Maintenance Entity Group Intermediate Point + + MPLS - Multi-Protocol Label Switching + + MPLS-TP - MPLS Transport Profile + + NMS - Network Management System + + PM - Performance Measurement + + RSVP-TE - Reservation Protocol Traffic Engineering + + TC - Traffic Class + +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. Overview of MPLS OAM for Transport Applications + + [RFC6371] describes how MPLS-TP OAM mechanisms are operated to meet + transport requirements outlined in [RFC5860]. + + [RFC6428] specifies two BFD operation modes: 1) "CC mode", which uses + periodic BFD message exchanges with symmetric timer settings + supporting Continuity Check, and 2) "CV/CC mode", which sends unique + maintenance entity identifiers in the periodic BFD messages + supporting CV as well as CC. + + [RFC6374] specifies mechanisms for Performance Monitoring of LSPs, in + particular it specifies loss and delay measurement OAM functions. + + [RFC6427] specifies fault management signals with which a server LSP + can notify client LSPs about various fault conditions to suppress + alarms or to be used as triggers for actions in the client LSPs. The + following signals are defined: Alarm Indication Signal (AIS), Link + Down Indication (LDI), and Lock Report (LKR). + + [RFC6371] describes the mapping of fault conditions to consequent + actions. Some of these mappings may be configured by the operator + depending on the application of the LSP. The following defects are + identified: Loss Of Continuity (LOC), Misconnectivity, MEP + Misconfiguration, and Period Misconfiguration. Out of these defect + conditions, the following consequent actions may be configurable: 1) + + + + + +Bellagamba, et al. Standards Track [Page 6] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + whether or not the LOC defect should result in blocking the outgoing + data traffic; 2) whether or not the "Period Misconfiguration defect" + should result in a signal fail condition. + +3. Theory of Operations + +3.1. MPLS-TP OAM Configuration Operation Overview + + GMPLS RSVP-TE, or alternatively LSP Ping [LSP-PING-CONF], can be used + to simply enable the different OAM functions by setting the + corresponding flags in the OAM Function Flags Sub-TLV [RFC7260]. 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 SHOULD NOT process or modify any of the + OAM Configuration TLVs but simply forward them to the end node. + There is one exception to this and that is if the MPLS OAM FMS Sub- + TLV is present. This sub-TLV MUST be examined even by intermediate + nodes that support these extensions but only acted upon by nodes + capable of transmitting FMS signals into the LSP being established. + The sub-TLV MAY be present when the FMS flag is set in the OAM + Function Flags Sub-TLV. If this sub-TLV is present, then the "OAM + MIP entities desired" and "OAM MEP entities desired" flags (described + in [RFC7260]) in the LSP Attribute Flags TLV MUST be set and the + entire OAM Configuration TLV placed either in the + LSP_REQUIRED_ATTRIBUTES object or in the LSP_ATTRIBUTES object in + order to ensure that capable intermediate nodes process the + configuration. If placed in the LSP_ATTRIBUTES object, nodes that + are not able to process the OAM Configuration TLV will forward the + message without generating an error. If the MPLS OAM FMS Sub-TLV has + been placed in the LSP_REQUIRED_ATTRIBUTES object, a node that + supports RFC 7260 but does not support the MPLS OAM FMS Sub-TLV MUST + generate a PathErr message with "OAM Problem/Configuration Error" + [RFC7260]. Otherwise, if the node doesn't support RFC 7260, it will + not raise any errors as described in the Section 4.1 of [RFC7260]. + + Finally, if the MPLS OAM FMS Sub-TLV is not included, only the "OAM + MEP entities desired" flag is set and the OAM Configuration TLV may + be placed in either LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES. + + + + + + + + + + + +Bellagamba, et al. Standards Track [Page 7] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +3.1.1. Configuration of BFD Sessions + + For this specification, BFD MUST be run in either one of the two + modes: + + o Asynchronous mode, where both sides should be in active mode; or + + o Unidirectional mode. + + In the simplest scenario, RSVP-TE (or alternatively LSP Ping + [LSP-PING-CONF]), 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 LSP-Ping-based + bootstrapping described in [RFC5884]) or directly in the RSVP-TE + signaling messages. + + When BFD Control packets are transported in the G-ACh, they are not + protected by any end-to-end checksum; only lower layers are providing + 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 happening, the BFD Configuration + Sub-TLV has an Integrity flag that, when set, enables BFD + Authentication using Keyed SHA1 with an empty key (all 0s) [RFC5880]. + This would ensure that every BFD Control packet carries 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 MUST be included in the BFD Configuration Sub- + TLV. The BFD Authentication Sub-TLV is used to specify which + authentication method should be used and which pre-shared key / + password should be used for this particular session. How the key + exchange is performed is out of scope of this document. + +3.1.2. Configuration of Performance Monitoring + + It is possible to configure Performance Monitoring functionalities + such as Loss, Delay, 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 OAM Function Flags Sub-TLV) or a + + + + + +Bellagamba, et al. Standards Track [Page 8] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + customized configuration. To customize the configuration, one would + set the respective flags and include the respective Loss and/or Delay + sub-TLVs. + + By setting the PM/Loss flag in the OAM Function Flags Sub-TLV and by + including the MPLS OAM PM Loss Sub-TLV, 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 + OAM Function Flags Sub-TLV; by including the MPLS OAM PM Loss Sub- + TLV, one can configure the measurement interval and the delay + threshold values for triggering protection. + +3.1.3. Configuration of Fault Management Signals + + To configure Fault Management signals and their refresh time, the FMS + flag in the OAM Function Flags Sub-TLV MUST be set and the MPLS OAM + FMS Sub-TLV included. When configuring Fault Management signals, 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. + + If an intermediate point is intended to originate fault management + signal 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 RSVP-TE session (or, alternatively, via an NMS or LSP Ping). + +3.2. MPLS OAM Configuration Sub-TLV + + The OAM Configuration TLV, defined in [RFC7260], specifies the OAM + functions that are used for the LSP. This document extends the OAM + Configuration TLV by defining a new OAM Type: "MPLS OAM" (3). The + MPLS OAM type is set to request the establishment of OAM functions + for MPLS-TP LSPs. The specific OAM functions are specified in the + OAM Function Flags Sub-TLV as depicted in [RFC7260]. + + When an egress LSR receives an OAM Configuration TLV indicating the + MPLS OAM type, the LSR will first process any present OAM Function + Flags Sub-TLV, and then it MUST process technology-specific + configuration TLVs. This document defines a sub-TLV, the MPLS OAM + Configuration Sub-TLV, which is carried in the OAM Configuration TLV. + + + + + +Bellagamba, et al. Standards Track [Page 9] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + 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 Conf. Sub-TLV (33) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ sub-TLVs ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: MPLS OAM Configuration Sub-TLV Format + + Type: 33, the MPLS OAM Configuration Sub-TLV. + + Length: Indicates the total length in octets, including sub-TLVs as + well as the Type and Length fields. + + The following MPLS-OAM-specific sub-TLVs MAY be included in the MPLS + OAM Configuration Sub-TLV: + + o BFD Configuration Sub-TLV MUST be included if either the CC, the + CV, or both OAM Function flags are being set in the OAM Function + Flags Sub-TLV [RFC7260]. This sub-TLV carries additional sub- + TLVs; failure to include the correct sub-TLVs MUST result in an + error being generated: "OAM Problem/Configuration Error". The + sub-TLVs are: + + * BFD Identifiers Sub-TLV MUST always be included. + + * Timer Negotiation Parameters Sub-TLV MUST be included if the N + flag is not set. + + * BFD Authentication Sub-TLV MAY be included if the I flag is + set. + + o Performance Monitoring Sub-TLV, which MUST be included if any of + the PM/Delay, PM/Loss, or PM/Throughput flags are set in the OAM + Function Flag Sub-TLV [RFC7260]. This sub-TLV MAY carry + additional sub-TLVs: + + * MPLS OAM PM Loss Sub-TLV MAY be included if the PM/Loss OAM + Function flag is set. If the MPLS OAM PM Loss Sub-TLV is not + included, default configuration values are used. The same sub- + TLV MAY also be included in case the PM/Throughput OAM Function + flag is set and there is the need to specify measurement + intervals different from the default ones. Since throughput + measurements use the same tool as loss measurements, the same + TLV is used. + + + +Bellagamba, et al. Standards Track [Page 10] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + * MPLS OAM PM Delay Sub-TLV MAY be included if the PM/Delay OAM + Function flag is set. If the MPLS OAM PM Delay Sub-TLV is not + included, default configuration values are used. + + o MPLS OAM FMS Sub-TLV MAY be included if the FMS OAM Function flag + is set. If the MPLS OAM FMS Sub-TLV is not included, default + configuration values are used. + + The following are some additional rules of processing the MPLS OAM + Configuration Sub-TLV: + + o The MPLS OAM Configuration Sub-TLV MAY be empty, i.e., have no + Value. If so, then its Length MUST be 8. Then, all OAM functions + that have their corresponding flags set in the OAM Function Flags + Sub-TLV MUST be assigned their default values or left disabled. + + o A sub-TLV that doesn't have a corresponding flag set MUST be + silently ignored. + + o If multiple copies of a sub-TLV are present, then only the first + sub-TLV MUST be used and the remaining sub-TLVs MUST be silently + ignored. + + However, not all the values can be derived from the standard RSVP-TE + objects, in particular the locally assigned Tunnel ID at the egress + cannot be derived by the ingress node. Therefore, the full LSP MEP- + ID used by the ingress has to be carried in the BFD Identifiers Sub- + TLV in the Path message and the egress LSP MEP-ID in the same way in + the Resv message. + +3.2.1. CV Flag Rules of Use + + If the CV flag is set in the OAM Function Flags Sub-TLV [RFC7260], + then the CC flag MUST be set as well because performing Connectivity + Verification implies performing Continuity Check as well. The format + of an MPLS-TP CV/CC message is shown in [RFC6428]. In order to + perform Connectivity Verification, the CV/CC message MUST contain the + "LSP MEP-ID" in addition to the BFD Control packet information. The + "LSP MEP-ID" contains four identifiers: + + MPLS-TP Global_ID + + MPLS-TP Node Identifier + + Tunnel_Num + + LSP_Num + + + + +Bellagamba, et al. Standards Track [Page 11] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + These values need to be correctly set by both ingress and egress when + transmitting a CV packet, and both ingress and egress need to know + what to expect when receiving a CV packet. Most of these values can + be derived from the Path and Resv messages [RFC3473], which use a + 5-tuple to uniquely identify an LSP within an operator's network. + This tuple is composed of a Tunnel Sender Address, Tunnel Endpoint + Address, Tunnel_ID, Extended Tunnel ID, and (GMPLS) LSP_ID. + +3.3. BFD Configuration Sub-TLV + + The BFD Configuration Sub-TLV (depicted below) is defined for BFD- + OAM-specific configuration parameters. The BFD Configuration Sub-TLV + is carried as a sub-TLV of the MPLS OAM Configuration Sub-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. Type (1) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Vers.|N|S|I|G|U|B| Reserved (set to all 0s) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ sub-TLVs ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: BFD Configuration Sub-TLV Format + + Type: 1, the BFD Configuration Sub-TLV. + + Length: Indicates the total length in octets, including sub-TLVs as + well as the Type and Length fields. + + Version: Identifies the BFD protocol version. If the egress LSR does + not support the version, an error MUST be generated: "OAM Problem/ + Unsupported BFD Version". + + BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD + Control messages is enabled, when cleared it is disabled. + + Symmetric Session (S): If set, the BFD session MUST use symmetric + timing values. + + + + + + +Bellagamba, et al. Standards Track [Page 12] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + 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". + + 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. 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". + + Encapsulation Capability (U): If set, it shows the capability of + encapsulating BFD messages into 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 unidirectional mode. + In the second case, the source node does not expect any Discriminator + values back from the destination node. + + Reserved: Reserved for future specifications; set to 0 on + transmission and ignored when received. + + The BFD Configuration Sub-TLV MUST include the following sub-TLVs in + the Path message: + + o BFD Identifiers Sub-TLV; and + + o Negotiation Timer Parameters Sub-TLV if the N flag is cleared. + + The BFD Configuration Sub-TLV MUST include the following sub-TLVs in + the Resv message: + + o BFD Identifiers Sub-TLV; and + + o Negotiation Timer Parameters Sub-TLV if: + + * the N and S flags are cleared; or if + + + + + + + +Bellagamba, et al. Standards Track [Page 13] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + * the N flag is cleared and the S flag is set and the Negotiation + Timer Parameters Sub-TLV received by the egress contains + unsupported values. In this case, an updated Negotiation Timer + Parameters Sub-TLV containing values supported by the egress + LSR MUST be returned to the ingress. + +3.3.1. BFD Identifiers Sub-TLV + + The BFD Identifiers Sub-TLV is carried as a sub-TLV of the BFD + Configuration Sub-TLV and is depicted below. + + 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 Identifiers Type (1) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local Discriminator | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MPLS-TP Global_ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MPLS-TP Node Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tunnel_Num | LSP_Num | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Figure 3: BFD Identifiers Sub-TLV Format + + Type: 1, the BFD Identifiers Sub-TLV. + + Length: Indicates the TLV total length in octets, including the Type + and Length fields (20). + + Local Discriminator: A unique, non-zero discriminator value generated + by the transmitting system and referring to itself; it is used to de- + multiplex multiple BFD sessions between the same pair of systems as + defined in [RFC5880]. + + MPLS-TP Global_ID, Node Identifier, Tunnel_Num, and LSP_Num: All set + as defined in [RFC6370]. + + + + + + + + + + + +Bellagamba, et al. Standards Track [Page 14] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +3.3.2. Negotiation Timer Parameters Sub-TLV + + The Negotiation Timer Parameters Sub-TLV is carried as a sub-TLV of + the BFD Configuration Sub-TLV and is depicted below. + + 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 Type (2) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Acceptable Min. Asynchronous TX interval | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Acceptable Min. Asynchronous RX interval | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Required Echo TX Interval | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: Negotiation Timer Parameters Sub-TLV Format + + Type: 2, the Negotiation Timer Parameters Sub-TLV. + + Length: Indicates the TLV total length in octets, including Type and + Length fields (16). + + Acceptable Min. Asynchronous TX interval: If the S flag is set in the + BFD Configuration Sub-TLV, 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 egress LSR cannot + support the value, it SHOULD reply with a supported interval. + + If the S flag is cleared in the BFD Configuration Sub-TLV, this field + expresses the desired time interval (in microseconds) at which the + ingress LSR intends to transmit BFD periodic control packets. + + Acceptable Min. Asynchronous RX interval: If the S flag is set in the + BFD Configuration Sub-TLV, this field MUST be set equal to + "Acceptable Min. Asynchronous TX interval" on transmit and MUST be + ignored on receipt since it has no additional meaning with respect to + the one described for "Acceptable Min. Asynchronous TX interval". + + If the S flag is cleared in the BFD Configuration Sub-TLV, it + expresses the minimum time interval (in microseconds) at which the + ingress/egress LSRs can receive periodic BFD Control packets. If + this value is greater than the "Acceptable Min. Asynchronous TX + interval" received from the ingress/egress LSR, the receiving LSR + MUST adopt the interval expressed in the "Acceptable Min. + Asynchronous RX interval". + + + + +Bellagamba, et al. Standards Track [Page 15] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + 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 LSR node cannot + support this value, it SHOULD reply with a supported value (which may + be zero if Echo is not supported). + +3.3.3. BFD Authentication Sub-TLV + + The BFD Authentication Sub-TLV is carried as a sub-TLV of the BFD + Configuration Sub-TLV and is depicted below. + + 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. Type (3) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Auth Type | Auth Key ID | Reserved (0s) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: BFD Authentication Sub-TLV Format + + Type: 3, the BFD Authentication Sub-TLV. + + Length: Indicates the TLV total length in octets, including Type and + Length fields (8). + + Auth Type: Indicates which type of authentication to use. The same + values are used as are defined in Section 4.1 of [RFC5880]. If the + egress LSR does not support this type, an "OAM Problem/Unsupported + BFD Authentication Type" error MUST be generated. + + 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 specifications; set to 0 on + transmission and ignored when received. + + + + + + + + +Bellagamba, et al. Standards Track [Page 16] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +3.3.4. Traffic Class Sub-TLV + + The Traffic Class Sub-TLV is carried as a sub-TLV of the BFD + Configuration Sub-TLV or Fault Management Signal Sub-TLV + (Section 3.5) 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Traffic Class Sub-Type (4) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TC | Reserved (set to all 0s) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: Traffic Class Sub-TLV Format + + Type: 4, the Traffic Class Sub-TLV. + + Length: Indicates the length of the Value field in octets (4). + + Traffic Class (TC): Identifies the TC [RFC5462] for periodic + continuity monitoring messages or packets with fault management + information. + + If the Traffic Class Sub-TLV is present, then the value of the TC + field MUST be used as the value of the TC field of an MPLS label + stack entry. If the Traffic Class Sub-TLV is absent from BFD + Configuration Sub-TLV or Fault Management Signal Sub-TLV, then + selection of the TC value is a local decision. + +3.4. Performance Monitoring Sub-TLV + + If the OAM Function Flags Sub-TLV has either the PM/Loss, PM/Delay, + or PM/Throughput flag set, the Performance Monitoring Sub-TLV MUST be + present in the MPLS OAM Configuration Sub-TLV. Failure to include + the correct sub-TLVs MUST result in an "OAM Problem/Configuration + Error" message 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], "the crossing of which will trigger warnings or alarms, + and result reporting and exception notification will be integrated + into the system-wide network management and reporting framework." + + + + + + + +Bellagamba, et al. Standards Track [Page 17] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + In case the values need to be different than the default ones, the + Performance Monitoring Sub-TLV includes the following sub-TLVs: + + o MPLS OAM PM Loss Sub-TLV if the PM/Loss and/or PM/Throughput flag + is set in the OAM Function Flags Sub-TLV; and + + o MPLS OAM PM Delay Sub-TLV if the PM/Delay flag is set in the OAM + Function Flags Sub-TLV. + + The Performance Monitoring Sub-TLV depicted below is carried as a + sub-TLV of the MPLS OAM Configuration 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Perf. Monitoring Type (2) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |D|L|J|Y|K|C| Reserved (set to all 0s) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ sub-TLVs ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: Performance Monitoring Sub-TLV Format + + Type: 2, the Performance Monitoring Sub-TLV. + + Length: Indicates the TLV total length in octets, including sub-TLVs + as well as Type and Length fields. + + Configuration Flags (for the specific function description please + refer to [RFC6374]): + + o 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. + + o 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. + + o 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. + + + + + +Bellagamba, et al. Standards Track [Page 18] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + o 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. + + o 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. + + o 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 specifications; set to 0 on + transmission and ignored when received. + +3.4.1. MPLS OAM PM Loss Sub-TLV + + The MPLS OAM PM Loss Sub-TLV depicted below 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 Type (1) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OTF |T|B| Reserved (set to all 0s) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Measurement Interval | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Test Interval | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Loss Threshold | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: MPLS OAM PM Loss Sub-TLV Format + + Type: 1, the MPLS OAM PM Loss Sub-TLV. + + Length: Indicates the length of the parameters in octets, including + Type and Length fields (20). + + Origin Timestamp Format (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 19] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + Configuration Flags (please refer to [RFC6374] for further details): + + o T: Traffic-class-specific measurement indicator. Set to 1 when + the measurement operation is scoped to packets of a particular + traffic class (Differentiated Service Code Point (DSCP) value) and + zero 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. + + o B: Octet (byte) count. When set to 1, it indicates that the + Counter 1-4 fields represent octet counts. When set to 0, it + indicates that the Counter 1-4 fields represent packet counts. By + default, it is set to 0. + + Reserved: Reserved for future specifications; set to 0 on + transmission and ignored when received. + + Measurement Interval: The time interval (in milliseconds) at which + Loss Measurement query messages MUST be sent in both directions. If + the egress LSR cannot support the value, it SHOULD reply with a + supported interval. By default, it is set to 100 milliseconds as per + [RFC6375]. + + Test Interval: Test messages interval (in milliseconds) as described + in [RFC6374]. By default, it is set to 10 milliseconds as per + [RFC6375]. If the egress LSR cannot support the value, it SHOULD + reply with a supported interval. + + Loss Threshold: The threshold value of measured lost packets per + measurement over which action(s) SHOULD be triggered. + + + + + + + + + + + + + + + + + + + + + +Bellagamba, et al. Standards Track [Page 20] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +3.4.2. MPLS OAM PM Delay Sub-TLV + + The MPLS OAM PM Delay Sub-TLV depicted below 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 Type (2) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OTF |T|B| Reserved (set to all 0s) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Measurement Interval | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Test Interval | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Delay Threshold | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 9: MPLS OAM PM Delay Sub-TLV Format + + Type: 2, the MPLS OAM PM Delay Sub-TLV. + + Length: Indicates the length of the parameters in octets, including + Type and Length fields (20). + + 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): + + o 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 (DSCP) value) + and zero otherwise. When set to 1, the Differentiated Service + (DS) field of the message indicates the measured traffic class. + By default, it is set to 1. + + o B: Octet (byte) count. When set to 1, it indicates that the + Counter 1-4 fields represent octet counts. When set to 0, it + indicates that the Counter 1-4 fields represent packet counts. By + default, it is set to 0. + + Reserved: Reserved for future specifications; set to 0 on + transmission and ignored when received. + + + + +Bellagamba, et al. Standards Track [Page 21] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + Measurement Interval: The time interval (in milliseconds) at which + Delay Measurement query messages MUST be sent on both directions. If + the egress LSR cannot support the value, it SHOULD reply with a + supported interval. By default, it is set to 1000 milliseconds as + per [RFC6375]. + + Test Interval: Test messages interval (in milliseconds) as described + in [RFC6374]. By default, it is set to 10 milliseconds as per + [RFC6375]. If the egress LSR cannot support the value, it SHOULD + reply with a supported interval. + + Delay Threshold: The threshold value of measured two-way delay (in + milliseconds) over which action(s) SHOULD be triggered. + +3.5. MPLS OAM FMS Sub-TLV + + The MPLS OAM FMS Sub-TLV depicted below is carried as a sub-TLV of + the MPLS OAM Configuration Sub-TLV. When both working and protection + paths are signaled, both LSPs SHOULD be signaled with identical + settings of the E flag, T flag, and the refresh timer. + + 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 FMS Type (3) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |E|S|T| Reserved | Refresh Timer | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Sub-TLVs ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 10: MPLS OAM FMS Sub-TLV Format + + Type: 3, the MPLS OAM FMS Sub-TLV. + + Length: Indicates the TLV total length in octets, including Type and + Length fields (8). + + FMS Signal Flags are used to enable the FMS signals at 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. + + + + + + + + +Bellagamba, et al. Standards Track [Page 22] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + The following flags are defined: + + E: Enable Alarm Indication Signal (AIS) and Lock Report (LKR) + signaling as described in [RFC6427]. The default value is 1 + (enabled). If the egress MEP does not support FMS signal + 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 client LSPs. The default value is 0 (disabled). If a + server MEP, which 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 by the configuration of a specific + timer value. The Default value is 0 (disabled). + + Remaining bits: Reserved for a future specification and set to 0. + + Refresh Timer: Indicates (in seconds) the refresh timer of fault + indication messages. The value MUST be between 1 to 20 seconds as + specified for the Refresh Timer field in [RFC6427]. If the egress + LSR cannot support the value, it SHOULD reply with a supported timer + value. + + The Fault Management Signals Sub-TLV MAY include the Traffic Class + Sub-TLV (Section 3.3.4.) If the Traffic Class 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 Traffic Class + Sub-TLV is absent, then selection of the TC value is local decision. + +4. Summary of MPLS OAM Configuration Errors + + In addition to error values specified in [RFC7260], this document + defines the following values for the "OAM Problem" error code: + + 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". + + + + +Bellagamba, et al. Standards Track [Page 23] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + 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 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 the specified Delay mode, an + "OAM Problem/Unsupported Delay Mode" error MUST be generated. + + o If an egress LSR does not support the 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. + + 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. + + + + + + + + + + +Bellagamba, et al. Standards Track [Page 24] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +5. IANA Considerations + +5.1. MPLS OAM Type + + This document specifies the new MPLS OAM type. IANA has allocated a + new type (3) from the "OAM Types" space of the "RSVP-TE OAM + Configuration Registry". + + +------+-------------+-----------+ + | Type | Description | Reference | + +------+-------------+-----------+ + | 3 | MPLS OAM | [RFC7487] | + +------+-------------+-----------+ + + Table 1: MPLS OAM Type + +5.2. MPLS OAM Configuration Sub-TLV + + This document specifies the MPLS OAM Configuration Sub-TLV. IANA has + allocated a new type (33) from the OAM Sub-TLV space of the "RSVP-TE + OAM Configuration Registry". + + +------+--------------------------------+-----------+ + | Type | Description | Reference | + +------+--------------------------------+-----------+ + | 33 | MPLS OAM Configuration Sub-TLV | [RFC7487] | + +------+--------------------------------+-----------+ + + Table 2: MPLS OAM Configuration Sub-TLV Type + + + + + + + + + + + + + + + + + + + + + + +Bellagamba, et al. Standards Track [Page 25] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +5.3. MPLS OAM Configuration Sub-TLV Types + + IANA has created an "MPLS OAM Configuration Sub-TLV Types" sub- + registry in the "RSVP-TE OAM Configuration Registry" for the sub-TLVs + carried in the MPLS OAM Configuration Sub-TLV. Values from this new + sub-registry are to be allocated through IETF Review except for the + "Reserved for Experimental Use" range. This document defines the + following types: + + +-------------+--------------------------------+-----------+ + | Type | Description | Reference | + +-------------+--------------------------------+-----------+ + | 0 | Reserved | [RFC7487] | + | 1 | BFD Configuration Sub-TLV | [RFC7487] | + | 2 | Performance Monitoring Sub-TLV | [RFC7487] | + | 3 | MPLS OAM FMS Sub-TLV | [RFC7487] | + | 4-65532 | Unassigned | | + | 65533-65534 | Reserved for Experimental Use | [RFC7487] | + | 65535 | Reserved | [RFC7487] | + +-------------+--------------------------------+-----------+ + + Table 3: MPLS OAM Configuration Sub-TLV Types + +5.4. BFD Configuration Sub-TLV Types + + IANA has created a "BFD Configuration Sub-TLV Types" sub-registry in + the "RSVP-TE OAM Configuration Registry" for the sub-TLV types + carried in the BFD Configuration Sub-TLV. Values from this new sub- + registry are to be allocated through IETF Review except for the + "Reserved for Experimental Use" range. This document defines the + following types: + + +-------------+--------------------------------------+-----------+ + | Type | Description | Reference | + +-------------+--------------------------------------+-----------+ + | 0 | Reserved | [RFC7487] | + | 1 | BFD Identifiers Sub-TLV | [RFC7487] | + | 2 | Negotiation Timer Parameters Sub-TLV | [RFC7487] | + | 3 | BFD Authentication Sub-TLV | [RFC7487] | + | 4 | Traffic Class Sub-TLV | [RFC7487] | + | 5-65532 | Unassigned | | + | 65533-65534 | Reserved for Experimental Use | [RFC7487] | + | 65535 | Reserved | [RFC7487] | + +-------------+--------------------------------------+-----------+ + + Table 4: BFD Configuration Sub-TLV Types + + + + + +Bellagamba, et al. Standards Track [Page 26] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +5.5. Performance Monitoring Sub-TLV Types + + IANA has created a "Performance Monitoring Sub-TLV Type" sub-registry + in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types + carried in the Performance Monitoring Sub-TLV. Values from this new + sub-registry are to be allocated through IETF Review except for the + "Reserved for Experimental Use" range. This document defines the + following types: + + +-------------+-------------------------------+-----------+ + | Type | Description | Reference | + +-------------+-------------------------------+-----------+ + | 0 | Reserved | [RFC7487] | + | 1 | MPLS OAM PM Loss Sub-TLV | [RFC7487] | + | 2 | MPLS OAM PM Delay Sub-TLV | [RFC7487] | + | 3-65532 | Unassigned | | + | 65533-65534 | Reserved for Experimental Use | [RFC7487] | + | 65535 | Reserved | [RFC7487] | + +-------------+-------------------------------+-----------+ + + Table 5: Performance Monitoring Sub-TLV Types + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bellagamba, et al. Standards Track [Page 27] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +5.6. New RSVP-TE Error Codes + + The following values have been assigned under the "OAM Problem" error + code [RFC7260] by IETF Review process: + + +------------------+------------------------------------+-----------+ + | Error Value Sub- | Description | Reference | + | Codes | | | + +------------------+------------------------------------+-----------+ + | 13 | Unsupported BFD Version | [RFC7487] | + | 14 | Unsupported BFD Encapsulation | [RFC7487] | + | | format | | + | 15 | Unsupported BFD Authentication | [RFC7487] | + | | Type | | + | 16 | Mismatch of BFD Authentication Key | [RFC7487] | + | | ID | | + | 17 | Unsupported Timestamp Format | [RFC7487] | + | 18 | Unsupported Delay Mode | [RFC7487] | + | 19 | Unsupported Loss Mode | [RFC7487] | + | 20 | Delay variation unsupported | [RFC7487] | + | 21 | Dyadic mode unsupported | [RFC7487] | + | 22 | Loopback mode unsupported | [RFC7487] | + | 23 | Combined mode unsupported | [RFC7487] | + | 24 | Fault management signaling | [RFC7487] | + | | unsupported | | + | 25 | Unable to create fault management | [RFC7487] | + | | association | | + +------------------+------------------------------------+-----------+ + + Table 6: MPLS OAM Configuration Error Codes + + The "Sub-Codes - 40 OAM Problem" sub-registry is located in the + "Error Codes and Globally-Defined Error Value Sub-Codes" registry. + +6. Security Considerations + + The signaling of OAM-related parameters and the automatic + establishment of OAM entities introduces additional security + considerations to those discussed in [RFC3473]. 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 as discussed in [RFC7260] and + [RFC6060]. + + Additional discussion of security for MPLS and GMPLS protocols can be + found in [RFC5920]. + + + + + +Bellagamba, et al. Standards Track [Page 28] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation Protocol- + Traffic Engineering (RSVP-TE) Extensions", RFC 3473, + January 2003, <http://www.rfc-editor.org/info/rfc3473>. + + [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., + Sprecher, N., and S. Ueno, "Requirements of an MPLS + Transport Profile", RFC 5654, September 2009, + <http://www.rfc-editor.org/info/rfc5654>. + + [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., + "Requirements for Operations, Administration, and + Maintenance (OAM) in MPLS Transport Networks", RFC 5860, + May 2010, <http://www.rfc-editor.org/info/rfc5860>. + + [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD)", RFC 5880, 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, June 2010, + <http://www.rfc-editor.org/info/rfc5884>. + + [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, + "Generalized Multiprotocol Label Switching (GMPLS) Control + of Ethernet Provider Backbone Traffic Engineering (PBB- + TE)", RFC 6060, March 2011, + <http://www.rfc-editor.org/info/rfc6060>. + + [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport + Profile (MPLS-TP) Identifiers", RFC 6370, 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, September 2011, + <http://www.rfc-editor.org/info/rfc6374>. + + + + + + +Bellagamba, et al. Standards Track [Page 29] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + + [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, 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, November 2011, + <http://www.rfc-editor.org/info/rfc6428>. + + [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE + Extensions for Operations, Administration, and Maintenance + (OAM) Configuration", RFC 7260, June 2014, + <http://www.rfc-editor.org/info/rfc7260>. + +7.2. Informative References + + [LSP-PING-CONF] + Bellagamba, E., Mirsky, G., Andersson, L., Skoldstrom, P., + Ward, D., and J. Drake, "Configuration of Proactive + Operations, Administration, and Maintenance (OAM) + Functions for MPLS-based Transport Networks using LSP + Ping", Work in Progress, draft-ietf-mpls-lsp-ping-mpls-tp- + oam-conf-09, January 2015. + + [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching + (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic + Class" Field", RFC 5462, February 2009, + <http://www.rfc-editor.org/info/rfc5462>. + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, 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, 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, September 2011, + <http://www.rfc-editor.org/info/rfc6375>. + + + + + + +Bellagamba, et al. Standards Track [Page 30] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +Acknowledgements + + The authors would like to thank David Allan, Lou Berger, Annamaria + Fulignoli, Eric Gray, Andras Kern, David Jocha, and David Sinicrope + for their useful comments. + +Contributors + + This document is the result of a large team of authors and + contributors. The following is a list of the contributors: + + John Drake + + Benoit Tremblay + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bellagamba, et al. Standards Track [Page 31] + +RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 + + +Authors' Addresses + + Elisa Bellagamba + Ericsson + + EMail: elisa.bellagamba@ericsson.com + + + Attila Takacs + Ericsson + + EMail: attila.takacs@ericsson.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 70 7957731 + EMail: pontus.skoldstrom@acreo.se + + + Dave Ward + Cisco + + EMail: dward@cisco.com + + + + + + + + + + + +Bellagamba, et al. Standards Track [Page 32] + |