--- 1/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.txt 2015-01-24 13:14:54.547975311 -0800 +++ 2/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16.txt 2015-01-24 13:14:54.603976653 -0800 @@ -1,51 +1,51 @@ CCAMP Working Group E. Bellagamba Internet-Draft A. Takacs Intended status: Standards Track G. Mirsky -Expires: July 15, 2015 Ericsson +Expires: July 28, 2015 Ericsson L. Andersson Huawei Technologies P. Skoldstrom Acreo AB D. Ward Cisco - January 11, 2015 + January 24, 2015 Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE - draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15 + draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16 Abstract - This specification describes the configuration of pro-active MPLS-TP + This specification describes the configuration of proactive MPLS-TP (MPLS-Transport Profile) Operations, Administration, and Maintenance (OAM) Functions for a given 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 15, 2015. + This Internet-Draft will expire on July 28, 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 @@ -89,54 +89,53 @@ 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . 26 9.2. Informative References . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction - This document describes the configuration of pro-active MPLS-TP - (MPLS-Transport Profile) Operations, Administration, and Maintenance - (OAM) Functions for a given LSP using TLVs using GMPLS RSVP-TE - [RFC3473]. The use of GMPLS RSVP-TE for the configuration of OAM - functions is defined in a technology agnostic way in [RFC7260]. 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 pro-active MPLS-TP OAM functions - running between 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. + This document describes the configuration of proactive MPLS-TP (MPLS- + Transport Profile) Operations, Administration, and Maintenance (OAM) + Functions for a given LSP using TLVs using 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 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 either using an NMS or LSP Ping, or with a control plane using signaling protocols such as RSVP-TE. 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. - Pro-active MPLS-TP OAM is performed by three different protocols, Bi- + Proactive MPLS-TP OAM is performed by three different protocols, Bi- directional Forwarding Detection (BFD) [RFC6428] for Continuity Check/Connectivity Verification, the delay measurement protocol (DM) [RFC6374] for delay and delay variation (jitter) measurements, and the loss measurement protocol (LM) [RFC6374] for packet loss and - throughput measurements. Additionally there is a number of Fault - Management Signals that can be configured. + throughput measurements. Additionally, there is 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 detect data plane failures of MPLS-TP point-to-point and might also be extended to support point-to-multipoint connections. The delay and loss measurements protocols [RFC6374] use a simple query/response model for performing bidirectional measurements that @@ -236,36 +235,36 @@ 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 + 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 has to be examined even by - intermediate nodes, 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 Attributes Flags TLV" MUST be set and the + 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 Attributes 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 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? + message without generating an error. If the "MPLS OAM FMS sub-TLV" been placed in the LSP_REQUIRED_ATTRIBUTES object a node that supports the RFC 7260 but does not support the "MPLS OAM FMS sub-TLV" MUST generate PathErr message with "OAM Problem/Configuration Error" [RFC7260]. Otherwise, if the node doesn't support the RFC 7260, it will not raise any errors as described in the Section 4.1 [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. @@ -335,22 +334,22 @@ 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? been set as indication of the + server adaptation function and the "Fault Management subscription" + flag in the "MPLS OAM FMS sub-TLV" been set as indication of the request to create the association at each intermediate node of the client LSP. 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" (TBA1). The "MPLS OAM" type is set to request the establishment of OAM @@ -375,38 +374,39 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBA2, 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": - - "BFD Configuration sub-TLV", which MUST be included if the CC - and/or the CV OAM Function flag is set. 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 Configuration sub-TLV", which MUST be included if either + the CC, the CV or both OAM Function flags 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. - "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". This sub-TLV MAY carry additional - sub-TLVs: + "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 interval different from the default ones. Since throughput measurements use the same tool as loss measurements the same TLV is used. @@ -419,41 +419,43 @@ default configuration values are used. Following are some additional rules of processing MPLS OAM Configuration sub-TLV: - MPLS OAM Configuration sub-TLV MAY be empty, i.e. have no Value. 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. - - sub-TLV that doesn't have corresponding flag set MUST be - silently ignored; - - if multiple copies of a sub-TLV are present, then only the first + - Sub-TLV that doesn't have corresponding flag set MUST be + silently ignored. + + - 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, 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: + 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 These values need to be correctly set by both ingress and egress when @@ -1164,20 +1166,23 @@ 8. 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]. + 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. @@ -1219,29 +1224,32 @@ 6428, November 2011. [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration", RFC 7260, June 2014. 9.2. Informative References [LSP-PING-CONF] Bellagamba, E., Andersson, L., Ward, D., Drake, J., and P. - Skoldstrom, "Configuration of pro-active MPLS-TP + Skoldstrom, "Configuration of proactive MPLS-TP Operations, Administration, and Maintenance (OAM) Functions Using LSP Ping", 2014, . [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009. + [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, July 2010. + [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011. [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011. Authors' Addresses