CCAMP Working Group D. Ceccarelli
Internet-Draft D. Caviglia
Intended status: Standards Track F. Fondelli
Expires: January 13, 2013 Ericsson
F. Zhang
D. Li
Huawei Technologies
D. Beller
Alcatel-Lucent
July 12, 2012
Link Management Protocol (LMP) Test Messages Extensions for Evolutive
Optical Transport Networks (OTN)
draft-ceccarelli-ccamp-gmpls-g709-lmp-test-04
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 January 13, 2013.
Copyright Notice
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
Ceccarelli, et al. Expires January 13, 2013 [Page 1]
Internet-Draft G709 Encoding for LMP Test Messages July 2012
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. LMP Behavior Negotiation update . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Ceccarelli, et al. Expires January 13, 2013 [Page 2]
Internet-Draft G709 Encoding for LMP Test Messages July 2012
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 January 13, 2013 [Page 3]
Internet-Draft G709 Encoding for LMP Test Messages July 2012
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 January 13, 2013 [Page 4]
Internet-Draft G709 Encoding for LMP Test Messages July 2012
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 January 13, 2013 [Page 5]
Internet-Draft G709 Encoding for LMP Test Messages July 2012
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:
+-------------+-----------------+-------------------+
| 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 |
| 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)
Ceccarelli, et al. Expires January 13, 2013 [Page 6]
Internet-Draft G709 Encoding for LMP Test Messages July 2012
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.
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)
Ceccarelli, et al. Expires January 13, 2013 [Page 7]
Internet-Draft G709 Encoding for LMP Test Messages July 2012
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).
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 January 13, 2013 [Page 8]
Internet-Draft G709 Encoding for LMP Test Messages July 2012
|
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. 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ceccarelli, et al. Expires January 13, 2013 [Page 9]
Internet-Draft G709 Encoding for LMP Test Messages July 2012
- O: 1 bit
This bit indicates support for the TEST behavior of OTN
technology-specific defined in this document
6. Security Considerations
TBD
7. 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.
8. IANA Considerations
A new C-Type value for the Trace Object Class (21) is TBA by IANA.
9. References
9.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
Ceccarelli, et al. Expires January 13, 2013 [Page 10]
Internet-Draft G709 Encoding for LMP Test Messages July 2012
Network (SONET)/Synchronous Digital Hierarchy (SDH)
Encoding for Link Management Protocol (LMP) Test
Messages", RFC 4207, October 2005.
9.2. Informative References
[ITUT-G.709]
ITU-T, "Interface for the Optical Transport Network
(OTN)", G.709 Recommendation (and Amendment 1),
February 2001.
Authors' Addresses
Daniele Ceccarelli
Ericsson
Via E. Melen 77
Genova - Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
Diego Caviglia
Ericsson
Via E. Melen 77
Genova - Sestri Ponente
Italy
Email: diego.caviglia@ericsson.com
Francesco Fondelli
Ericsson
Via Moruzzi 1
Pisa
Italy
Email: francesco.fondelli@ericsson.com
Ceccarelli, et al. Expires January 13, 2013 [Page 11]
Internet-Draft G709 Encoding for LMP Test Messages July 2012
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
Dieter Beller
Alcatel-Lucent
Lorenzstrasse 10
Stuttgart 70435
Germany
Email: dieter.beller@alcatel-lucent.com
Ceccarelli, et al. Expires January 13, 2013 [Page 12]