Network Working Group A. Kern Internet-Draft A. Takacs Intended status: Standards Track Ericsson Expires: May 14, 2014 November 10, 2013 GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-06 Abstract GMPLS has been extended to support connection establishment in both SONET/SDH and OTN networks. However support for the configuration of the OAM functions is not specified. Both SONET/SDH and OTN implement OAM functions to monitor the transported signals. This document defines extensions to RSVP-TE for SONET/SDH and OTN OAM configuration based on the OAM Configuration Framework defined in a separate document. This document supports, but does not modify, ITU-T OAM mechanisms. 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]. 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 May 14, 2014. Kern & Takacs Expires May 14, 2014 [Page 1] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 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 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of SONET/SDH and OTN OAM related functions . . . . . 3 2.1. Continuity supervision . . . . . . . . . . . . . . . . . 3 2.2. Connectivity supervision . . . . . . . . . . . . . . . . 3 2.2.1. SONET/SDH . . . . . . . . . . . . . . . . . . . . . . 4 2.2.2. OTN . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Signal quality supervision . . . . . . . . . . . . . . . 4 2.3.1. SONET/SDH . . . . . . . . . . . . . . . . . . . . . . 4 2.3.2. OTN . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Delay measurement . . . . . . . . . . . . . . . . . . . . 5 3. RSVP-TE signaling extensions . . . . . . . . . . . . . . . . 5 3.1. Operation overview . . . . . . . . . . . . . . . . . . . 5 3.1.1. Continuity Check supervision . . . . . . . . . . . . 6 3.1.2. Connectivity Monitoring supervision . . . . . . . . . 6 3.1.2.1. SDH/SONET . . . . . . . . . . . . . . . . . . . . 6 3.1.2.2. OTN . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Signal quality supervision . . . . . . . . . . . . . 7 3.2. Signaling support of Virtual Concatenation Groups (VCG) . 8 3.3. OAM types and functions . . . . . . . . . . . . . . . . . 8 3.4. SONET/SDH OAM Configuration Sub-TLV . . . . . . . . . . . 9 3.5. OTN OAM Configuration Sub-TLV . . . . . . . . . . . . . . 9 3.6. SDH TTI Configuration Sub-TLV . . . . . . . . . . . . . . 9 3.7. OTN TTI Configuration Sub-TLV . . . . . . . . . . . . . . 10 3.8. Degraded Signal Thresholds Sub-TLV . . . . . . . . . . . 12 4. Error handling . . . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 15 Kern & Takacs Expires May 14, 2014 [Page 2] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction Both SONET/SDH and OTN implement OAM functions to monitor the transported signals. Supervision functions include continuity, connectivity, signal quality, alignment and payload supervision. The ITU-T G.806 [G.806] recommendation defines the generic framework of the supervision functions, which are then further specified for SONET /SDH and OTN in technology specific documents. GMPLS has been extended to support connection establishment in SONET/ SDH [RFC4606], and in OTN [RFC4328] [RFC6344] networks. These documents however do not support the configuration of the respective OAM supervision functions. [I-D.ietf-ccamp-oam-configuration-fwk] defines a technology-agnostic framework for GMPLS to support the establishment and configuration of the pro-active OAM functions of signaled connections. The properties of the OAM functions are exchanged during connection establishment and may be modified during the life of the connection. The technology specific parameters to be exchanged are to be described in accompanying documents. This document defines the extensions for SONET/SDH and OTN OAM configuration for end-to-end monitoring. 2. Overview of SONET/SDH and OTN OAM related functions SONET/SDH [G.707] and OTN [G.709] provide a variety of supervision functions. Among these functions we consider continuity, connectivity and signal quality supervision functions, as these are the candidates for GMPLS based configuration. We also consider delay measurement functionality for OTN. The reader should refer to the ITU-T documents for additional information. Familiarity with GMPLS, SONET/SDH and OTN terminology is assumed. 2.1. Continuity supervision Continuity supervision provides methods for monitoring the health of a connection (trail). 2.2. Connectivity supervision The connectivity supervision function provides a method to detect misconnections. The detection procedure is based on a Trace Trail Identifier (TTI) known by both endpoints. The TTI is included by the source node as an overhead signal for each connection. The receiver node then compares the received TTI with the expected value and determines if a mis-connection occurred. Kern & Takacs Expires May 14, 2014 [Page 3] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 2.2.1. SONET/SDH In case of SONET/SDH, connectivity supervision is implemented in the Regeneration Section (RS) and in the lower and higher order path layers (LOVC and HOVC). In all layers the TTI encodes only the Access Point Identifier (API) of the source node. In the various layers, the lengths of these TTIs are different. In RS, the TTI (encoded in J0 byte) is either 1 or 16 bytes long. In higher order paths the TTI (encoded in J1), is either 16 or 64 bytes long. In lower order paths, the TTI is transmitted in the J2 byte and is 16 bytes long. 2.2.2. OTN In case of OTN, connectivity supervision is supported by the OTUk and ODUk digital hierarchy layers. In both layers, the length of the TTI is 64 bytes, but only the first 32 bytes are considered for connectivity supervision. This first part is further divided into a Source Access Point Identifier (SAPI) and a Destination Access Point Identifier (DAPI). Connectivity supervision may consider either the SAPI or DAPI only or both. The structure of the SAPI and DAPI is specified in [G.709]. 2.3. Signal quality supervision The quality of the transmitted signal is monitored as a ratio of bad frames. If the number of such frames reaches a threshold, a defect state is declared. To detect the correctness of the frames, an Error Detection Code (EDC), such as Bit Interleaved Parity (BIP), is used. The distribution of the errors is assumed to follow either Poisson or a bursty distribution. For Poisson distribution, an EDC violation ratio is defined as the threshold; while for the bursty model, the threshold is defined as a number of consecutive 1-second time intervals in which the EDC violation exceeds a predefined ratio. In case of Poisson error distribution, two defect state levels are defined: the Excessive Error and Degraded Signal defect. In the case of the bursty model, only the Degraded Signal defect level is considered. 2.3.1. SONET/SDH SONET/SDH supports both Excessive Error and Degraded Signal defect levels and supports both Poisson and bursty error distribution models. These signal quality parameters are configured for the Multiplexing Section (MS) and the LOVC and HOVC path layers. 2.3.2. OTN Kern & Takacs Expires May 14, 2014 [Page 4] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 For OTN, in the digital transport layers (OTUk and ODUk), only the bursty error distribution model with the Degraded Signal defect level is supported. Two parameters are defined: Ratio of the bad frames in a one second interval (0% to 100% or 0 to number of frames per 1-second interval) and Number of consecutive intervals (between 2 and 10). Signal quality supervision in the optical transport layers is not specified by [G.798], it is indicated to be for further study. 2.4. Delay measurement [G.709] introduced a tool for measuring round-trip delay of a bidirectional ODU path or tandem connection. For implementing delay measurement, a one-bit delay measurement (DM) signal is defined in the ODUk header. That signal bit is a constant value (either 0 or 1). One endpoint initiates a delay measurement by inverting the bit emitted in the DM signal. The remote endpoint loops back the DM signal; therefore, the delay measurement initiating node will receive the inverted signal from the remote endpoint. This way the initiating endpoint will determine the round trip delay. 3. RSVP-TE signaling extensions 3.1. Operation overview RFC 4328, RFC 4606 and RFC6344 defined the GMPLS RSVP-TE extensions necessary to manage SONET/SDH and OTN optical and digital hierarchy connections. The monitoring functions associated to these connections MAY be configured when configuring the connections. The LSP Attribute Flag "OAM MEP entities desired" [I-D.ietf-ccamp-oam-configuration-fwk] MUST be used to signal that the monitoring functions at the endpoints MUST be established. The "OAM MIP entities desired" flag MUST be set to 0 and MUST be ignored. To configure OAM parameters, the OAM Configuration TLV MAY be included in the LSP_ATTRIBUTES object. The TLV identifies which OAM technology ("OAM Type" field) to be used as well as which OAM functions are to be enabled (OAM Function Flags Sub-TLV). For SONET/ SDH and OTN, the "Continuity Check" and "Connectivity Verification" flags control the Continuity and Connectivity supervision functions, while the "Performance Monitoring/Loss" flag enables the Signal Quality supervision function. The recent revision of OTN [G.709] introduced delay measurement capability for paths. A node MAY enable delay measurement by setting the "Performance Monitoring/Delay" flag. By setting that flag, the node also indicates that it will initiate the delay measurement; therefore, the remote endpoint node SHOULD NOT initiate delay Kern & Takacs Expires May 14, 2014 [Page 5] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 measurement over the configured connection. Equipment designed to earlier versions of G709 MUST clear the "Performance Monitoring/Loss" flag and upon receiving an OAM configuration message with "Performance Monitoring/Delay" flag set MUST generate "OAM Problem/ Unsupported OAM Function" error. The "Performance Monitoring/Delay" flag MUST be cleared for SONET/SDH as it is not supported by SONET/ SDH. For additional details, the appropriate technology specific sub-TLV MAY be carried in the OAM Configuration TLV. 3.1.1. Continuity Check supervision In case of both SONET/SDN and OTN technologies, setting up the continuity supervision function for a connection does not need further configuration besides enabling it. Therefore, by setting the "Connectivity Monitoring" Flag of OAM Function implicitly enables the continuity supervision function as well. 3.1.2. Connectivity Monitoring supervision 3.1.2.1. SDH/SONET [G.707] defines three TTI overhead bytes (signals) for connectivity supervision: the J0 byte in RS layer, the J1 byte in the HOVC layer and the J2 byte in the LOVC layer. The source node transmits the TTI and the destination node matches it with the expected one. When the destination detects mismatch, a defect state will be declared. Since these bytes encode a TTI identifier defined for the source node, different stream will be emitted in the upstream and downstream directions for bidirectional connections. During the configuration the downstream (destination) node has to be configured with the TTI value to be expected in the downstream direction and the TTI value to be emitted in the upstream direction. Therefore, the SONET/SDH OAM Configuration TLV carries two Connectivity Supervision TLVs. 3.1.2.2. OTN [G.709] defines a 64 byte long TTI format, where the first 32 bytes have a generic structure: a zero byte, a 15 bytes long SAPI, a second zero byte and finally the 15 bytes long DAPI format. For a unidirectional connection, a single Connection Supervision TLV encodes elements of the TTI to be emitted. This TLV also specifies which parts of the TTI are compared to the expected values (only SAPI, only DAPI, both SAPI and DAPI). Kern & Takacs Expires May 14, 2014 [Page 6] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 In case of a bidirectional connection an endpoint can use a common API value for SAPI (for transmitted signal) and DAPI (for received signal). (See Figure 1.) The TTI values used in downstream and upstream directions are derived from the two API values: the downstream TTI will have the form of [0, API_a, 0, API_z] while the upstream TTI will use the form of [0, API_z, 0 API_a]. Ingress Node Egress Node ( API_a ) TTI_upstream = [0, API_z, 0, API_a ] ( API_z ) | Rx port | -- < -- < -- < -- < -- < -- < -- < -- < -- | Tx Port | | Tx port | -- > -- > -- > -- > -- > -- > -- > -- > -- | Rx Port | TTI_downstream = [0, API_a, 0, API_z ] Figure 1: TTI construction when a single API identifies the receiver and transmitter interfaces Then, a single Connectivity Supervision TLV is defined. The SAPI field carries the API of the ingress node (API_a) that initiates the signaling, while the DAPI carries the API of the egress node (API_z). On the other hand, it is possible that the endpoints use different values as SAPI and DAPI to identify the transmitter and receiver ports of a bidirectional connection (See Figure 2). In this case the TTIs to be used in the two directions are independent, thus, they must be explicitly configured. Therefore, two Connectivity Supervision TLVs are added to the OTN OAM Configuration TLV. Each TLV encodes whether it defines the downstream or the upstream TTI. Ingress Node Egress Node ( API_a1 ) TTI_upstream = [0, API_z1, 0, API_a1 ] ( API_z1 ) | Rx port | -- < -- < -- < -- < -- < -- < -- < -- < -- | Tx Port | | Tx port | -- > -- > -- > -- > -- > -- > -- > -- > -- | Rx Port | ( API_a2 ) TTI_downstream = [0, API_a2, 0, API_z2 ] ( API_z2 ) Figure 2: TTI construction when dedicated APIs identify the receiver and transmitter interfaces 3.1.3. Signal quality supervision Signal quality supervision function is implemented in the MS, HOVC, LOVC layers of SONET/SDH. All three layers support exceeded error level with Poisson error distribution model and degraded signal defect level with both of the Poisson and bursty error distribution models. Dedicated Signal quality supervision TLVs encode each level, therefore when the "Performance Monitoring/Loss" flag is set; several such TLVs MAY be added to the SONET/SDH OAM Configuration TLV. If a configuration TLV for a particular level is missing, the default parameters for that level SHOULD be applied. Kern & Takacs Expires May 14, 2014 [Page 7] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 OTN supports only Degraded Signal defect with bursty error model in OTUk and ODUk layers. Thus, the only parameters to be encoded are: the threshold for bad frames in a 1-second interval and the number of consecutive 1-second intervals with excessive bad frames. Furthermore, as only one level is allowed, a single Signal quality supervision TLV MAY be added to the OTN OAM Configuration TLV. 3.2. Signaling support of Virtual Concatenation Groups (VCG) A capability of both SONET/SDH and OTN is the support of virtual concatenation. This inverse multiplexing method uses multiplicity of parallel individual signals. The supervision function parameters of these basic signals can be different. [RFC6344] describes GMPLS signaling capabilities to support virtual concatenation. A Virtual Concatenated Group (VCG) is constructed from several individual data plane signals. The co-routed signals of a VCG may be provisioned together using a single RSVP-TE session (co- signaled). As different OAM configuration may be applied to each of these individual signals, the OAM configuration extension is applied as follows. We assume that the same OAM type and the same set of OAM functions apply to each individual signal of the VCG. A single OAM Configuration TLV MUST be carried in the LSP_ATTRIBUTES Object, while multiple instances of technology specific OAM configuration sub-TLVs MAY be added: one instance per individual signal. The order of these TLVs references the logical order of the individual signals (as they are listed in the Label Object). [RFC6344] allows extension/pruning of a VCG. To achieve it, the traffic descriptor, which encodes how the VCG is structured, in the RSVP-TE session is updated. If the VCG is updated, the contents of the OAM Configuration TLV MUST be updated accordingly. 3.3. OAM types and functions This document defines two new code points for the "OAM Type" field of the OAM Configuration TLV, defined in [I-D.ietf-ccamp-oam-configuration-fwk]: SONET/SDH OAM and OTN Digital Hierarchy OAM. The "OAM Function Flags Sub-TLV" is defined in [I-D.ietf-ccamp-oam-configuration-fwk]. SONET/SDH and OTN supervision functions are defined in this document for the following flags: "Continuity Check", "Connectivity Verification", "Performance Monitoring/Loss" and "Performance Monitoring/Delay". Kern & Takacs Expires May 14, 2014 [Page 8] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 3.4. SONET/SDH OAM Configuration Sub-TLV SONET/SDH OAM Configuration Sub-TLV is defined to encode the parameters of continuity, connectivity and signal quality supervision functions for SONET/SDH networks. 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 (34) (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ sub TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: indicates a new type: the SONET/SDH OAM Configuration TLV (IANA to define). Length: indicates the total length including sub-TLVs 3.5. OTN OAM Configuration Sub-TLV OTN OAM Configuration TLV is defined to encode the parameters of continuity, connectivity and signal quality supervision functions for OTN. 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 (35) (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ sub TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: indicates a new type: the OTN OAM Configuration TLV (IANA to define). Length: indicates the total length including sub-TLVs 3.6. SDH TTI Configuration Sub-TLV Kern & Takacs Expires May 14, 2014 [Page 9] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 This sub-TLV is carried in the SONET/SDH OAM Configuration Sub-TLV, if the Connectivity Verification OAM Function Flag is set. In each supporting layer, the TTI identifies the source interface (SAPI); however, the length of this identifier varies layer-by-layer (see Section 2.2.1). Therefore, a generic TLV is defined supporting various TTI lengths. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|U| Reserved | TTI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TTI cont ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flag "A", when set enables the AIS insertion when detecting a TTI mismatch. Flag "U" encodes if the TTI refers to the downstream node's source TTI (U=0) or the upstream node's TTI (U=1) (expected TTI). The TTI field carries the TTI to be transmitted by the source node and to be expected by the sink. The TLV is padded to 4 bytes. If the specified length and format of the TTI carried in this TLV is not supported by the referenced SONET/SDH layer, an error must be generated: "OAM Problem/TTI Length Mismatch". 3.7. OTN TTI Configuration Sub-TLV This sub-TLV is carried in the OTN OAM Configuration Sub-TLV, if the Connectivity Verification OAM Function Flag is set. 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 = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|S|D|APP| Reserved | SAPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAPI cont | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAPI cont | Kern & Takacs Expires May 14, 2014 [Page 10] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAPI cont | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAPI | DAPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DAPI cont | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DAPI cont | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DAPI cont | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Three control flags are defined. Flag "A" indicates that AIS insertion when detecting a TTI mismatch (failing the connectivity verification) is required (A=1) or not (A=0). The next two flags define which parts of the received TTI are compared to the expected one. If flag "S" is set, the TTI bytes 1 to 15 are matched to the expected SAPI value. If the flag "D" is set, the TTI bytes 17 to 31 are matched to the expected DAPI value. If both "S" and "D" are set, both parts of TTI are compared to SAPI and DAPI values. Setting both "S" and "D" bits to 0 is invalid, and if encountered, an error must be generated: "OAM Problem/Invalid CC/CV configuration". The next two bits "APP" encode the applicability of the TTI configuration and the following code points are defined: 0 - Single TTI configuration: the TTI configuration is done according only to this TLV and no further TTI configuration TLVs are expected. This code point is used for unidirectional connections and for bidirectional connections with common APIs (See Figure 1) 1 - Downstream TTI for double TTI configuration: the current TLV instructs the configuration of the TTI to be used in downstream direction (See Figure 2). 2 - Upstream TTI for double TTI configuration: the current TLV instructs the configuration of the TTI to be used in upstream direction (See Figure 2). 3 - Invalid. If the APP is set to 1 and the next or the previous sub-TLV is not an OTN TTI Configuration TLV with APP code point 2, then an error must be generated "OAM Problem/Invalid OTN TTI Configuration - Missing Upstream TTI configuration". Kern & Takacs Expires May 14, 2014 [Page 11] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 If the APP is set to 2 and the next or the previous sub-TLV is not an OTN TTI Configuration TLV with APP code point 1, then an error must be generated "OAM Problem/Invalid OTN TTI Configuration - Missing Downstream TTI configuration". If the APP is set to either 1 or 2 and the unidirectional LSP is signaled (no UPSTREAM_LABEL is added to the message) or the APP is set to 3, an error must be generated "OAM Problem/Invalid OTN TTI Configuration - Invalid applicability code". 3.8. Degraded Signal Thresholds Sub-TLV The Degraded Signal Thresholds Sub-TLV instructs the configuration of the signal quality supervision function. This sub-TLV is applicable in both SONET/SDH and OTN cases. This sub-TLV can be carried in both the SONET/SDH OAM Configuration Sub-TLV or OTN OAM Configuration Sub- TLV, if the PerformanceMonitoring/Loss OAM Function Flag is set. 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 = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B|L| Reserved | DEG_THR | DEG_M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Two flags are defined to encode the signal quality measurement. The bit "B" encodes if distribution of errors is either Poisson (B=0) or Bursty (B=1). In case of Poisson distribution of errors, two levels of defects are defined and encoded with bit "L": excessive error (L=0) and degraded signal (L=1). Since in case of Bursty distribution of errors, only degraded signal defect is to be detected, therefore, in this latter case (B=1), the "L" bit must be set. Otherwise, an error must be generated: "OAM Problem/Invalid Performance Monitoring/Loss configuration". The field "DEG_THR" defines the threshold for the bad frames (BIP-8 violations) in both Poisson and bursty distributions of errors. In the first case (B=0), this field encodes the quotient of the threshold 10e-X. The possible values for excessive error are 3,4 and 5, while for degraded signal defect, the values are 6,7,8 and 9. In the second case (B=1), it encodes the ratio of the bad frames in a 1-second period and can be set between 0 and 100, interpreted as ratios in percentage. Kern & Takacs Expires May 14, 2014 [Page 12] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 The field "DEG_M" defines the monitoring time-frame in 1 second periods assuming bursty distribution of errors. The valid values are 2 to 10 periods. 4. Error handling In addition to error values specified in [I-D.ietf-ccamp-oam-configuration-fwk] this document defines the following values for the "OAM Problem" Error Code. If in the OTN TTI Configuration Sub-TLV both the "S" and "D" bits are set to 0, an error must be generated: "OAM Problem/Invalid CC/CV Configuration". If the specified length and format of the TTI carried in the SONET/ SDH TTI Configuration Sub-TLV is not supported by the SONET/SDH layer, an error must be generated: "OAM Problem/TTI Length Mismatch" If in the OTN TTI Configuration Sub-TLV the "APP" field is set to 1 and the next or the previous sub-TLV is not an OTN TTI Configuration TLV with "APP" code point 2, then an error must be generated "OAM Problem/Invalid OTN TTI Configuration - Missing Upstream TTI Configuration". If in the OTN TTI Configuration Sub-TLV the "APP" field is set to 2 and the next or the previous sub-TLV is not an OTN TTI Configuration TLV with APP code point 1, then an error must be generated "OAM Problem/Invalid OTN TTI Configuration - Missing Downstream TTI Configuration". If in the OTN TTI Configuration Sub-TLV the "APP" field is set to either 1 or 2 and an unidirectional LSP is signaled (no UPSTREAM_LABEL) or the "APP" field is set to 3, an error must be generated "OAM Problem/Invalid OTN TTI Configuration - Invalid Applicability Code". If flag "B" in Degraded Signal Thresholds Sub-TLV is set to 1 and flag "L" in the same sub-TLV is set to 0, an error must be generated "OAM Problem/Invalid Performance Monitoring/Loss Configuration". 5. IANA Considerations This document specifies two new sub-TLVs to be carried in the OAM Configuration TLV in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Objects in Path and Resv messages. The document defines two new values of the "OAM Type" field of the OAM Configuration TLV. IANA is requested to make the following assignments in the RSVP-TE OAM Configuration Registry. Kern & Takacs Expires May 14, 2014 [Page 13] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 RSVP-TE OAM Configuration Registry OAM Type Description ------------------- ----------------------------------- 3 SONET/SDH OAM 4 OTN Digital Hierarchy OAM Sub-TLV Type Description ------------------- ----------------------------------- 34 SONET/SDH OAM Configuration Sub-TLV 35 OTN OAM Configuration Sub-TLV IANA is requested to maintain the SONET/SDH and OTN TLV Type space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the SONET/SDH and OTN OAM Configuration Sub-TLVs. This document defines the following types. SONET/SDH and OTN TLV Type Description -------------------------- -------------------------------- 0 Reserved 1 SONET/SDH TTI Configuration Sub-TLV 2 OTN TTI Configuration Sub-TLV 3 Degraded Signal Thresholds Sub-TLV IANA is requested to assigne the following error values under the "OAM Problem" error code: "TTI Length Mismatch", "Invalid CC/CV Configuration", "Invalid OTN TTI Configuration - Missing Upstream TTI Configuration", "Invalid OTN TTI Configuration - Missing Downstream TTI Configuration", "Invalid OTN TTI Configuration - Invalid Applicability Code", "Invalid Performance Monitoring/Loss Configuration". 6. Security Considerations Security aspects are addressed in the OAM configuration framework document [I-D.ietf-ccamp-oam-configuration-fwk]. This document does not introduce any additional security issues to those discussed in [I-D.ietf-ccamp-oam-configuration-fwk] and the SONET/SDH and OTN technology-specific RFCs. 7. Acknowledgements Kern & Takacs Expires May 14, 2014 [Page 14] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 The authors would like to thank Francesco Fondelli for his useful comments. 8. References 8.1. Normative References [I-D.ietf-ccamp-oam-configuration-fwk] Takacs, A., Fedyk, D., and H. Jia, "GMPLS RSVP-TE extensions for OAM Configuration", draft-ietf-ccamp-oam- configuration-fwk-10 (work in progress), June 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [G.707] International Telecommunications Union, "Network node interface for the synchronous digital hierarchy (SDH)", ITU-T Recommendation G.707, 2007. [G.709] International Telecommunications Union, "Interfaces for the Optical Transport Network (OTN)", ITU-T Recommendation G.709, 2012. [G.798] International Telecommunications Union, "Characteristics of optical transport network hierarchy equipment functional blocks ", ITU-T Recommendation G.798, 2006. [G.806] International Telecommunications Union, "Characteristics of transport equipment - Description methodology and generic functionality", ITU-T Recommendation G.806, 2009. [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006. [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006. [RFC6344] Bernstein, G., Caviglia, D., Rabbat, R., and H. van Helvoort, "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", RFC 6344, August 2011. Kern & Takacs Expires May 14, 2014 [Page 15] Internet-Draft GMPLS Based OTN and SDH OAM Configuration November 2013 Authors' Addresses Andras Kern Ericsson Laborc u. 1. Budapest 1037 Hungary Email: andras.kern@ericsson.com Attila Takacs Ericsson Laborc u. 1. Budapest 1037 Hungary Email: attila.takacs@ericsson.com Kern & Takacs Expires May 14, 2014 [Page 16]