--- 1/draft-ietf-ccamp-oam-configuration-fwk-09.txt 2013-06-15 20:14:24.142046925 +0100 +++ 2/draft-ietf-ccamp-oam-configuration-fwk-10.txt 2013-06-15 20:14:24.186047994 +0100 @@ -1,21 +1,21 @@ Network Working Group A. Takacs Internet-Draft Ericsson Intended status: Standards Track D. Fedyk -Expires: July 26, 2013 Alcatel-Lucent +Expires: December 17, 2013 Alcatel-Lucent J. He Huawei - January 22, 2013 + June 15, 2013 GMPLS RSVP-TE extensions for OAM Configuration - draft-ietf-ccamp-oam-configuration-fwk-09 + draft-ietf-ccamp-oam-configuration-fwk-10 Abstract OAM is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to @@ -36,21 +36,21 @@ 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 26, 2013. + This Internet-Draft will expire on December 17, 2013. Copyright Notice Copyright (c) 2013 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 @@ -64,31 +64,31 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 6 3.1. Establishment of OAM Entities and Functions . . . . . . . 7 3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 8 3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 9 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 10 4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 10 4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11 4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 12 - 4.2.2. Technology Specific sub-TLVs . . . . . . . . . . . . . 13 + 4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . . 13 4.3. Administrative Status Information . . . . . . . . . . . . 13 - 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 13 + 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 14 4.5. Considerations on Point-to-Multipoint OAM Configuration . 14 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction GMPLS is designed as an out-of-band control plane supporting dynamic connection provisioning for any suitable data plane technology; including spatial switching (e.g., incoming port or fiber to outgoing port or fiber), wavelength-division multiplexing (e.g., DWDM), time- division multiplexing (e.g., SONET/SDH, G.709), and Ethernet Provider Backbone Bridging - Traffic Engineering (PBB-TE) and MPLS. In most of these technologies, there are Operations, Administration and @@ -116,26 +116,29 @@ plane connection establishment mechanisms are synchronized with OAM establishment and activation. In particular, if the GMPLS control plane is employed, it is desirable to bind OAM setup and configuration to connection establishment signaling to avoid two separate management/configuration steps (connection setup followed by OAM configuration) which increases delay, processing, and more importantly may be prone to misconfiguration errors. Once OAM entities are setup and configured, pro-active as well as on-demand OAM functions can be activated via the management plane. On the other hand, it should be possible to activate/deactivate pro-active - OAM functions via the GMPLS control plane as well. + OAM functions via the GMPLS control plane as well. In some + situations it may be possible to use the GMPLS control plane to + control on-demand OAM functions too. This document describes requirements for OAM configuration and control via RSVP-TE. Extensions to the RSVP-TE protocol are specified providing a framework to configure and control OAM entities along with the capability to carry technology specific information. + Extensions can be grouped into: generic elements that are applicable to any OAM solution; and technology specific elements that provide additional configuration parameters, which may only be needed for a specific OAM technology. This document specifies the technology agnostic elements and specifies the way additional technology specific OAM parameters are provided. This document addresses end-to-end OAM configuration, that is, the setup of OAM entities bound to an end-to-end LSP, and configuration and control of OAM functions running end-to-end in the LSP. @@ -270,25 +273,25 @@ In addition to MP and ME identification parameters, pro-active OAM functions (e.g., Continuity Check (CC) and Performance Monitoring (PM)) may have additional parameters that require configuration as well. In particular, the frequency of periodic CC packets and the measurement interval for loss and delay measurements may need to be configured. The above parameters may be either derived from LSP provisioning information, or alternatively, pre-configured default values can be - used. In the simplest case, the control plane provides information - on whether or not OAM entities need to be setup for the signaled LSP. - If OAM entities are created, control plane signaling must also - provide a means to activate/deactivate OAM message flows and - associated alarms. + used. In the simplest case, the control plane MAY provide + information on whether or not OAM entities need to be setup for the + signaled LSP. If OAM entities are created, control plane signaling + MUST also provide a means to activate/deactivate OAM message flows + and associated alarms. OAM identifiers, as well as the configuration of OAM functions, are technology specific (i.e., vary depending on the data plane technology and the chosen OAM solution). In addition, for any given data plane technology, a set of OAM solutions may be applicable. Therefore, the OAM configuration framework allows selecting a specific OAM solution to be used for the signaled LSP and provides means to carry detailed OAM configuration information in technology specific TLVs. @@ -298,44 +301,43 @@ enabled in the appropriate order. When using the GMPLS control plane, establishment and enabling of OAM functions MUST be bound to RSVP-TE message exchanges. An LSP may be signaled and established without OAM configuration first, and OAM entities may be added later with a subsequent re- signaling of the LSP. Alternatively, the LSP may be setup with OAM entities with the first signaling of the LSP. The below procedures apply to both cases. - Before the initiating a Path message with OAM Configuration - information, an initiating node MUST establish and configure the - corresponding OAM entities locally. But until the LSP is - established, OAM source functions MUST NOT start sending any OAM - messages. In the case of bidirectional connections, in addition to - the OAM source function, the initiator node MUST set up the OAM sink - function and prepare it to receive OAM messages. During this time - the OAM alarms MUST be suppressed (e.g., due to missing or - unidentified OAM messages). To achieve OAM alarm suppression, Path - message MUST be sent with the "OAM Alarms Enabled" ADMIN_STATUS flag - cleared. + Before initiating a Path message with OAM Configuration information, + an initiating node MUST establish and configure the corresponding OAM + entities locally. But until the LSP is established, OAM source + functions MUST NOT start sending any OAM messages. In the case of + bidirectional connections, in addition to the OAM source function, + the initiator node MUST set up the OAM sink function and prepare it + to receive OAM messages. During this time the OAM alarms MUST be + suppressed (e.g., due to missing or unidentified OAM messages). To + achieve OAM alarm suppression, Path message MUST be sent with the + "OAM Alarms Enabled" ADMIN_STATUS flag cleared. When the Path message arrives at the receiver, the remote end MUST establish and configure OAM entities according to the OAM information provided in the Path message. If this is not possible, a PathErr SHOULD be sent and neither the OAM entities nor the LSP SHOULD be established. If OAM entities are established successfully, the OAM sink function MUST be prepared to receive OAM messages, but MUST NOT generate any OAM alarms (e.g., due to missing or unidentified OAM messages). In the case of bidirectional connections, in addition to the OAM sink function, an OAM source function MUST be set up and, according to the requested configuration, the OAM source function MUST start sending OAM messages. Then a Resv message is sent back, - including the OAM Configuration TLV that corresponds to the actually + including the OAM Configuration TLV that corresponds to the established and configured OAM entities and functions. Depending on the OAM technology, some elements of the OAM Configuration TLV MAY be updated/changed; i.e., if the remote end is not supporting a certain OAM configuration it may suggest an alternative setting, which may or may not be accepted by the initiator of the Path message. If it is accepted, the initiator will reconfigure its OAM functions according to the information received in the Resv message. If the alternate setting is not acceptable a ResvErr may be sent tearing down the LSP. Details of this operation are technology specific and should be described in accompanying technology specific documents. @@ -437,56 +439,56 @@ attributes that do not need to be acted on by all Label Switched Routers (LSRs) along the path of the LSP. In particular, these options and attributes may apply only to key LSRs on the path such as the ingress LSR and egress LSR. Options and attributes can be signaled transparently, and only examined at those points that need to act on them. The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC5420] to provide means to signal LSP attributes and options in the form of TLVs. Options and attributes signaled in the LSP_ATTRIBUTES object can be passed transparently through LSRs not supporting a particular option or attribute, while - the contents of the LSP_REQUIRED_ATTRIBUTES object must be examined + the contents of the LSP_REQUIRED_ATTRIBUTES object MUST be examined and processed by each LSR. One TLV is defined in [RFC5420]: the Attributes Flags TLV. One bit (IANA to assign): "OAM MEP entities desired" is allocated in the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES object. If the "OAM MEP entities desired" bit is set it is indicating that the establishment of OAM MEP entities are required at the endpoints of the signaled LSP. If the establishment of MEPs is not supported - an error must be generated: "OAM Problem/MEP establishment not + an error MUST be generated: "OAM Problem/MEP establishment not supported". If the "OAM MEP entities desired" bit is set and additional parameters need to be configured, an OAM Configuration TLV MAY be - included in the LSP_ATTRIBUTES Object. + included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object. One bit (IANA to assign): "OAM MIP entities desired" is allocated in the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or - LSP_REQUIRED_ATTRIBUES objects. This bit can only be set if the "OAM - MEP entities desired" bit is set. If the "OAM MIP entities desired" - bit is set in the LSP_ATTRIBUTES Flags TLV in the + LSP_REQUIRED_ATTRIBUES objects. This bit MUST only be set if the + "OAM MEP entities desired" bit is set. If the "OAM MIP entities + desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the establishment of OAM MIP entities is required at every transit node of the signaled LSP. If the establishment of a MIP is not supported an error MUST be generated: "OAM Problem/MIP establishment not supported". 4.2. OAM Configuration TLV This TLV provides information about which OAM technology/method should be used and carries sub-TLVs for any additional OAM configuration information. The OAM Configuration TLV MAY be carried in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object, - it is indicating that intermediate nodes MUST recognize and - eventually react on the OAM configuration information. + it is indicating that intermediate nodes MUST recognize and react on + the OAM configuration information. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OAM Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ sub-TLVs ~ @@ -513,34 +515,41 @@ values in a new "RSVP-TE OAM Configuration Registry". The receiving node, based on the OAM Type, will check if a corresponding technology specific OAM configuration sub-TLV is included in the OAM Configuration TLV. If the included technology specific OAM configuration sub-TLV is different from what is specified in the OAM Type an error MUST be generated: "OAM Problem/ OAM Type Mismatch". IANA is requested to maintain the sub-TLV space in the new "RSVP-TE OAM Configuration Registry". - Note that there is a hierarchical dependency in between the OAM + Sub-TLV Type Description + ------------ ------------------------------------ + 0 Reserved + 1 OAM Function Flags Sub-TLV + 2-31 Reserved for generic Sub-TLVs + 32- Reserved for technology specific Sub-TLVs + + Note that there is a hierarchical dependency between the OAM configuration elements. First, the "OAM MEP entities desired" flag needs to be set. Only when that flag is set MAY an "OAM Configuration TLV" be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on the "OAM Type" field, it MAY carry a technology specific OAM configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP entities desired" flag is not set but an OAM Configuration TLV is present) an error MUST be generated: "OAM Problem/Configuration Error". 4.2.1. OAM Function Flags Sub-TLV - As the first sub-TLV the "OAM Function Flags sub-TLV" MUST always be + As the first sub-TLV the "OAM Function Flags Sub-TLV" MUST always be included in the "OAM Configuration TLV". "OAM Function Flags" specifies which pro-active OAM functions (e.g., connectivity monitoring, loss and delay measurement) and which fault management signals MUST be established and configured. If the selected OAM Function(s) is(are) not supported, an error MUST be generated: "OAM Problem/Unsupported OAM Function". 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -554,27 +563,27 @@ OAM Function Flags is bitmap with extensible length based on the Length field of the TLV. Bits are numbered from left to right. IANA is requested to maintain the OAM Function Flags in the new "RSVP-TE OAM Configuration Registry". This document defines the following flags. OAM Function Flag bit# Description --------------------- --------------------------- 0 Continuity Check (CC) 1 Connectivity Verification (CV) - 2 Fault Monitoring Signal (FMS) + 2 Fault Management Signal (FMS) 3 Performance Monitoring/Loss (PM/Loss) 4 Performance Monitoring/Delay (PM/Delay) 5 Performance Monitoring/Throughput Measurement (PM/Throughput) -4.2.2. Technology Specific sub-TLVs +4.2.2. Technology Specific Sub-TLVs One technology specific sub-TLV MAY be defined for each "OAM Type". This sub-TLV MUST contain any further OAM configuration information for that specific "OAM Type". The technology specific sub-TLV, when used, MUST be carried within the OAM Configuration TLV. IANA is requested to maintain the OAM technology specific sub-TLV space in the new "RSVP-TE OAM Configuration Registry". 4.3. Administrative Status Information @@ -582,71 +591,71 @@ Object. The Administrative Status Information is described in [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in [RFC3473]. Two bits are allocated for the administrative control of OAM monitoring. Two bits (IANA to assign) are allocated by this draft: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When the "OAM Flows Enabled" bit is set, OAM packets are sent; if it is cleared, no OAM packets are emitted. When the "OAM Alarms Enabled" bit is set OAM triggered alarms are enabled and associated consequent - actions are executed including the notification of the management + actions are executed including the notification to the management system. When this bit is cleared, alarms are suppressed and no action is executed and the management system is not notified. 4.4. Handling OAM Configuration Errors - To handle OAM configuration errors a new Error Code (IANA to assign) + To handle OAM configuration errors, a new Error Code (IANA to assign) "OAM Problem" is introduced. To refer to specific problems, a set of Error Values are defined under the "OAM Problem" error code. If a node does not support the establishment of OAM MEP or MIP entities it MUST use the error value: "MEP establishment not supported" or "MIP establishment not supported" respectively in the PathErr message. If a node does not support a specific OAM technology/solution it MUST use the error value: "Unsupported OAM Type" in the PathErr message. If a different technology specific OAM configuration TLV is included than what was specified in the OAM Type an error MUST be generated with error value: "OAM Type Mismatch" in the PathErr message. - There is a hierarchy in between the OAM configuration elements. If - this hierarchy is broken the error value: "Configuration Error" MUST - be used in the PathErr message. + There is a hierarchy between the OAM configuration elements. If this + hierarchy is broken, the error value: "Configuration Error" MUST be + used in the PathErr message. - If a node does not support a specific OAM Function it MUST use the + If a node does not support a specific OAM Function, it MUST use the error value: "Unsupported OAM Function" in the PathErr message. 4.5. Considerations on Point-to-Multipoint OAM Configuration RSVP-TE extensions for the establishment of point-to-multipoint (P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress LSRs, and are appropriately combined by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. One Path message may signal one or multiple S2L sub-LSPs for a single P2MP LSP. Hence, the S2L sub-LSPs belonging to a P2MP LSP can be signaled using one Path message or split across multiple Path messages. P2MP OAM mechanisms are very specific to the data plane technology, - therefore in this document we only highlight the basic principles of + therefore in this document, we only highlight the basic principles of P2MP OAM configuration. We consider only the root to leaf OAM flows, - and as such aspects of the configuration of return paths are outside + and as such, aspects of the configuration of return paths are outside the scope of our discussions. We also limit our consideration to the case where all leaves must successfully establish OAM entities with identical configuration in order the P2MP OAM is successfully established. In any case, the discussion set forth below provides - only guidelines for P2MP OAM configuration, details should be - specified in technology specific documents. + only guidelines for P2MP OAM configuration, details will be specified + in technology specific documents. The root node may use a single Path message or multiple Path messages to setup the whole P2MP tree. In the case when multiple Path messages are used, the root node is responsible to keep the OAM Configuration information consistent in each of the sent Path messages, i.e., the same information MUST be included in all Path messages used to construct the multicast tree. Each branching node will propagate the Path message downstream on each of the branches, when constructing a Path message the OAM Configuration information MUST be copied unchanged from the received Path message, including @@ -670,64 +679,88 @@ entities desired" bit cleared in the RRO Attributes sub-object. Branching nodes should collect and merge the received RROs according to the procedures described in [RFC4875]. This way, the root when receiving the Resv message (or messages if multiple Path messages were used to set up the tree) will have a clear information about which of the leaves could establish the OAM functions. If all leaves established OAM entities successfully, the root can enable the OAM message flow. On the other hand, if at some leaves the establishment was unsuccessful additional actions will be needed before the OAM message flow can be enabled. Such action could be to setup two - independent P2MP LSPs. One with OAM Configuration information + independent P2MP LSPs. One LSP with OAM Configuration information towards leaves which could successfully setup the OAM function. This can be done by pruning the leaves which failed to setup OAM of the previously signaled P2MP LSP. The other P2MP LSP could be constructed for leaves without OAM entities. The exact procedures - SHOULD be described in technology specific documents. + will be described in technology specific documents. 5. IANA Considerations Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs to be allocated in the ADMIN_STATUS Object. Two bits ("OAM MEP entities desired" and "OAM MIP entities desired") needs to be allocated in the LSP Attributes Flags Registry. This document specifies one new TLV to be carried in the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv messages: OAM Configuration TLV. One new Error Code: "OAM Problem" and a set of new values: "MEP establishment not supported", "MIP establishment not supported", - "Unsupported OAM Type", "Configuration Error" and "Unsupported OAM - Function" needs to be assigned. + "Unsupported OAM Type", "Configuration Error", "OAM Type Mismatch" + and "Unsupported OAM Function" needs to be assigned. IANA is requested to open a new registry: "RSVP-TE OAM Configuration Registry" that maintains the "OAM Type" code points, an associated sub-TLV space, and the allocations of "OAM Function Flags" within the OAM Configuration TLV. + RSVP-TE OAM Configuration Registry + + OAM Type Description + ------------ ------------------ + 0-255 Reserved + + Sub-TLV Type Description + ------------ ------------------------------------ + 0 Reserved + 1 OAM Function Flags Sub-TLV + 2-31 Reserved for generic Sub-TLVs + 32- Reserved for technology specific Sub-TLVs + + OAM Function Flag bit# Description + ---------------------- ------------------------------- + 0 Continuity Check (CC) + 1 Connectivity Verification (CV) + 2 Fault Management Signal (FMS) + 3 Performance Monitoring/Loss (PM/Loss) + 4 Performance Monitoring/Delay (PM/Delay) + 5 Performance Monitoring/Throughput Measurement + (PM/Throughput) + 6- Reserved + 6. Security Considerations The signaling of OAM related parameters and the automatic establishment of OAM entities based on RSVP-TE messages adds a new aspect to the security considerations discussed in [RFC3473]. In particular, a network element could be overloaded, if a remote attacker could request liveliness monitoring, with frequent periodic messages, for a high number of LSPs, targeting a single network element. Such an attack can efficiently be prevented when mechanisms for message integrity and node authentication are deployed. Since the OAM configuration extensions rely on the hop-by-hop exchange of exiting RSVP-TE messages, procedures specified for RSVP message security in [RFC2747] can be used to mitigate possible attacks. - For a more comprehensive discussion on GMPLS security please see the + For a more comprehensive discussion on GMPLS security, please see the Security Framework for MPLS and GMPLS Networks [RFC5920]. Cryptography can be used to protect against many attacks described in [RFC5920]. 7. Acknowledgements The authors would like to thank Francesco Fondelli, Adrian Farrel, Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful comments.