draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt   draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt 
Network Working Group J.P. Lang Network Working Group J.P. Lang
Internet Draft (Rincon Networks) Internet Draft (Rincon Networks)
Category: Standards Track Category: Standards Track
Expires: September 2003 D. Papadimitriou Expires: September 2003 D. Papadimitriou
(Alcatel) (Alcatel)
March 2003 May 2003
SONET/SDH Encoding for Link Management SONET/SDH Encoding for Link Management
Protocol (LMP) Test messages Protocol (LMP) Test messages
draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
This document details the Synchronous Optical NETwork (SONET)/ This document details the Synchronous Optical NETwork (SONET)/
Synchronous Digital Hierarchy (SDH) technology specific information Synchronous Digital Hierarchy (SDH) technology specific information
needed when sending Link Management Protocol (LMP) test messages. needed when sending Link Management Protocol (LMP) test messages.
[Editor's note: "Changes from previous version" notes can be removed [Editor's note: "Changes from previous version" notes can be removed
prior to publication as an RFC.] prior to publication as an RFC.]
Changes from previous version: Changes from previous version:
o Editorial changes resulting from AD review. o Removed Jx-16 message formats
1. Introduction 1. Introduction
For scalability purposes, multiple physical resources that For scalability purposes, multiple physical resources that
interconnect LSRs can be combined to form a single traffic interconnect LSRs can be combined to form a single traffic
engineering (TE) link for the purposes of path computation and engineering (TE) link for the purposes of path computation and
signaling. These resources may represent one or more physical links signaling. These resources may represent one or more physical links
that connect the LSRs, or they may represent a Label Switched Path that connect the LSRs, or they may represent a Label Switched Path
(LSP) if LSP hierarchy [LSP-HIER] is used. The management of TE (LSP) if LSP hierarchy [LSP-HIER] is used. The management of TE
links is not restricted to in-band messaging, but instead can be links is not restricted to in-band messaging, but instead can be
skipping to change at page 2, line 47 skipping to change at page 2, line 47
exchange. Link property correlation is used to aggregate multiple exchange. Link property correlation is used to aggregate multiple
data links into a single TE Link and to synchronize the link data links into a single TE Link and to synchronize the link
properties. Link verification is used to verify the physical properties. Link verification is used to verify the physical
connectivity of the data links and to exchange the Interface_Ids of connectivity of the data links and to exchange the Interface_Ids of
the data links. Fault management is primarily used to suppress the data links. Fault management is primarily used to suppress
alarms and to localize failures in both opaque and transparent alarms and to localize failures in both opaque and transparent
networks. When LMP is used with SONET/SDH, however, the fault networks. When LMP is used with SONET/SDH, however, the fault
management procedures may not be needed as existing SONET/SDH management procedures may not be needed as existing SONET/SDH
mechanisms can be used. mechanisms can be used.
In this document, we define SONET/SDH technology specific In this document, the SONET/SDH technology specific information for
information needed when running LMP. Specifically, we define the LMP is defined. Specifically, the SONET/SDH test procedures used for
SONET/SDH test procedures used for Link verification and link Link verification and link property correlation are detailed. These
property correlation. This requires a new trace monitoring function procedures include the trace correlation transport mechanism
that is discussed in this document. Once the data links have been (defined for J0, J1, J2) that supports a separation of the transport
verified, they can be grouped to form TE links. and control plane identifiers. This requires a new trace monitoring
function that is also discussed in this document. Once the data
links have been verified, they can be grouped to form TE links.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The reader is assumed to be familiar with the terminology in [LMP], The reader is assumed to be familiar with the terminology in [LMP],
[G.707], and [T1.105]. The following abbreviations are used in this [G.707], and [T1.105]. The following abbreviations are used in this
document: document:
skipping to change at page 4, line 21 skipping to change at page 4, line 21
The defined encoding is consistent with the LSP Encoding Type as The defined encoding is consistent with the LSP Encoding Type as
defined in [RFC 3471]. For SONET/SDH, this value must equal the defined in [RFC 3471]. For SONET/SDH, this value must equal the
value given for "SDH ITU-T G.707/ SONET ANSI T1.105". value given for "SDH ITU-T G.707/ SONET ANSI T1.105".
The transport mechanism is defined using the Verify Transport The transport mechanism is defined using the Verify Transport
Mechanism bit mask. The scope of this bit mask is restricted to the Mechanism bit mask. The scope of this bit mask is restricted to the
link encoding type. Multiple bits may be set when this field is link encoding type. Multiple bits may be set when this field is
included in the BeginVerify message; however, only one bit may be included in the BeginVerify message; however, only one bit may be
set when it is included in the BeginVerifyAck message. set when it is included in the BeginVerifyAck message.
In the following subsection, we define the various options for In the following subsection, the various options for Verify
Verify Transport Mechanism when the encoding is SONET/SDH. Transport Mechanism are defined when the encoding is SONET/SDH. The
trace correlation transport mechanism (defined for J0, J1, J2)
supports a separation of the transport and control plane
identifiers.
3.1. Verify Transport Mechanism 3.1. Verify Transport Mechanism
This field is 16 bits in length. This field is 16 bits in length.
In this document, we define the flags for SONET/SDH encoding. Note In this document, the flags for SONET/SDH encoding are defined.
that all values are defined in network byte order (i.e., big-endian Note that all values are defined in network byte order (i.e., big-
byte order). endian byte order).
0x0001 J0-16: 16 byte J0 Test Message
Capable of transmitting Test messages using J0 overhead
bytes with frame length of 16 bytes (with CRC-7). See
table 9-1 of ITU G.707 [G.707] for the 16-byte J0
definition. The definition of CRC-7 is found in Annex B
of ITU G.707.
Note that due to the byte limitation, the Test message
is NOT sent as an IP packet and as such, no layer 2
encapsulation is used. A dedicated Test message format
is defined as follows:
The Test message (i.e., the string inserted into the
frame) is a 15-byte message, where the 7 most
significant bits (msb) of each byte are usable. Due to
the byte limitation, the LMP Header is not included.
The first usable 4 bits are reserved. These bits MUST
be sent as zero and ignored on receipt. The next usable
2 bits are used to identify the message type. For the
Test message, this value is 0. The next usable bit is
used to determine the address type of the Interface_Id.
For IPv4, this value is 0. For unnumbered, this value
is 1. The next usable 32 bits MUST be the Interface_Id.
The next usable 32 bits MUST be the Verify_Id that was
received in the VERIFY_ID object of the BeginVerifyAck
message. The remaining bits are reserved and should be
sent as zero and ignored on receipt.
Note that this Test Message format is only valid when 0x0001 : Reserved
the Interface_Id is either IPv4 or unnumbered.
0x0002 DCCS: Test Message over the Section/RS DCC 0x0002 DCCS: Test Message over the Section/RS DCC
Capable of transmitting Test messages using the DCC Capable of transmitting Test messages using the DCC
Section/RS Overhead bytes with bit-oriented HDLC Section/RS Overhead bytes with bit-oriented HDLC
framing format [RFC1662]. framing format [RFC1662].
The Test message is sent as defined in [LMP]. The Test message is sent as defined in [LMP].
0x0004 DCCL: Test Message over the Line/MS DCC 0x0004 DCCL: Test Message over the Line/MS DCC
skipping to change at page 6, line 4 skipping to change at page 5, line 24
over which the J0 test message is sent and the J0 over which the J0 test message is sent and the J0
pattern sent in-band, the transmitting node must pattern sent in-band, the transmitting node must
provide the correlation between this pattern and the J0 provide the correlation between this pattern and the J0
test message. This correlation is done using the TRACE test message. This correlation is done using the TRACE
object as defined in Section 4. object as defined in Section 4.
The format of the test message is as follows: The format of the test message is as follows:
<Test Message> ::=<Common Header> <LOCAL_INTERFACE_ID> <Test Message> ::=<Common Header> <LOCAL_INTERFACE_ID>
<VERIFY_ID> <TRACE> <VERIFY_ID> <TRACE>
0x0010 J1-16: 16 byte J1 Test Message
Capable of transmitting Test messages using the SDH
HOVC J1 Path Trace byte (frame length of 16 bytes with
CRC-7), see [G.707].
Note that due to the byte limitation, the Test message
is NOT sent as an IP packet and as such, no layer 2
encapsulation is used. The Test message format defined
above for J0-16 is used.
Note that this Test Message format is only valid when 0x0010: Reserved
the Interface_Id is either IPv4 or unnumbered.
0x0020 J2-16: 16 byte J2 Test Message
Capable of transmitting Test messages using the
SONET/SDH VT SPE/LOVC J2 Path Trace byte (frame length
of 16 bytes with CRC-7), see [T1.105] and [G.707].
Note that due to the byte limitation, the Test message 0x0020: Reserved
is NOT sent as an IP packet and as such, no layer 2
encapsulation is used. The Test message format defined
above for J0-16 is used.
0x0040 J1-trace: J1 Path Trace Correlation 0x0040 J1-trace: J1 Path Trace Correlation
Capable of transmitting SONET/SDH STS SPE/HOVC Path Capable of transmitting SONET/SDH STS SPE/HOVC Path
trace over J1 Path overhead byte as defined in [T1.105] trace over J1 Path overhead byte as defined in [T1.105]
and [G.707]. and [G.707].
The Test message is not transmitted using the J1 bytes The Test message is not transmitted using the J1 bytes
(i.e., over the data link), but is sent over the (i.e., over the data link), but is sent over the
control channel and correlated for consistency to the control channel and correlated for consistency to the
skipping to change at page 16, line 13 skipping to change at page 15, line 13
Email: jplang@ieee.org email: dimitri.papadimitriou@alcatel.be Email: jplang@ieee.org email: dimitri.papadimitriou@alcatel.be
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/