[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                       Fatai Zhang
Internet Draft                                               Xian Zhang
Category: Standards Track                                        Huawei
                                                          D. Ceccarelli
                                                            D. Caviglia
                                                               Ericsson
                                                          Guoying Zhang
                                                                   CATR
                                                              D. Beller
                                                              S.Belotti
                                                         Alcatel-Lucent
Expires: April 11, 2013                                October 12, 2012

           Link Management Protocol (LMP) extensions for G.709
                       Optical Transport Networks

              draft-cecczhang-ccamp-gmpls-g709v3-lmp-00.txt


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



Abstract

   Recent progress of the Optical Transport Network (OTN) has introduced
   new signal types (i.e., ODU0, ODU4, ODU2e and ODUflex) and new
   Tributary Slot granularity (1.25Gbps).



Ceccarelli & Zhang       Expires April 2013                   [Page 1]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


   Since equipments deployed prior to recently defined ITU-T
   recommendations only support 2.5 Gbps Tributary Slot granularity and
   ODU1, ODU2 and ODU3 containers, the compatibility problem should be
   considered. In addition, a Higher Order ODU (HO ODU) link may not
   support all the types of Lower Order ODU (LO ODU) signals defined by
   the new OTN standard because of the limitation of the devices at the
   two ends of a link. In these cases, the control plane is required to
   run the capability discovering functions for the evolutive OTN.

   This document describes the extensions to the Link Management
   Protocol (LMP) needed to discover the capability of HO ODU link,
   including the granularity of Tributary Slot to be used and the LO ODU
   signal types that the link can support. Moreover, extensions of LMP
   test messages detailing the OTN technology specific information in
   order to cover also G.709v3 signal types and containers are also
   provided.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Table of Contents


   1. Introduction  ................................................ 3
   2. Terminology  ................................................. 4
   3. Overview of the Evolutive G.709 .............................. 4
   4. Link Capability Discovery  ................................... 5
      4.1. Link Capabaplity Discovery Requirements ................. 5
         4.1.1. Discovering the Granularity of the TS .............. 5
         4.1.2. Discovering the Supported LO ODU Signal Types....... 6
      4.2. Extensions: LMP Link Summary Message .................... 7
         4.2.1. Message Extension .................................. 7
            4.2.1.1. LinkSummary Message ........................... 7
            4.2.1.2. LinkSummaryAck Message ........................ 8
            4.2.1.3. LinkSummaryNack Message ....................... 8
         4.2.2. Object Definitions ................................. 8
         4.2.3. Procedures ........................................ 10
   5. Verifying Link Connectivity ................................. 12
      5.1. Encoding Type  ......................................... 13
      5.2. Verify Transport Mechanism ............................. 13
      5.3. Transmission Rate ...................................... 14
   6. Trace Monitoring  ........................................... 15
      6.1. TRACE Object for evolutive OTN ......................... 15
      6.2. Discovery Response Message for Layer Adjacency Discovery 17


Ceccarelli & Zhang       Expires April 2013                   [Page 2]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


   7. LMP Behavior Negotiation Update ............................. 18
   8. Security Considerations ..................................... 18
   9. IANA Considerations  ........................................ 19
   10. Acknowledgments  ........................................... 19
   11. References  ................................................ 19
      11.1. Normative References .................................. 19
      11.2. Informative References ................................ 20
   12. Authors' Addresses  ........................................ 20
   13. Contributors  .............................................. 22

1. Introduction

   The Link Management Protocol (LMP) defined in [RFC4204] is being
   developed as part of the Generalized MPLS (GMPLS) protocol suite to
   manage Traffic Engineering (TE) links.

   Recently, great progress has been made for the Optical Transport
   Networking (OTN) technologies in ITU-T. New ODU containers (i.e.,
   ODU0, ODU4, ODU2e and ODUflex) and a new Tributary Slot (TS)
   granularity (1.25Gbps) have been introduced by the [G709-V3],
   enhancing the flexibility of OTNs.

   With the evolution and deployment of G.709 technology, the backward
   compatibility problem requires to be considered. In data plane, the
   equipment supporting 1.25Gbps TS can combine the specific Tributary
   Slots together (e.g., combination of TS#i and TS#i+4 on a HO ODU2
   link) so that it can interwork with other equipments which support
   2.5Gbps TS. From the control plane point of view, it is necessary to
   discover which type of TS is supported at both ends of a link, so
   that it can choose and reserve the TS resources correctly in this
   link for the connection.

   Additionally, the requirement of discovering the signal types of
   Lower Order ODU (LO ODU) that can be supported by a Higher Order ODU
   (HO ODU) should be taken into account. Equipment at one end of a HO
   ODU link may not support to transport some types of LO ODU signals
   (e.g., may not support the ODUflex). In this case, this HO ODU link
   should not be selected for those types of LO ODU connections.

   From the perspective of control plane, it is necessary to discover
   the capability of a HO ODUk or OTUk link including the granularity of
   TS to be used and the LO ODU signal types that the link can support.
   Note that this capability information can be, in principle,
   discovered by routing. Since in certain case, routing is not present
   (e.g., UNI case) we need to extend link management protocol
   capabilities to cover this aspect. Obviously, in case of routing
   presence, the discovering procedure by LMP could also be optional.


Ceccarelli & Zhang       Expires April 2013                   [Page 3]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


   A further enhancement needed with respect to LMP covers the link
   verification and link property correlation functionalities and the
   G.709 test procedures they are based on. Such procedures require the
   definition of a G.709 specific TRACE object.  After data links have
   been verified, it is possible to group them into the TE links.

   This document extends the LMP and describes the solution of
   discovering HO ODU link capability and operating link verification
   and link property correlation.


2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3. Overview of the Evolutive G.709

   The traditional OTN standard [ITUT-G709] describes the optical
   transport hierarchy (OTH) and introduces three ODU signal types (i.e.,
   ODU1, ODU2 and ODU3). The ODUj can be mapped into one or more
   Tributary Slots (with a granularity of 2.5Gbps) of OPUk where j<k.
   The ODUj can also be mapped into OTUj (j=1, 2 or 3) directly.

   Recent revisions of ITU-T Recommendation G.709 have introduced new
   features for the evolutive Optical Transport Networks (OTN). New ODU
   signals, including ODU0, ODU4, ODU2e and ODUflex, are described in
   [G709-V3]. This document also defines the new multiplexing hierarchy
   for the evolutive OTN. In this multiplexing hierarchy, LO ODUj can be
   mapped into an OTUj, or multiplexed into a HO ODUk (where j<k) by
   occupying several tributary slots.

   In case of LO ODUj mapping into OTUj, the following mappings are
   defined:

      - ODU1 into OTU1 mapping

      - ODU2 into OTU2 mapping

      - ODU3 into OTU3 mapping

      - ODU4 into OTU4 mapping

   In case of LO ODUj multiplexing into HO ODUk, a new Tributary Slot
   granularity (i.e., 1.25Gbps) is introduced in [G709-V3]. For the



Ceccarelli & Zhang       Expires April 2013                   [Page 4]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


   evolutive OTN, the multiplexing of ODUj (j = 0, 1, 2, 2e, 3, flex)
   into an ODUk (k > j) signal can be depicted as follows:

      - ODU0 into ODU1 multiplexing (with 1,25Gbps TS granularity)

      - ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS
         granularity)

      - ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity)

      - ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing
         (with 1.25Gbps TS granularity)

      - ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity)

      - ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4
         multiplexing (with 1.25Gbps TS granularity)

   Note that If TS auto-negotiation is supported, a node supporting
   1.25Gbps TS can interwork with the other nodes that supporting
   2.5Gbps TS by combining specific TSs together in data plane, as
   descirbied in [OTN-frwk].

4. Link Capability Discovery

4.1. Link Capabaplity Discovery Requirements

4.1.1. Discovering the Granularity of the TS

   As described in section 3.1, if the two ends of a link use different
   granularities of TS, The LO ODU must be mapped into specific combined
   Tributary Slots in the end of link with TS of 1.25Gbps.

   From the perspective of control plane, when creating a LO ODU
   connection, the node MUST select and reserve specific TS for the
   connection if the two ends of a link use different granularities of
   TS. For example, for an ODU2 link, we suppose that node A only
   supports the 2.5Gbps TS while node B supports the 1.25Gbps TS. When
   node B receives a Path message from node A requesting an ODU1
   connection, node B MUST reserve the TS#i and TS#i+4 (where i<=4)
   (with the granularity of 1.25Gbps) and tell node A via the label
   carried in the Resv message that the TS#i (with the granularity of
   2.5Gbps) among the 4 slots has been reserved for the ODU1 connection.
   Otherwise, the reservation procedure will fail.





Ceccarelli & Zhang       Expires April 2013                   [Page 5]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


          +-----+         Path          +-----+
          |     |    ------------>      |     |
          |  A  +-------ODU2 link-------+  B  |
          |     |    <-------------     |     |
          +-----+         Resv          +-----+
     (Support 2.5G TS)              (Support 1.25G TS)

   Therefore, for an ODU2 or ODU3 link, in order to reserve TS resources
   correctly for a LO ODU connection, the control plane of the two ends
   MUST know which granularity the other end can support before creating
   the LO ODU connection.

4.1.2. Discovering the Supported LO ODU Signal Types

   Many new ODU signal types are introduced by [G709-V3], such as ODU0,
   ODU4, ODU2e and ODUflex. It is possible that equipment does not
   always support all the LO ODU signal types introduced by [G709-V3].
   If one end of a HO ODU link can not support a certain LO ODU signal
   type and there is no HO ODU FA LSP able to support this LO ODU signal,
   the HO ODU link/FA LSP can not be selected to carry such type of LO
   ODU connection.

   For example, in the following figure, if the interfaces IF1, IF2, IF8,
   IF7, IF5 and IF6 can support ODUflex signals, while the interfaces IF
   3 and IF4 can not support ODUflex signals. In this case, if one
   ODUflex connection from A to C is requested, and there is no HO ODU
   FA LSP from node A to C through node B, link #1 and #2 should be
   excluded, link #3 and link #4 are the candidates (the possible path
   could be A-D-C through link #3 and link #4).


                              +-----+
                    link #3   |     |  link #4
            +-----------------+  D  +-----------------+
            |              IF8|     |IF7              |
            |                 +-----+                 |
            |                                         |
            |IF1                                   IF6|
         +--+--+              +-----+              +--+--+
         |     |    link #1   |     |    link #2   |     |
         |  A  +--------------+  B  +--------------+  C  |
         |     |IF2        IF3|     |IF4        IF5|     |
         +-----+              +-----+              +-----+


   Therefore, it is necessary for the two ends of a HO ODU link to
   discover which types of LO ODU can be supported by the HO ODU link.


Ceccarelli & Zhang       Expires April 2013                   [Page 6]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


   After discovering, the capability information can be flooded by IGP,
   so that the correct path for an ODU connection can be calculated.

4.2. Extensions: LMP Link Summary Message

   [RFC4204] defines the Link Management Protocol (LMP) which consists
   of four main procedures: control channel management, link property
   correlation, link connectivity verification, and fault management. As
   part of LMP, the link property correlation is used to verify the
   consistency of the TE and data link information on both sides of a
   link. This document extends the link property correlation procedure
   to discover the capability of both sides of a HO ODU link.

   The designated HO ODU overhead bytes (e.g., the GCC1 and GCC2
   overhead bytes) can be used as the control channel to carry the LMP
   message after the HO ODU link is created. The out-of-band Data
   Communication Network (DCN) can also be used.

4.2.1. Message Extension

   Three messages are used for link property correlation: LinkSummary,
   LinkSummaryAck and LinkSummaryNack Message. This document does not
   change the basic procedure of LMP but just add a new subobject (HO
   ODU Link Capability) in the DATA_LINK object to carry the capability
   of one end of a HO ODU link.

   The formats of LinkSummary, LinkSummaryAck and LinkSummaryNack
   messages are defined in [RFC4204].

4.2.1.1. LinkSummary Message

   The local end of a TE link can send a LinkSummary message to the
   remote end to start the negotiation about the capability that the TE
   link can support.

   One new Subobject named HO ODU Link Capability Subobject in the
   DATA_LINK object is introduced by this document. This new subobect is
   used to tell the remote end of the HO ODU link which TS granularity
   and which LO ODU signal types that the local end can support. When
   the DATA_LINK object carries the new HO ODU Link Capability Subobject,
   the N flag SHOULD be set to 1 which means that the subobject is
   negotiable.



Ceccarelli & Zhang       Expires April 2013                   [Page 7]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


4.2.1.2. LinkSummaryAck Message

   The LinkSummaryAck message is used to tell the remote end that it has
   the same capability as the remote end after the LinkSummary message
   is received by the local end.

4.2.1.3. LinkSummaryNack Message

   The LinkSummaryNack message is used to tell the remote end that it
   has different capability from the remote end after the LinkSummary
   message is received by the local end. The LinkSummaryNack message
   also carries the HO ODU Link Capability subobject in the DATA_LINK
   object to tell the remote end the exact capability of the HO ODU link
   after negotiation, i.e., the granularity of TS and the types of LO
   ODU that both side of the HO ODU link can support.

4.2.2. Object Definitions

   A new HO ODU Link Capability subobject type is introduced to the DATA
   LINK object to carry the HO ODU link capability information. The
   format of the new subobject is defined as follow:

    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       |    Length     |OD(T)Uk| T |     Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|B|C|D|E|F|G|  LO ODU Flags   |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type (8 bits):

   The value of this subobject type is TBD.

   Length (8 bits):

   The Length field contains the total length of the subobject in bytes,
   including the Type and Length fields. As for RFC 4204, the Length
   MUST be at least 4, and MUST be a multiple of 4. Value of this field
   is 8.

    OD(T)Uk (4 bits):

   This field is used to indicate the HO ODU link type (in case of LO
   ODUj multiplexing into HO ODUk, wherein j<k) or the OTU link type (in
   case of LO ODUk mapping into OTUk).


Ceccarelli & Zhang       Expires April 2013                   [Page 8]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


   OD(T)Uk field     Signal type of HO ODUk or OTUk
   -------------     ------------------------------
      0              Reserved (for future use)
      1              HO ODU1 or OTU1
      2              HO ODU2 or OTU2
      3              HO ODU3 or OTU3
      4              HO ODU4 or OTU4
      5-15           Reserved (for future use)


   T (2 bits):

   The T bits are used to indicate the granularity of the TS of the HO
   ODU link.

   T field      TS type
   -------      -------
     00         Meaningless
     01         1.25Gbps TS granularity
     10         2.5Gbps TS granularity
     11         Reserved (for future use)

   In case that an OTUk link only support ODUj (j=k) into OTUk mapping
   and does not support any ODUj into ODUk (j<k) multiplexing, then the
   T field is not meaningful and MUST be filled with 0 and be ignored on
   receipt.

   LO ODU flags (A|B|C|D|E|F|G) (16 bits):

   These flags are used to indicate which LO ODU signal types that one
   end or the both end can support. The flags will be set to 1 if the
   corresponding LO ODU signal types are supported to be mapped or
   multiplexed into the OTUk or HO ODUk link.

   This rule imposes that:

   - At least one flag is set to 1.

   - When the ODUj (j=k) flag corresponding to the signal type HO
      ODUk/OTUk is set to 1, then the signal type OD(T)Uk has to be
      intended as LO ODUk and direct mapping over OTUk is supported.

      * Furthermore, if only the ODUj(j=k) flag is set to 1, it means
         that the HO ODUk/OTUk link only supports ODUj(j=k) into OTUk
         mapping. In other words, the link does not support any ODUj


Ceccarelli & Zhang       Expires April 2013                   [Page 9]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


         into ODUk (j<k) multiplexing (i.e., payload type != 20/21), but
         may support carrying various non-ODU client signals listed in
         Table 15-8 of [G709-V3].

   - When an ODUj (j<k) flag not corresponding to the signal type HO
      ODUk/OTUk is set to 1 then the signal type OD(T)Uk has to be
      intended as HO ODUk and multiplexing of LO ODUj over HO ODUk is
      supported.

        Flag A: indicates whether LO ODU0 is supported.

        Flag B: indicates whether LO ODU1 is supported.

        Flag C: indicates whether LO ODU2 is supported.

        Flag D: indicates whether LO ODU3 is supported.

        Flag E: indicates whether LO ODU4 is supported.

        Flag F: indicates whether LO ODU2e is supported.

        Flag G: indicates whether LO ODUflex is supported.

   For example, if one end of an OTU2 link supports LO ODU0, LO ODU1, LO
   ODUflex into HO ODU2 multiplexing and supports LO ODU2 into OTU2
   mapping, the flags A, B, C, and G will be set to 1.

   As a further example, if one end of an OTU2 link supports only LO
   ODU2 into OTU2 mapping but no multiplexing, only flag C will be set
   to 1.

   The remaining flags are reserved for future use and MUST be set to 0.

4.2.3. Procedures

   The Link Summary messages used for capability discovery for HO ODUk
   or OTUk link are sent between adjacent nodes after the HO ODU link is
   created or driven by some events (e.g., an operator command). The
   procedure is described below:

   o The local end of the HO ODU link sends a LinkSummary message
      including one or more DATA_LINK objects, each of which contains
      the Local_Interface_Id, the Remote_Interface_Id, and the HO ODU
      link capability subobject. This subobject carries the capability
      that the local end can support, i.e., the granularity of TS and
      the set of LO ODU signal types that the local end can support. The
      LinkSummary message is sent to the remote end.


Ceccarelli & Zhang       Expires April 2013                  [Page 10]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


   o On receipt of the LinkSummary message, the remote end of the HO
      ODU link firstly determines whether the local/remote Interface_Id
      mappings match those that are stored locally as described in
      [RFC4204], and then obtains the HO ODU link capability subobject
      and determines the capability of the HO ODU link that both ends
      can support. The detail procedures are as follow:

      - Only if both ends support the 1.25Gbps TS, the remote end would
         choose the 1.25Gbps as the negotiated granularity for the HO
         ODU link. In other cases, the 2.5Gbps TS MUST be used (e.g., if
         the local end can support 1.25Gbps, and the remote end can
         support 2.5Gbps, and then the local end should imitate 2.5Gbps).

      - The remote end compares the two sets of LO ODU signal types
         that the local end and the remote end can support, and
         calculates the intersection of them, i.e., extracts all the LO
         ODU signal types that both two ends can support. This
         intersection is the set of LO ODU signal types that the HO ODU
         link can support.

   o If both the two ends support the same capability, i.e., they
      support the same granularity of TS and the same LO ODU signal
      types, the remote end replies a LinkSummaryAck message to the
      local end. So the both ends know what capability the HO ODU link
      can support.

   o If the two ends support different capabilities, i.e., they support
      different granularities of TS or different LO ODU signal types,
      the remote end replies a LinkSummaryNack message to the local end.
      The LinkSummaryNack message carries an ERROR_CODE object and one
      or more DATA_LINK objects. The ERROR_CODE "Renegotiate
      LINK_SUMMARY parameters" (see [RFC4204]) indicates that the two
      ends of the HO ODU link support different capabilities, and the
      DATA_LINK object carries the HO ODU link capability subobject
      which contains the negotiated granularity of TS and the set of LO
      ODU signal types that both ends can support. The local end can
      learn the HO ODU link capability after receiving the
      LinkSummaryNack message.

   o If the remote end does not support the HO ODU link capability
      negotiation procedure, the LinkSummaryNack message MUST be
      responded with an ERROR_CODE "Not support of HO ODU Link
      Capability subobject" (TBA) indicating the reason of rejection.






Ceccarelli & Zhang       Expires April 2013                  [Page 11]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


5. Verifying Link Connectivity

   [RFC4204] defines a link verification procedure based on the in-band
   transmission of Test messages over the data links. It is used to
   verify the physical connectivity of such links, to discover data
   plane resources and to exchange the Interface_Ids. It is also
   possible to use a single procedure to verify multiple data links and
   correlate the information collected by means of the Verify_Id
   assigned to the procedure.

   The link verification procedure works as follows:

     - BeginVerify message: the local node sends a BeginVerify message
     over a control channel. It includes a BEGIN_VERIFY object which
     contains all the parameters characterizing the data link like, for
     example, the number of data links that must be verified, the
     transmission interval of the Test messages or the wavelength over
     which the Test messages will be sent.

     - BeginVerifyAck: if the remote node, upon receiving a BeginVerify
     message, is ready to begin the procedure, it replies with a
     BeginVerifyAck message. Such message specifies the desired
     transport mechanism for the Test messages and the Verify_Id of the
     procedure assigned by the remote node.

     - Data link Testing: the local node, upon receiving the
     BeginVerifyAck message, can begin testing the data links
     repeatedly sending Test messages over them.  The remote node will
     reply either with a TestStatsSuccess or a TestStatusFailure for
     each data link.  As a consequence the local node will send a
     TestStatusAck.

     - End of testing: The local node can terminate the Test procedure
     at anytime just sending an EndVerifyMessage towards the remote
     node.

   Evolutive OTNs need the support from LMP for the testing of all the
   possible data links defined by ITU-T.  This document provides, at
   present, support to the data links defined by G.709 and G.709
   amendment 3 recommendations and to G.Sup43 temporary document.

   The BEGIN_VERIFY class is defined in Section 13.8 of [RFC4204]. The
   following fields are extended: Encoding Type, Verify Transport
   Mechanism and Transmission Rate.





Ceccarelli & Zhang       Expires April 2013                  [Page 12]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


5.1. Encoding Type

   The Encoding Type identifies the type of encoding supported by the
   interface. LMP encoding type is consistent with the LSP encoding
   types defined for RSVP-TE [RFC3471]. In particular, the value to be
   used for G.709 hierarchy ODU and OTU signals is "Digital Wrapper".

5.2. Verify Transport Mechanism

   This field defines the transport mechanism for the Test messages and
   its scope depends on each encoding type.  It is a 16 bit mask set by
   the local node where each bit identifies the various mechanisms it
   can support for LMP test messages transmission.  This document
   defines the field values with respect to the G.709 digital encoding
   (they are expressed in network byte order).

      - 0x01 OTUk TTI: 64 byte Test Message

     Capability of transmitting Test messages using OTUk Trail Trace
     Identifier (TTI) overhead with frame length of 64 bytes. See ITU
     G.709 Section 15.2 and Section 15.7 for the structure and
     definition.  The Test message is sent according to [RFC4204].

      - 0x02 ODUk TTI: 64 byte Test Message

     Capability of transmitting Test messages using ODUk Trail Trace
     Identifier (TTI) overhead with frame length of 64 bytes. See ITU
     G.709 Section 15.2 and Section 15.8 for the structure and
     definition.  The Test message is sent according to [RFC4204].

      - 0x04 GCC0: Test Message over the GCC0

     Capability of transmitting Test messages using the OTUk Overhead
     General Communications Channel (GCC0).  See ITU G.709 Section 15.7
     for the structure and definition.  The Test message is sent
     according to [RFC4204] using bit-oriented HDLC framing format
     [RFC1662].

      - 0x08 GCC1/2: Test Message over the GCC1/2

     Capability of transmitting Test messages using the ODUk Overhead
     General Communications Channels (GCC1/2).  See ITU G.709 Section
     15.8 for the structure and definition.  The Test message is sent
     according to [RFC4204] using bit-oriented HDLC framing format
     [RFC1662].

     - 0x10 OTUk TTI - Section Trace Correlation


Ceccarelli & Zhang       Expires April 2013                  [Page 13]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


     Capability of transmitting OTUk Trail Trace Identifier (TTI) as
     defined in ITU-T G.709.  The Test message is not transmitted using
     the OTUk TTI overhead bytes (i.e. data link), but is sent over the
     control channel and correlated for consistency to the received
     pattern.  The correlation between the Interface_Id and the in-band
     pattern is achieved using the TRACE Object as defined in Section 4
     of [RFC4207]. No modification to TestStatusSuccess or
     TestStatusFailure messages is required.

      - 0x20 ODUk TTI - Path Trace Correlation

     Capability of transmitting ODUk Trail Trace Identifier (TTI) as
     defined in ITU-T G.709.  The Test message is not transmitted using
     the OTUk TTI overhead bytes (i.e. data link), but is sent over the
     control channel and correlated for consistency to the received
     pattern.  The correlation between the Interface_Id the Testmessage
     is sent from and the pattern sent in-band is achieved using the
     TRACE Object as defined in Section 4 of [RFC4207]. No modification
     to TestStatusSuccess or TestStatusFailure messages is required.

5.3. Transmission Rate

   The transmission rate of the data links where the link verification
   procedure can be performed is defined into the TransmissionRate field
   of the BEGIN_VERIFY class ([RFC4204] Section 13.8). Values are
   expressed in IEEE floating point format using a 32-bit number field
   and expressed in bytes per second. The following table defines the
   values to be used in OTNs:

           +-------------+-----------------+-------------------+

           | Signal Type | Bit-rate (kbps) | Value (Bytes/Sec) |

           +-------------+-----------------+-------------------+

           |    ODU0     |    1 244 160    |     0x4D1450C0    |

           +-------------+-----------------+-------------------+

           |    ODU1     |    2 498 775    |     0x4D94F048    |

           |    OTU1     |    2 666 057    |     0x4D9EE8CD    |

           +-------------+-----------------+-------------------+

           |    ODU2     |   10 037 274    |     0x4E959129    |



Ceccarelli & Zhang       Expires April 2013                  [Page 14]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


           |    OTU2     |   10 709 226    |     0x4E9F9475    |

           +-------------+-----------------+-------------------+

           |    ODU2e    |   10 399 525    |     0x4E9AF70A    |

           +-------------+-----------------+-------------------+

           |    ODU3     |   40 319 219    |     0X4F963367    |

           |    OTU3     |   43 018 416    |     0X4FA0418F    |

           +-------------+-----------------+-------------------+

           |    ODU4     |  104 794 445    |     0x504331E3    |

           |    OTU4     |  111 809 973    |     0x50504326    |

           +-------------+-----------------+-------------------+

                   Transmission Rate values (Bytes/Sec)



6. Trace Monitoring

   [RFC4207] describes the set of trace monitoring procedures that allow
   a node to do trace monitoring by using the G.709 hierarchy
   capabilities.

   This document defines a new C-Type of the TRACE Object class used for
   Trace Monitoring features as defined in [RFC4207].

6.1. TRACE Object for evolutive OTN

   The TRACE Object Class assigned by IANA is 21. A new C-Type is TBA
   and value 2 is suggested. The TRACE Object format is the same as
   defined in [RFC4207] and is shown in the following:

    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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |N|   C-Type    |     Class     |            Length             |



Ceccarelli & Zhang       Expires April 2013                  [Page 15]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |           Trace Type          |          Trace Length         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                                                               |

   //                         Trace Message                       //

   |                                                               |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            TRACE Object Class

   Trace Type: 16 bits

   The Trace Type field is used to identify the type of the trace
   message. The following values are defined and all other values are
   reserved and should be sent as zero and ignored on receipt.

           1 = OTUk TTI

           2 = ODUk TTI

           3 = Level 1 ODUkT TTI

           4 = Level 2 ODUkT TTI

           5 = Level 3 ODUkT TTI

           6 = Level 4 ODUkT TTI

           7 = Level 5 ODUkT TTI

           8 = Level 6 ODUkT TTI (default for layer adjacency discovery)

   It shall be noted that an Amendment to ITU-T G.7714.1 has been
   approved in September 2010 that defines an extension for OTN layer
   adjacency discovery based on the ODUk TCM function (ODUkT) providing
   6 TCM levels. By default the TCM level 6 SHALL be used.

   Trace Length: 16 bits

   Expresses the length of the trace message in bytes (as specified by
   the Trace Type).


Ceccarelli & Zhang       Expires April 2013                  [Page 16]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


   Trace Message:

   This field includes the value of the expected message to be received
   in-band.  The valid length and value combinations are determined by
   the ITU.T G.709 recommendation. The message MUST be padded with
   zeros to a 32-bit boundary, if necessary.  Trace Length does not
   include padding zeroes.

   This object is non negotiable.

6.2. Discovery Response Message for Layer Adjacency Discovery

   ITU-T Recommendation G.7714.1 [ITUT-G.7714.1] describes an automatic
   layer adjacency discovery procedure that can be applied to the ITU-T
   G.709 OTN technology. The discovery message can be sent to the
   adjacent node via the Trail Trace Identifier (TTI) and Appendix III
   of G.7714.1 describes how the discovery response message can be sent
   back to the originator of the discovery message (discovery agent in
   G.7714.1 terminology) using the LMP protocol.

   As defined in [ITUT-G.7714.1], the TraceMonitor message [RFC4207] is
   used to convey the discovery response message.  The following mapping
   table shows how the discovery response message attributes are mapped
   to TraceMonitor message objects or other fields of the LMP message
   (see G.7714.1, section 11 for the description of the attributes):

                                 |

   G.7714.1 discovery response   |   TraceMonitor/LMP message field

   message attribute             |

---------------------------------+--------------------------------------

  <Received DA DCN ID>           |   <TRACE>: received discovery message

                                 |

  <Received TCP-ID>              |   <TRACE>: received discovery message

                                 |

   <Sent DA DCN ID>              |   IP source address in the IP header

                                 |

   <Sent Tx TCP-ID>              |   identical to <Sent Rx TCP-ID>


Ceccarelli & Zhang       Expires April 2013                  [Page 17]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


                                 |

   <Sent Rx TCP-ID>              |   <LOCAL_INTERFACE_ID>

                                 |

   The received TTI, more specifically the discovery message in the SAPI
   field contains the <Received DA DCN ID> and the <Received TCP-ID>.
   These attributes are included in the discovery response message by
   copying the received TTI into the <TRACE> field of the TraceMonitor
   message.

   The IP address of the node sending the discovery response message
   corresponds to the <Sent_DA_DCN_ID> and is the IP source address in
   the IP header of the LMP TraceMonitor message.

   Typically, the Trail Connection Point (TCP-)IDs in transmit and
   receive direction are identical for OTN equipment, i.e., the <Sent Rx
   TCP-ID> is identical to the <Sent Tx TCP-ID>.  The <Sent Rx TCP-ID>
   identifies the TCP on which the Discovery Message was received and
   corresponds to the <LOCAL_INTERFACE_ID> object in the TraceMonitor
   message.

7. LMP Behavior Negotiation Update

   This docuemnt also introduces an update to the BehaviorConfig C-Type
   defined in [LMP-NEG]. A new flag in the BehaviorConfig is needed for
   the indication of the support for OTN Test Messages:

    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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |S|D|C|O|                 Must Be Zero (MBZ)                    |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      - O: 1 bit

     This bit indicates support for the TEST behavior of OTN
     technology-specific defined in this document.

8. Security Considerations

   TBD.


Ceccarelli & Zhang       Expires April 2013                  [Page 18]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


9. IANA Considerations

   TBD.

10. Acknowledgments

   TBD.

11. References

11.1. Normative References

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

   [RFC4204]   J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204,
               October 2005.

   [OTN-frwk]  Zhang, F. et al, "Framework for GMPLS and PCE Control of
               G.709 Optical Transport Networks", draft-ietf-ccamp-
               gmpls-g709-framework-08.txt, June 19, 2012.

   [ITUT-G709] ITU-T, "Interface for the Optical Transport Network
               (OTN)", G.709 Recommendation, March 2003.

   [G709-V3]   ITU-T, "Interfaces for the Optical Transport Network
               (OTN)", G.709 Recommendation, December 2009.

   [ITUT-G.7714.1] ITU-T, "Protocol for automatic discovery in SDH and
               OTN networks, G.7714.1 Recommendation", April 2003.

   [RFC1662]  Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
               July 1994.

   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
               (GMPLS) Signaling Functional Description", RFC 3471,
               January 2003.

   [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
               (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4207]  Lang, J. and D. Papadimitriou, "Synchronous Optical
             Network (SONET)/Synchronous Digital Hierarchy (SDH)
             Encoding for Link Management Protocol (LMP) Test
             Messages", RFC 4207, October 2005.




Ceccarelli & Zhang       Expires April 2013                  [Page 19]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


11.2. Informative References

   [RFC3945]   Mannie, E., "Generalized Multi-Protocol Label Switching
               (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4328]   D. Papadimitriou, Ed. "Generalized Multi-Protocol Label
               Switching (GMPLS) Signaling Extensions for G.709 Optical
               Transport Networks Control", RFC 4328, Jan 2006.

   [LMP-NEG]   D.Li, D.Ceccarelli, L.Berger, "Link Management Protocol
               Behavior Negotiation and Configuration Modifications," July
               2012, draft-ietf-ccamp-lmp-behavior-negotiation-06.

12. Authors' Addresses

   Fatai Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972912
   Email: zhangfatai@huawei.com


   Xian Zhang
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972913
   Email: zhang.xian@huawei.com

   Daniele Ceccarelli
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: daniele.ceccarelli@ericsson.com




Ceccarelli & Zhang       Expires April 2013                  [Page 20]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


   Diego Caviglia
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: diego.caviglia@ericsson.com


   Francesco Fondelli
   Ericsson
   Via Moruzzi 1
   Pisa
   Italy

   Email: francesco.fondelli@ericsson.com

   Guoying Zhang
   China Academy of Telecommunication Research of MII
   11 Yue Tan Nan Jie Beijing, P.R.China

   Phone: +86-10-68094272
   Email: zhangguoying@mail.ritt.com.cn

   Pietro Grandi
   Alcatel-Lucent
   Optics CTO
   Via Trento 30 20059 Vimercate (Milano) Italy
   +39 039 6864930

   Email: pietro_vittorio.grandi@alcatel-lucent.it

   Sergio Belotti
   Alcatel-Lucent
   Optics CTO
   Via Trento 30 20059 Vimercate (Milano) Italy
   +39 039 6863033

   Email: sergio.belotti@alcatel-lucent.it

   Dan Li


Ceccarelli & Zhang       Expires April 2013                  [Page 21]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Shenzhen 518129 P.R.China  Bantian, Longgang District
   Phone: +86-755-28973237

   Email: danli@huawei.com


   Dieter Beller
   Alcatel-Lucent
   Lorenzstrasse 10
   Stuttgart  70435
   Germany

   Email: dieter.beller@alcatel-lucent.com

13. Contributors

   Yi Lin
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972914
   Email: yi.lin@huawei.com


Intellectual Property

   The IETF Trust takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the technology
   described in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or
   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers or
   users of this specification can be obtained from the IETF on-line IPR
   repository at http://www.ietf.org/ipr


Ceccarelli & Zhang       Expires April 2013                  [Page 22]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

   The definitive version of an IETF Document is that published by, or
   under the auspices of, the IETF. Versions of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, the IETF. Versions of
   these Legal Provisions that are published by third parties, including
   those that are translated into other languages, should not be
   considered to be definitive versions of these Legal Provisions.

   For the avoidance of doubt, each Contributor to the IETF Standards
   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to the
   provisions of RFC 5378. No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect and
   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.


Disclaimer of Validity

   All IETF Documents and the information contained therein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.


Full Copyright Statement

   Copyright (c) 2012 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



Ceccarelli & Zhang       Expires April 2013                  [Page 23]


draft-cecczhang-ccamp-gmpls-g.709v3-lmp-00.txt            October  2012


   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.










































Ceccarelli & Zhang       Expires April 2013                  [Page 24]