draft-ietf-ccamp-lmp-wdm-03.txt		draft-ietf-ccamp-lmp-wdm-04.txt
	Network Working Group A. Fredette, Editor		This Internet-Draft, draft-ietf-ccamp-lmp-wdm-03.txt, was published as a Proposed Standard, RFC 4209
	Internet Draft (Hatteras Networks)		(http://www.ietf.org/rfc/rfc4209.txt), on 2005-11-1.
	Category: Standards Track
	Expiration Date: June 2004 J. Lang, Editor
	(Rincon Networks)
	December 2003
	Link Management Protocol (LMP) for Dense Wavelength Division
	Multiplexing (DWDM) Optical Line Systems
	draft-ietf-ccamp-lmp-wdm-03.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
	The Link Management Protocol (LMP) is defined to manage traffic
	engineering (TE) links. In its present form, LMP focuses on peer
	nodes; i.e., nodes that peer in signaling and/or routing. In this
	document we propose extensions to LMP to allow it to be used between
	a peer node and an adjacent optical line system (OLS). These
	extensions are intended to satisfy the "Optical Link Interface
	Requirements" described in a companion document.
	[Editor's note: "Changes from previous version" notes can be removed
	prior to publication as an RFC.]
	Changes from previous version:
	o Modified the IANA Considerations section as a result of IESG
	review.
	1. Introduction
	Networks are being developed with routers, switches, optical cross-
	connects (OXCs), dense wavelength division multiplexing (DWDM)
	optical line systems (OLSs), and add-drop multiplexors (ADMs) that
	use a common control plane [e.g., Generalized MPLS (GMPLS)] to
	dynamically provision resources and to provide network survivability
	using protection and restoration techniques.
	The Link Management Protocol (LMP) is being developed as part of the
	GMPLS protocol suite to manage traffic engineering (TE) links [LMP].
	In its present form, LMP focuses on peer nodes; i.e., nodes that
	peer in signaling and/or routing (e.g., OXC-to-OXC, as illustrated
	in Figure 1). In this document, extensions to LMP to allow it to be
	used between a peer node and an adjacent optical line system (OLS)
	are proposed. These extensions are intended to satisfy the "Optical
	Link Interface Requirements" described in [OLI]. It is assumed that
	the reader is familiar with LMP as defined in [LMP].
	+------+ +------+ +------+ +------+
	| | ----- | | | | ----- | |
	| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
	| | ----- | | | | ----- | |
	+------+ +------+ +------+ +------+
	^ ^
	| |
	+---------------------LMP---------------------+
	Figure 1: LMP Model
	Consider two peer nodes (e.g., two OXCs) interconnected by a
	wavelength-multiplexed link; i.e., a DWDM optical link (see Figure 1
	above). Information about the configuration of this link and its
	current state is known by the two OLSs (OLS1 and OLS2), and allowing
	them to communicate this information to the corresponding peer nodes
	(OXC1 and OXC2) via LMP can improve network usability by reducing
	required manual configuration and by enhancing fault detection and
	recovery.
	Information about the state of LSPs using the DWDM optical link is
	known by the peer nodes (OXC1 and OXC2), and allowing them to
	communicate this information to the corresponding OLSs (OLS1 and
	OLS2) is useful for alarm management and link monitoring. Alarm
	management is important because the administrative state of an LSP,
	known to the peer nodes (e.g., via the Admin Status object of GMPLS
	signaling [GMPLS-SIG]) can be used to suppress spurious alarm
	reporting from the OLSs.
	The model for extending LMP to OLSs is shown in Figure 2.
	+------+ +------+ +------+ +------+
	| | ----- | | | | ----- | |
	| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
	| | ----- | | | | ----- | |
	+------+ +------+ +------+ +------+
	^ ^ ^ ^ ^ ^
	| | | | | |
	| +-----LMP-----+ +-----LMP-----+ |
	| |
	+----------------------LMP-----------------------+
	Figure 2: Extended LMP Model
	In this model, a peer node may have LMP sessions with adjacent OLSs
	as well as adjacent peer nodes. In Figure 2, for example, the OXC1-
	OXC2 LMP session can be used to build traffic-engineering (TE) links
	for GMPLS signaling and routing, as described in [LMP]. The OXC1-
	OLS1 and the OXC2-OLS2 LMP sessions are used to exchange information
	about the configuration of the DWDM optical link and its current
	state and information about the state of LSPs using that link.
	The latter type of LMP sessions is discussed in this document. It is
	important to note that a peer node may have LMP sessions with one or
	more OLSs and an OLS may have LMP sessions with one or more peer
	nodes.
	Although there are many similarities between an LMP session between
	two peer nodes and an LMP session between a peer node and an OLS,
	there are some differences as well. The former type of LMP session
	is used to provide the basis for GMPLS signaling and routing. The
	latter type of LMP session is used to augment knowledge about the
	links between peer nodes.
	A peer node maintains its peer node - OLS LMP sessions and its peer
	node - peer node LMP sessions independently. This means that it MUST
	be possible for LMP sessions to come up in any order. In particular,
	it MUST be possible for a peer node - peer node LMP session to come
	up in the absence of any peer node - OLS LMP sessions and vice
	versa.
	1.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].
	The reader is assumed to be familiar with the terminology in [LMP].
	DWDM: Dense wavelength division multiplexor
	OLS: Optical line system
	Opaque:
	A device is called X-opaque if it examines or modifies the X
	aspect of the signal while forwarding an incoming signal from
	input to output.
	OXC: Optical cross-connect
	Transparent:
	As defined in [LMP], a device is called X-transparent if it
	forwards incoming signals from input to output without examining
	or modifying the X aspect of the signal. For example, a Frame
	Relay switch is network-layer transparent; an all-optical switch
	is electrically transparent.
	1.2. Scope of LMP-WDM Protocol
	This document focuses on extensions required for use with opaque
	OLSs. In particular, this document is intended for use with OLSs
	having SONET, SDH, and Ethernet user ports.
	At the time of this writing, work is ongoing in the area of fully
	transparent wavelength routing; however, it is premature to identify
	the necessary information to be exchanged between a peer node and an
	OLS in this context. Nevertheless, the protocol described in this
	document provides the necessary framework in which to exchange
	whatever additional information is deemed appropriate.
	2. LMP Extensions for Optical Line Systems
	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
	All four functions are supported in LMP-WDM.
	2.1. Control Channel Management
	As in [LMP], we do not specify the exact implementation of the
	control channel; it could be, for example, a separate wavelength,
	fiber, Ethernet link, an IP tunnel routed over a separate management
	network, a multi-hop IP network, or the overhead bytes of a data
	link.
	The control channel management for a peer node - OLS link is the
	same as for a peer node - peer node link, as described in [LMP].
	To distinguish between a peer node - OLS LMP session from a peer
	node - peer node LMP session, a new LMP-WDM CONFIG object is defined
	(C-Type = TBA by IANA). The format of the CONFIG object is as
	follows:
	Class = 6.
	o C-Type = TBA, LMP-WDM_CONFIG
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|W|O| (Reserved) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Reserved field should be sent as zero and ignored on receipt.
	WDM: 1 bit
	This bit indicates support for the LMP-WDM extensions defined
	in this draft.
	OLS: 1 bit
	If set, this bit indicates that the sender is an optical line
	system (OLS). If clear, this bit indicates that the sender is a
	peer node.
	The LMP-WDM extensions are designed for peer node - OLS LMP
	sessions. The OLS bit allows a node to identify itself as an OLS or
	a peer node. This is used to detect misconfiguration of a peer node
	-OLS LMP session between two peer nodes or a peer node - peer node
	LMP session between a peer node and an OLS.
	If the node does not support the LMP-WDM extensions, it MUST reply
	to the Config message with a ConfigNack message.
	If a peer node that is configured to run LMP-WDM receives a Config
	message with the OLS bit clear in LMP-WDM_CONFIG Object, it MUST
	reply to the Config message with a ConfigNack message.
	2.2. Link Verification
	The Test procedure used with OLSs is the same as described in [LMP].
	The VerifyTransportMechanism (included in the BeginVerify and
	BeginVerifyAck messages) is used to allow nodes to negotiate a link
	verification method and is essential for line systems that have
	access to overhead bytes rather than the payload. The VerifyId
	(provided by the remote node in the BeginVerifyAck message, and used
	in all subsequent Test messages) is used to differentiate Test
	messages from different LMP Link Verification procedures. In
	addition to the Test procedure described in [LMP], the trace
	monitoring function of [LMP-SDH] may be used for link verification
	when the OLS user ports are SONET or SDH.
	In a combined LMP and LMP-WDM context, there is an interplay between
	the data links being managed by peer node - peer node LMP sessions
	and peer node - OLS LMP sessions. For example, in Figure 2, the
	OXC1-OLS1 LMP session manages the data links between OXC1 and OLS1,
	and the OXC2-OLS2 LMP session manages the data links between OXC2
	and OLS2. However, the OXC1-OXC2 LMP session manages the data links
	between OXC1 and OXC2, which are actually a concatenation of the
	data links between OXC1 and OLS1, the DWDM span between OLS1 and
	OLS2, and the data links between OXC2 and OLS2, and it is these
	concatenated links which comprise the TE links which are advertised
	in the GMPLS TE link state database.
	The implication of this is that when the data links between OXC1 and
	OXC2 are being verified, using the LMP link verification procedure,
	OLS1 and OLS2 need to make themselves transparent with respect to
	these concatenated data links. The coordination of verification of
	OXC1-OLS1 and OXC2-OLS2 data links to ensure this transparency is
	the responsibility of the peer nodes, OXC1 and OXC2.
	It is also necessary for these peer nodes to understand the mappings
	between the data links of the peer node - OLS LMP session and the
	concatenated data links of the peer node - peer node LMP session.
	2.3. Link Summarization
	As in [LMP], the LinkSummary message is used to synchronize the
	Interface Ids and correlate the properties of the TE link. (Note
	that the term "TE Link" originated from routing/signaling
	applications of LMP, whereas this concept does not necessarily apply
	to an OLS. However, the term is used in this document to remain
	consistent with LMP terminology.) The LinkSummary message includes
	one or more DATA_LINK objects. The contents of the DATA_LINK object
	consist of a series of variable-length data items called Data Link
	sub-objects describing the capabilities of the data links.
	In this document, several additional Data Link sub-objects are
	defined to describe additional link characteristics. The link
	characteristics are, in general, those needed by the CSPF to select
	the path for a particular LSP. These link characteristics describe
	the specified peer node - OLS data link as well as the associated
	DWDM span between the two OLSs.
	The format of the Data Link sub-objects follows the format described
	in [LMP] and is shown below for readability:
	0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
	| Type | Length | (Sub-object contents) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
	Type: 8 bits
	The Type indicates the type of contents of the sub-object.
	Length: 8 bits
	The Length field contains the total length of the sub-object in
	bytes, including the Type and Length fields. The Length MUST be
	at least 4, and MUST be a multiple of 4.
	The following Link Characteristics are exchanged on a per data link
	basis.
	2.3.1. Link Group ID
	The main purpose of the Link Group ID is to reduce control traffic
	during failures that affect many data links. A local ID may be
	assigned to a group of data links. This ID can be used to reduce the
	control traffic in the event of a failure by enabling a single
	ChannelStatus message with the LINK GROUP CHANNEL_STATUS object (see
	Section 2.4.1) to be used for a group of data links instead of
	individual ChannelStatus messages for each data link. A data link
	may be a member of multiple groups. This is achieved by including
	multiple Link Group ID sub-objects in the LinkSummary message.
	The Link Group ID feature allows Link Groups to be assigned based
	upon the types of fault correlation and aggregation supported by a
	given OLS. From a practical perspective, the Link Group ID is used
	to map (or group) data links into "failable entities" known
	primarily to the OLS. If one of those failable entities fails, all
	associated data links are failed and the peer node is notified with
	a single message.
	For example, an OLS could create a Link Group for each laser in the
	OLS. The data links associated with each laser would then each be
	assigned the Link Group ID for that laser. If a laser fails, the OLS
	would then report a single failure affecting all of the data links
	with Link Group ID of the failed laser. The peer node that receives
	the single failure notification then knows which data links are
	affected. Similarly, an OLS could create a Link Group ID for a
	fiber, to report a failure affecting all of the data links
	associated with that fiber if a loss-of-signal (LOS) is detected for
	that fiber.
	The format of the Link Group ID sub-object (Type=TBD, 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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Link Group ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Reserved field should be sent as zero and ignored on receipt.
	Link Group ID: 32 bits
	Link Group ID 0xFFFFFFFF is reserved and indicates all data
	links in a TE link. All data links are members of Link Group
	0xFFFFFFFF by default.
	2.3.2. Shared Risk Link Group (SRLG) Identifier
	This identifies the SRLGs of which the data link is a member. This
	information may be configured on an OLS by the user and used for
	diverse path computation (see [GMPLS-RTG]).
	The format of the SRLG sub-object (Type=TBD, Length=(N+1)*4 where N
	is the number of SRLG values) 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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SRLG value #1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SRLG value #2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// ... //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SRLG value #(N-1) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SRLG value #N |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Reserved field should be sent as zero and ignored on receipt.
	Shared Risk Link Group Value: 32 bits
	See [GMPLS-RTG]. List as many SRLGs as apply.
	2.3.3. Bit Error Rate (BER) Estimate
	This object provides an estimate of the BER for the data link.
	The Bit Error Rate (BER) is the proportion of bits that have errors
	relative to the total number of bits received in a transmission,
	usually expressed as ten to a negative power. For example, a
	transmission might have a BER of "10 to the minus 13", meaning that,
	out of every 10,000,000,000,000 bits transmitted, one bit may be in
	error. The BER is an indication of overall signal quality.
	The format of the BER Estimate sub-object (Type=TBD; Length=4) 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 | BER | (Reserved) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Reserved field should be sent as zero and ignored on receipt.
	BER: 8 bits
	The exponent from the BER representation described above. I.e.,
	if the BER is 10 to the minus X, the BER field is set to X.
	2.3.4. Optical Protection
	This indicates whether the link is protected by the OLS. This
	information can be used as a measure of link capability. It may be
	advertised by routing and used by signaling as a selection criterion
	as described in [RFC3471].
	The format of the Optical Protection sub-object (Type=TBD; Length=4)
	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) | Link Flags|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Reserved field should be sent as zero and ignored on receipt.
	Link Flags: 6 bits
	Encoding for Link Flags is defined in Section 7 of [RFC3471].
	2.3.5. Total Span Length
	This indicates the total distance of fiber in the OLS. This may be
	used as a routing metric or to estimate delay.
	The format of the Total Span Length sub-object (Type=TBD, 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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Span Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Reserved field should be sent as zero and ignored on receipt.
	Span Length: 32 bits
	This value represents the total Length of the WDM span in 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=TBD,
	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
	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, 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 [LMP].
	I.e., 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 [LMP].
	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 [LMP] 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 =TBA by IANA):
	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
	Link Group ID 0xFFFFFFFF is reserved and indicates all data
	links in a TE link. All data links are members of Link Group
	0xFFFFFFFF by default.
	Channel Status: 32 bits
	The values for the Channel Status field are defined in [LMP].
	This Object is non-negotiable.
	3. Intellectual Property Considerations
	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.
	4. References
	4.1. Normative References
	[GMPLS-RTG] Kompella, K., Rekhter, Y. et al, "Routing Extensions in
	Support of Generalized MPLS," (work in progress).
	[LMP] Lang, J. P., Editor, "The Link Management Protocol
	(LMP)," (work in progress).
	[LMP-SDH] Lang, J. P., Papadimitriou, D., "SONET/SDH Encoding for
	Link Management Protocol (LMP) Test messages," (work in
	progress).
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels," BCP 14, RFC 2119, March 1997.
	[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
	Switching (GMPLS) - Signaling Functional Description,"
	RFC 3471, January 2003.
	[RFC3630] Katz, D., Yeung, D., and Kompella, K., "Traffic
	Engineering (TE) Extensions to OSPF Version 2," RFC
	3630, September 2003.
	4.2. Informative References
	[OLI] Fredette, A., Editor, "Optical Link Interface
	Requirements," (work in progress).
	5. Security Considerations
	LMP message security uses IPsec as described in [LMP]. 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 [LMP].
	6. IANA Considerations
	LMP [LMP] defines the following name spaces and how IANA can make
	assignments in those 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 [LMP])
	- LMP-WDM_CONFIG (suggested C-Type = 2)
	o under CHANNEL_STATUS class name (as defined in [LMP])
	- LINK_GROUP (suggested C-Type = 4)
	LMP Sub-Object Class names:
	o under DATA_LINK Class name (as defined in [LMP])
	- Link_GroupId (suggested sub-object Type = 3)
	- SRLG (suggested sub-object Type = 4)
	- BER_Estimate (suggested sub-object Type = 5)
	- Optical_Protection (suggested sub-object Type = 6)
	- Total_Span_Length (suggested sub-object Type = 7)
	- Administrative_Group (suggested sub-object Type = 8)
	7. Contributors
	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, John Yu.
	8. Contact Address
	Andre Fredette
	Hatteras Networks
	P.O. Box 110025
	Research Triangle Park
	NC 27709-0025, USA
	EMail: Afredette@HatterasNetworks.com
	Jonathan P. Lang
	Rincon Networks
	829 De La Vina, Suite 220
	Santa Barbara, CA 93101, USA
	EMail: jplang@ieee.org
	9. Full Copyright Statement
	Copyright (C) The Internet Society (2003). 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.
End of changes. 1 change blocks.
	0 lines changed or deleted		0 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/