CCAMP Working Group D. Ceccarelli
Internet-Draft D. Caviglia
Intended status: Standards Track F. Fondelli
Expires: March 26, 2010 Ericsson
F. Zhang
D. Li
Huawei Technologies
M. Corsi
Altran
September 22, 2009
Link Management Protocol (LMP) Test Messages Extensions for Evolutive
Optical Transport Networks (OTN)
draft-ceccarelli-ccamp-gmpls-g709-lmp-test-00
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 March 26, 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
Ceccarelli, et al. Expires March 26, 2010 [Page 1]
Internet-Draft G709 Encoding for LMP Test Messages September 2009
and restrictions with respect to this document.
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 defined in old internet draft
detailing the ITU-T G.709 OTN technology specific information and
extends them in order to cover also recently introduced signal types
and containters defined by the ITU-T.
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
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. Acknoledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Ceccarelli, et al. Expires March 26, 2010 [Page 2]
Internet-Draft G709 Encoding for LMP Test Messages September 2009
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 document. 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 March 26, 2010 [Page 3]
Internet-Draft G709 Encoding for LMP Test Messages September 2009
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 raccomendations and to G.Sup43 temporary document.
The BEGIN_VERIFY class is defined in Section 13.8 of [RFC4204]. The
following fields are updated: 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 March 26, 2010 [Page 4]
Internet-Draft G709 Encoding for LMP Test Messages September 2009
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 oder).
- 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 accordingly 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 accordingly 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
accordingly 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
accordingly 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 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
Ceccarelli, et al. Expires March 26, 2010 [Page 5]
Internet-Draft G709 Encoding for LMP Test Messages September 2009
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 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 |
Ceccarelli, et al. Expires March 26, 2010 [Page 6]
Internet-Draft G709 Encoding for LMP Test Messages September 2009
| OTU4 | 111 809 973 | 0x50504326 |
+-------------+-----------------+-------------------+
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.
1 = OTUk TTI
2 = ODUk TTI
Ceccarelli, et al. Expires March 26, 2010 [Page 7]
Internet-Draft G709 Encoding for LMP Test Messages September 2009
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.
5. Security Considerations
TBD
6. Acknoledgements
TBD
7. IANA Considerations
A new C-Type value for the Trace Object Class (21) is TBA by IANA.
8. References
8.1. Normative References
[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.
Ceccarelli, et al. Expires March 26, 2010 [Page 8]
Internet-Draft G709 Encoding for LMP Test Messages September 2009
[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.
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
Ceccarelli, et al. Expires March 26, 2010 [Page 9]
Internet-Draft G709 Encoding for LMP Test Messages September 2009
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: zhangfatai@huawei.com
Marco Corsi
Altran
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: marco.corsi@altran.it
Ceccarelli, et al. Expires March 26, 2010 [Page 10]