One document matched: draft-papadimitriou-ccamp-lmp-test-g709-00.txt
CCAMP Working Group D. Papadimitriou
Internet Draft Alcatel
Document: draft-papadimitriou-ccamp-lmp-test-g709-00
Expires: April 2003 J. Lang
Calient
October 2002
G.709 Encoding for Link Management Protocol (LMP)
Test messages
draft-papadimitriou-ccamp-lmp-test-g709-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 [1].
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.
1. Abstract
This document detail the G.709 Optical Transport Network technology
specific information needed when sending Link Management Protocol
(LMP) test messages.
2. Conventions used in this document
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 RFC-2119 [2].
In addition, the reader is assumed to be familiar with the
terminology in ITU-T [ITUT-G709] as well as [LMP], [LMP-TEST] and
D.Papadimitriou Internet Draft û Expires April 2003 1
draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002
[GMPLS-SIG]. Abbreviations used in this document are detailed in
Appendix 1.
3. 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 G.709, however, the fault management
procedures may not be needed as existing G.709 mechanisms can be
used.
In this document, we define G.709 technology specific information
needed when running LMP. Specifically, we define the G.709 test
procedures used for Link verification and link property correlation.
This requires a G.709 specific TRACE object that is defined in this
document. Once the data links have been verified, they can be
grouped to form TE links.
4. 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 [MPLS-BDL], depending on the
configuration), and physical connectivity verification. Multiple
D.Papadimitriou Internet Draft û Expires April 2003 2
draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002
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 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. These
values are defined as follows:
Signal Type Bit-rate (kbps) Value (Bytes/Sec)
----------- -------------- ----------------
ODU1 2 498 775 0x4D94F048
OTU1 2 666 057 0x4D9EE8CD
ODU2 10 037 274 0x4E959129
OTU2 10 709 226 0x4E9F9475
ODU3 40 319 219 0x4F963367
OTU3 43 018 416 0x4FA0418F
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 G.709, this value must equal the value
given for "G.709 Digital".
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 G.709 Digital.
4.1 Verify Transport Mechanism
This field is 16 bits in length.
In this document, we define the flags with respect to the G.709
digital encoding. Note that all values are defined in network byte
order (i.e., big-endian byte order).
D.Papadimitriou Internet Draft û Expires April 2003 3
draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002
0x01 OTUk TTI: 64 byte Test Message
Capable 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 as defined in [LMP].
0x02 ODUk TTI: 64 byte Test Message
Capable 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 as defined in [LMP].
0x04 GCC0: Test Message over the GCC0
Capable 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 as defined in [LMP] using bit-oriented
HDLC framing format [RFC-1662].
0x08 GCC1/2: Test Message over the GCC1/2
Capable 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 as defined in [LMP] using bit-oriented
HDLC framing format [RFC-1662].
0x10 OTUk TTI - Section Trace Correlation
Capable 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., over the data link), but is sent over the control
channel and correlated for consistency to the received pattern.
In order to get the mapping between the Interface_Id for which
the OTUk TTI Test message is sent and the pattern sent in-band,
the transmitting node must provide the correlation between this
pattern and the OTUk TTI Test message. This correlation is done
using the TRACE object as defined in [LMP-TEST] Section 4. Note
D.Papadimitriou Internet Draft û Expires April 2003 4
draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002
that no change is required for the TestStatusSuccess or
TestStatusFailure messages.
0x20 ODUk TTI - Path Trace Correlation
Capable 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., over the data link), but is sent over the control
channel and correlated for consistency to the received pattern.
In order to get the mapping between the Interface_Id for which
the ODUk TTI Test message is sent and the pattern sent in-band,
the transmitting node must provide the correlation between this
pattern and the ODUk TTI Test message. This correlation is done
using the TRACE object as defined in [LMP-TEST] Section 4. Note
that no change is required for the TestStatusSuccess or
TestStatusFailure messages.
5. Trace Monitoring
The trace monitoring features described in [LMP-TEST] allow a node
controlling the trace monitoring operations performed using the
G.709 capabilities.
The following section defines the new C-Type of the TRACE object
class allowing for the Trace Monitoring capabilities as defined in
[LMP-TEST]. Any other objects and messages as well as their
corresponding processing are as defined [LMP-TEST].
5.1 TRACE Object Class
Class = TBA by IANA - C-Type = 2 û Format:
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.
D.Papadimitriou Internet Draft û Expires April 2003 5
draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002
1: OTUk TTI
2: ODUk TTI
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 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.
8. Security Considerations
No new security considerations are introduced in this document in
addition to [LMP].
9. References
9.1 Normative References
[ITUT-G709] ITU-T G.709 Recommendation, version 1.0 (and Amendment
1), æInterface for the Optical Transport Network
(OTN)Æ, ITU-T, February 2001 (and October 2001).
[ITUT-G798] ITU-T G.798 Recommendation, version 1.0,
æCharacteristics of Optical Transport Network Hierarchy
Equipment Functional BlocksÆ, ITU-T, October 2001.
[ITUT-G872] ITU-T G.872 Recommendation, version 2.0, æArchitecture
of Optical Transport NetworkÆ, ITU-T, October 2001.
[GMPLS-ARCH] E.Mannie (Editor) et al., æGeneralized Multi-Protocol
Label Switching (GMPLS) ArchitectureÆ, Internet Draft,
Work in progress, draft-ietf-ccamp-gmpls-architecture-
03.txt, August 2002.
[GMPLS-SIG] L.Berger (Editor) et al., æGeneralized MPLS
- Signaling Functional DescriptionÆ, Internet Draft,
Work in progress, draft-ietf-mpls-generalized-
signaling-09.txt, August 2002.
[GMPLS-G709] D.Papadimitriou (Editor) et al., æGeneralized
Multiprotocol Label Switching Extensions for G.709
Optical Transport Network ControlÆ, Internet Draft,
Work in progress, draft-ietf-ccamp-gmpls-g709-02.txt,
September 2002.
D.Papadimitriou Internet Draft û Expires April 2003 6
draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002
[LMP] J.Lang (Editor) et al., "Link Management Protocol
(LMP)," Internet Draft, Work in progress, draft-ietf-
ccamp-lmp-05.txt, September 2002.
[LMP-TEST] J.Lang and D.Papadimitriou, "SONET/SDH Encoding for
Link Management Protocol (LMP) Test messages", Internet
Draft, Work in progress, draft-ietf-ccamp-lmp-test-
sonet-sdh-00.txt, September 2002.
[MPLS-BDL] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling in
MPLS Traffic Engineering," Work in progress, Internet
Draft, draft-ietf-mpls-bundle-04.txt, August 2002.
[RFC-1662] W.Simpson, Ed., "PPP in HDLC-like Framing", IETF RFC
1662, STD 51, July 1994.
[RFC-2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
9.2 Informative References
[MPLS-HIER] Kompella, K., Rekhter, Y., " LSP Hierarchy with
Generalized MPLS TE," (work in progress).
10. Acknowledgments
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.
11. Author's Addresses
Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
Jonathan P. Lang (Calient Networks)
25 Castilian, Goleta, CA 93117, USA
Email: jplang@calient.net
Appendix 1 û Abbreviations
BSNT Bit Stream without Octet Timing
BSOT Bit Stream with Octet Timing
CBR Constant Bit Rate
FC Fiber Channel
FEC Forward Error Correction
FSC Fiber Switch Capable
GCC General Communication Channel
GFP Generic Framing Procedure
D.Papadimitriou Internet Draft û Expires April 2003 7
draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002
LSC Lambda Switch Capable
LSP Label Switched Path
MS Multiplex Section
naOH non-associated Overhead
NMC Number of Multiplexed Components
NVC Number of Virtual Components
OCC Optical Channel Carrier
OCG Optical Carrier Group
OCh Optical Channel (with full functionality)
OChr Optical Channel (with reduced functionality)
ODTUG Optical Date Tributary Unit Group
ODU Optical Channel Data Unit
OH Overhead
OMS Optical Multiplex Section
OMU Optical Multiplex Unit
OOS OTM Overhead Signal
OPS Optical Physical Section
OPU Optical Channel Payload Unit
OSC Optical Supervisory Channel
OTH Optical transport hierarchy
OTM Optical transport module
OTN Optical transport network
OTS Optical transmission section
OTU Optical Channel Transport Unit
OTUkV Functionally Standardized OTUk
PPP Point to Point Protocol
PSC Packet Switch Capable
RES Reserved
RS Regenerator Section
TDM Time Division Multiplex
TTI Trail Trace Identifier
D.Papadimitriou Internet Draft û Expires April 2003 8
draft-papadimitriou-ccamp-lmp-test-g709-00.txt Oct. 2002
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 implmentation 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.
D.Papadimitriou Internet Draft û Expires April 2003 9
| PAFTECH AB 2003-2026 | 2026-04-24 01:17:16 |