[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

CCAMP Working Group                                        D. Ceccarelli
Internet-Draft                                               D. Caviglia
Intended status: Standards Track                             F. Fondelli
Expires: November 13, 2010                                      Ericsson
                                                                F. Zhang
                                                                   D. Li
                                                     Huawei Technologies
                                                                M. Corsi
                                                                  Altran
                                                               D. Beller
                                                          Alcatel-Lucent
                                                            May 12, 2010


 Link Management Protocol (LMP) Test Messages Extensions for Evolutive
                    Optical Transport Networks (OTN)
             draft-ceccarelli-ccamp-gmpls-g709-lmp-test-02

Abstract

   This document specifies Link Management Protocol (LMP) extensions for
   the support of enhanced Optical Transport Networks (OTN).  In
   particular it updates LMP test messages detailing the ITU-T G.709 OTN
   technology specific information and extends them in order to cover
   also recently introduced signal types and containers defined by the
   ITU-T.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 13, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Ceccarelli, et al.      Expires November 13, 2010               [Page 1]

Internet-Draft     G709 Encoding for LMP Test Messages          May 2010


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Verifying Link Connectivity  . . . . . . . . . . . . . . . . .  3
     3.1.  Encoding Type  . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Verify Transport Mechanism . . . . . . . . . . . . . . . .  5
     3.3.  Transmission Rate  . . . . . . . . . . . . . . . . . . . .  6
   4.  Trace Monitoring . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  TRACE Object for evolutive OTN . . . . . . . . . . . . . .  7
     4.2.  Discovery Response Message for Layer Adjacency
           Discovery  . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10





















Ceccarelli, et al.      Expires November 13, 2010               [Page 2]

Internet-Draft     G709 Encoding for LMP Test Messages          May 2010


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


2.  Introduction

   [RFC4204] defines the Link Management Protocol (LMP), which is a
   protocol of the Generalized Multi-Protocol Label Switching (GMPLS)
   [RFC3945] suite used to manage Traffic Engineering (TE) links.  A TE
   link may be made by multiple physical resources interconnecting Label
   Switched Routers (LSRs), that are combined together for scalability
   reasons.

   Current definition of LMP consists of two mandatory procedures:

      - Control channel management: used to maintain control channels
      connectivity between adjacent LSRs.  Such procedure is based on
      the exchange of a message called Config message followed by a
      lightweight keep-alive message exchange

      - Link property correlation: used to combine multiple physical
      links into a single TE link.

   and two optional procedures:

      - Link verification: used to verify the connectivity of the
      physical links composing a TE link and to exchange their
      Interface_Ids

      - Fault management: used to suppress alarms and locate failures.
      This feature may not be needed in G.709 networks because fault
      management mechanisms are provided by the G.709 architecture.

   This document defines G.709 technology specific information needed
   when running LMP.  In particular it is focused on 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.


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



Ceccarelli, et al.      Expires November 13, 2010               [Page 3]

Internet-Draft     G709 Encoding for LMP Test Messages          May 2010


   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.

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




Ceccarelli, et al.      Expires November 13, 2010               [Page 4]

Internet-Draft     G709 Encoding for LMP Test Messages          May 2010


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

      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



Ceccarelli, et al.      Expires November 13, 2010               [Page 5]

Internet-Draft     G709 Encoding for LMP Test Messages          May 2010


      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 Test
      message 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.

3.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.  Non normative Signal Types are marked
   with (*):


           +-------------+-----------------+-------------------+
           | Signal Type | Bit-rate (kbps) | Value (Bytes/Sec) |
           +-------------+-----------------+-------------------+
           |    ODU0     |    1 244 160    |     0x4D1440C0    |
           +-------------+-----------------+-------------------+
           |    ODU1     |    2 498 775    |     0x4D94F048    |
           |    OTU1     |    2 666 057    |     0x4D9EE8CD    |
           +-------------+-----------------+-------------------+
           |    ODU2     |   10 037 274    |     0x4E959129    |
           |    OTU2     |   10 709 226    |     0x4E9F9475    |
           +-------------+-----------------+-------------------+
           |    ODU2e    |   10 399 525    |     0x4E9AF70A    |
           +-------------+-----------------+-------------------+
           |    ODU3     |   40 319 219    |     0X4F963367    |
           |    OTU3     |   43 018 416    |     0X4FA0418F    |
           +-------------+-----------------+-------------------+
           |    ODU3e1*  |   41 774 364    |     0x4F9B9F23    |
           |    OTU3e1*  |   44 570 974    |     0x4FA60A31    |
           |    ODU3e2*  |   41 785 968    |     0x4F9BAA34    |
           |    OTU3e2*  |   44 583 355    |     0x4FA61600    |
           +-------------+-----------------+-------------------+
           |    ODU4     |  104 794 445    |     0x504331E3    |
           |    OTU4     |  111 809 973    |     0x50504326    |



Ceccarelli, et al.      Expires November 13, 2010               [Page 6]

Internet-Draft     G709 Encoding for LMP Test Messages          May 2010


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


                   Transmission Rate values (Bytes/Sec)


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

4.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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           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.









Ceccarelli, et al.      Expires November 13, 2010               [Page 7]

Internet-Draft     G709 Encoding for LMP Test Messages          May 2010


           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 is planned to
   be approved in June 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).

   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.

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






Ceccarelli, et al.      Expires November 13, 2010               [Page 8]

Internet-Draft     G709 Encoding for LMP Test Messages          May 2010


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


5.  Security Considerations

   TBD


6.  Acknowledgements

   The authors would like to thank Attila Takacs, Andras Kern, Sergio
   Belotti and Pietro Grandi for the kind review of the ID and the
   valuable comments provided.







Ceccarelli, et al.      Expires November 13, 2010               [Page 9]

Internet-Draft     G709 Encoding for LMP Test Messages          May 2010


7.  IANA Considerations

   A new C-Type value for the Trace Object Class (21) is TBA by IANA.


8.  References

8.1.  Normative References

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

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

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

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

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

8.2.  Informative References

   [ITUT-G.709]
              ITU-T, "Interface for the Optical Transport Network
              (OTN)", G.709 Recommendation (and Amendment 1),
              February 2001.











Ceccarelli, et al.      Expires November 13, 2010              [Page 10]

Internet-Draft     G709 Encoding for LMP Test Messages          May 2010


Authors' Addresses

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

   Email: daniele.ceccarelli@ericsson.com


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

   Email: diego.caviglia@ericsson.com


   Francesco Fondelli
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: francesco.fondelli@ericsson.com


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

   Email: zhangfatai@huawei.com


   Dan Li
   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






Ceccarelli, et al.      Expires November 13, 2010              [Page 11]

Internet-Draft     G709 Encoding for LMP Test Messages          May 2010


   Marco Corsi
   Altran
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: marco.corsi@altran.it


   Dieter Beller
   Alcatel-Lucent
   Lorenzstrasse 10
   Stuttgart  70435
   Germany

   Email: dieter.beller@alcatel-lucent.com



































Ceccarelli, et al.      Expires November 13, 2010              [Page 12]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/