--- 1/draft-ietf-ccamp-oam-configuration-fwk-12.txt 2014-02-25 10:14:39.798353095 -0800 +++ 2/draft-ietf-ccamp-oam-configuration-fwk-13.txt 2014-02-25 10:14:39.850354362 -0800 @@ -1,36 +1,34 @@ Network Working Group A. Takacs Internet-Draft Ericsson Intended status: Standards Track D. Fedyk -Expires: July 16, 2014 Alcatel-Lucent +Expires: August 29, 2014 Hewlett-Packard Company J. He Huawei - January 12, 2014 + February 25, 2014 GMPLS RSVP-TE extensions for OAM Configuration - draft-ietf-ccamp-oam-configuration-fwk-12 + draft-ietf-ccamp-oam-configuration-fwk-13 Abstract - Operations, Administration and Maintenance is an integral part of - transport connections, hence it is required that Operations, - Administration and Maintenance functions are activated/deactivated in - sync with connection commissioning/decommissioning; avoiding spurious - alarms and ensuring consistent operation. In certain technologies, - Operations, Administration and Maintenance entities are inherently + Operations, Administration and Maintenance (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 Operations, - Administration and Maintenance entities. This document specifies - extensions to RSVP-TE to support the establishment and configuration - of Operations, Administration and Maintenance entities along with - Label Switched Path signaling. + require extra configuration to establish and configure OAM entities. + This document specifies extensions to RSVP-TE to support the + establishment and configuration of OAM entities along with Label + Switched Path signaling. 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 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -38,21 +36,22 @@ 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 16, 2014. + + This Internet-Draft will expire on August 29, 2014. Copyright Notice Copyright (c) 2014 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 @@ -81,40 +80,40 @@ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5.1. ADMIN_STATUS Object Bit Flags . . . . . . . . . . . . . . 17 5.2. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 17 5.3. New LSP Attributes . . . . . . . . . . . . . . . . . . . 18 5.4. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 18 5.5. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 19 5.5.1. OAM Types Sub-Registry . . . . . . . . . . . . . . . 19 5.5.2. OAM Sub-TLVs Sub-Registry . . . . . . . . . . . . . . 19 5.5.3. OAM Function Flags Sub-Registry . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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 - Maintenance (OAM) functions employed to monitor the health and - performance of the connections and to trigger data plane (DP) - recovery mechanisms. Similar to connection provisioning, OAM - functions follow general principles, but also have some technology - specific characteristics. + port or fiber), wavelength-division multiplexing (e.g., Dense + Wavelength Division Multiplexing (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 Maintenance + (OAM) functions employed to monitor the health and performance of the + connections and to trigger data plane (DP) recovery mechanisms. + Similar to connection provisioning, OAM functions follow general + principles, but also have some technology specific characteristics. OAM is an integral part of transport connections. Therefore 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. In some situations the use of OAM functions, such as Fault Management (FM) and Performance Management (PM), may be optional (based on network management policies). Hence, the network @@ -132,36 +131,36 @@ 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. 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. - + control via Resource Reservation Protocol - Traffic Engineering + (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. - Configuration of OAM entities for LSP segments and tandem connections - are out of the scope of this document. + setup of OAM entities bound to an end-to-end Label-Switched Path + (LSP), and configuration and control of OAM functions running end-to- + end in the LSP. Configuration of OAM entities for LSP segments and + tandem connections are out of the scope of this document. The mechanisms described in this document provide an additional option for bootstrapping OAM that is not intended to replace or deprecate the use of other technology specific OAM bootstrapping techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The procedures specified in this document are intended only for use in environments where RSVP-TE signaling is used to set up the LSPs that are to be monitored using OAM. 2. Requirements @@ -217,25 +216,27 @@ used to track the liveliness of PBB-TE connections and detect data plane failures. In the IETF, the GMPLS controlled Ethernet Label Switching (GELS) (see [RFC5828] and [RFC6060]) work extended the GMPLS control plane to support the establishment of PBB-TE data plane connections. Without control plane support separate management commands would be needed to configure and start CFM. GMPLS based OAM configuration and control needs to provide a general framework to be applicable to a wide range of data plane technologies and OAM solutions. There are three typical data plane technologies - used for transport applications: wavelength based such as WSON, TDM - based such as SDH/SONET, and packet based such as MPLS-TP [RFC5921] - and Ethernet PBB-TE [IEEE.802.1Q-2011]. For all these data planes, - the operator MUST be able to configure and control the following OAM - functions: + used for transport applications: wavelength based such as Wavelength + Switched Optical Networks (WSON), Time-Division Multiplexing (TDM) + based such as Synchronous Digital Hierarchy (SDH) and Synchronous + Optical Networking (SONET), and packet based such as MPLS-TP + [RFC5921] and Ethernet PBB-TE [IEEE.802.1Q-2011]. For all these data + planes, the operator MUST be able to configure and control the + following OAM functions: o It MUST be possible to explicitly request the setup of OAM entities for the signaled LSP and provide specific information for the setup if this is required by the technology. o Control of alarms is important to avoid false alarm indications and reporting to the management system. It MUST be possible to enable/disable alarms generated by OAM functions. In some cases, selective alarm control may be desirable when, for instance, the operator is only concerned about critical alarms. Therefore the @@ -355,41 +356,42 @@ 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 MUST be sent - back, including the LSP_Attributes Flags TLV, with the appropriate - setting of the "OAM MEP entities desired" and "OAM MIP entities - desired" flags, and 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 + message 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 MUST be sent back, including the + LSP_Attributes Flags TLV, with the appropriate setting of the "OAM + MEP entities desired" and "OAM MIP entities desired" flags, and 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. + setting is not acceptable a ResvErr message MAY be sent tearing down + the LSP. Details of this operation are technology specific and + should be described in accompanying technology specific documents. When the initiating side receives the Resv message, it completes any pending OAM configuration and enables the OAM source function to send OAM messages. After this exchange, OAM entities are established and configured for the LSP and OAM messages are exchanged. OAM alarms can now be enabled. The initiator, during the period when OAM alarms are disabled, sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS flag set. The receiving node enables the OAM alarms after processing @@ -579,20 +581,23 @@ support a specific OAM Type MUST respond with an error indicating "OAM Problem/Unsupported OAM Type". OAM Type Description ------------ -------------------- 0-255 Reserved This document defines no types. IANA is requested to maintain the values in a new "RSVP-TE OAM Configuration Registry". + Length: indicates the total length of the TLV in octets. The TLV + MUST be zero-padded so that the TLV is four octet aligned. + Two groups of TLVs are defined: generic sub-TLVs and technology specific sub-TLVs. Generic sub-TLVs carry information that are applicable independent of the actual OAM technology, while technology specific sub-TLVs are providing configuration parameters for specific OAM technologies. This document defines one generic sub-TLV, see Section 4.2.1, while it is foreseen that technology specific sub-TLVs will be defined by separate documents. The receiving node, based on the OAM Type, will check if a corresponding technology specific OAM configuration sub-TLV is @@ -662,23 +667,22 @@ If technology-specific configuration information is needed for a specific "OAM Type", then this information is carried in a technology-specific sub-TLV. Such sub-TLVs are OPTIONAL and an OAM Configuration TLV MUST NOT contain more than one technology- specific sub-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 Administrative Status Information is carried in the ADMIN_STATUS - Object. The Administrative Status Information is described in - [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in - [RFC3473]. + Object, which is specified for RSVP-TE in [RFC3473]. The + Administrative Status Information is described in [RFC3471]. Two bits are allocated for the administrative control of OAM monitoring. Two bits (IANA to assign) are allocated by this document: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST be enabled; if it is cleared, OAM mechanisms MUST be disabled. When the "OAM Alarms Enabled" bit is set OAM triggered alarms are enabled and associated consequent actions MUST be executed including the notification to the management system. When this bit is cleared, alarms are suppressed and no action SHOULD be executed and the @@ -834,71 +838,75 @@ Error Code | Meaning | Reference -----------+-------------+------------- TBA | OAM Problem | [This.ID] The value is to be selected from the range 0-239. The following Error Value sub-codes are defined for this new Error Code as follows: Value | Description | Reference - ------+---------------------------------+-------------- + --------+---------------------------------+-------------- + 0 | Reserved | [This.ID] 1 | MEP establishment not supported | [This.ID] 2 | MIP establishment not supported | [This.ID] 3 | Unsupported OAM Type | [This.ID] 4 | Configuration Error | [This.ID] 5 | OAM Type Mismatch | [This.ID] 6 | Unsupported OAM Function | [This.ID] + 7-32767 | Unassigned | + 32768-65535| Reserved for Private Use | [This.ID] 5.5. RSVP-TE OAM Configuration Registry IANA is requested to create a new registry called "RSVP-TE OAM Configuration Registry". IANA is requested to create sub-registries as defined in the - following subsections: + following subsections. The registration procedures specified are as + defined in [RFC5226]. 5.5.1. OAM Types Sub-Registry IANA is requested to create the "OAM Types" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows: Range | Registration Procedures -------+------------------------- 0-255 | IETF Review There are no initial values in this registry. IANA should show the registry as follows: OAM Type Number | OAM Type Description | Reference ----------------+----------------------+-------------- - 0-255 | Not allocated | + 0-255 | Unassigned | 5.5.2. OAM Sub-TLVs Sub-Registry IANA is requested to create the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows: Range | Purpose | Registration Procedures ------------+------------------------------|------------------------ 0-31 | Generic Sub-TLVs | IETF Review 32-65534 | Technology-specific Sub-TLVs | IETF Review 65535-65536 | Experimental Sub-TLVs | Experimental IANA is requested to populate the registry as follows: Sub-TLV Type | Description | Reference -------------+----------------------------+------- 0 | Reserved | [This.ID] 1 | OAM Function Flags Sub-TLV | [This.ID] - 2-31 | Not allocated | - 32-65534 | Not allocated | + 2-31 | Unassigned | + 32-65534 | Unassigned | 5.5.3. OAM Function Flags Sub-Registry IANA is requested to create the "OAM Function Flags Sub-Registry" sub-registry of the "RSVP-TE OAM Configuration Registry". New values in the registry are allocated by "IETF Review". There is no top value to the range. Bits are counted from bit 0 as the first bit transmitted. @@ -907,21 +915,21 @@ OAM Function Flag | Description bit number | ------------------+--------------------------------------------- 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-... | Not allocated + 6-... | Unassigned 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 @@ -948,20 +956,24 @@ Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009. 8.2. Informative References [IEEE.802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual @@ -1011,22 +1023,22 @@ Authors' Addresses Attila Takacs Ericsson Konyves Kalman krt. 11. Budapest 1097 Hungary Email: attila.takacs@ericsson.com - Don Fedyk - Alcatel-Lucent - Groton, MA 01450 + Hewlett-Packard Company + 153 Taylor Street + Littleton, MA 01460 USA - Email: don.fedyk@gmail.com + Email: don.fedyk@hp.com Jia He Huawei Email: hejia@huawei.com