Network Working Group                                            A. Kern
Internet-Draft                                                 A. Takacs
Intended status: Standards Track                                Ericsson
Expires: April 29, 2010                                 October 26, 2009


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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 29, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.









Kern & Takacs            Expires April 29, 2010                 [Page 1]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


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 functions is not specified.
   Both SONET/SDH and OTN implement supervision functions to qualify 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].










































Kern & Takacs            Expires April 29, 2010                 [Page 2]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


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].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Overview of SONET/SDH and OTN OAM related functions  . . . . .  5
     2.1.  Continuity supervision . . . . . . . . . . . . . . . . . .  5
     2.2.  Connectivity supervision . . . . . . . . . . . . . . . . .  5
       2.2.1.  SONET/SDH  . . . . . . . . . . . . . . . . . . . . . .  5
       2.2.2.  OTN  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Signal quality supervision . . . . . . . . . . . . . . . .  5
       2.3.1.  SONET/SDH  . . . . . . . . . . . . . . . . . . . . . .  6
       2.3.2.  OTN  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  RSVP-TE signaling extensions . . . . . . . . . . . . . . . . .  7
     3.1.  OAM configuration of switching layers  . . . . . . . . . .  7
     3.2.  OAM configuration of section layers  . . . . . . . . . . .  7
     3.3.  SONET/SDH OAM configuration  . . . . . . . . . . . . . . .  9
       3.3.1.  Generic procedures . . . . . . . . . . . . . . . . . .  9
       3.3.2.  Connectivity supervision configuration . . . . . . . .  9
       3.3.3.  Signal quality supervision configuration . . . . . . . 10
       3.3.4.  Tandem Connection Monitoring support . . . . . . . . . 10
       3.3.5.  Non intrusive Monitoring support . . . . . . . . . . . 10
     3.4.  OTN OAM configuration  . . . . . . . . . . . . . . . . . . 10
       3.4.1.  Generic procedures . . . . . . . . . . . . . . . . . . 10
       3.4.2.  Connectivity monitoring supervision configuration  . . 11
       3.4.3.  Signal quality supervision configuration . . . . . . . 12
       3.4.4.  Tandem connection monitoring . . . . . . . . . . . . . 12
       3.4.5.  Signaling support of non-intrusive monitoring  . . . . 13
     3.5.  Signaling support of Virtual Concatenation Groups (VCG)  . 13
     3.6.  OAM types and functions  . . . . . . . . . . . . . . . . . 14
     3.7.  Extensions to LSP_TUNNEL_INTERFACE_ID objects  . . . . . . 15
     3.8.  SONET/SDH OAM Configuration sub-TLV  . . . . . . . . . . . 15
     3.9.  OTN OAM Configuration sub-TLV  . . . . . . . . . . . . . . 15
     3.10. TTI Configuration Sub-TLV  . . . . . . . . . . . . . . . . 16
       3.10.1. SDH TTI Configuration Sub-TLV  . . . . . . . . . . . . 16
       3.10.2. OTN TTI Configuration Sub-TLV  . . . . . . . . . . . . 17
     3.11. Degraded signal thresholds Sub-TLV . . . . . . . . . . . . 18
   4.  Error handling . . . . . . . . . . . . . . . . . . . . . . . . 20
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26



Kern & Takacs            Expires April 29, 2010                 [Page 3]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


1.  Introduction

   Both SONET/SDH and OTN implement supervision functions to qualify 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 both
   SONET/SDH [RFC4606] and OTN [RFC4328] networks.  These documents
   however do not support the configuration of the respective
   supervision functions.

   [GMPLS-OAM-FWK] defines a technology-agnostic framework for GMPLS to
   support the establishment and configuration of the pro-active OAM
   functions of signalled 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.





























Kern & Takacs            Expires April 29, 2010                 [Page 4]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


2.  Overview of SONET/SDH and OTN OAM related functions

   SONET/SDH [G.707] and OTN [G.709] provide a variety of supervision
   functions.  Here we only consider continuity, connectivity and signal
   quality supervision functions, as these are the candidates for GMPLS
   based configuration.

2.1.  Continuity supervision

   Continuity supervision provides methods 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 if a miss-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 the lengths of these TTIs are different.  In RS the TTI
   (encoded in J0 octet) is either 1 or 16 octets long.  In higher order
   paths the TTI (encoded in J1), is either 16 or 64 octet long.  In
   lower order paths the TTI is transmitted in the J2 byte and is 16
   octet 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, but only the first 32 octets 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



Kern & Takacs            Expires April 29, 2010                 [Page 5]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


   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.  Note,
   that Tandem Connection sub-layers support only bursty error
   distribution model with Degraded Signal defect level.

2.3.2.  OTN

   For OTN, in the digital transport layers (OTUk and 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.




















Kern & Takacs            Expires April 29, 2010                 [Page 6]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


3.  RSVP-TE signaling extensions

   Both SONET/SDH and OTN define hierarchical transport technologies,
   where the transport functionalities are distributed between layers.
   These layers can be characterized based on whether switching is
   performed in that layer or not (See Table 1).

   +-------------+------------+----------------------------------------+
   |     Does    |     OTN    |                SONET/SDH               |
   |  switching? |            |                                        |
   +-------------+------------+----------------------------------------+
   |     yes     |  ODU, OCh, |  Path (HOVC and LOVC), MS (in case of  |
   |             |    OChr    |         transparent switching)         |
   |             |            |                                        |
   |      no     |  OTU, OMS  |   RS, MS (in case of non-transparent   |
   |             |            |               switching)               |
   +-------------+------------+----------------------------------------+

    Table 1: SONET/SDH and OTN layer examples for switching and section
                                  layers

3.1.  OAM configuration of switching layers

   Generally, the OAM related parameters of a signalled LSP refer to the
   switching layer connection.

   o  If the flag "Connectivity monitoring" in the OAM Configuration TLV
      is set, one or two Connectivity Supervision TLVs are added.  One
      TLV is added if the connection is either unidirectional or
      bidirectional but the same configuration data is used at both
      endpoints.  Otherwise, two TLV are added, one for each direction.

   o  If the flag "Performance Monitoring/Loss" in the OAM Configuration
      TLV is set, Signal Quality Supervision TLVs can be added.

   o  Flag "Performance Monitoring/Delay" must be cleared.

   The egress node parses and interprets the OAM parameters while
   intermediate nodes do not process the information.  The technology
   independent procedures are as per [GMPLS-OAM-FWK] while the
   technology specific steps are defined in Section 3.3 and Section 3.4
   in this document.

3.2.  OAM configuration of section layers

   In the point of view of OAM configuration of connections of a section
   layer, two cases can be differentiated:




Kern & Takacs            Expires April 29, 2010                 [Page 7]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


   When the section layer connection models a link between two
   physically adjacent nodes, the related OAM parameters are configured
   either manually or by other means (e.g., as part of link property
   correlation function of LMP).  Therefore, this case is out of scope
   of this document.

   When a section layer connection models a logical link, which is
   implemented with a connection of a server switching layer, the
   related OAM parameters are configured along with the signaling of the
   implementing server switching layer connection.

   In this latter case, if the [LSP-HIER-BIS] signaling is used to setup
   the server layer connection and institiate it as FA-LSP, the OAM
   Configuration TLV can be added to the LSP_TUNNEL_INTERFACE_ID object
   to configure the OAM of the client section layer.  As a single link
   is monitored: OAM MEP entities are desired while MIP entities are
   not.  Furthermore, Alarm Indication from server layer is desired as
   well.  This information is originally encoded in the LSP Attributes
   Flags TLV.  As fix values for these bits are provided this TLV does
   not need to be added to the LSP_TUNNEL_INTERFACE_ID object.

   Therefore, the ingress node performs the following steps during
   constructing a PATH message:

   o  Add LSP_TUNNEL_INTERFACE_ID object where a new flag "O" is set
      indicating that OAM configuration for the client layer connection
      (FA) is desired.

   o  Adds an OAM Configuration TLV to the LSP_TUNNEL_INDERFACE_ID
      object and set its fields appropriately.

   o  Technology specific OAM Configuration TLV (e.g., SONET/SDH or OTN)
      is added and extended as follows:

      *  If flag "Connectivity monitoring" in OAM Configuration TLV is
         set one or two Connectivity Supervision TLVs is added.  One TLV
         is added if the connection is either unidirectional or
         bidirectional but the same configuration data is used on both
         endpoints.  Otherwise, two TLV are added, one for each
         direction.

      *  If flag "Performance Monitoring/Loss" in OAM Configuration TLV
         is set Signal Quality Supervision TLVs can be added.

   The egress node performs the following steps at the receipt of a PATH
   message:





Kern & Takacs            Expires April 29, 2010                 [Page 8]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


   o  Checks if LSP_TUNNEL_INTERFACE_ID object is added and flag "O" is
      set.

   o  If the "Connectivity monitoring" OAM function is set in the OAM
      Configuration TLV, the egress expects one or two Connectivity
      Supervision TLVs.

   o  If the "Performance Monitoring/Loss" OAM function is set in the
      OAM Configuration TLV, one or two Signal quality supervision TLVs
      can be added to define the parameters to be configured.  If no
      TLVs are added the suggested default values are used.

3.3.  SONET/SDH OAM configuration

3.3.1.  Generic procedures

   The RS and MS layers of SONET/SDH define sections between two
   adjacent nodes.  In the basic configuration the supervision
   parameters encoded in the signal are terminated and processed in the
   adjacent nodes, thus, their configuration depends on whether they run
   over a physical link or a logical link implemented by a lower layer
   network.  In the first case their configuration is done manually or
   by other means (not discussed in this document).  In the latter case
   the RS and MS layer configuration is done along with the
   configuration of the connection in the sever layer.  This can be
   automated using FA-LSPs as described in Section 3.2

   The HOVC and LOVC path layers, as well as the RS and MS layers in
   transpared forwarding, are configured as in Section 3.1.

   The layer to be configured with RSVP-TE is encoded in the signal type
   field of the SENDER_TSPEC object.  The content of the OAM
   configuration TLV is relevant to that layer.

3.3.2.  Connectivity supervision configuration

   [G.707] defines three bytes (signals) for connectivity supervision
   purposes: the J0 byte in RS layer, the J1 and J2 bytes in HOVC and
   LOVC layers.  These bytes encode 1 octet, 16 octet or 64 octet long
   unstructured octet streams.  These streams encode the Access Point
   Identifier of the source node.

   In the case of bidirectional connection, different TTIs have to be
   emitted in the upstream and downstream directions.  During the
   configuration the egress 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.



Kern & Takacs            Expires April 29, 2010                 [Page 9]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


3.3.3.  Signal quality supervision configuration

   Signal quality supervision function is implemented in MS, HOVC, LOVC
   layers.  All three layers support exceeded error level with Poisson
   error distribution model and degraded signal defect level with both,
   Poisson and bursty error distribution model.  Dedicated Signal
   quality supervision TLVs encode each level, therefore when the
   "Performance Monitoring/Loss" flag is set; several such TLVs can 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 is to be applied.

3.3.4.  Tandem Connection Monitoring support

   TBA

3.3.5.  Non intrusive Monitoring support

   TBA

3.4.  OTN OAM configuration

3.4.1.  Generic procedures

   The optical transport hierarchy provides connectivity and continuity
   supervision functions with appropriate maintenance signals.  The OTS
   and OMS layers are section layers describing physical links.  RSVP-TE
   does not support the configuration of these layers [RFC4328], hence
   OTS and OMS related OAM parameters are also out of scope of this
   document.  The OCh layer adds end-to-end management signals.
   Although the OCh/OChr transport layer is configured with GMPLS the
   related OAM functions do not need configuration.

   The digital transport hierarchy has supervision functions as well.
   Both OTUk and ODUk layers implement connectivity and signal quality
   supervision functions, respectively.  The OAM configuration for these
   layers is supported by the extensions defined in this document.

   o  For OTUk connections the OAM functions are provisioned together
      with the server OCh/OChr LSP as defined in Section 3.2.

   o  For ODUk connections the procedure defined in Section 3.1 is used.
      If the client layer network has section layer OAM monitoring
      capabilities, then the parameters of this latter layer can be
      encoded as per Section 3.2.






Kern & Takacs            Expires April 29, 2010                [Page 10]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


3.4.2.  Connectivity monitoring supervision configuration

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

   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).

   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




Kern & Takacs            Expires April 29, 2010                [Page 11]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


3.4.3.  Signal quality supervision configuration

   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.

3.4.4.  Tandem connection monitoring

   [GMPLS-OAM-FWK] provides a generic mechanism to configure Tandem
   Connection Monitoring: the endpoints of a TCM Entity as well as the
   relevant OAM attributes are encoded with two TCME Configuration TLVs
   carried in HOP_ATTRIBUTES subobjects in the ERO [HOP_ATTR].

   In the optical hierarchy, the OCh connections do not support tandem
   connection monitoring.

   In the digital hierarchy, the ODUk header field implements six
   channels for Tandem Connection Monitoring features.  This allows
   deploying up to six overlapping TCMEs, and disjoint TMCEs may use the
   same channels.  The Level field defined in [GMPLS-OAM-FWK] with the
   limitation that its value must be an integer value from domain 1 to 6
   provides a direct mapping to the TCM instance indefiers (TCM1,TCM2,
   ..., TCM6).

   To configure the connection monitoring supervision function for a
   TCME the TTIs of the end-to-end connection can be considered as well
   as new TTI values can be provisioned.  Therefore the TCM ingress
   looks for the TCM egress and besides the procedures defined in
   [GMPLS-OAM-FWK] it performs the following steps:

      If no TTI Configuration TLVs are given at the TCME ingress but are
      given at the corresponding TCME egress an error must generated:
      "TMCE Problem/TTI Configuration mismatch".

      If one or more TTI Configuration TLVs are given the ingress must
      check if TTI values are specified at the TCME egress.  If not, the
      ingress node extends the TCME Configuration TLV of the egress node
      with the proper TTI configuration parameters.  Otherwise, it must
      generate an error: "TMCE Problem/TTI Configuration mismatch".

   For signal quality supervision the defect states and thresholds
   applicable at the monitoring entity can be specified.  As default
   value, the treshold parameters used at the (end-to-end connection or
   the proper TC) egress are applicable.






Kern & Takacs            Expires April 29, 2010                [Page 12]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


3.4.5.  Signaling support of non-intrusive monitoring

   OTN supports non-intrusive monitoring of end-to-end optical
   connections and end-to-end and tandem connections in the digital
   hierarchy.  To place and configure a non-intrusive monitoring element
   the OAM Configuration framework introduced the NIME Configuration TLV
   [GMPLS-OAM-FWK], which is carried in HOP_ATTRIBUTES subobjects in the
   ERO [HOP_ATTR].

   The Level value of NIME Configuration TLV indicates what is
   monitored: either the end-to-end flow (0) or a particular tandem
   connection (1..6).  As TCM is not supported by optical hierarchy, in
   case of monitoring OCh connections the Level value must be set to 0.

   For connectivity suppervision the expected TTI value must be
   determined.  The ingress node of the monitored end-to-end or tandem
   connection can extend technology specific sub-TLV of the NIME
   Configuration TLV with one or two TTI Configuration TLVs:

      The end-to-end connection ingress extends all NIME Configuration
      TLVs with LEVEL attribute set to 0.

      The TCME ingress extends all NIME Configuration TLVs that are
      placed before the TCME egress and have the same Level value as the
      TCME ingress.

   In case of bidirectional connections with asymmetric TTIs, flags "U"
   and "D" selects which of the two TTI values are to be used.

   For signal quality supervision the defect states and thresholds
   applicable at the monitoring entity can be specified.  As default
   value, the treshold parameters used at the (end-to-end connection or
   the proper TC) egress are applicable.

   For OCh connection [G.798] defines two kinds of non-intrusive
   monitoring functions.  The first option is based on the OCh
   attributes, while the second one terminates the optical channel and
   processes the carried OTU frames as well.  To make distinction
   between the two options, the OAM Type of the NIME Configuration TLV
   is used: OTN optical hierarchy indicates first option, and OTN
   digital hierarchy indicates the second.

3.5.  Signaling support of Virtual Concatenation Groups (VCG)

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



Kern & Takacs            Expires April 29, 2010                [Page 13]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


   [GMPLS-VCAT-LCAS] summarises GMPLS signaling capabilities to support
   virtual concatenation and proposes extensions to that.  A Virtual
   Concatenated Group (VCG) is constructed from several individual data
   plane signals.  Several co-routed data plane signals can be
   provisioned together using a single RSVP-TE session (co-signaled).
   Multiple RSVP-TE sessions can be merged to form the VCG.  These
   sessions are then associated using RSVP-TE Calls [RFC4974].

   As the scope of a single RSVP-TE session covers the co-signaled
   elements of a VCG, the OAM configuration extension is only relevant
   for this case too.

   We assume that the same OAM type and the same set of OAM functions
   apply to every individual signal of the VCG.  A single generic OAM
   Configuration TLV is added to define these common parameters while
   multiple instances of technology specific OAM Configuration TLVs are
   listed: one instance per individual signal.  The order of these TLVs
   refers to logical order of the basic signals (as they are listed in
   the label object).

   [GMPLS-VCAT-LCAS] 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 extended a new OAM
   Configuration TLV is added to the LSP Attributes objects together
   with updating the traffic descriptor.

   Support of LCAS is FFS.

3.6.  OAM types and functions

   This document defines three new OAM types [GMPLS-OAM-FWK]: SONET/SDH
   OAM, OTN Digital Hierarchy OAM and OTN Optical hierarchy OAM.

             OAM Type           Description
           ------------      ------------------
               0                Reserved
               1                Ethernet OAM
               2                SONET/SDH OAM
               3                OTN Digital Hierarchy OAM
               4                OTN Optical hierarchy OAM
             5-256              Reserved


   The OAM Configuration TLV defines three OAM functions: Connectivity
   Monitoring, Loss Measurement and Delay Measurement.  SONET/SDH and
   OTN supervision functions support Connectivity Monitoring and Loss
   Measurement.  Therefore, if Delay measurement function is requested
   the nodes must generate an error with value "OAM Problem/Unsupported



Kern & Takacs            Expires April 29, 2010                [Page 14]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


   OAM Function".

3.7.  Extensions to LSP_TUNNEL_INTERFACE_ID objects

   To support the OAM configuration of dynamically configured FAs the
   following extension to the LSP_TUNNEL_INTERFACE_ID Object is defined.
   A new flag (O) (IANA to assign) is added to the actions field of the
   LSP_TUNNEL_INTERFACE_ID Object: this bit indicates whether OAM
   monitoring for the section is desired.

   The bit can be set independently from the other flags.  When it is
   set, the following TLVs must be added to the LSP_TUNNEL_INTERFACE_ID
   object as sub-TLVs:

   o  OAM Configuration TLV to declare desired OAM technology and
      functions.

   o  Technology specific OAM Configuration TLVs if needed.

3.8.  SONET/SDH OAM Configuration sub-TLV

   SONET/SDH OAM Configuration 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 (2) (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.9.  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.





Kern & Takacs            Expires April 29, 2010                [Page 15]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


      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 (3) (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.10.  TTI Configuration Sub-TLV

3.10.1.  SDH TTI Configuration Sub-TLV

   Several SONET/SDH layers support connectivity supervision functions.
   In every 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 (1) (IANA)       |         Length                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|U|            Reserved       |              TTI              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                            TTI cont                          ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Flat "U" encodes if the TTI refers to the downstream TTI (U=0) or the
   upstream one (U=1).

   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.

   If the specified length and format of the TTI carried in this TLV is



Kern & Takacs            Expires April 29, 2010                [Page 16]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


   not supported by the referred SONET/SDH layer, error must be
   generated: "OAM Problem/TTI Length Mismatch".

3.10.2.  OTN TTI Configuration Sub-TLV

      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 = 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 detecting 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 octets 1 to 15 are matched to the
   expected SAPI value.  If the flag "D" is set the TTI octets 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 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)





Kern & Takacs            Expires April 29, 2010                [Page 17]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


      1 - Downstream TTI for double TTI configuration: the current TLV
      instruct 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 the configuration of the TTI to be used in upstream
      direction (See Figure 2).

      3 - Invalid.

   This TLV is included only if the "Connection Monitoring" flag in the
   OAM Configuration TLV is set.

   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".

   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.11.  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.

      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 (3) (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,



Kern & Takacs            Expires April 29, 2010                [Page 18]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


   therefore, in this latter case (B=1) the "L" bit must be set.
   Otherwise 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 are 6,7,8 and 9.

   In the second case (B=1) it encodes 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 monitoring time-frame in 1 second periods
   assuming bursty distribution of errors.  The valid values are 2 to 10
   periods.


































Kern & Takacs            Expires April 29, 2010                [Page 19]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


4.  Error handling

   In addition to error values specified in [GMPLS-OAM-FWK] this
   document defines the following values for the "OAM Problem" Error
   Code.

   o  If Delay measurement function is requested in the OAM
      Configuration TLV, an error must be generated "OAM Problem/
      Unsupported OAM Function".

   o  In case of SONET/SDH the length or format of the TTI to be
      configured is not supported by the referred SONET/SDH layer, error
      must be generated: "OAM Problem/TTI Length Mismatch".

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

   o  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".

   o  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".

   o  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"

   o  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 error must be generated
      "OAM Problem/Invalid Performance Monitoring/Loss configuration".

   o  If TTI configurations at TMCE ingress and egress nodes are not
      compatible an error must be generated: "TCME Problem/TTI
      Configuration mismatch"











Kern & Takacs            Expires April 29, 2010                [Page 20]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


5.  IANA Considerations

   This document specifies a new SONET/SDH OAM Configuration TLV and OTN
   OAM Configuration TLV to be carried in the OAM Configuration TLV in
   LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path messages.
   The document assigns OAM Types 2 and 3 to OAM Type field of the OAM
   Configuration TLV.

   The following values need to be assigned under the Error Codes "OAM
   Problem/Unsupported OAM Function", "OAM Problem/TTI Length Mismatch",
   "OAM Problem/Invalid CC/CV configuration", "OAM Problem/Invalid OTN
   TTI Configuration/Missing Upstream TTI configuration", "OAM Problem/
   Invalid OTN TTI Configuration/Missing Downstream TTI configuration",
   "OAM Problem/Invalid OTN TTI Configuration/Invalid applicability
   code", "OAM Problem/Invalid Performance Monitoring/Loss
   configuration", "TMCE Problem/TTI Configuration mismatch"



































Kern & Takacs            Expires April 29, 2010                [Page 21]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


6.  Security Considerations

   Security aspects are addressed in the OAM configuration framework
   document [GMPLS-OAM-FWK]















































Kern & Takacs            Expires April 29, 2010                [Page 22]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


7.  Acknowledgements

   The authors would like to thank Francesco Fondelli for his useful
   comments.















































Kern & Takacs            Expires April 29, 2010                [Page 23]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


8.  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.783]    International Telecommunications Union, "Characteristics
              of synchronous digital hierarchy (SDH) equipment
              functional blocks", ITU-T Recommendation G.783,
              December 2006.

   [G.798]    International Telecommunications Union, "Characteristics
              of optical transport network hierarchy equipment
              functional 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.

   [GMPLS-OAM-FWK]
              Takacs, A., Fedyk, D., and H. Jia, "OAM Configuration
              Framework and Requirements for GMPLS RSVP-TE",
              draft-ietf-ccamp-oam-configuration-fwk-01 (work in
              progress), March 2009.

   [GMPLS-VCAT-LCAS]
              Bernstein, G., Rabbat, R., and H. Helvoort, "Operating
              Virtual Concatenation (VCAT) and the Link Capacity
              Adjustment Scheme (LCAS) with Generalized Multi-Protocol
              Label Switching (GMPLS)",
              draft-ietf-ccamp-gmpls-vcat-lcas-07 (work in progress),
              December 2008.

   [HOP_ATTR]
              Kern, A. and A. Takacs, "Encoding of Attributes of LSP
              hops using RSVP-TE", Internet-draft Work in progress,
              October 2009.

   [LSP-HIER-BIS]
              Shiomoto, K., Farrel, A., Rabbat, R., Ayyangar, A., and Z.
              Ali, "Procedures for Dynamically Signaled Hierarchical
              Label Switched Paths",



Kern & Takacs            Expires April 29, 2010                [Page 24]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


              draft-ietf-ccamp-lsp-hierarchy-bis-06 (work in progress),
              December 2008.

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

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [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.

   [RFC4974]  Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS)
              RSVP-TE Signaling Extensions in Support of Calls",
              RFC 4974, August 2007.





























Kern & Takacs            Expires April 29, 2010                [Page 25]


Internet-Draft  GMPLS Based OTN and SDH OAM Configuration   October 2009


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 April 29, 2010                [Page 26]