Network Working Group J. Lang
Internet Draft Calient Networks
Category: Standards Track D. Papadimitriou
Expires: March 2003 Alcatel
September 2002
SONET/SDH Encoding for Link Management
Protocol (LMP) Test messages
draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This document details the Synchronous Optical NETwork
(SONET)/Synchronous Digital Hierarchy (SDH) technology specific
information needed when sending Link Management Protocol (LMP) test
messages.
J. Lang and D. Papadimitriou [Page 1]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
1. Introduction
For scalability purposes, multiple physical resources that
interconnect LSRs can be combined to form a single traffic
engineering (TE) link for the purposes of path computation and
signaling. These resources may represent one or more physical links
that connect the LSRs, or they may represent a Label Switched Path
(LSP) if LSP hierarchy [LSP-HIER] is used. The management of TE
links is not restricted to in-band messaging, but instead can be
done using out-of-band techniques.
The Link Management Protocol (LMP) [LMP] is being developed as part
of the Generalized MPLS (GMPLS) protocol suite to manage traffic
engineering (TE) links. LMP currently consists of four main
procedures, of which, the first two are mandatory and the last two
are optional:
1. Control channel management
2. Link property correlation
3. Link verification
4. Fault management
Control channel management is used to establish and maintain control
channel connectivity between adjacent nodes. This is done using a
Config message exchange followed by a lightweight keep-alive message
exchange. Link property correlation is used to aggregate multiple
data links into a single TE Link and to synchronize the link
properties. Link verification is used to verify the physical
connectivity of the data links and to exchange the Interface_Ids of
the data links. Fault management is primarily used to suppress
alarms and to localize failures in both opaque and transparent
networks. When LMP is used with SONET/SDH, however, the fault
management procedures may not be needed as existing SONET/SDH
mechanisms can be used.
In this document, we define SONET/SDH technology specific
information needed when running LMP. Specifically, we define the
SONET/SDH test procedures used for Link verification and link
property correlation. This requires a new trace monitoring function
that is discussed in this document. Once the data links have been
verified, they can be grouped to form TE links.
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].
The reader is assumed to be familiar with the terminology in [LMP],
[G707], and [T1105]. The following abbreviations are used in this
document:
J. Lang and D. Papadimitriou [Page 2]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
CRC-N: Cyclic Redundancy Check-N.
DCC: Data communications channel.
LOVC: Lower order virtual container
HOVC: Higher order virtual container
MS: Multiplex section.
MSOH: Multiplex section overhead.
POH: Path overhead.
RS: Regenerator section.
RSOH: Regenerator section overhead.
SDH: Synchronous digital hierarchy.
SOH: Section overhead.
SONET: Synchronous Optical Network.
STM(-N): Synchronous Transport Module (-N) (SDH).
STS(-N): Synchronous Transport Signal-Level N (SONET).
VC-n: Virtual Container-n (SDH).
VTn: Virtual Tributary-n (SONET).
3. Verifying Link Connectivity
In [LMP], a link verification procedure is defined whereby Test
messages are transmitted in-band over the data links. This is used
for data plane discovery, Interface_Id exchange (Interface_Ids are
used in GMPLS signaling, either as port labels [GMPLS-SIG] or
component link identifiers [BUNDLE], depending on the
configuration), and physical connectivity verification. Multiple
data links can be verified using a single verification procedure;
the correlation is done using the Verify_Id that is assigned to the
procedure.
As part of the link verification procedure, a BeginVerify message
exchange is used to agree upon parameters for the Test procedure.
This can be initiated by sending a BeginVerify message over the
control channel. This message includes a BEGIN_VERIFY object that
contains a number of fields specifying, among other things, the
transmission (bit) rate, encoding type, and transport mechanisms for
the Test messages. If the remote node receives a BeginVerify
message and is ready to begin the procedure, it sends a
J. Lang and D. Papadimitriou [Page 3]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
BeginVerifyAck message specifying the desired transport mechanism
for the Test messages. The remote node also assigns a Verify_Id to
the procedure and includes it in the BeginVerifyAck message.
The transmission rate of the data link over which the Test messages
will be transmitted is represented in IEEE floating point format
using a 32-bit number field and expressed in bytes per second. See
[GMPLS-SIG] for values defined for SONET/SDH.
The encoding type identifies the encoding supported by an interface.
The defined encoding is consistent with the LSP Encoding Type as
defined in [GMPLS-SIG]. For SONET/SDH, this value must equal the
value given for "SDH ITU-T G.707/ SONET ANSI T1.105".
The transport mechanism is defined using the Verify Transport
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
included in the BeginVerify message; however, only one bit may be
set when it is included in the BeginVerifyAck message.
In the following subsection, we define the various options for
Verify Transport Mechanism when the encoding is SONET/SDH.
3.1. Verify Transport Mechanism
This field is 16 bits in length.
In this document, we define the flags for SONET/SDH encoding. Note
that all values are defined in network byte order (i.e., big-endian
byte order).
0x01 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 [G707] 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 special 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.
J. Lang and D. Papadimitriou [Page 4]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
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
the Interface_Id is either IPv4 or unnumbered.
0x02 J0-64: 64 byte J0 Test Message
Capable of transmitting Test messages using J0 overhead
bytes with frame length of 64 bytes (see [T1105]).
Note that this is only appropriate for SONET encoding
and not SDH encoding.
The Test message is sent as defined in [LMP].
0x04 DCCS: Test Message over the Section/RS DCC
Capable of transmitting Test messages using the DCC
Section/RS Overhead bytes with bit-oriented HDLC
framing format [RFC1662].
The Test message is sent as defined in [LMP].
0x08 DCCL: Test Message over the Line/MS DCC
Capable of transmitting Test messages using the DCC
Line/MS Overhead bytes with bit-oriented HDLC framing
format [RFC1662].
The Test message is sent as defined in [LMP].
0x10 J0-trace: J0 Section Trace Correlation
Capable of transmitting SONET/SDH Section/RS trace over
J0 Section/RS overhead byte as defined in ANSI
T1.105/ITU-T G.707.
The Test message is not transmitted using the J0 bytes
(i.e., over the data link), but is sent over the
control channel and correlated for consistency to the
received J0 pattern.
In order to get the mapping between the Interface_Id
over which the J0 test message is sent and the J0
pattern sent in-band, the transmitting node must
J. Lang and D. Papadimitriou [Page 5]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
provide the correlation between this pattern and the J0
test message. This correlation is done using the TRACE
object as defined in Section 4.
The format of the test message is as follows:
<Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID>
<VERIFY_ID> <TRACE>
Note that no change is required for the
TestStatusSuccess or TestStatusFailure messages.
0x20 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 [G707].
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
the Interface_Id is either IPv4 or unnumbered.
0x40 J1-64: 64 byte J1 Test Message
Capable of transmitting Test messages using J1 overhead
bytes with frame length of 64 bytes (see [T1105]).
Note that this is only appropriate for SONET encoding
and not SDH encoding.
The Test message is sent as defined in [LMP].
0x80 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 [T1105] and [G707].
Note that due to the byte limitation, the Test message
is NOT sent as an IP packet and as such, no L2
encapsulation is used. The Test message format defined
above for J0-16 is used.
0x100 J1-trace: J1 Path Trace Correlation
Capable of transmitting SONET/SDH STS SPE/HOVC Path
trace over J1 Path overhead byte as defined in [T1105]
and [G707].
J. Lang and D. Papadimitriou [Page 6]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
The Test message is not transmitted using the J1 bytes
(i.e., over the data link), but is sent over the
control channel and correlated for consistency to the
received J1 pattern.
In order to get the mapping between the Interface_Id
over which the J1 test message is sent and the J1
pattern sent in-band, the transmitting node must
provide the correlation between this pattern and the J1
test message. This correlation is done using the TRACE
object as defined in Section 4.
The Test Message format is identical to that defined
above in J0-trace.
Note that no change is required for the
TestStatusSuccess or TestStatusFailure messages.
0x200 J2-trace: J2 Section Trace Correlation
Capable of transmitting SONET/SDH VT SPE/LOVC Path
trace over J2 Path overhead byte as defined in [T1105]
and [G707].
The Test message is not transmitted using the J2 bytes
(i.e., over the data link), but is sent over the
control channel and correlated for consistency to the
received J2 pattern.
In order to get the mapping between the Interface_Id
over which the J2 test message is sent and the J2
pattern sent in-band, the transmitting node must
provide the correlation between this pattern and the J2
test message. This correlation is done using the TRACE
object as defined in Section 4.
The Test Message format is identical to that defined
above in J0-trace.
Note that no change is required for the
TestStatusSuccess or TestStatusFailure messages.
4. Trace Monitoring
The trace monitoring features described in this section allow a node
to do trace monitoring by using the SONET/SDH capabilities.
o An node may request its neighbor (the remote node) to monitor
a link for a specific pattern in the overhead using the
TraceMonitor Message. An example of this overhead is the
SONET Section Trace message transmitted in the J0 byte. If
J. Lang and D. Papadimitriou [Page 7]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
the actual trace message does not match the expected trace
message, the remote node MUST report the mismatch condition.
o A node may request the value of the current trace message on
a given data link using the TraceReq Message.
o A node may request a remote node to send a specific trace
message over a data link using the TraceInsertReq Message.
4.1.1. TraceMonitor Message
The Msg Type for the TraceMonitor message is TBA by IANA.
The TraceMonitor message is sent over the control channel and is
used to request the remote node to monitor a data link for a
specific trace value. This value is inserted in the <TRACE> object.
The format of the TraceMonitor message is as follows:
<TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE>
The remote node MUST respond to a TraceMonitor message with either a
TraceMonitorAck or TraceMonitorNack Message.
4.1.1.1. TRACE Object Class
Class = TBA by IANA.
o C-Type = 1
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 Type: 16 bits
The type of the trace message. The following values are
defined. All other values are reserved and should be sent as
zero and ignored on receipt.
1 = SONET Section Trace (J0 Byte)
2 = SONET Path Trace (J1 Byte)
3 = SONET Path Trace (J2 Byte)
4 = SDH Section Trace (J0 Byte)
J. Lang and D. Papadimitriou [Page 8]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
5 = SDH Path Trace (J1 Byte)
6 = SDH Path Trace (J2 Byte)
Trace Length: 16 bits
This is the length in bytes of the trace message (as specified
by the Trace Type).
Trace Message:
This is the value of the expected message to be received in-
band. The valid length and value combinations are determined by
the specific technology: for SONET see [T1105] and for SDH see
[G707] . 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.1.2. TraceMonitorAck Message
The TraceMonitorAck message is used to acknowledge receipt of the
TraceMonitor message and indicate that all of the TRACE Objects in
the TraceMonitor message have been received and processed correctly
(i.e. no Trace Mismatch).
The format is as follows:
<TraceMonitorAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the
MESSAGE_ID_ACK object MUST be obtained from the TraceMonitor message
being acknowledged.
4.1.3. TraceMonitorNack Message
The TraceMonitorNack message is used to acknowledge receipt of the
TraceMonitor message and indicate that the TRACE Object in the
TraceMonitor message was not processed correctly. This could be
because the trace monitoring requested is not supported or there was
an error in the TRACE object value(s).
The format is as follows:
<TraceMonitorNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The MESSAGE_ID_ACK and ERROR_CODE objects are defined in [LMP]. The
contents of the MESSAGE_ID_ACK object MUST be obtained from the
TraceMonitor message being acknowledged.
J. Lang and D. Papadimitriou [Page 9]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
If the Trace type is not supported, the ERROR_CODE MUST indicate,
"Unsupported Trace Type."
If the TRACE object was not equal to the value seen in the Trace,
the ERROR_CODE MUST indicate, "Invalid Trace Message"
The TraceMonitorNack message uses the ERROR_CODE C-Type
4.1.3.1. ERROR_CODE Class
C-Type = TBA by IANA
The following new error code bit-values are defined:
0x01 = Unsupported Trace Type
0x02 = Invalid Trace Message
All other values are Reserved.
Multiple bits may be set to indicate multiple errors.
This Object is non-negotiable.
4.1.4. TraceMismatch Message
The TraceMismatch message is sent over the control channel and is
used to report a trace mismatch on a data link for which trace
monitoring was requested. The format is as follows:
<TraceMismatch message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID>
[<LOCAL_INTERFACE_ID> ...]
A neighboring node that receives a TraceMismatch message MUST
respond with a TraceMismatchAck message.
The LOCAL_INTERFACE_ID object is defined in [LMP]. The
LOCAL_INTERFACE_ID in this message is the local Interface Id of the
data link that has a trace mismatch. A trace mismatch for multiple
LOCAL_INTERFACE_ID's may be reported in the same message.
4.1.5. TraceMismatchAck Message
The TraceMismatchAck message is used to acknowledge receipt of a
TraceMismatch message. The format is as follows:
<TraceMismatchAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the
MESSAGE_ID_ACK object MUST be obtained from the TraceMismatch
message being acknowledged.
J. Lang and D. Papadimitriou [Page 10]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
4.1.6. TraceReq Message
The TraceReq message is sent over the control channel and is used to
request the current trace value of a data link.
<TraceReq Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE_REQ>
The format of the TRACE_REQ object is as follows:
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 | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trace Type: 16 bits
Defined in Section 4.1.1.1.
4.1.7. TraceReport Message
The TraceReport message is sent over the control channel after
receiving a TraceReq message.
<TraceReport Message> ::= <Common Header> <MESSAGE_ID_ACK> <TRACE>
The TraceReport message MUST include a TRACE Object (as described in
Section 4.1.1.1) for the requested data link.
The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the
MESSAGE_ID_ACK object MUST be obtained from the TraceReq message
being acknowledged.
4.1.8. TraceReqNack Message
The TraceReqNack message is sent over the control channel after
receiving a TraceReq message.
<TraceReqNak Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The MESSAGE_ID_ACK and ERROR_CODE objects are defined in [LMP]. The
contents of the MESSAGE_ID_ACK object MUST be obtained from the
TraceReq message being acknowledged.
The TraceReqNak message MUST include an ERROR_CODE Object (as
described in Section 4.1.3.1) for the requested data link.
J. Lang and D. Papadimitriou [Page 11]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
4.1.9. TraceInsertReq Message
The InsertTraceReq message is sent over the control channel and is
used to request a remote node to send a specific trace message over
a data link (this assumes that the remote knows the mapping between
interface idÆs before fulfilling such request).
<InsertTraceReq Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE>
A node that receives an InsertTraceReq message MUST respond with
either a InsertTraceAck or InsertTraceNack Message.
The MESSAGE_ID_object is defined in [LMP].
4.1.10. InsertTraceAck Message
The InsertTraceAck message is used to acknowledge receipt of the
InsertTrace message and indicate that the TRACE Object in the
InsertTrace message has been received and processed correctly (i.e.
no Trace Mismatch). The format is as follows:
<InsertTraceAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the
MESSAGE_ID_ACK object MUST be obtained from the InsertTrace message
being acknowledged.
4.1.11. InsertTraceNack Message
The InsertTraceNack message is used to acknowledge receipt of the
InsertTrace message and to indicate that the TRACE Object in the
InsertTrace message was not processed correctly. This could be
because the trace monitoring requested is not supported or there was
an error in the value.
The format is as follows:
<InsertTraceNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The MESSAGE_ID_ACK object is defined in [LMP]. The ERROR_CODE
Object usage is described in Section 4.1.3.1.
4.1.12 InsertTraceMismatch Message ? or simply re-use of
TraceMismatch messaging as described here above ?
5. Security Considerations
No new security considerations are introduced in this document.
6. Intellectual Property Considerations
J. Lang and D. Papadimitriou [Page 12]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
J. Lang and D. Papadimitriou [Page 13]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
7. References
7.1. Normative References
[LMP] Lang, J., ed., "Link Management Protocol (LMP)," (work
in progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[G707] ITU-T G.707, "Network node interface for the synchronous
digital hierarchy (SDH)," October 2000.
[T1105] T1.105, "Revised Draft T105 SONET Base Standard,"
January 2001.
[GMPLS-SIG] Ashwood-Smith, P., Banerjee, A., et al, "Generalized
MPLS - Signaling Functional Description," (work in
progress).
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering," (work in progress).
[RFC1662] W. Simpson, Ed., "PPP in HDLC-like Framing", IETF RFC
1662, STD 51, July 1994.
7.2. Informative References
[LSP-HIER] Kompella, K., Rekhter, Y., " LSP Hierarchy with
Generalized MPLS TE," (work in progress).
8. Acknowledgements
The authors would like to thank Bernard Sales, Emmanuel Desmet, Gert
Grammel, Jim Jones, Stefan Ansorge, and James Scott for their many
contributions to this document.
We would also like to thank Greg Bernstein and Michiel van
Everdingen for their insightful comments and for acting with a
strong combination of toughness, professionalism, and courtesy.
9. Author's Addresses
Jonathan P. Lang Dimitri Papadimitriou
Calient Networks Alcatel
25 Castilian Drive Francis Wellesplein 1
Goleta, CA 93117 B-2018 Antwerpen, Belgium
Email: jplang@calient.net email: Dimitri.Papadimitriou@alcatel.be
J. Lang and D. Papadimitriou [Page 14]
Internet Draft draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt Sep. 2002
10. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
J. Lang and D. Papadimitriou [Page 15]
