meters, expressed as an unsigned (long) integer.
2.3.6. Administrative Group (Color)
The administrative group (or Color) to which the data link belongs.
The format of the Administrative Group sub-object (Type = 8, Length =
8) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
Administrative Group: 32 bits
A 32-bit value, as defined in [RFC3630].
2.4. Fault Management
The Fault Management procedure used between a peer and an OLS follows
the procedures described in [RFC4204]; some further extensions are
defined in this section. The information learned from the OLS-peer
fault management procedures may be used to trigger peer-peer LMP
fault management, or may be used to trigger GMPLS signaling/routing
procedures directly.
Fault management consists of three major functions:
1. Fault Detection
2. Fault Localization
3. Fault Notification
The fault detection mechanisms are the responsibility of the
individual nodes and are not specified as part of this protocol.
Fault detection mechanisms may include a Bit Error Rate (BER)
exceeding a threshold, and loss-of-signal (LOS) and SONET/SDH-level
errors. It is the responsibility of the OLS to translate these
failures into (Signal) OK, Signal Failure (SF), or Signal Degrade
(SD), as described in [RFC4204].
That is, an OLS uses the messages defined in the LMP fault
localization procedures (ChannelStatus, ChannelStatusAck,
ChannelStatusRequest, and ChannelStatusResponse messages) to inform
the adjacent peer node of failures it has detected, in order to
initiate the LMP fault localization procedures between peer nodes,
but it does not participate in those procedures.
The OLS may also execute its own fault localization process to allow
it to determine the location of the fault along the DWDM span. For
example, the OLS may be able to pinpoint the fault to a particular
amplifier in a span of thousands of kilometers in length.
To report data link failures and recovery conditions, LMP-WDM uses
the ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and
ChannelStatusResponse messages defined in [RFC4204].
Each data link is identified by an Interface_ID. In addition, a Link
Group ID may be assigned to a group of data links (see Section
2.3.1). The Link Group ID may be used to reduce the control traffic
by providing channel status information for a group of data links. A
new LINK GROUP CHANNEL_STATUS object is defined below for this
purpose. This object may be used in place of the CHANNEL_STATUS
objects described in [RFC4204] in the ChannelStatus message.
2.4.1. LINK_GROUP CHANNEL_STATUS Object
The LINK_GROUP CHANNEL_STATUS object is used to indicate the status
of the data links belonging to a particular Link Group. The
correlation of data links to Group ID is made with the Link Group ID
sub-object of the DATA_LINK object.
The format of the LINK_GROUP CHANNEL_STATUS object is as follows
(Class = 13, C-Type = 4):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Group ID: 32 bits
The Link Group ID 0xFFFFFFFF is reserved and indicates all data
links in a TE link. All data links are members of the Link
Group 0xFFFFFFFF by default.
Channel Status: 32 bits
The values for the Channel Status field are defined in
[RFC4204].
This object is non-negotiable.
3. Security Considerations
LMP message security uses IPsec, as described in [RFC4204]. This
document only defines new LMP objects that are carried in existing
LMP messages. As such, this document introduces no other new
security considerations not covered in [RFC4204].
4. IANA Considerations
LMP [RFC4204] defines the following name spaces and the ways in which
IANA can make assignments to these namespaces:
- LMP Message Type
- LMP Object Class
- LMP Object Class type (C-Type) unique within the Object Class
- LMP Sub-object Class type (Type) unique within the Object Class
This memo introduces the following new assignments:
LMP Object Class Types:
o under CONFIG class name (as defined in [RFC4204])
- LMP-WDM_CONFIG (C-Type = 2)
o under CHANNEL_STATUS class name (as defined in [RFC4204])
- LINK_GROUP (C-Type = 4)
LMP Sub-Object Class names:
o under DATA_LINK Class name (as defined in [RFC4204])
- Link_GroupId (sub-object Type = 3)
- SRLG (sub-object Type = 4)
- BER_Estimate (sub-object Type = 5)
- Optical_Protection (sub-object Type = 6)
- Total_Span_Length (sub-object Type = 7)
- Administrative_Group (sub-object Type = 8)
5. Contributors
The authors would like to acknowledge Osama S. Aboul-Magd, Stuart
Brorson, Sudheer Dharanikota, John Drake, David Drysdale, W. L.
Edwards, Adrian Farrel, Andre Fredette, Rohit Goyal, Hirokazu
Ishimatsu, Monika Jaeger, Ram Krishnan, Jonathan P. Lang, Raghu
Mannam, Eric Mannie, Dimitri Papadimitriou, Jagan Shantigram, Ed
Snyder, George Swallow, Gopala Tumuluri, Yong Xue, Lucy Yong, and
John Yu.
6. References
6.1. Normative References
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, September 2005.
[RFC4204] Lang, J., Ed., "The Link Management Protocol (LMP)", RFC
4204, September 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, September 2005.
[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.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
6.2. Informative References
[OLI] Fredette, A., Editor, "Optical Link Interface
Requirements", Work in Progress.
Editors’ Addresses
Andre Fredette
Hatteras Networks
P.O. Box 110025
Research Triangle Park
NC 27709-0025, USA
EMail: Afredette@HatterasNetworks.com
Jonathan P. Lang
Sonos, Inc.
223 E. De La Guerra St.
Santa Barbara, CA 93101
EMail: jplang@ieee.org
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.