Network Working Group                                            A. Kern
Internet-Draft                                                 A. Takacs
Intended status: Standards Track                                Ericsson
Expires: March May 14, 2014                                  November 10, 2013                                       September 2012

    GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration
              draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05
              draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-06

Abstract

   GMPLS has been extended to support connection establishment in both
   SONET/SDH [RFC4606] and OTN [RFC4328] networks.  However support for the configuration of
   the supervision OAM functions is not specified.  Both SONET/SDH and OTN implement supervision
   OAM functions to qualify 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 [GMPLS-OAM-FWK]. 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 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 March 2013. May 14, 2014.

Copyright Notice

   Copyright (c) 2012 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  . . . . . . . . . . . . . . . . . . . . . . . . .  4   3
   2.  Overview of SONET/SDH and OTN OAM related functions . . . . .  5   3
     2.1.  Continuity supervision  . . . . . . . . . . . . . . . . . .  5   3
     2.2.  Connectivity supervision  . . . . . . . . . . . . . . . . .  5   3
       2.2.1.  SONET/SDH . . . . . . . . . . . . . . . . . . . . . .  5   4
       2.2.2.  OTN . . . . . . . . . . . . . . . . . . . . . . . . .  5   4
     2.3.  Signal quality supervision  . . . . . . . . . . . . . . . .  6   4
       2.3.1.  SONET/SDH . . . . . . . . . . . . . . . . . . . . . .  6   4
       2.3.2.  OTN . . . . . . . . . . . . . . . . . . . . . . . . .  6   4
     2.4.  Delay measurement . . . . . . . . . . . . . . . . . . . .  6   5
   3.  RSVP-TE signaling extensions  . . . . . . . . . . . . . . . . .  7   5
     3.1.  Operation overview  . . . . . . . . . . . . . . . . . . . .  7   5
       3.1.1.  Continuity Check supervision  . . . . . . . . . . . . .  7   6
       3.1.2.  Connectivity Monitoring supervision . . . . . . . . .  8   6
         3.1.2.1.  SDH/SONET . . . . . . . . . . . . . . . . . . . .  8   6
         3.1.2.2.  OTN . . . . . . . . . . . . . . . . . . . . . . .  8   6
       3.1.3.  Signal quality supervision  . . . . . . . . . . . . . .  9   7
     3.2.  Signaling support of Virtual Concatenation Groups (VCG) .  9   8
     3.3.  OAM types and functions . . . . . . . . . . . . . . . . . 10   8
     3.4.  SONET/SDH OAM Configuration sub-TLV Sub-TLV . . . . . . . . . . . 10   9
     3.5.  OTN OAM Configuration sub-TLV Sub-TLV . . . . . . . . . . . . . . 11   9
     3.6.  SDH TTI Configuration Sub-TLV . . . . . . . . . . . . . . . . 11
       3.6.1.  SDH   9
     3.7.  OTN TTI Configuration Sub-TLV . . . . . . . . . . . . 11
       3.6.2.  OTN TTI Configuration Sub-TLV  . . . . . . . . . . . . 12
     3.7.  10
     3.8.  Degraded signal thresholds Signal Thresholds Sub-TLV  . . . . . . . . . . . . 14  12
   4.  Error handling  . . . . . . . . . . . . . . . . . . . . . . . . 16  13
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . 18  14
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 19  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 20  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 20  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 20  15

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 22  16

1.  Introduction

   Both SONET/SDH and OTN implement supervision OAM functions to qualify 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 SONET
   /SDH and OTN in technology specific documents.

   GMPLS has been extended to support connection establishment in SONET/
   SDH [RFC4606], and in OTN [RFC4328] and OTNv3 [OTNv3_SIG] [RFC6344] networks.  These
   documents however do not support the configuration of the respective
   OAM supervision functions.

   [GMPLS-OAM-FWK]

   [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 signalled 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.709v3] [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 management function of 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 emitting 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 decides
   determines if a miss-connection mis-connection occurred.

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
   layers, the lengths of these TTIs are different.  In RS RS, the TTI
   (encoded in J0 octet) byte) is either 1 or 16 octets bytes long.  In higher order
   paths the TTI (encoded in J1), is either 16 or 64 octet bytes long.  In
   lower order paths paths, the TTI is transmitted in the J2 byte and is 16
   octet
   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 octets, bytes, but only the first 32 octets 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 threshold, a defect
   state is declared.  To detect the correctness of the frames 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 distribution, an EDC violation
   ratio is defined as the threshold; while for the bursty model 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 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
   For OTN, in the digital transport layers (OTUk and ODUk) ODUk), only the
   bursty error distribution model errors 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.709v3]

   [G.709] introduced a tool for measuring round-trip delay of a
   bidirectional ODU path or tandem connection.  For implementing delay
   measurement
   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 RFC 4328 define RFC6344 defined the GMPLS RSVP-TE extensions
   necessary to manage SDH/SONET SONET/SDH and OTN optical and digital hierarchy
   connections.
   Connections for recent version of OTN, the OTNv3 are configured
   according to [OTNv3_SIG].  The monitoring functions associated to these
   connections may MAY be configured together with when configuring the
   connection itself. connections.

   The LSP Attribute Flag "OAM MEP entities desired" [GMPLS-OAM-FWK] is
   [I-D.ietf-ccamp-oam-configuration-fwk] MUST be used to signal that
   the monitoring functions at the endpoints must MUST be established.  The
   "OAM MIP entities desired" flag must MUST be set to 0 and must MUST be ignored.

   To configure OAM parameters parameters, the OAM Configuration TLV can 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). Sub-TLV).  For SONET/
   SDH and OTN 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.

   Recent release

   The recent revision of OTN [G.709v3] [G.709] introduced delay measurement
   capability for paths.  Such  A node enables MAY enable delay measurement by setting
   the "Performance Monitoring/Delay" flag.  By setting that flag flag, the
   node also indicates that it will initiate the delay measurement proactively; measurement;
   therefore, the remote endpoint node should not initate SHOULD NOT initiate delay
   measurement over the configured connection proactively.  Equipments connection.  Equipment designed according to
   earlier version versions of G709 must MUST clear the "Performance Monitoring/Loss"
   flag and upon receiving an OAM configuration message with
   "Performance Monitoring/Delay" flag set must MUST generate "OAM Problem/Unsupported Problem/
   Unsupported OAM Function" error.  The "Performance Monitoring/Delay"
   flag must MUST be cleared for SONET/SDH as it is not supported by SONET/SDH. SONET/
   SDH.

   For additional details details, the appropriate technology specific sub-TLV
   can
   MAY be carried in the OAM Configuration TLV.

3.1.1.  Continuity Check supervision

   In case of both discussed 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
   purposes:
   supervision: the J0 byte in RS layer, the J1 and J2 bytes byte in the HOVC layer
   and the J2 byte in the LOVC layers.  These bytes encode 1 octet, 16 octet or 64 octet long
   unstructured octet streams. layer.  The source node emits this stream transmits the TTI
   and the destination node matches it with an the expected one.  When the
   destination detects mismatch, a defect state will be declared.

   Since these streams bytes encode an identifier a TTI identifier defined for the source
   node, different stream will to be emitted in the upstream and downstream
   directions for bidirectional connections.  During the configuration
   the egress 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  Therefore, the SONET/SDH OAM
   Configuration TLV carries two Connectivity Supervision TLVs.

3.1.2.2.  OTN

   [G.709] defines a 64 octet byte long TTI, TTI format, where the first 32 octets bytes
   have a generic structure: a zero octet, byte, a 15 octet bytes long SAPI, a second
   zero
   octet byte and finally the 15 octet bytes long DAPI. DAPI format.

   For a unidirectional connection 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).

   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 SDH/SONET. SONET/SDH.  All three layers support exceeded error
   level with Poisson error distribution model and degraded signal
   defect level with both, both of the Poisson and bursty error distribution model.
   models.  Dedicated Signal quality supervision TLVs encode each level,
   therefore when the "Performance Monitoring/Loss" flag is set; several
   such TLVs can MAY be added to the SONET/SDH OAM Configuration TLV.  If a
   configuration TLV for a particular level is missing missing, the default
   parameters for that level is to SHOULD be applied.

   The

   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 allowed, a single Signal quality
   supervision TLV is MAY be added to the OTN OAM Configuration TLV.

3.2.  Signaling support of Virtual Concatenation Groups (VCG)

   A key capability of both, both SONET/SDH and OTN is the support of virtual
   concatenation.  This inverse multiplexing method uses multiplicity of
   parallel basic individual signals.  The supervision function parameters of
   these basic signals can be different.

   [RFC6344] summarises describes GMPLS signaling capabilities to support virtual
   concatenation and proposes extensions to that.
   concatenation.  A Virtual Concatenated Group (VCG) is constructed
   from several individual data plane signals.  The co-routed signals of
   a VCG could may be provisioned together using a single RSVP-TE session (co-signaled). (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 every each individual signal of the VCG.  A single OAM
   Configuration TLV is MUST be carried in the LSP_ATTRIBUTES Object, while
   multiple instances of technology specific OAM configuration sub-TLVs
   are
   MAY be added: one instance per individual signal.  The order of these
   TLVs refers to references the logical order of the basic individual signals (as they
   are listed in the Label Object).

   [RFC6344] allows extension/pruning of a VCG.  To achieve it it, the
   traffic descriptor, which encodes how the VCG is structured, in the
   RSVP-TE session is updated.  If the VCG is updated updated, the contents of
   the OAM Configuration TLV needs to 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 [GMPLS-OAM-FWK]:
   [I-D.ietf-ccamp-oam-configuration-fwk]: SONET/SDH OAM and OTN Digital
   Hierarchy OAM.

             OAM Type           Description
           ------------      ------------------
               3                SONET/SDH OAM
               4                OTN Digital Hierarchy OAM

   The "OAM Function Flags sub-TLV", Sub-TLV" is defined in [GMPLS-OAM-FWK].  SONET/
   SDH
   [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".

3.4.  SONET/SDH OAM Configuration sub-TLV Sub-TLV

   SONET/SDH OAM Configuration sub-TLV 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 (4) (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 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 (5) (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.  TTI Configuration Sub-TLV

3.6.1.  SDH TTI Configuration Sub-TLV
   This sub-TLV is carried in the SONET/SDH OAM Configuration sub-TLV, Sub-TLV,
   if the Connectivity Verification OAM Function Flag is set.  In every each
   supporting layers layer, the TTI identifies the source interface (SAPI);
   however, the length of this identifier varies layer-by-layer (See (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 (1) (IANA)           |         Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|U|            Reserved       |              TTI              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                            TTI cont                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flag "A", when set enables the AIS insertion on when detecting a TTI
   mismatch.

   Flat

   Flag "U" encodes if the TTI refers to the downstream node's source
   TTI (U=0) or the upstream one (U=1). 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-octets. 4 bytes.

   If the specified length and format of the TTI carried in this TLV is
   not supported by the referred referenced SONET/SDH layer, an error must be
   generated: "OAM Problem/TTI Length Mismatch".

3.6.2.

3.7.  OTN TTI Configuration Sub-TLV

   This sub-TLV is carried in the OTN OAM Configuration sub-TLV, 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 (1) (IANA)           |         Length = 32           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|S|D|APP|      Reserved       |              SAPI             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            SAPI cont                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            SAPI cont                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            SAPI cont                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SAPI      |                      DAPI                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            DAPI cont                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            DAPI cont                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            DAPI cont                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Three control flags are defined.  Flag "A" indicates that AIS
   insertion on 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 set, the TTI octets bytes 1 to 15 are matched to the
   expected SAPI value.  If the flag "D" is set set, the TTI octets bytes 17 to 31
   are matched to the expected DAPI value.  If both "S" and "D" are set 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 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
      instruct
      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
      instruct
      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 Configuration - Missing
   Upstream TTI configuration".

   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 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
   Configuration - Invalid applicability code"

3.7. code".

3.8.  Degraded signal thresholds Signal Thresholds Sub-TLV

   The Degraded signal thresholds 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 Sub-TLV or OTN OAM Configuration sub- 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 (2)  (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 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 errors, only degraded signal defect is to be
   detected, therefore, in this latter case (B=1) (B=1), the "L" bit must be
   set.
   Otherwise  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, both Poisson and bursty distributions of errors.  In
   the first case (B=0) (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 defect, the values are 6,7,8 and 9.

   In the second case (B=1) (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.

   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 [GMPLS-OAM-FWK]
   [I-D.ietf-ccamp-oam-configuration-fwk] this document defines the
   following values for the "OAM Problem" Error Code.

   o  In case of SONET/SDH if Performance Measurement/Delay flag is set

   If in the OAM Functions Flag sub-TLV, an error must be generated "OAM
      Problem/Unsupported OAM Function".

   o  In case of OTN if TTI Configuration Sub-TLV both the equipment does not support delay measurement "S" and the Performance Measurement/Delay flag is "D" bits are
   set in the received
      OAM Functions Flag sub-TLV, to 0, an error must be generated generated: "OAM
      Problem/Unsupported OAM Function".

   o  In case of SONET/SDH OAM when Problem/Invalid CC/CV
   Configuration".

   If the specified length or and format of the TTI to
      be configured carried in the SONET/
   SDH TTI Configuration Sub-TLV is not supported by the referred SONET/SDH
   layer, an error must be generated: "OAM Problem/TTI Length Mismatch".

   o Mismatch"

   If both "S" and "D" bits in the OTN TTI Configuration TLV are set to
      0, error must be generated: "OAM Problem/Invalid CC/CV
      configuration"

   o  If Sub-TLV the APP "APP" field is set to 1
   and the next or the previous sub-TLV is not an OTN TTI Configuration
   TLV with APP "APP" code point 2, then an error must be generated "OAM
   Problem/Invalid OTN TTI Configuration/ Configuration - Missing Upstream TTI configuration".

   o
   Configuration".

   If in the APP 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/ Configuration - Missing Downstream TTI configuration".

   o
   Configuration".

   If in the APP OTN TTI Configuration Sub-TLV the "APP" field is set to
   either 1 or 2 and the an unidirectional LSP is signaled (no UPSTREAM_LABEL is added to the message)
   UPSTREAM_LABEL) or the APP "APP" field is set to 3, an error must be
   generated "OAM Problem/Invalid OTN TTI
      Configuration/Invalid applicability code"

   o Configuration - Invalid
   Applicability Code".

   If flag "B" in Degraded signal thresholds Signal Thresholds Sub-TLV is set to 1 and
   flag "L" in the same sub-TLV is set to 0 0, an error must be generated
   "OAM Problem/Invalid Performance Monitoring/Loss configuration". 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 assigns defines two new
   values 3 and
   4 from of the "OAM Type" field of the OAM Configuration TLV.

   The  IANA is
   requested to make the following assignments in the RSVP-TE OAM
   Configuration Registry.

    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 need to be assigned under the
   "OAM Problem" error code: "OAM Problem/Unsupported OAM Function", "OAM Problem/TTI "TTI Length Mismatch", "OAM Problem/Invalid "Invalid CC/CV configuration", "OAM
   Problem/Invalid
   Configuration", "Invalid OTN TTI Configuration/Missing Configuration - Missing Upstream TTI
   configuration", "OAM Problem/Invalid
   Configuration", "Invalid OTN TTI Configuration/Missing Configuration - Missing Downstream
   TTI configuration", "OAM Problem/Invalid Configuration", "Invalid OTN TTI
   Configuration/Invalid applicability code", "OAM Problem/Invalid Configuration - Invalid
   Applicability Code", "Invalid Performance Monitoring/Loss configuration".
   Configuration".

6.  Security Considerations

   Security aspects are addressed in the OAM configuration framework
   document [GMPLS-OAM-FWK] [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
   The authors would like to thank Francesco Fondelli for his useful
   comments.

8.  References

8.1.  Normative References

   [GMPLS-OAM-FWK]

   [I-D.ietf-ccamp-oam-configuration-fwk]
              Takacs, A., Fedyk, D., and H. Jia, "OAM Configuration
              Framework and Requirements "GMPLS RSVP-TE
              extensions for GMPLS RSVP-TE",
              draft-ietf-ccamp-oam-configuration-fwk-01 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 2009. 1997.

8.2.  Informative References

   [G.707]    International Telecommunications Union, "Network node
              interface for the synchronous digital hierarchy (SDH)",
              ITU-T Recommendation G.707, January 2007.

   [G.709]    International Telecommunications Union, "Interfaces for
              the Optical Transport Network (OTN)", ITU-T Recommendation
              G.709, March 2003.

   [G.709v3]  International Telecommunications Union, "Interfaces for
              the Optical Transport Network (OTN)", ITU-T
              Recommendation G.709, December 2009. 2012.

   [G.798]    International Telecommunications Union, "Characteristics
              of optical transport network hierarchy equipment
              functional blocks", blocks ", ITU-T Recommendation G.798,
              December 2006.

   [G.806]    International Telecommunications Union, "Characteristics
              of transport equipment - Description methodology and
              generic functionality", ITU-T Recommendation G.806,
              January 2009.

   [OTNv3_SIG]
              Zhang, F., Zhang, G., Belotti, S., Ceccarelli, D., and K.
              Pithewan, "Operating Virtual Concatenation (VCAT) and the
              Link Capacity Adjustment Scheme (LCAS) with Generalized
              Multi-Protocol Label Switching (GMPLS)",
              draft-ietf-ccamp-gmpls-signaling-g709v3-01 (work in
              progress), October 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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
              Multi-Protocol Label Switching (GMPLS)", RFC 6344, August
              2011.

Authors' Addresses

   Andras Kern
   Ericsson
   Laborc u. 1.
   Budapest,
   Budapest  1037
   Hungary

   Email: andras.kern@ericsson.com

   Attila Takacs
   Ericsson
   Laborc u. 1.
   Budapest,
   Budapest  1037
   Hungary

   Email: attila.takacs@ericsson.com