summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4204.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc4204.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc4204.txt')
-rw-r--r--doc/rfc/rfc4204.txt4819
1 files changed, 4819 insertions, 0 deletions
diff --git a/doc/rfc/rfc4204.txt b/doc/rfc/rfc4204.txt
new file mode 100644
index 0000000..e62b8b0
--- /dev/null
+++ b/doc/rfc/rfc4204.txt
@@ -0,0 +1,4819 @@
+
+
+
+
+
+
+Network Working Group J. Lang, Ed.
+Request for Comments: 4204 Sonos, Inc.
+Category: Standards Track October 2005
+
+
+ Link Management Protocol (LMP)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ For scalability purposes, multiple data links can be combined to form
+ a single traffic engineering (TE) link. Furthermore, the management
+ of TE links is not restricted to in-band messaging, but instead can
+ be done using out-of-band techniques. This document specifies a link
+ management protocol (LMP) that runs between a pair of nodes and is
+ used to manage TE links. Specifically, LMP will be used to maintain
+ control channel connectivity, verify the physical connectivity of the
+ data links, correlate the link property information, suppress
+ downstream alarms, and localize link failures for
+ protection/restoration purposes in multiple kinds of networks.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Terminology ................................................5
+ 2. LMP Overview ....................................................6
+ 3. Control Channel Management ......................................8
+ 3.1. Parameter Negotiation ......................................9
+ 3.2. Hello Protocol ............................................10
+ 4. Link Property Correlation ......................................13
+ 5. Verifying Link Connectivity ....................................15
+ 5.1. Example of Link Connectivity Verification .................18
+ 6. Fault Management ...............................................19
+ 6.1. Fault Detection ...........................................20
+ 6.2. Fault Localization Procedure ..............................20
+ 6.3. Examples of Fault Localization ............................21
+
+
+
+
+Lang Standards Track [Page 1]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ 6.4. Channel Activation Indication .............................22
+ 6.5. Channel Deactivation Indication ...........................23
+ 7. Message_Id Usage ...............................................23
+ 8. Graceful Restart ...............................................24
+ 9. Addressing .....................................................25
+ 10. Exponential Back-off Procedures ...............................26
+ 10.1. Operation ...............................................26
+ 10.2. Retransmission Algorithm ................................27
+ 11. LMP Finite State Machines .....................................28
+ 11.1. Control Channel FSM .....................................28
+ 11.2. TE Link FSM .............................................32
+ 11.3. Data Link FSM ...........................................34
+ 12. LMP Message Formats ...........................................38
+ 12.1. Common Header ...........................................39
+ 12.2. LMP Object Format .......................................41
+ 12.3. Parameter Negotiation Messages ..........................42
+ 12.4. Hello Message (Msg Type = 4) ............................43
+ 12.5. Link Verification Messages ..............................43
+ 12.6. Link Summary Messages ...................................47
+ 12.7. Fault Management Messages ...............................49
+ 13. LMP Object Definitions ........................................50
+ 13.1. CCID (Control Channel ID) Class .........................50
+ 13.2. NODE_ID Class ...........................................51
+ 13.3. LINK_ID Class ...........................................52
+ 13.4. INTERFACE_ID Class ......................................53
+ 13.5. MESSAGE_ID Class ........................................54
+ 13.6. CONFIG Class ............................................55
+ 13.7. HELLO Class .............................................56
+ 13.8. BEGIN_VERIFY Class ......................................56
+ 13.9. BEGIN_VERIFY_ACK Class ..................................58
+ 13.10. VERIFY_ID Class ........................................59
+ 13.11. TE_LINK Class ..........................................59
+ 13.12. DATA_LINK Class ........................................61
+ 13.13. CHANNEL_STATUS Class ...................................65
+ 13.14. CHANNEL_STATUS_REQUEST Class ...........................68
+ 13.15. ERROR_CODE Class .......................................70
+ 14. References ....................................................71
+ 14.1. Normative References ....................................71
+ 14.2. Informative References ..................................72
+ 15. Security Considerations .......................................73
+ 15.1. Security Requirements ...................................73
+ 15.2. Security Mechanisms .....................................74
+ 16. IANA Considerations ...........................................76
+ 17. Acknowledgements ..............................................83
+ 18. Contributors ..................................................83
+
+
+
+
+
+
+Lang Standards Track [Page 2]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+1. Introduction
+
+ Networks are being developed with routers, switches, crossconnects,
+ dense wavelength division multiplexed (DWDM) systems, and add-drop
+ multiplexors (ADMs) that use a common control plane, e.g.,
+ Generalized MPLS (GMPLS), to dynamically allocate resources and to
+ provide network survivability using protection and restoration
+ techniques. A pair of nodes may have thousands of interconnects,
+ where each interconnect may consist of multiple data links when
+ multiplexing (e.g., Frame Relay DLCIs at Layer 2, time division
+ multiplexed (TDM) slots or wavelength division multiplexed (WDM)
+ wavelengths at Layer 1) is used. For scalability purposes, multiple
+ data links may be combined into a single traffic-engineering (TE)
+ link.
+
+ To enable communication between nodes for routing, signaling, and
+ link management, there must be a pair of IP interfaces that are
+ mutually reachable. We call such a pair of interfaces a control
+ channel. Note that "mutually reachable" does not imply that these
+ two interfaces are (directly) connected by an IP link; there may be
+ an IP network between the two. Furthermore, the interface over which
+ the control messages are sent/received may not be the same interface
+ over which the data flows. This document specifies a link management
+ protocol (LMP) that runs between a pair of nodes and is used to
+ manage TE links and verify reachability of the control channel. For
+ the purposes of this document, such nodes are considered "LMP
+ neighbors" or simply "neighboring nodes".
+
+ In GMPLS, the control channels between two adjacent nodes are no
+ longer required to use the same physical medium as the data links
+ between those nodes. For example, a control channel could use a
+ separate virtual circuit, wavelength, fiber, Ethernet link, an IP
+ tunnel routed over a separate management network, or a multi-hop IP
+ network. A consequence of allowing the control channel(s) between
+ two nodes to be logically or physically diverse from the associated
+ data links is that the health of a control channel does not
+ necessarily correlate to the health of the data links, and vice-
+ versa. Therefore, a clean separation between the fate of the control
+ channel and data links must be made. New mechanisms must be
+ developed to manage the data links, both in terms of link
+ provisioning and fault management.
+
+ Among the tasks that LMP accomplishes is checking that the grouping
+ of links into TE links, as well as the properties of those links, are
+ the same at both end points of the links -- this is called "link
+ property correlation". Also, LMP can communicate these link
+ properties to the IGP module, which can then announce them to other
+
+
+
+
+Lang Standards Track [Page 3]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ nodes in the network. LMP can also tell the signaling module the
+ mapping between TE links and control channels. Thus, LMP performs a
+ valuable "glue" function in the control plane.
+
+ Note that while the existence of the control network (single or
+ multi-hop) is necessary for enabling communication, it is by no means
+ sufficient. For example, if the two interfaces are separated by an
+ IP network, faults in the IP network may result in the lack of an IP
+ path from one interface to another, and therefore an interruption of
+ communication between the two interfaces. On the other hand, not
+ every failure in the control network affects a given control channel,
+ hence the need for establishing and managing control channels.
+
+ For the purposes of this document, a data link may be considered by
+ each node that it terminates on as either a 'port' or a 'component
+ link', depending on the multiplexing capability of the endpoint on
+ that link; component links are multiplex capable, whereas ports are
+ not multiplex capable. This distinction is important since the
+ management of such links (including, for example, resource
+ allocation, label assignment, and their physical verification) is
+ different based on their multiplexing capability. For example, a
+ Frame Relay switch is able to demultiplex an interface into virtual
+ circuits based on DLCIs; similarly, a SONET crossconnect with OC-192
+ interfaces may be able to demultiplex the OC-192 stream into four
+ OC-48 streams. If multiple interfaces are grouped together into a
+ single TE link using link bundling [RFC4201], then the link resources
+ must be identified using three levels: Link_Id, component interface
+ Id, and label identifying virtual circuit, timeslot, etc. Resource
+ allocation happens at the lowest level (labels), but physical
+ connectivity happens at the component link level. As another
+ example, consider the case where an optical switch (e.g., PXC)
+ transparently switches OC-192 lightpaths. If multiple interfaces are
+ once again grouped together into a single TE link, then link bundling
+ [RFC4201] is not required and only two levels of identification are
+ required: Link_Id and Port_Id. In this case, both resource
+ allocation and physical connectivity happen at the lowest level
+ (i.e., port level).
+
+ To ensure interworking between data links with different multiplexing
+ capabilities, LMP-capable devices SHOULD allow sub-channels of a
+ component link to be locally configured as (logical) data links. For
+ example, if a Router with 4 OC-48 interfaces is connected through a
+ 4:1 MUX to a cross-connect with OC-192 interfaces, the cross-connect
+ should be able to configure each sub-channel (e.g., STS-48c SPE if
+ the 4:1 MUX is a SONET MUX) as a data link.
+
+
+
+
+
+
+Lang Standards Track [Page 4]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ LMP is designed to support aggregation of one or more data links into
+ a TE link (either ports into TE links, or component links into TE
+ links). The purpose of forming a TE link is to group/map the
+ information about certain physical resources (and their properties)
+ into the information that is used by Constrained SPF for the purpose
+ of path computation, and by GMPLS signaling.
+
+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
+ [RFC3471], [RFC4202], and [RFC4201].
+
+ Bundled Link:
+
+ As defined in [RFC4201], a bundled link is a TE link such that,
+ for the purpose of GMPLS signaling, a combination of <link
+ identifier, label> is not sufficient to unambiguously identify the
+ appropriate resources used by an LSP. A bundled link is composed
+ of two or more component links.
+
+ Control Channel:
+
+ A control channel is a pair of mutually reachable interfaces that
+ are used to enable communication between nodes for routing,
+ signaling, and link management.
+
+ Component Link:
+
+ As defined in [RFC4201], a component link is a subset of resources
+ of a TE Link such that (a) the partition is minimal, and (b)
+ within each subset a label is sufficient to unambiguously identify
+ the appropriate resources used by an LSP.
+
+ Data Link:
+
+ A data link is a pair of interfaces that are used to transfer user
+ data. Note that in GMPLS, the control channel(s) between two
+ adjacent nodes are no longer required to use the same physical
+ medium as the data links between those nodes.
+
+ Link Property Correlation:
+
+ This is a procedure to correlate the local and remote properties
+ of a TE link.
+
+
+
+Lang Standards Track [Page 5]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Multiplex Capability:
+
+ The ability to multiplex/demultiplex a data stream into sub-rate
+ streams for switching purposes.
+
+ Node_Id:
+
+ For a node running OSPF, the LMP Node_Id is the same as the
+ address contained in the OSPF Router Address TLV. For a node
+ running IS-IS and advertising the TE Router ID TLV, the Node_Id is
+ the same as the advertised Router ID.
+
+ Port:
+
+ An interface that terminates a data link.
+
+ TE Link:
+
+ As defined in [RFC4202], a TE link is a logical construct that
+ represents a way to group/map the information about certain
+ physical resources (and their properties) that interconnect LSRs
+ into the information that is used by Constrained SPF for the
+ purpose of path computation, and by GMPLS signaling.
+
+ Transparent:
+
+ 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.
+
+2. LMP Overview
+
+ The two core procedures of LMP are control channel management and
+ link property correlation. Control channel management is used to
+ establish and maintain control channels between adjacent nodes. This
+ is done using a Config message exchange and a fast keep-alive
+ mechanism between the nodes. The latter is required if lower-level
+ mechanisms are not available to detect control channel failures.
+ Link property correlation is used to synchronize the TE link
+ properties and verify the TE link configuration.
+
+ LMP requires that a pair of nodes have at least one active bi-
+ directional control channel between them. Each direction of the
+ control channel is identified by a Control Channel Id (CC_Id), and
+ the two directions are coupled together using the LMP Config message
+ exchange. Except for Test messages, which may be limited by the
+
+
+
+
+Lang Standards Track [Page 6]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ transport mechanism for in-band messaging, all LMP packets are run
+ over UDP with an LMP port number. The link level encoding of the
+ control channel is outside the scope of this document.
+
+ An "LMP adjacency" is formed between two nodes when at least one bi-
+ directional control channel is established between them. Multiple
+ control channels may be active simultaneously for each adjacency;
+ control channel parameters, however, MUST be individually negotiated
+ for each control channel. If the LMP fast keep-alive is used over a
+ control channel, LMP Hello messages MUST be exchanged over the
+ control channel. Other LMP messages MAY be transmitted over any of
+ the active control channels between a pair of adjacent nodes. One or
+ more active control channels may be grouped into a logical control
+ channel for signaling, routing, and link property correlation
+ purposes.
+
+ The link property correlation function of LMP is designed to
+ aggregate multiple data links (ports or component links) into a TE
+ link and to synchronize the properties of the TE link. As part of
+ the link property correlation function, a LinkSummary message
+ exchange is defined. The LinkSummary message includes the local and
+ remote Link_Ids, a list of all data links that comprise the TE link,
+ and various link properties. A LinkSummaryAck or LinkSummaryNack
+ message MUST be sent in response to the receipt of a LinkSummary
+ message indicating agreement or disagreement on the link properties.
+
+ LMP messages are transmitted reliably using Message_Ids and
+ retransmissions. Message_Ids are carried in MESSAGE_ID objects. No
+ more than one MESSAGE_ID object may be included in an LMP message.
+ For control-channel-specific messages, the Message_Id is within the
+ scope of the control channel over which the message is sent. For
+ TE-link-specific messages, the Message_Id is within the scope of the
+ LMP adjacency. The value of the Message_Id is monotonically
+ increasing and wraps when the maximum value is reached.
+
+ In this document, two additional LMP procedures are defined: link
+ connectivity verification and fault management. These procedures are
+ particularly useful when the control channels are physically diverse
+ from the data links. Link connectivity verification is used for data
+ plane discovery, Interface_Id exchange (Interface_Ids are used in
+ GMPLS signaling, either as port labels or component link identifiers,
+ depending on the configuration), and physical connectivity
+ verification. This is done by sending Test messages over the data
+ links and TestStatus messages back over the control channel. Note
+ that the Test message is the only LMP message that must be
+ transmitted over the data link. The ChannelStatus message exchange
+ is used between adjacent nodes for both the suppression of downstream
+ alarms and the localization of faults for protection and restoration.
+
+
+
+Lang Standards Track [Page 7]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ For LMP link connectivity verification, the Test message is
+ transmitted over the data links. For X-transparent devices, this
+ requires examining and modifying the X aspect of the signal. The LMP
+ link connectivity verification procedure is coordinated using a
+ BeginVerify message exchange over a control channel. To support
+ various aspects of transparency, a Verify Transport Mechanism is
+ included in the BeginVerify and BeginVerifyAck messages. Note that
+ there is no requirement that all data links must lose their
+ transparency simultaneously; but, at a minimum, it must be possible
+ to terminate them one at a time. There is also no requirement that
+ the control channel and TE link use the same physical medium;
+ however, the control channel MUST be terminated by the same two
+ control elements that control the TE link. Since the BeginVerify
+ message exchange coordinates the Test procedure, it also naturally
+ coordinates the transition of the data links in and out of the
+ transparent mode.
+
+ The LMP fault management procedure is based on a ChannelStatus
+ message exchange that uses the following messages: ChannelStatus,
+ ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse.
+ The ChannelStatus message is sent unsolicited and is used to notify
+ an LMP neighbor about the status of one or more data channels of a TE
+ link. The ChannelStatusAck message is used to acknowledge receipt of
+ the ChannelStatus message. The ChannelStatusRequest message is used
+ to query an LMP neighbor for the status of one or more data channels
+ of a TE Link. The ChannelStatusResponse message is used to
+ acknowledge receipt of the ChannelStatusRequest message and indicate
+ the states of the queried data links.
+
+3. Control Channel Management
+
+ To initiate an LMP adjacency between two nodes, one or more bi-
+ directional control channels MUST be activated. The control channels
+ can be used to exchange control-plane information such as link
+ provisioning and fault management information (implemented using a
+ messaging protocol such as LMP, proposed in this document), path
+ management and label distribution information (implemented using a
+ signaling protocol such as RSVP-TE [RFC3209]), and network topology
+ and state distribution information (implemented using traffic
+ engineering extensions of protocols such as OSPF [RFC3630] and IS-IS
+ [RFC3784]).
+
+ For the purposes of LMP, the exact implementation of the control
+ channel is not specified; it could be, for example, a separate
+ wavelength or fiber, an Ethernet link, an IP tunnel through a
+ separate management network, or the overhead bytes of a data link.
+ Each node assigns a node-wide, unique, 32-bit, non-zero integer
+ control channel identifier (CC_Id). This identifier comes from the
+
+
+
+Lang Standards Track [Page 8]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ same space as the unnumbered interface Id. Furthermore, LMP packets
+ are run over UDP with an LMP port number. Thus, the link level
+ encoding of the control channel is not part of the LMP specification.
+
+ To establish a control channel, the destination IP address on the far
+ end of the control channel must be known. This knowledge may be
+ manually configured or automatically discovered. Note that for in-
+ band signaling, a control channel could be explicitly configured on a
+ particular data link. In this case, the Config message exchange can
+ be used to dynamically learn the IP address on the far end of the
+ control channel. This is done by sending the Config message with the
+ unicast IP source address and the multicast IP destination address
+ (224.0.0.1 or ff02::1). The ConfigAck and ConfigNack messages MUST
+ be sent to the source IP address found in the IP header of the
+ received Config message.
+
+ Control channels exist independently of TE links and multiple control
+ channels may be active simultaneously between a pair of nodes.
+ Individual control channels can be realized in different ways; one
+ might be implemented in-fiber while another one may be implemented
+ out-of-fiber. As such, control channel parameters MUST be negotiated
+ over each individual control channel, and LMP Hello packets MUST be
+ exchanged over each control channel to maintain LMP connectivity if
+ other mechanisms are not available. Since control channels are
+ electrically terminated at each node, it may be possible to detect
+ control channel failures using lower layers (e.g., SONET/SDH).
+
+ There are four LMP messages that are used to manage individual
+ control channels. They are the Config, ConfigAck, ConfigNack, and
+ Hello messages. These messages MUST be transmitted on the channel to
+ which they refer. All other LMP messages may be transmitted over any
+ of the active control channels between a pair of LMP adjacent nodes.
+
+ In order to maintain an LMP adjacency, it is necessary to have at
+ least one active control channel between a pair of adjacent nodes
+ (recall that multiple control channels can be active simultaneously
+ between a pair of nodes). In the event of a control channel failure,
+ alternate active control channels can be used and it may be possible
+ to activate additional control channels as described below.
+
+3.1. Parameter Negotiation
+
+ Control channel activation begins with a parameter negotiation
+ exchange using Config, ConfigAck, and ConfigNack messages. The
+ contents of these messages are built using LMP objects, which can be
+ either negotiable or non-negotiable (identified by the N bit in the
+ object header). Negotiable objects can be used to let LMP peers
+
+
+
+
+Lang Standards Track [Page 9]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ agree on certain values. Non-negotiable objects are used for the
+ announcement of specific values that do not need, or do not allow,
+ negotiation.
+
+ To activate a control channel, a Config message MUST be transmitted
+ to the remote node, and in response, a ConfigAck message MUST be
+ received at the local node. The Config message contains the Local
+ Control Channel Id (CC_Id), the sender's Node_Id, a Message_Id for
+ reliable messaging, and a CONFIG object. It is possible that both
+ the local and remote nodes initiate the configuration procedure at
+ the same time. To avoid ambiguities, the node with the higher
+ Node_Id wins the contention; the node with the lower Node_Id MUST
+ stop transmitting the Config message and respond to the Config
+ message it received. If the Node_Ids are equal, then one (or both)
+ nodes have been misconfigured. The nodes MAY continue to retransmit
+ Config messages in hopes that the misconfiguration is corrected.
+ Note that the problem may be solved by an operator changing the
+ Node_Ids on one or both nodes.
+
+ The ConfigAck message is used to acknowledge receipt of the Config
+ message and express agreement on ALL of the configured parameters
+ (both negotiable and non-negotiable).
+
+ The ConfigNack message is used to acknowledge receipt of the Config
+ message, indicate which (if any) non-negotiable CONFIG objects are
+ unacceptable, and to propose alternate values for the negotiable
+ parameters.
+
+ If a node receives a ConfigNack message with acceptable alternate
+ values for negotiable parameters, the node SHOULD transmit a Config
+ message using these values for those parameters.
+
+ If a node receives a ConfigNack message with unacceptable alternate
+ values, the node MAY continue to retransmit Config messages in hopes
+ that the misconfiguration is corrected. Note that the problem may be
+ solved by an operator changing parameters on one or both nodes.
+
+ In the case where multiple control channels use the same physical
+ interface, the parameter negotiation exchange is performed for each
+ control channel. The various LMP parameter negotiation messages are
+ associated with their corresponding control channels by their node-
+ wide unique identifiers (CC_Ids).
+
+3.2. Hello Protocol
+
+ Once a control channel is activated between two adjacent nodes, the
+ LMP Hello protocol can be used to maintain control channel
+ connectivity between the nodes and to detect control channel
+
+
+
+Lang Standards Track [Page 10]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ failures. The LMP Hello protocol is intended to be a lightweight
+ keep-alive mechanism that will react to control channel failures
+ rapidly so that IGP Hellos are not lost and the associated link-state
+ adjacencies are not removed unnecessarily.
+
+3.2.1. Hello Parameter Negotiation
+
+ Before sending Hello messages, the HelloInterval and
+ HelloDeadInterval parameters MUST be agreed upon by the local and
+ remote nodes. These parameters are exchanged in the Config message.
+ The HelloInterval indicates how frequently LMP Hello messages will be
+ sent, and is measured in milliseconds (ms). For example, if the
+ value were 150, then the transmitting node would send the Hello
+ message at least every 150 ms. The HelloDeadInterval indicates how
+ long a device should wait to receive a Hello message before declaring
+ a control channel dead, and is measured in milliseconds (ms).
+
+ The HelloDeadInterval MUST be greater than the HelloInterval, and
+ SHOULD be at least 3 times the value of HelloInterval. If the fast
+ keep-alive mechanism of LMP is not used, the HelloInterval and
+ HelloDeadInterval parameters MUST be set to zero.
+
+ The values for the HelloInterval and HelloDeadInterval should be
+ selected carefully to provide rapid response time to control channel
+ failures without causing congestion. As such, different values will
+ likely be configured for different control channel implementations.
+ When the control channel is implemented over a directly connected
+ link, the suggested default values for the HelloInterval is 150 ms
+ and for the HelloDeadInterval is 500 ms.
+
+ When a node has either sent or received a ConfigAck message, it may
+ begin sending Hello messages. Once it has sent a Hello message and
+ received a valid Hello message (i.e., with expected sequence numbers;
+ see Section 3.2.2), the control channel moves to the up state. (It
+ is also possible to move to the up state without sending Hellos if
+ other methods are used to indicate bi-directional control-channel
+ connectivity. For example, indication of bi-directional connectivity
+ may be learned from the transport layer.) If, however, a node
+ receives a ConfigNack message instead of a ConfigAck message, the
+ node MUST not send Hello messages and the control channel SHOULD NOT
+ move to the up state. See Section 11.1 for the complete control
+ channel FSM.
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 11]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+3.2.2. Fast Keep-alive
+
+ Each Hello message contains two sequence numbers: the first sequence
+ number (TxSeqNum) is the sequence number for the Hello message being
+ sent and the second sequence number (RcvSeqNum) is the sequence
+ number of the last Hello message received from the adjacent node over
+ this control channel.
+
+ There are two special sequence numbers. TxSeqNum MUST NOT ever be 0.
+ TxSeqNum = 1 is used to indicate that the sender has just started or
+ has restarted and has no recollection of the last TxSeqNum that was
+ sent. Thus, the first Hello sent has a TxSeqNum of 1 and an RxSeqNum
+ of 0. When TxSeqNum reaches (2^32)-1, the next sequence number used
+ is 2, not 0 or 1, as these have special meanings.
+
+ Under normal operation, the difference between the RcvSeqNum in a
+ Hello message that is received and the local TxSeqNum that is
+ generated will be at most 1. This difference can be more than one
+ only when a control channel restarts or when the values wrap.
+
+ Since the 32-bit sequence numbers may wrap, the following expression
+ may be used to test if a newly received TxSeqNum value is less than a
+ previously received value:
+
+ If ((int) old_id - (int) new_id > 0) {
+ New value is less than old value;
+ }
+
+ Having sequence numbers in the Hello messages allows each node to
+ verify that its peer is receiving its Hello messages. By including
+ the RcvSeqNum in Hello packets, the local node will know which Hello
+ packets the remote node has received.
+
+ The following example illustrates how the sequence numbers operate.
+ Note that only the operation at one node is shown, and alternative
+ scenarios are possible:
+
+ 1) After completing the configuration stage, Node A sends Hello
+ messages to Node B with {TxSeqNum=1;RcvSeqNum=0}.
+
+ 2) Node A receives a Hello from Node B with {TxSeqNum=1;RcvSeqNum=1}.
+ When the HelloInterval expires on Node A, it sends Hellos to Node
+ B with {TxSeqNum=2;RcvSeqNum=1}.
+
+ 3) Node A receives a Hello from Node B with {TxSeqNum=2;RcvSeqNum=2}.
+ When the HelloInterval expires on Node A, it sends Hellos to Node
+ B with {TxSeqNum=3;RcvSeqNum=2}.
+
+
+
+
+Lang Standards Track [Page 12]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+3.2.3. Control Channel Down
+
+ To allow bringing a control channel down gracefully for
+ administration purposes, a ControlChannelDown flag is available in
+ the Common Header of LMP packets. When data links are still in use
+ between a pair of nodes, a control channel SHOULD only be taken down
+ administratively when there are other active control channels that
+ can be used to manage the data links.
+
+ When bringing a control channel down administratively, a node MUST
+ set the ControlChannelDown flag in all LMP messages sent over the
+ control channel. The node that initiated the control channel down
+ procedure may stop sending Hello messages after HelloDeadInterval
+ seconds have passed, or if it receives an LMP message over the same
+ control channel with the ControlChannelDown flag set.
+
+ When a node receives an LMP packet with the ControlChannelDown flag
+ set, it SHOULD send a Hello message with the ControlChannelDown flag
+ set and move the control channel to the down state.
+
+3.2.4. Degraded State
+
+ A consequence of allowing the control channels to be physically
+ diverse from the associated data links is that there may not be any
+ active control channels available while the data links are still in
+ use. For many applications, it is unacceptable to tear down a link
+ that is carrying user traffic simply because the control channel is
+ no longer available; however, the traffic that is using the data
+ links may no longer be guaranteed the same level of service. Hence,
+ the TE link is in a Degraded state.
+
+ When a TE link is in the Degraded state, routing and signaling SHOULD
+ be notified so that new connections are not accepted and the TE link
+ is advertised with no unreserved resources.
+
+4. Link Property Correlation
+
+ As part of LMP, a link property correlation exchange is defined for
+ TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack
+ messages. The contents of these messages are built using LMP
+ objects, which can be either negotiable or non-negotiable (identified
+ by the N flag in the object header). Negotiable objects can be used
+ to let both sides agree on certain link parameters. Non-negotiable
+ objects are used for announcement of specific values that do not
+ need, or do not allow, negotiation.
+
+
+
+
+
+
+Lang Standards Track [Page 13]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Each TE link has an identifier (Link_Id) that is assigned at each end
+ of the link. These identifiers MUST be the same type (i.e, IPv4,
+ IPv6, unnumbered) at both ends. If a LinkSummary message is received
+ with different local and remote TE link types, then a LinkSummaryNack
+ message MUST be sent with Error Code "Bad TE Link Object".
+ Similarly, each data link is assigned an identifier (Interface_Id) at
+ each end. These identifiers MUST also be the same type at both ends.
+ If a LinkSummary message is received with different local and remote
+ Interface_Id types, then a LinkSummaryNack message MUST be sent with
+ Error Code "Bad Data Link Object".
+
+ Link property correlation SHOULD be done before the link is brought
+ up and MAY be done any time a link is up and not in the Verification
+ process.
+
+ The LinkSummary message is used to verify for consistency the TE and
+ data link information on both sides. Link Summary messages are also
+ used (1) to aggregate multiple data links (either ports or component
+ links) into a TE link; (2) to exchange, correlate (to determine
+ inconsistencies), or change TE link parameters; and (3) to exchange,
+ correlate (to determine inconsistencies), or change Interface_Ids
+ (either Port_Ids or component link identifiers).
+
+ The LinkSummary message includes a TE_LINK object followed by one or
+ more DATA_LINK objects. The TE_LINK object identifies the TE link's
+ local and remote Link_Id and indicates support for fault management
+ and link verification procedures for that TE link. The DATA_LINK
+ objects are used to characterize the data links that comprise the TE
+ link. These objects include the local and remote Interface_Ids, and
+ may include one or more sub-objects further describing the properties
+ of the data links.
+
+ If the LinkSummary message is received from a remote node, and the
+ Interface_Id mappings match those that are stored locally, then the
+ two nodes have agreement on the Verification procedure (see Section
+ 5) and data link identification configuration. If the verification
+ procedure is not used, the LinkSummary message can be used to verify
+ agreement on manual configuration.
+
+ The LinkSummaryAck message is used to signal agreement on the
+ Interface_Id mappings and link property definitions. Otherwise, a
+ LinkSummaryNack message MUST be transmitted, indicating which
+ Interface mappings are not correct and/or which link properties are
+ not accepted. If a LinkSummaryNack message indicates that the
+ Interface_Id mappings are not correct and the link verification
+ procedure is enabled, the link verification process SHOULD be
+ repeated for all mismatched, free data links; if an allocated data
+ link has a mapping mismatch, it SHOULD be flagged and verified when
+
+
+
+Lang Standards Track [Page 14]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ it becomes free. If a LinkSummaryNack message includes negotiable
+ parameters, then acceptable values for those parameters MUST be
+ included. If a LinkSummaryNack message is received and includes
+ negotiable parameters, then the initiator of the LinkSummary message
+ SHOULD send a new LinkSummary message. The new LinkSummary message
+ SHOULD include new values for the negotiable parameters. These
+ values SHOULD take into account the acceptable values received in the
+ LinkSummaryNack message.
+
+ It is possible that the LinkSummary message could grow quite large
+ due to the number of DATA LINK objects. An LMP implementation SHOULD
+ be able to fragment when transmitting LMP messages, and MUST be able
+ to re-assemble IP fragments when receiving LMP messages.
+
+5. Verifying Link Connectivity
+
+ In this section, an optional procedure is described that may be used
+ to verify the physical connectivity of the data links and dynamically
+ learn (i.e., discover) the TE link and Interface_Id associations.
+ The procedure SHOULD be done when establishing a TE link, and
+ subsequently, on a periodic basis for all unallocated (free) data
+ links of the TE link.
+
+ Support for this procedure is indicated by setting the "Link
+ Verification Supported" flag in the TE_LINK object of the LinkSummary
+ message.
+
+ If a BeginVerify message is received and link verification is not
+ supported for the TE link, then a BeginVerifyNack message MUST be
+ transmitted with Error Code indicating, "Link Verification Procedure
+ not supported for this TE Link."
+
+ A unique characteristic of transparent devices is that the data is
+ not modified or examined during normal operation. This
+ characteristic poses a challenge for validating the connectivity of
+ the data links and establishing the label mappings. Therefore, to
+ ensure proper verification of data link connectivity, it is required
+ that, until the data links are allocated for user traffic, they must
+ be opaque (i.e., lose their transparency). To support various
+ degrees of opaqueness (e.g., examining overhead bytes, terminating
+ the IP payload, etc.) and, hence, different mechanisms to transport
+ the Test messages, a Verify Transport Mechanism field is included in
+ the BeginVerify and BeginVerifyAck messages.
+
+ There is no requirement that all data links be terminated
+ simultaneously; but, at a minimum, the data links MUST be able to be
+ terminated one at a time. Furthermore, for the link verification
+ procedure it is assumed that the nodal architecture is designed so
+
+
+
+Lang Standards Track [Page 15]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ that messages can be sent and received over any data link. Note that
+ this requirement is trivial for opaque devices since each data link
+ is electrically terminated and processed before being forwarded to
+ the next opaque device; but that in transparent devices this is an
+ additional requirement.
+
+ To interconnect two nodes, a TE link is defined between them, and at
+ a minimum, there MUST be at least one active control channel between
+ the nodes. For link verification, a TE link MUST include at least
+ one data link.
+
+ Once a control channel has been established between the two nodes,
+ data link connectivity can be verified by exchanging Test messages
+ over each of the data links specified in the TE link. It should be
+ noted that all LMP messages except the Test message are exchanged
+ over the control channels and that Hello messages continue to be
+ exchanged over each control channel during the data link verification
+ process. The Test message is sent over the data link that is being
+ verified. Data links are tested in the transmit direction because
+ they are unidirectional; therefore, it may be possible for both nodes
+ to (independently) exchange the Test messages simultaneously.
+
+ To initiate the link verification procedure, the local node MUST send
+ a BeginVerify message over a control channel. To limit the scope of
+ Link Verification to a particular TE Link, the local Link_Id MUST be
+ non-zero. If this field is zero, the data links can span multiple TE
+ links and/or they may comprise a TE link that is yet to be
+ configured. For the case where the local Link_Id field is zero, the
+ "Verify all Links" flag of the BEGIN_VERIFY object is used to
+ distinguish between data links that span multiple TE links and those
+ that have not yet been assigned to a TE link. Specifically,
+ verification of data links that span multiple TE links is indicated
+ by setting the local Link_Id field to zero and setting the "Verify
+ all Links" flag. Verification of data links that have not yet been
+ assigned to a TE link is indicated by setting the local Link_Id field
+ to zero and clearing the "Verify all Links" flag.
+
+ The BeginVerify message also contains the number of data links that
+ are to be verified; the interval (called VerifyInterval) at which the
+ Test messages will be sent; the encoding scheme and transport
+ mechanisms that are supported; the data rate for Test messages; and,
+ when the data links correspond to fibers, the wavelength identifier
+ over which the Test messages will be transmitted.
+
+ If the remote node receives a BeginVerify message and it is ready to
+ process Test messages, it MUST send a BeginVerifyAck message back to
+ the local node specifying the desired transport mechanism for the
+ TEST messages. The remote node includes a 32-bit, node-unique
+
+
+
+Lang Standards Track [Page 16]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Verify_Id in the BeginVerifyAck message. The Verify_Id MAY be
+ randomly selected; however, it MUST NOT overlap any other Verify_Id
+ currently being used by the node selecting it. The Verify_Id is then
+ used in all corresponding verification messages to differentiate them
+ from different LMP peers and/or parallel Test procedures. When the
+ local node receives a BeginVerifyAck message from the remote node, it
+ may begin testing the data links by transmitting periodic Test
+ messages over each data link. The Test message includes the
+ Verify_Id and the local Interface_Id for the associated data link.
+ The remote node MUST send either a TestStatusSuccess or a
+ TestStatusFailure message in response for each data link. A
+ TestStatusAck message MUST be sent to confirm receipt of the
+ TestStatusSuccess and TestStatusFailure messages. Unacknowledged
+ TestStatusSuccess and TestStatusFailure messages SHOULD be
+ retransmitted until the message is acknowledged or until a retry
+ limit is reached (see also Section 10).
+
+ It is also permissible for the sender to terminate the Test procedure
+ anytime after sending the BeginVerify message. An EndVerify message
+ SHOULD be sent for this purpose.
+
+ Message correlation is done using message identifiers and the
+ Verify_Id; this enables verification of data links, belonging to
+ different link bundles or LMP sessions, in parallel.
+
+ When the Test message is received, the received Interface_Id (used in
+ GMPLS as either a Port label or component link identifier, depending
+ on the configuration) is recorded and mapped to the local
+ Interface_Id for that data link, and a TestStatusSuccess message MUST
+ be sent. The TestStatusSuccess message includes the local
+ Interface_Id along with the Interface_Id and Verify_Id received in
+ the Test message. The receipt of a TestStatusSuccess message
+ indicates that the Test message was detected at the remote node and
+ the physical connectivity of the data link has been verified. When
+ the TestStatusSuccess message is received, the local node SHOULD mark
+ the data link as up and send a TestStatusAck message to the remote
+ node. If, however, the Test message is not detected at the remote
+ node within an observation period (specified by the
+ VerifyDeadInterval), the remote node MUST send a TestStatusFailure
+ message over the control channel, which indicates that the
+ verification of the physical connectivity of the data link has
+ failed. When the local node receives a TestStatusFailure message, it
+ SHOULD mark the data link as FAILED and send a TestStatusAck message
+ to the remote node. When all the data links on the list have been
+ tested, the local node SHOULD send an EndVerify message to indicate
+ that testing is complete on this link.
+
+
+
+
+
+Lang Standards Track [Page 17]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ If the local/remote data link mappings are known, then the link
+ verification procedure can be optimized by testing the data links in
+ a defined order known to both nodes. The suggested criterion for
+ this ordering is by increasing the value of the remote Interface_Id.
+
+ Both the local and remote nodes SHOULD maintain the complete list of
+ Interface_Id mappings for correlation purposes.
+
+5.1. Example of Link Connectivity Verification
+
+ Figure 1 shows an example of the link verification scenario that is
+ executed when a link between Node A and Node B is added. In this
+ example, the TE link consists of three free ports (each transmitted
+ along a separate fiber) and is associated with a bi-directional
+ control channel (indicated by a "c"). The verification process is as
+ follows:
+
+ o A sends a BeginVerify message over the control channel to B,
+ indicating it will begin verifying the ports that form the TE
+ link. The LOCAL_LINK_ID object carried in the BeginVerify message
+ carries the identifier (IP address or interface index) that A
+ assigns to the link.
+ o Upon receipt of the BeginVerify message, B creates a Verify_Id and
+ binds it to the TE Link from A. This binding is used later when B
+ receives the Test messages from A, and these messages carry the
+ Verify_Id. B discovers the identifier (IP address or interface
+ index) that A assigns to the TE link by examining the
+ LOCAL_LINK_ID object carried in the received BeginVerify message.
+ (If the data ports are not yet assigned to the TE Link, the
+ binding is limited to the Node_Id of A.) In response to the
+ BeginVerify message, B sends the BeginVerifyAck message to A. The
+ LOCAL_LINK_ID object carried in the BeginVerifyAck message is used
+ to carry the identifier (IP address or interface index) that B
+ assigns to the TE link. The REMOTE_LINK_ID object carried in the
+ BeginVerifyAck message is used to bind the Link_Ids assigned by
+ both A and B. The Verify_Id is returned to A in the
+ BeginVerifyAck message over the control channel.
+ o When A receives the BeginVerifyAck message, it begins transmitting
+ periodic Test messages over the first port (Interface Id=1). The
+ Test message includes the Interface_Id for the port and the
+ Verify_Id that was assigned by B.
+ o When B receives the Test messages, it maps the received
+ Interface_Id to its own local Interface_Id = 10 and transmits a
+ TestStatusSuccess message over the control channel back to Node A.
+ The TestStatusSuccess message includes both the local and received
+ Interface_Ids for the port as well as the Verify_Id. The
+
+
+
+
+
+Lang Standards Track [Page 18]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Verify_Id is used to determine the local/remote TE link
+ identifiers (IP addresses or interface indices) to which the data
+ links belong.
+ o A will send a TestStatusAck message over the control channel back
+ to B, indicating it received the TestStatusSuccess message.
+ o The process is repeated until all of the ports are verified.
+ o At this point, A will send an EndVerify message over the control
+ channel to B, indicating that testing is complete.
+ o B will respond by sending an EndVerifyAck message over the control
+ channel back to A.
+
+ Note that this procedure can be used to "discover" the
+ connectivity of the data ports.
+
+ +---------------------+ +---------------------+
+ + + + +
+ + Node A +<-------- c --------->+ Node B +
+ + + + +
+ + + + +
+ + 1 +--------------------->+ 10 +
+ + + + +
+ + + + +
+ + 2 + /---->+ 11 +
+ + + /----/ + +
+ + + /---/ + +
+ + 3 +----/ + 12 +
+ + + + +
+ + + + +
+ + 4 +--------------------->+ 14 +
+ + + + +
+ +---------------------+ +---------------------+
+
+ Figure 1: Example of link connectivity between Node A and Node B.
+
+6. Fault Management
+
+ In this section, an optional LMP procedure is described that is used
+ to manage failures by rapid notification of the status of one or more
+ data channels of a TE Link. The scope of this procedure is within a
+ TE link, and as such, the use of this procedure is negotiated as part
+ of the LinkSummary exchange. The procedure can be used to rapidly
+ isolate data link and TE link failures, and is designed to work for
+ both unidirectional and bi-directional LSPs.
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 19]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ An important implication of using transparent devices is that
+ traditional methods that are used to monitor the health of allocated
+ data links may no longer be appropriate. Instead of fault detection
+ being in layer 2 or layer 3, it is delegated to the physical layer
+ (i.e., loss of light or optical monitoring of the data).
+
+ Recall that a TE link connecting two nodes may consist of a number of
+ data links. If one or more data links fail between two nodes, a
+ mechanism must be used for rapid failure notification so that
+ appropriate protection/restoration mechanisms can be initiated. If
+ the failure is subsequently cleared, then a mechanism must be used to
+ notify that the failure is clear and the channel status is OK.
+
+6.1. Fault Detection
+
+ Fault detection should be handled at the layer closest to the
+ failure; for optical networks, this is the physical (optical) layer.
+ One measure of fault detection at the physical layer is detecting
+ loss of light (LOL). Other techniques for monitoring optical signals
+ are still being developed and will not be further considered in this
+ document. However, it should be clear that the mechanism used for
+ fault notification in LMP is independent of the mechanism used to
+ detect the failure, and simply relies on the fact that a failure is
+ detected.
+
+6.2. Fault Localization Procedure
+
+ In some situations, a data link failure between two nodes is
+ propagated downstream such that all the downstream nodes detect the
+ failure without localizing the failure. To avoid multiple alarms
+ stemming from the same failure, LMP provides failure notification
+ through the ChannelStatus message. This message may be used to
+ indicate that a single data channel has failed, multiple data
+ channels have failed, or an entire TE link has failed. Failure
+ correlation is done locally at each node upon receipt of the failure
+ notification.
+
+ To localize a fault to a particular link between adjacent nodes, a
+ downstream node (downstream in terms of data flow) that detects data
+ link failures will send a ChannelStatus message to its upstream
+ neighbor indicating that a failure has been detected (bundling
+ together the notification of all the failed data links). An upstream
+ node that receives the ChannelStatus message MUST send a
+ ChannelStatusAck message to the downstream node indicating it has
+ received the ChannelStatus message. The upstream node should
+ correlate the failure to see if the failure is also detected locally
+ for the corresponding LSP(s). If, for example, the failure is clear
+ on the input of the upstream node or internally, then the upstream
+
+
+
+Lang Standards Track [Page 20]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ node will have localized the failure. Once the failure is
+ correlated, the upstream node SHOULD send a ChannelStatus message to
+ the downstream node indicating that the channel is failed or is OK.
+ If a ChannelStatus message is not received by the downstream node, it
+ SHOULD send a ChannelStatusRequest message for the channel in
+ question. Once the failure has been localized, the signaling
+ protocols may be used to initiate span or path protection and
+ restoration procedures.
+
+ If all of the data links of a TE link have failed, then the upstream
+ node MAY be notified of the TE link failure without specifying each
+ data link of the failed TE link. This is done by sending failure
+ notification in a ChannelStatus message identifying the TE Link
+ without including the Interface_Ids in the CHANNEL_STATUS object.
+
+6.3. Examples of Fault Localization
+
+ In Figure 2, a sample network is shown where four nodes are connected
+ in a linear array configuration. The control channels are bi-
+ directional and are labeled with a "c". All LSPs are also bi-
+ directional.
+
+ In the first example [see Fig. 2(a)], there is a failure on one
+ direction of the bi-directional LSP. Node 4 will detect the failure
+ and will send a ChannelStatus message to Node 3 indicating the
+ failure (e.g., LOL) to the corresponding upstream node. When Node 3
+ receives the ChannelStatus message from Node 4, it returns a
+ ChannelStatusAck message back to Node 4 and correlates the failure
+ locally. When Node 3 correlates the failure and verifies that the
+ failure is clear, it has localized the failure to the data link
+ between Node 3 and Node 4. At that time, Node 3 should send a
+ ChannelStatus message to Node 4 indicating that the failure has been
+ localized.
+
+ In the second example [see Fig. 2(b)], a single failure (e.g., fiber
+ cut) affects both directions of the bi-directional LSP. Node 2 (Node
+ 3) will detect the failure of the upstream (downstream) direction and
+ send a ChannelStatus message to the upstream (in terms of data flow)
+ node indicating the failure (e.g., LOL). Simultaneously (ignoring
+ propagation delays), Node 1 (Node 4) will detect the failure on the
+ upstream (downstream) direction, and will send a ChannelStatus
+ message to the corresponding upstream (in terms of data flow) node
+ indicating the failure. Node 2 and Node 3 will have localized the
+ two directions of the failure.
+
+
+
+
+
+
+
+Lang Standards Track [Page 21]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ +-------+ +-------+ +-------+ +-------+
+ + Node1 + + Node2 + + Node3 + + Node4 +
+ + +-- c ---+ +-- c ---+ +-- c ---+ +
+ ----+---\ + + + + + + +
+ <---+---\\--+--------+-------+---\ + + + /--+--->
+ + \--+--------+-------+---\\---+-------+---##---+---//--+----
+ + + + + \---+-------+--------+---/ +
+ + + + + + + (a) + +
+ ----+-------+--------+---\ + + + + +
+ <---+-------+--------+---\\--+---##---+--\ + + +
+ + + + \--+---##---+--\\ + + +
+ + + + + (b) + \\--+--------+-------+--->
+ + + + + + \--+--------+-------+----
+ + + + + + + + +
+ +-------+ +-------+ +-------+ +-------+
+
+ Figure 2: Two types of data link failures are shown (indicated
+ by ## in the figure):
+ (A) a data link corresponding to the downstream direction of a
+ bi-directional LSP fails,
+ (B) two data links corresponding to both directions of a bi-
+ directional LSP fail. The control channel connecting two
+ nodes is indicated with a "c".
+
+6.4. Channel Activation Indication
+
+ The ChannelStatus message may also be used to notify an LMP neighbor
+ that the data link should be actively monitored. This is called
+ Channel Activation Indication. This is particularly useful in
+ networks with transparent nodes where the status of data links may
+ need to be triggered using control channel messages. For example, if
+ a data link is pre-provisioned and the physical link fails after
+ verification and before inserting user traffic, a mechanism is needed
+ to indicate the data link should be active, otherwise the failure may
+ not be detectable.
+
+ The ChannelStatus message is used to indicate that a channel or group
+ of channels are now active. The ChannelStatusAck message MUST be
+ transmitted upon receipt of a ChannelStatus message. When a
+ ChannelStatus message is received, the corresponding data link(s)
+ MUST be put into the Active state. If upon putting them into the
+ Active state, a failure is detected, the ChannelStatus message SHOULD
+ be transmitted as described in Section 6.2.
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 22]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+6.5. Channel Deactivation Indication
+
+ The ChannelStatus message may also be used to notify an LMP neighbor
+ that the data link no longer needs to be actively monitored. This is
+ the counterpart to the Channel Active Indication.
+
+ When a ChannelStatus message is received with Channel Deactive
+ Indication, the corresponding data link(s) MUST be taken out of the
+ Active state.
+
+7. Message_Id Usage
+
+ The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP
+ messages to support reliable message delivery. This section
+ describes the usage of these objects. The MESSAGE_ID and
+ MESSAGE_ID_ACK objects contain a Message_Id field.
+
+ Only one MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP
+ message.
+
+ For control-channel-specific messages, the Message_Id field is within
+ the scope of the CC_Id. For TE link specific messages, the
+ Message_Id field is within the scope of the LMP adjacency.
+
+ The Message_Id field of the MESSAGE_ID object contains a generator-
+ selected value. This value MUST be monotonically increasing. A
+ value is considered to be previously used when it has been sent in an
+ LMP message with the same CC_Id (for control channel specific
+ messages) or LMP adjacency (for TE Link specific messages). The
+ Message_Id field of the MESSAGE_ID_ACK object contains the Message_Id
+ field of the message being acknowledged.
+
+ Unacknowledged messages sent with the MESSAGE_ID object SHOULD be
+ retransmitted until the message is acknowledged or until a retry
+ limit is reached (see also Section 10).
+
+ Note that the 32-bit Message_Id value may wrap. The following
+ expression may be used to test if a newly received Message_Id value
+ is less than a previously received value:
+
+ If ((int) old_id - (int) new_id > 0) {
+ New value is less than old value;
+ }
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 23]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Nodes processing incoming messages SHOULD check to see if a newly
+ received message is out of order and can be ignored. Out-of-order
+ messages can be identified by examining the value in the Message_Id
+ field. If a message is determined to be out-of-order, that message
+ should be silently dropped.
+
+ If the message is a Config message, and the Message_Id value is less
+ than the largest Message_Id value previously received from the sender
+ for the CC_Id, then the message SHOULD be treated as being out-of-
+ order.
+
+ If the message is a LinkSummary message and the Message_Id value is
+ less than the largest Message_Id value previously received from the
+ sender for the TE Link, then the message SHOULD be treated as being
+ out-of-order.
+
+ If the message is a ChannelStatus message and the Message_Id value is
+ less than the largest Message_Id value previously received from the
+ sender for the specified TE link, then the receiver SHOULD check the
+ Message_Id value previously received for the state of each data
+ channel included in the ChannelStatus message. If the Message_Id
+ value is greater than the most recently received Message_Id value
+ associated with at least one of the data channels included in the
+ message, the message MUST NOT be treated as out of order; otherwise,
+ the message SHOULD be treated as being out of order. However, the
+ state of any data channel MUST NOT be updated if the Message_Id value
+ is less than the most recently received Message_Id value associated
+ with the data channel.
+
+ All other messages MUST NOT be treated as out-of-order.
+
+8. Graceful Restart
+
+ This section describes the mechanism to resynchronize the LMP state
+ after a control plane restart. A control plane restart may occur
+ when bringing up the first control channel after a control
+ communications failure. A control communications failure may be the
+ result of an LMP adjacency failure or a nodal failure wherein the LMP
+ control state is lost, but the data plane is unaffected. The latter
+ is detected by setting the "LMP Restart" bit in the Common Header of
+ the LMP messages. When the control plane fails due to the loss of
+ the control channel, the LMP link information should be retained. It
+ is possible that a node may be capable of retaining the LMP link
+ information across a nodal failure. However, in both cases the
+ status of the data channels MUST be synchronized.
+
+
+
+
+
+
+Lang Standards Track [Page 24]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ It is assumed the Node_Id and Local Interface_Ids remain stable
+ across a control plane restart.
+
+ After the control plane of a node restarts, the control channel(s)
+ must be re-established using the procedures of Section 3.1. When
+ re-establishing control channels, the Config message SHOULD be sent
+ using the unicast IP source and destination addresses.
+
+ If the control plane failure was the result of a nodal failure where
+ the LMP control state is lost, then the "LMP Restart" flag MUST be
+ set in LMP messages until a Hello message is received with the
+ RcvSeqNum equal to the local TxSeqNum. This indicates that the
+ control channel is up and the LMP neighbor has detected the restart.
+
+ The following assumes that the LMP component restart only occurred on
+ one end of the TE Link. If the LMP component restart occurred on
+ both ends of the TE Link, the normal procedures for LinkSummary
+ should be used, as described in Section 4.
+
+ Once a control channel is up, the LMP neighbor MUST send a
+ LinkSummary message for each TE Link across the adjacency. All the
+ objects of the LinkSummary message MUST have the N-bit set to 0,
+ indicating that the parameters are non-negotiable. This provides the
+ local/remote Link_Id and Interface_Id mappings, the associated data
+ link parameters, and indication of which data links are currently
+ allocated to user traffic. When a node receives the LinkSummary
+ message, it checks its local configuration. If the node is capable
+ of retaining the LMP link information across a restart, it must
+ process the LinkSummary message as described in Section 4 with the
+ exception that the allocated/de-allocated flag of the DATA_LINK
+ object received in the LinkSummary message MUST take precedence over
+ any local value. If, however, the node was not capable of retaining
+ the LMP link information across a restart, the node MUST accept the
+ data link parameters of the received LinkSummary message and respond
+ with a LinkSummaryAck message.
+
+ Upon completion of the LinkSummary exchange, the node that has
+ restarted the control plane SHOULD send a ChannelStatusRequest
+ message for that TE link. The node SHOULD also verify the
+ connectivity of all unallocated data channels.
+
+9. Addressing
+
+ All LMP messages are run over UDP with an LMP port number (except, in
+ some cases, the Test messages, which may be limited by the transport
+ mechanism for in-band messaging). The destination address of the IP
+ packet MAY be either the address learned in the Configuration
+ procedure (i.e., the Source IP address found in the IP header of the
+
+
+
+Lang Standards Track [Page 25]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ received Config message), an IP address configured on the remote
+ node, or the Node_Id. The Config message is an exception as
+ described below.
+
+ The manner in which a Config message is addressed may depend on the
+ signaling transport mechanism. When the transport mechanism is a
+ point-to-point link, Config messages SHOULD be sent to the Multicast
+ address (224.0.0.1 or ff02::1). Otherwise, Config messages MUST be
+ sent to an IP address on the neighboring node. This may be
+ configured at both ends of the control channel or may be
+ automatically discovered.
+
+10. Exponential Back-off Procedures
+
+ This section is based on [RFC2961] and provides exponential back-off
+ procedures for message retransmission. Implementations MUST use the
+ described procedures or their equivalent.
+
+10.1. Operation
+
+ The following operation is one possible mechanism for exponential
+ back-off retransmission of unacknowledged LMP messages. The sending
+ node retransmits the message until an acknowledgement message is
+ received or until a retry limit is reached. When the sending node
+ receives the acknowledgement, retransmission of the message is
+ stopped. The interval between message retransmission is governed by
+ a rapid retransmission timer. The rapid retransmission timer starts
+ at a small interval and increases exponentially until it reaches a
+ threshold.
+
+ The following time parameters are useful to characterize the
+ procedures:
+
+ Rapid retransmission interval Ri:
+
+ Ri is the initial retransmission interval for unacknowledged
+ messages. After sending the message for the first time, the
+ sending node will schedule a retransmission after Ri milliseconds.
+
+ Rapid retry limit Rl:
+
+ Rl is the maximum number of times a message will be transmitted
+ without being acknowledged.
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 26]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Increment value Delta:
+
+ Delta governs the speed with which the sender increases the
+ retransmission interval. The ratio of two successive
+ retransmission intervals is (1 + Delta).
+
+ Suggested default values for an initial retransmission interval (Ri)
+ of 500 ms are a power of 2 exponential back-off (Delta = 1) and a
+ retry limit of 3.
+
+10.2. Retransmission Algorithm
+
+ After a node transmits a message requiring acknowledgement, it should
+ immediately schedule a retransmission after Ri seconds. If a
+ corresponding acknowledgement message is received before Ri seconds,
+ then message retransmission SHOULD be canceled. Otherwise, it will
+ retransmit the message after (1+Delta)*Ri seconds. The
+ retransmission will continue until either an appropriate
+ acknowledgement message is received or the rapid retry limit, Rl, has
+ been reached.
+
+ A sending node can use the following algorithm when transmitting a
+ message that requires acknowledgement:
+
+ Prior to initial transmission, initialize Rk = Ri and Rn = 0.
+
+ while (Rn++ < Rl) {
+ transmit the message;
+ wake up after Rk milliseconds;
+ Rk = Rk * (1 + Delta);
+ }
+ /* acknowledged message or no reply from receiver and Rl
+ reached*/
+ do any needed clean up;
+ exit;
+
+ Asynchronously, when a sending node receives a corresponding
+ acknowledgment message, it will change the retry count, Rn, to Rl.
+
+ Note that the transmitting node does not advertise or negotiate the
+ use of the described exponential back-off procedures in the Config or
+ LinkSummary messages.
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 27]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+11. LMP Finite State Machines
+
+11.1. Control Channel FSM
+
+ The control channel FSM defines the states and logics of operation of
+ an LMP control channel.
+
+11.1.1. Control Channel States
+
+ A control channel can be in one of the states described below. Every
+ state corresponds to a certain condition of the control channel and
+ is usually associated with a specific type of LMP message that is
+ periodically transmitted to the far end.
+
+ Down: This is the initial control channel state. In this
+ state, no attempt is being made to bring the control
+ channel up and no LMP messages are sent. The control
+ channel parameters should be set to the initial values.
+
+ ConfSnd: The control channel is in the parameter negotiation
+ state. In this state the node periodically sends a
+ Config message, and is expecting the other side to reply
+ with either a ConfigAck or ConfigNack message. The FSM
+ does not transition into the Active state until the
+ remote side positively acknowledges the parameters.
+
+ ConfRcv: The control channel is in the parameter negotiation
+ state. In this state, the node is waiting for acceptable
+ configuration parameters from the remote side. Once such
+ parameters are received and acknowledged, the FSM can
+ transition to the Active state.
+
+ Active: In this state the node periodically sends a Hello message
+ and is waiting to receive a valid Hello message. Once a
+ valid Hello message is received, it can transition to the
+ up state.
+
+ Up: The CC is in an operational state. The node receives
+ valid Hello messages and sends Hello messages.
+
+ GoingDown: A CC may go into this state because of administrative
+ action. While a CC is in this state, the node sets the
+ ControlChannelDown bit in all the messages it sends.
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 28]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+11.1.2. Control Channel Events
+
+ Operation of the LMP control channel is described in terms of FSM
+ states and events. Control channel events are generated by the
+ underlying protocols and software modules, as well as by the packet
+ processing routines and FSMs of associated TE links. Every event has
+ its number and a symbolic name. Description of possible control
+ channel events is given below.
+
+ 1 : evBringUp: This is an externally triggered event indicating
+ that the control channel negotiation should begin.
+ This event, for example, may be triggered by an
+ operator command, by the successful completion of a
+ control channel bootstrap procedure, or by
+ configuration. Depending on the configuration,
+ this will trigger either
+ 1a) the sending of a Config message,
+ 1b) a period of waiting to receive a Config
+ message from the remote node.
+
+ 2 : evCCDn: This event is generated when there is indication
+ that the control channel is no longer available.
+
+ 3 : evConfDone: This event indicates a ConfigAck message has been
+ received, acknowledging the Config parameters.
+
+ 4 : evConfErr: This event indicates a ConfigNack message has been
+ received, rejecting the Config parameters.
+
+ 5 : evNewConfOK: New Config message was received from neighbor and
+ positively acknowledged.
+
+ 6 : evNewConfErr: New Config message was received from neighbor and
+ rejected with a ConfigNack message.
+
+ 7 : evContenWin: New Config message was received from neighbor at
+ the same time a Config message was sent to the
+ neighbor. The local node wins the contention. As
+ a result, the received Config message is ignored.
+
+ 8 : evContenLost: New Config message was received from neighbor at
+ the same time a Config message was sent to the
+ neighbor. The local node loses the contention.
+ 8a) The Config message is positively
+ acknowledged.
+ 8b) The Config message is negatively
+ acknowledged.
+
+
+
+
+Lang Standards Track [Page 29]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ 9 : evAdminDown: The administrator has requested that the control
+ channel is brought down administratively.
+
+ 10: evNbrGoesDn: A packet with ControlChannelDown flag is received
+ from the neighbor.
+
+ 11: evHelloRcvd: A Hello packet with expected SeqNum has been
+ received.
+
+ 12: evHoldTimer: The HelloDeadInterval timer has expired indicating
+ that no Hello packet has been received. This moves
+ the control channel back into the Negotiation
+ state, and depending on the local configuration,
+ this will trigger either
+ 12a) the sending of periodic Config messages,
+ 12b) a period of waiting to receive Config
+ messages from the remote node.
+
+ 13: evSeqNumErr: A Hello with unexpected SeqNum received and
+ discarded.
+
+ 14: evReconfig: Control channel parameters have been reconfigured
+ and require renegotiation.
+
+ 15: evConfRet: A retransmission timer has expired and a Config
+ message is resent.
+
+ 16: evHelloRet: The HelloInterval timer has expired and a Hello
+ packet is sent.
+
+ 17: evDownTimer: A timer has expired and no messages have been
+ received with the ControlChannelDown flag set.
+
+11.1.3. Control Channel FSM Description
+
+ Figure 3 illustrates operation of the control channel FSM in a form
+ of FSM state transition diagram.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 30]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ +--------+
+ +----------------->| |<--------------+
+ | +--------->| Down |<----------+ |
+ | |+---------| |<-------+ | |
+ | || +--------+ | | |
+ | || | ^ 2,9| 2| 2|
+ | ||1b 1a| | | | |
+ | || v |2,9 | | |
+ | || +--------+ | | |
+ | || +->| |<------+| | |
+ | || 4,7,| |ConfSnd | || | |
+ | || 14,15+--| |<----+ || | |
+ | || +--------+ | || | |
+ | || 3,8a| | | || | |
+ | || +---------+ |8b 14,12a| || | |
+ | || | v | || | |
+ | |+-|------>+--------+ | || | |
+ | | | +->| |-----|-|+ | |
+ | | |6,14| |ConfRcv | | | | |
+ | | | +--| |<--+ | | | |
+ | | | +--------+ | | | | |
+ | | | 5| ^ | | | | |
+ | | +---------+ | | | | | | |
+ | | | | | | | | | |
+ | | v v |6,12b | | | | |
+ | |10 +--------+ | | | | |
+ | +----------| | | | | | |
+ | | +--| Active |---|-+ | | |
+ 10,17| | 5,16| | |-------|---+ |
+ +-------+ 9 | 13 +->| | | | |
+ | Going |<--|----------+--------+ | | |
+ | Down | | 11| ^ | | |
+ +-------+ | | |5 | | |
+ ^ | v | 6,12b| | |
+ |9 |10 +--------+ | |12a,14 |
+ | +----------| |---+ | |
+ | | Up |-------+ |
+ +------------------| |---------------+
+ +--------+
+ | ^
+ | |
+ +---+
+ 11,13,16
+
+ Figure 3: Control Channel FSM
+
+
+
+
+
+
+Lang Standards Track [Page 31]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Event evCCDn always forces the FSM to the down state. Events
+ evHoldTimer and evReconfig always force the FSM to the Negotiation
+ state (either ConfSnd or ConfRcv).
+
+11.2. TE Link FSM
+
+ The TE Link FSM defines the states and logics of operation of the LMP
+ TE Link.
+
+11.2.1. TE Link States
+
+ An LMP TE link can be in one of the states described below. Every
+ state corresponds to a certain condition of the TE link and is
+ usually associated with a specific type of LMP message that is
+ periodically transmitted to the far end via the associated control
+ channel or in-band via the data links.
+
+ Down: There are no data links allocated to the TE link.
+
+ Init: Data links have been allocated to the TE link, but the
+ configuration has not yet been synchronized with the LMP
+ neighbor. The LinkSummary message is periodically
+ transmitted to the LMP neighbor.
+
+ Up: This is the normal operational state of the TE link. At
+ least one LMP control channel is required to be
+ operational between the nodes sharing the TE link. As
+ part of normal operation, the LinkSummary message may be
+ periodically transmitted to the LMP neighbor or generated
+ by an external request.
+
+ Degraded: In this state, all LMP control channels are down, but the
+ TE link still includes some data links that are allocated
+ to user traffic.
+
+11.2.2. TE Link Events
+
+ Operation of the LMP TE link is described in terms of FSM states and
+ events. TE Link events are generated by the packet processing
+ routines and by the FSMs of the associated control channel(s) and the
+ data links. Every event has its number and a symbolic name.
+ Descriptions of possible events are given below.
+
+ 1 : evDCUp: One or more data channels have been enabled and
+ assigned to the TE Link.
+
+ 2 : evSumAck: LinkSummary message received and positively
+ acknowledged.
+
+
+
+Lang Standards Track [Page 32]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ 3 : evSumNack: LinkSummary message received and negatively
+ acknowledged.
+
+ 4 : evRcvAck: LinkSummaryAck message received acknowledging the
+ TE Link Configuration.
+
+ 5 : evRcvNack: LinkSummaryNack message received.
+
+ 6 : evSumRet: Retransmission timer has expired and LinkSummary
+ message is resent.
+
+ 7 : evCCUp: First active control channel goes up.
+
+ 8 : evCCDown: Last active control channel goes down.
+
+ 9 : evDCDown: Last data channel of TE Link has been removed.
+
+11.2.3. TE Link FSM Description
+
+ Figure 4 illustrates operation of the LMP TE Link FSM in a form of
+ FSM state transition diagram.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 33]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ 3,7,8
+ +--+
+ | |
+ | v
+ +--------+
+ | |
+ +------------>| Down |<---------+
+ | | | |
+ | +--------+ |
+ | | ^ |
+ | 1| |9 |
+ | v | |
+ | +--------+ |
+ | | |<-+ |
+ | | Init | |3,5,6 |9
+ | | |--+ 7,8 |
+ 9| +--------+ |
+ | | |
+ | 2,4| |
+ | v |
+ +--------+ 7 +--------+ |
+ | |------>| |----------+
+ | Deg | | Up |
+ | |<------| |
+ +--------+ 8 +--------+
+ | ^
+ | |
+ +--+
+ 2,3,4,5,6
+
+ Figure 4: LMP TE Link FSM
+
+ In the above FSM, the sub-states that may be implemented when the
+ link verification procedure is used have been omitted.
+
+11.3. Data Link FSM
+
+ The data link FSM defines the states and logics of operation of a
+ data link within an LMP TE link. Operation of a data link is
+ described in terms of FSM states and events. Data links can either
+ be in the active (transmitting) mode, where Test messages are
+ transmitted from them, or the passive (receiving) mode, where Test
+ messages are received through them. For clarity, separate FSMs are
+ defined for the active/passive data links; however, a single set of
+ data link states and events are defined.
+
+
+
+
+
+
+Lang Standards Track [Page 34]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+11.3.1. Data Link States
+
+ Any data link can be in one of the states described below. Every
+ state corresponds to a certain condition of the data link.
+
+ Down: The data link has not been put in the resource pool
+ (i.e., the link is not 'in service')
+
+ Test: The data link is being tested. An LMP Test message is
+ periodically sent through the link.
+
+ PasvTest: The data link is being checked for incoming test
+ messages.
+
+ Up/Free: The link has been successfully tested and is now put
+ in the pool of resources (in-service). The link has
+ not yet been allocated to data traffic.
+
+ Up/Alloc: The link is up and has been allocated for data
+ traffic.
+
+11.3.2. Data Link Events
+
+ Data link events are generated by the packet processing routines and
+ by the FSMs of the associated control channel and the TE link.
+
+ Every event has its number and a symbolic name. Description of
+ possible data link events is given below:
+
+ 1 :evCCUp: First active control channel goes up.
+
+ 2 :evCCDown: LMP neighbor connectivity is lost. This indicates
+ the last LMP control channel has failed between
+ neighboring nodes.
+
+ 3 :evStartTst: This is an external event that triggers the
+ sending of Test messages over the data link.
+
+ 4 :evStartPsv: This is an external event that triggers the
+ listening for Test messages over the data link.
+
+ 5 :evTestOK: Link verification was successful and the link can
+ be used for path establishment.
+ (a) This event indicates the Link Verification
+ procedure (see Section 5) was successful
+ for this data link and a TestStatusSuccess
+ message was received over the control
+ channel.
+
+
+
+Lang Standards Track [Page 35]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ (b) This event indicates the link is ready for
+ path establishment, but the Link
+ Verification procedure was not used. For
+ in-band signaling of the control channel,
+ the control channel establishment may be
+ sufficient to verify the link.
+
+ 6 :evTestRcv: Test message was received over the data port and a
+ TestStatusSuccess message is transmitted over the
+ control channel.
+
+ 7 :evTestFail: Link verification returned negative results. This
+ could be because (a) a TestStatusFailure message
+ was received, or (b) the Verification procedure
+ has ended without receiving a TestStatusSuccess or
+ TestStatusFailure message for the data link.
+
+ 8 :evPsvTestFail: Link verification returned negative results. This
+ indicates that a Test message was not detected and
+ either (a) the VerifyDeadInterval has expired or
+ (b) the Verification procedure has ended and the
+ VerifyDeadInterval has not yet expired.
+
+ 9 :evLnkAlloc: The data link has been allocated.
+
+ 10:evLnkDealloc: The data link has been de-allocated.
+
+ 11:evTestRet: A retransmission timer has expired and the Test
+ message is resent.
+
+ 12:evSummaryFail: The LinkSummary did not match for this data port.
+
+ 13:evLocalizeFail: A Failure has been localized to this data link.
+
+ 14:evdcDown: The data channel is no longer available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 36]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+11.3.3. Active Data Link FSM Description
+
+ Figure 5 illustrates operation of the LMP active data link FSM in a
+ form of FSM state transition diagram.
+
+ +------+
+ | |<-------+
+ +--------->| Down | |
+ | +----| |<-----+ |
+ | | +------+ | |
+ | |5b 3| ^ | |
+ | | | |7 | |
+ | | v | | |
+ | | +------+ | |
+ | | | |<-+ | |
+ | | | Test | |11 | |
+ | | | |--+ | |
+ | | +------+ | |
+ | | 5a| 3^ | |
+ | | | | | |
+ | | v | | |
+ |12 | +---------+ | |
+ | +-->| |14 | |
+ | | Up/Free |----+ |
+ +---------| | |
+ +---------+ |
+ 9| ^ |
+ | | |
+ v |10 |
+ +---------+ |
+ | |13 |
+ |Up/Alloc |------+
+ | |
+ +---------+
+
+ Figure 5: Active LMP Data Link FSM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 37]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+11.3.4. Passive Data Link FSM Description
+
+ Figure 6 illustrates operation of the LMP passive data link FSM in a
+ form of FSM state transition diagram.
+
+ +------+
+ | |<------+
+ +---------->| Down | |
+ | +-----| |<----+ |
+ | | +------+ | |
+ | |5b 4| ^ | |
+ | | | |8 | |
+ | | v | | |
+ | | +----------+ | |
+ | | | PasvTest | | |
+ | | +----------+ | |
+ | | 6| 4^ | |
+ | | | | | |
+ | | v | | |
+ |12 | +---------+ | |
+ | +--->| Up/Free |14 | |
+ | | |---+ |
+ +----------| | |
+ +---------+ |
+ 9| ^ |
+ | | |
+ v |10 |
+ +---------+ |
+ | |13 |
+ |Up/Alloc |-----+
+ | |
+ +---------+
+
+ Figure 6: Passive LMP Data Link FSM
+
+12. LMP Message Formats
+
+ All LMP messages (except, in some cases, the Test messages, which are
+ limited by the transport mechanism for in-band messaging) are run
+ over UDP with an LMP port number (701).
+
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 38]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+12.1. Common Header
+
+ In addition to the UDP header and standard IP header, all LMP
+ messages (except, in some cases, the Test messages which may be
+ limited by the transport mechanism for in-band messaging) have the
+ following common header:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vers | (Reserved) | Flags | Msg Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LMP Length | (Reserved) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Reserved field should be sent as zero and ignored on receipt.
+
+ All values are defined in network byte order (i.e., big-endian byte
+ order).
+
+ Vers: 4 bits
+
+ Protocol version number. This is version 1.
+
+ Flags: 8 bits
+
+ The following bit-values are defined. All other bits are reserved
+ and should be sent as zero and ignored on receipt.
+
+ 0x01: ControlChannelDown
+
+ 0x02: LMP Restart
+
+ This bit is set to indicate that a nodal failure has occurred
+ and the LMP control state has been lost. This flag may be
+ reset to 0 when a Hello message is received with RcvSeqNum
+ equal to the local TxSeqNum.
+
+ Msg Type: 8 bits
+
+ The following values are defined. All other values are reserved
+
+ 1 = Config
+
+ 2 = ConfigAck
+
+ 3 = ConfigNack
+
+
+
+
+Lang Standards Track [Page 39]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ 4 = Hello
+
+ 5 = BeginVerify
+
+ 6 = BeginVerifyAck
+
+ 7 = BeginVerifyNack
+
+ 8 = EndVerify
+
+ 9 = EndVerifyAck
+
+ 10 = Test
+
+ 11 = TestStatusSuccess
+
+ 12 = TestStatusFailure
+
+ 13 = TestStatusAck
+
+ 14 = LinkSummary
+
+ 15 = LinkSummaryAck
+
+ 16 = LinkSummaryNack
+
+ 17 = ChannelStatus
+
+ 18 = ChannelStatusAck
+
+ 19 = ChannelStatusRequest
+
+ 20 = ChannelStatusResponse
+
+ All of the messages are sent over the control channel EXCEPT the
+ Test message, which is sent over the data link that is being
+ tested.
+
+ LMP Length: 16 bits
+
+ The total length of this LMP message in bytes, including the
+ common header and any variable-length objects that follow.
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 40]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+12.2. LMP Object Format
+
+ LMP messages are built using objects. Each object is identified by
+ its Object Class and Class-type. Each object has a name, which is
+ always capitalized in this document. LMP objects can be either
+ negotiable or non-negotiable (identified by the N bit in the object
+ header). Negotiable objects can be used to let the devices agree on
+ certain values. Non-negotiable objects are used for announcement of
+ specific values that do not need or do not allow negotiation.
+
+ All values are defined in network byte order (i.e., big-endian byte
+ order).
+
+ The format of the LMP 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ // (object contents) //
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ N: 1 bit
+
+ The N flag indicates if the object is negotiable (N=1) or non-
+ negotiable (N=0).
+
+ C-Type: 7 bits
+
+ Class-type, unique within an Object Class. Values are defined in
+ Section 13.
+
+ Class: 8 bits
+
+ The Class indicates the object type. Each object has a name,
+ which is always capitalized in this document.
+
+ Length: 16 bits
+
+ The Length field indicates the length of the object in bytes,
+ including the N, C-Type, Class, and Length fields.
+
+
+
+
+
+
+
+Lang Standards Track [Page 41]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+12.3. Parameter Negotiation Messages
+
+12.3.1. Config Message (Msg Type = 1)
+
+ The Config message is used in the control channel negotiation phase
+ of LMP. The contents of the Config message are built using LMP
+ objects. The format of the Config message is as follows:
+
+ <Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
+ <LOCAL_NODE_ID> <CONFIG>
+
+ The above transmission order SHOULD be followed.
+
+ The MESSAGE_ID object is within the scope of the LOCAL_CCID object.
+
+ The Config message MUST be periodically transmitted until (1) it
+ receives a ConfigAck or ConfigNack message, (2) a retry limit has
+ been reached and no ConfigAck or ConfigNack message has been
+ received, or (3) it receives a Config message from the remote node
+ and has lost the contention (e.g., the Node_Id of the remote node is
+ higher than the Node_Id of the local node). Both the retransmission
+ interval and the retry limit are local configuration parameters.
+
+12.3.2. ConfigAck Message (Msg Type = 2)
+
+ The ConfigAck message is used to acknowledge receipt of the Config
+ message and indicate agreement on all parameters.
+
+ <ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
+ <REMOTE_CCID> <MESSAGE_ID_ACK>
+ <REMOTE_NODE_ID>
+
+ The above transmission order SHOULD be followed.
+
+ The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
+ objects MUST be obtained from the Config message being acknowledged.
+
+12.3.3. ConfigNack Message (Msg Type = 3)
+
+ The ConfigNack message is used to acknowledge receipt of the Config
+ message and indicate disagreement on non-negotiable parameters or
+ propose other values for negotiable parameters. Parameters where
+ agreement was reached MUST NOT be included in the ConfigNack Message.
+ The format of the ConfigNack message is as follows:
+
+ <ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
+ <LOCAL_NODE_ID> <REMOTE_CCID>
+ <MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG>
+
+
+
+Lang Standards Track [Page 42]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ The above transmission order SHOULD be followed.
+
+ The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
+ objects MUST be obtained from the Config message being negatively
+ acknowledged.
+
+ It is possible that multiple parameters may be invalid in the Config
+ message.
+
+ If a negotiable CONFIG object is included in the ConfigNack message,
+ it MUST include acceptable values for the parameters.
+
+ If the ConfigNack message includes CONFIG objects for non-negotiable
+ parameters, they MUST be copied from the CONFIG objects received in
+ the Config message.
+
+ If the ConfigNack message is received and only includes CONFIG
+ objects that are negotiable, then a new Config message SHOULD be
+ sent. The values in the CONFIG object of the new Config message
+ SHOULD take into account the acceptable values included in the
+ ConfigNack message.
+
+ If a node receives a Config message and recognizes the CONFIG object,
+ but does not recognize the C-Type, a ConfigNack message including the
+ unknown CONFIG object MUST be sent.
+
+12.4. Hello Message (Msg Type = 4)
+
+ The format of the Hello message is as follows:
+
+ <Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>
+
+ The above transmission order SHOULD be followed.
+
+ The Hello message MUST be periodically transmitted at least once
+ every HelloInterval msec. If no Hello message is received within the
+ HelloDeadInterval, the control channel is assumed to have failed.
+
+12.5. Link Verification Messages
+
+12.5.1. BeginVerify Message (Msg Type = 5)
+
+ The BeginVerify message is sent over the control channel and is used
+ to initiate the link verification process. The format is as follows:
+
+ <BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
+ <MESSAGE_ID> [<REMOTE_LINK_ID>]
+ <BEGIN_VERIFY>
+
+
+
+Lang Standards Track [Page 43]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ The above transmission order SHOULD be followed.
+
+ To limit the scope of Link Verification to a particular TE Link, the
+ Link_Id field of the LOCAL_LINK_ID object MUST be non-zero. If this
+ field is zero, the data links can span multiple TE links and/or they
+ may comprise a TE link that is yet to be configured. In the special
+ case where the local Link_Id field is zero, the "Verify all Links"
+ flag of the BEGIN_VERIFY object is used to distinguish between data
+ links that span multiple TE links and those that have not yet been
+ assigned to a TE link (see Section 5).
+
+ The REMOTE_LINK_ID object may be included if the local/remote Link_Id
+ mapping is known.
+
+ The Link_Id field of the REMOTE_LINK_ID object MUST be non-zero if
+ included.
+
+ The BeginVerify message MUST be periodically transmitted until (1)
+ the node receives either a BeginVerifyAck or BeginVerifyNack message
+ to accept or reject the verify process or (2) a retry limit has been
+ reached and no BeginVerifyAck or BeginVerifyNack message has been
+ received. Both the retransmission interval and the retry limit are
+ local configuration parameters.
+
+12.5.2. BeginVerifyAck Message (Msg Type = 6)
+
+ When a BeginVerify message is received and Test messages are ready to
+ be processed, a BeginVerifyAck message MUST be transmitted.
+
+ <BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
+ <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
+ <VERIFY_ID>
+
+ The above transmission order SHOULD be followed.
+
+ The LOCAL_LINK_ID object may be included if the local/remote Link_Id
+ mapping is known or learned through the BeginVerify message.
+
+ The Link_Id field of the LOCAL_LINK_ID MUST be non-zero if included.
+
+ The contents of the MESSAGE_ID_ACK object MUST be obtained from the
+ BeginVerify message being acknowledged.
+
+ The VERIFY_ID object contains a node-unique value that is assigned by
+ the generator of the BeginVerifyAck message. This value is used to
+ uniquely identify the Verification process from multiple LMP
+ neighbors and/or parallel Test procedures between the same LMP
+ neighbors.
+
+
+
+Lang Standards Track [Page 44]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+12.5.3. BeginVerifyNack Message (Msg Type = 7)
+
+ If a BeginVerify message is received and a node is unwilling or
+ unable to begin the Verification procedure, a BeginVerifyNack message
+ MUST be transmitted.
+
+ <BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>]
+ <MESSAGE_ID_ACK> <ERROR_CODE>
+
+ The above transmission order SHOULD be followed.
+
+ The contents of the MESSAGE_ID_ACK object MUST be obtained from the
+ BeginVerify message being negatively acknowledged.
+
+ If the Verification process is not supported, the ERROR_CODE MUST
+ indicate "Link Verification Procedure not supported".
+
+ If Verification is supported, but the node is unable to begin the
+ procedure, the ERROR_CODE MUST indicate "Unwilling to verify". If a
+ BeginVerifyNack message is received with such an ERROR_CODE, the node
+ that originated the BeginVerify SHOULD schedule a BeginVerify
+ retransmission after Rf seconds, where Rf is a locally defined
+ parameter.
+
+ If the Verification Transport mechanism is not supported, the
+ ERROR_CODE MUST indicate "Unsupported verification transport
+ mechanism".
+
+ If remote configuration of the Link_Id is not supported and the
+ content of the REMOTE_LINK_ID object (included in the BeginVerify
+ message) does not match any configured values, the ERROR_CODE MUST
+ indicate "Link_Id configuration error".
+
+ If a node receives a BeginVerify message and recognizes the
+ BEGIN_VERIFY object but does not recognize the C-Type, the ERROR_CODE
+ MUST indicate "Unknown object C-Type".
+
+12.5.4. EndVerify Message (Msg Type = 8)
+
+ The EndVerify message is sent over the control channel and is used to
+ terminate the link verification process. The EndVerify message may
+ be sent any time the initiating node desires to end the Verify
+ procedure. The format is as follows:
+
+ <EndVerify Message> ::=<Common Header> <MESSAGE_ID> <VERIFY_ID>
+
+ The above transmission order SHOULD be followed.
+
+
+
+
+Lang Standards Track [Page 45]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ The EndVerify message will be periodically transmitted until (1) an
+ EndVerifyAck message has been received or (2) a retry limit has been
+ reached and no EndVerifyAck message has been received. Both the
+ retransmission interval and the retry limit are local configuration
+ parameters.
+
+12.5.5. EndVerifyAck Message (Msg Type =9)
+
+ The EndVerifyAck message is sent over the control channel and is used
+ to acknowledge the termination of the link verification process. The
+ format is as follows:
+
+ <EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
+ <VERIFY_ID>
+
+ The above transmission order SHOULD be followed.
+
+ The contents of the MESSAGE_ID_ACK object MUST be obtained from the
+ EndVerify message being acknowledged.
+
+12.5.6. Test Message (Msg Type = 10)
+
+ The Test message is transmitted over the data link and is used to
+ verify its physical connectivity. Unless explicitly stated, these
+ messages MUST be transmitted over UDP like all other LMP messages.
+ The format of the Test messages is as follows:
+
+ <Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>
+
+ The above transmission order SHOULD be followed.
+
+ Note that this message is sent over a data link and NOT over the
+ control channel. The transport mechanism for the Test message is
+ negotiated using the Verify Transport Mechanism field of the
+ BEGIN_VERIFY object and the Verify Transport Response field of the
+ BEGIN_VERIFY_ACK object (see Sections 13.8 and 13.9).
+
+ The local (transmitting) node sends a given Test message periodically
+ (at least once every VerifyInterval ms) on the corresponding data
+ link until (1) it receives a correlating TestStatusSuccess or
+ TestStatusFailure message on the control channel from the remote
+ (receiving) node or (2) all active control channels between the two
+ nodes have failed. The remote node will send a given TestStatus
+ message periodically over the control channel until it receives
+ either a correlating TestStatusAck message or an EndVerify message.
+
+
+
+
+
+
+Lang Standards Track [Page 46]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+12.5.7. TestStatusSuccess Message (Msg Type = 11)
+
+ The TestStatusSuccess message is transmitted over the control channel
+ and is used to transmit the mapping between the local Interface_Id
+ and the Interface_Id that was received in the Test message.
+
+ <TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID>
+ <MESSAGE_ID> <LOCAL_INTERFACE_ID>
+ <REMOTE_INTERFACE_ID> <VERIFY_ID>
+
+ The above transmission order SHOULD be followed.
+
+ The contents of the REMOTE_INTERFACE_ID object MUST be obtained from
+ the corresponding Test message being positively acknowledged.
+
+12.5.8. TestStatusFailure Message (Msg Type = 12)
+
+ The TestStatusFailure message is transmitted over the control channel
+ and is used to indicate that the Test message was not received.
+
+ <TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID>
+ <VERIFY_ID>
+
+ The above transmission order SHOULD be followed.
+
+12.5.9. TestStatusAck Message (Msg Type = 13)
+
+ The TestStatusAck message is used to acknowledge receipt of the
+ TestStatusSuccess or TestStatusFailure messages.
+
+ <TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
+ <VERIFY_ID>
+
+ The above transmission order SHOULD be followed.
+
+ The contents of the MESSAGE_ID_ACK object MUST be obtained from the
+ TestStatusSuccess or TestStatusFailure message being acknowledged.
+
+12.6. Link Summary Messages
+
+12.6.1. LinkSummary Message (Msg Type = 14)
+
+ The LinkSummary message is used to synchronize the Interface_Ids and
+ correlate the properties of the TE link. The format of the
+ LinkSummary message is as follows:
+
+ <LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
+ <DATA_LINK> [<DATA_LINK>...]
+
+
+
+Lang Standards Track [Page 47]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ The above transmission order SHOULD be followed.
+
+ The LinkSummary message can be exchanged any time a link is not in
+ the Verification process. The LinkSummary message MUST be
+ periodically transmitted until (1) the node receives a LinkSummaryAck
+ or LinkSummaryNack message or (2) a retry limit has been reached and
+ no LinkSummaryAck or LinkSummaryNack message has been received. Both
+ the retransmission interval and the retry limit are local
+ configuration parameters.
+
+12.6.2. LinkSummaryAck Message (Msg Type = 15)
+
+ The LinkSummaryAck message is used to indicate agreement on the
+ Interface_Id synchronization and acceptance/agreement on all the link
+ parameters. It is on the reception of this message that the local
+ node makes the Link_Id associations.
+
+ <LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
+
+ The above transmission order SHOULD be followed.
+
+12.6.3. LinkSummaryNack Message (Msg Type = 16)
+
+ The LinkSummaryNack message is used to indicate disagreement on non-
+ negotiated parameters or propose other values for negotiable
+ parameters. Parameters on which agreement was reached MUST NOT be
+ included in the LinkSummaryNack message.
+
+ <LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
+ <ERROR_CODE> [<DATA_LINK>...]
+
+ The above transmission order SHOULD be followed.
+
+ The DATA_LINK objects MUST include acceptable values for all
+ negotiable parameters. If the LinkSummaryNack includes DATA_LINK
+ objects for non-negotiable parameters, they MUST be copied from the
+ DATA_LINK objects received in the LinkSummary message.
+
+ If the LinkSummaryNack message is received and only includes
+ negotiable parameters, then a new LinkSummary message SHOULD be sent.
+ The values received in the new LinkSummary message SHOULD take into
+ account the acceptable parameters included in the LinkSummaryNack
+ message.
+
+ If the LinkSummary message is received with unacceptable, non-
+ negotiable parameters, the ERROR_CODE MUST indicate "Unacceptable
+ non-negotiable LINK_SUMMARY parameters."
+
+
+
+
+Lang Standards Track [Page 48]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ If the LinkSummary message is received with unacceptable negotiable
+ parameters, the ERROR_CODE MUST indicate "Renegotiate LINK_SUMMARY
+ parameters."
+
+ If the LinkSummary message is received with an invalid TE_LINK
+ object, the ERROR_CODE MUST indicate "Invalid TE_LINK object."
+
+ If the LinkSummary message is received with an invalid DATA_LINK
+ object, the ERROR_CODE MUST indicate "Invalid DATA_LINK object."
+
+ If the LinkSummary message is received with a TE_LINK object but the
+ C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown TE_LINK
+ object C-Type."
+
+ If the LinkSummary message is received with a DATA_LINK object but
+ the C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown
+ DATA_LINK object C-Type."
+
+12.7. Fault Management Messages
+
+12.7.1. ChannelStatus Message (Msg Type = 17)
+
+ The ChannelStatus message is sent over the control channel and is
+ used to notify an LMP neighbor of the status of a data link. A node
+ that receives a ChannelStatus message MUST respond with a
+ ChannelStatusAck message. The format is as follows:
+
+ <ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
+ <MESSAGE_ID> <CHANNEL_STATUS>
+
+ The above transmission order SHOULD be followed.
+
+ If the CHANNEL_STATUS object does not include any Interface_Ids, then
+ this indicates the entire TE Link has failed.
+
+12.7.2. ChannelStatusAck Message (Msg Type = 18)
+
+ The ChannelStatusAck message is used to acknowledge receipt of the
+ ChannelStatus Message. The format is as follows:
+
+ <ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
+
+ The above transmission order SHOULD be followed.
+
+ The contents of the MESSAGE_ID_ACK object MUST be obtained from the
+ ChannelStatus message being acknowledged.
+
+
+
+
+
+Lang Standards Track [Page 49]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+12.7.3. ChannelStatusRequest Message (Msg Type = 19)
+
+ The ChannelStatusRequest message is sent over the control channel and
+ is used to request the status of one or more data link(s). A node
+ that receives a ChannelStatusRequest message MUST respond with a
+ ChannelStatusResponse message. The format is as follows:
+
+ <ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
+ <MESSAGE_ID>
+ [<CHANNEL_STATUS_REQUEST>]
+
+ The above transmission order SHOULD be followed.
+
+ If the CHANNEL_STATUS_REQUEST object is not included, then the
+ ChannelStatusRequest is being used to request the status of ALL of
+ the data link(s) of the TE Link.
+
+12.7.4. ChannelStatusResponse Message (Msg Type = 20)
+
+ The ChannelStatusResponse message is used to acknowledge receipt of
+ the ChannelStatusRequest Message and notify the LMP neighbor of the
+ status of the data channel(s). The format is as follows:
+
+ <ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK>
+ <CHANNEL_STATUS>
+
+ The above transmission order SHOULD be followed.
+
+ The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
+ ChannelStatusRequest message being acknowledged.
+
+13. LMP Object Definitions
+
+13.1. CCID (Control Channel ID) Class
+
+ Class = 1
+
+ o C-Type = 1, LOCAL_CCID
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CC_Id |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Lang Standards Track [Page 50]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ CC_Id: 32 bits
+
+ This MUST be node-wide unique and non-zero. The CC_Id identifies
+ the control channel of the sender associated with the message.
+
+ This object is non-negotiable.
+
+ o C-Type = 2, REMOTE_CCID
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CC_Id |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ CC_Id: 32 bits
+
+ This identifies the remote node's CC_Id and MUST be non-zero.
+
+ This object is non-negotiable.
+
+13.2. NODE_ID Class
+
+ Class = 2
+
+ o C-Type = 1, LOCAL_NODE_ID
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Node_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Node_Id:
+
+ This identities the node that originated the LMP packet.
+
+ This object is non-negotiable.
+
+ o C-Type = 2, REMOTE_NODE_ID
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Node_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Lang Standards Track [Page 51]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Node_Id:
+
+ This identities the remote node.
+
+ This object is non-negotiable.
+
+13.3. LINK_ID Class
+
+ Class = 3
+
+ o C-Type = 1, IPv4 LOCAL_LINK_ID
+
+ o C-Type = 2, IPv4 REMOTE_LINK_ID
+
+ 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_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ o C-Type = 3, IPv6 LOCAL_LINK_ID
+
+ o C-Type = 4, IPv6 REMOTE_LINK_ID
+
+ 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_Id (16 bytes) +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ o C-Type = 5, Unnumbered LOCAL_LINK_ID
+
+ o C-Type = 6, Unnumbered REMOTE_LINK_ID
+
+ 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_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Lang Standards Track [Page 52]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Link_Id:
+
+ For LOCAL_LINK_ID, this identifies the sender's Link associated
+ with the message. This value MUST be non-zero.
+
+ For REMOTE_LINK_ID, this identifies the remote node's Link_Id and
+ MUST be non-zero.
+
+ This object is non-negotiable.
+
+13.4. INTERFACE_ID Class
+
+ Class = 4
+
+ o C-Type = 1, IPv4 LOCAL_INTERFACE_ID
+
+ o C-Type = 2, IPv4 REMOTE_INTERFACE_ID
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ o C-Type = 3, IPv6 LOCAL_INTERFACE_ID
+
+ o C-Type = 4, IPv6 REMOTE_INTERFACE_ID
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Interface_Id (16 bytes) +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ o C-Type = 5, Unnumbered LOCAL_INTERFACE_ID
+
+ o C-Type = 6, Unnumbered REMOTE_INTERFACE_ID
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 53]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Interface_Id:
+
+ For the LOCAL_INTERFACE_ID, this identifies the data link. This
+ value MUST be node-wide unique and non-zero.
+
+ For the REMOTE_INTERFACE_ID, this identifies the remote node's
+ data link. The Interface_Id MUST be non-zero.
+
+ This object is non-negotiable.
+
+13.5. MESSAGE_ID Class
+
+ Class = 5
+
+ o C-Type=1, MessageId
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message_Id |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Message_Id:
+
+ The Message_Id field is used to identify a message. This value is
+ incremented and only decreases when the value wraps. This is used
+ for message acknowledgment.
+
+ This object is non-negotiable.
+
+ o C-Type = 2, MessageIdAck
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message_Id |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 54]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Message_Id:
+
+ The Message_Id field is used to identify the message being
+ acknowledged. This value is copied from the MESSAGE_ID object of
+ the message being acknowledged.
+
+ This object is non-negotiable.
+
+13.6. CONFIG Class
+
+ Class = 6.
+
+ o C-Type = 1, HelloConfig
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | HelloInterval | HelloDeadInterval |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ HelloInterval: 16 bits.
+
+ Indicates how frequently the Hello packets will be sent and is
+ measured in milliseconds (ms).
+
+ HelloDeadInterval: 16 bits.
+
+ If no Hello packets are received within the HelloDeadInterval, the
+ control channel is assumed to have failed. The HelloDeadInterval
+ is measured in milliseconds (ms). The HelloDeadInterval MUST be
+ greater than the HelloInterval, and SHOULD be at least 3 times the
+ value of HelloInterval.
+
+ If the fast keep-alive mechanism of LMP is not used, the
+ HelloInterval and HelloDeadInterval MUST be set to zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 55]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+13.7. HELLO Class
+
+ Class = 7
+
+ o C-Type = 1, Hello
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TxSeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RcvSeqNum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ TxSeqNum: 32 bits
+
+ This is the current sequence number for this Hello message. This
+ sequence number will be incremented when the sequence number is
+ reflected in the RcvSeqNum of a Hello packet that is received over
+ the control channel.
+
+ TxSeqNum=0 is not allowed. TxSeqNum=1 is used to indicate that
+ this is the first Hello message sent over the control channel.
+
+ RcvSeqNum: 32 bits
+
+ This is the sequence number of the last Hello message received
+ over the control channel. RcvSeqNum=0 is used to indicate that a
+ Hello message has not yet been received.
+
+ This object is non-negotiable.
+
+13.8. BEGIN_VERIFY Class
+
+ Class = 8
+
+ o C-Type = 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 56]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags | VerifyInterval |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Number of Data Links |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | EncType | (Reserved) | Verify Transport Mechanism |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TransmissionRate |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Wavelength |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Reserved field should be sent as zero and ignored on receipt.
+
+ Flags: 16 bits
+
+ The following flags are defined:
+
+ 0x0001 Verify all Links
+
+ If this bit is set, the verification process checks all
+ unallocated links; else it only verifies new ports or
+ component links that are to be added to this TE link.
+
+ 0x0002 Data Link Type
+
+ If set, the data links to be verified are ports, otherwise
+ they are component links
+
+ VerifyInterval: 16 bits
+
+ This is the interval between successive Test messages and is
+ measured in milliseconds (ms).
+
+ Number of Data Links: 32 bits
+
+ This is the number of data links that will be verified.
+
+ EncType: 8 bits
+
+ This is the encoding type of the data link. The defined EncType
+ values are consistent with the LSP Encoding Type values of
+ [RFC3471].
+
+
+
+
+
+
+Lang Standards Track [Page 57]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Verify Transport Mechanism: 16 bits
+
+ This defines the transport mechanism for the Test Messages. The
+ scope of this bit mask is restricted to each encoding type. The
+ local node will set the bits corresponding to the various
+ mechanisms it can support for transmitting LMP test messages. The
+ receiver chooses the appropriate mechanism in the BeginVerifyAck
+ message.
+
+ The following flag is defined across all Encoding Types. All
+ other flags are dependent on the Encoding Type.
+
+ 0x8000 Payload:Test Message transmitted in the payload
+
+ Capable of transmitting Test messages in the payload.
+ The Test message is sent as an IP packet as defined
+ above.
+
+ TransmissionRate: 32 bits
+
+ This is the transmission rate of the data link over which the Test
+ messages will be transmitted. This is expressed in bytes per
+ second and represented in IEEE floating-point format.
+
+ Wavelength: 32 bits
+
+ When a data link is assigned to a port or component link that is
+ capable of transmitting multiple wavelengths (e.g., a fiber or
+ waveband-capable port), it is essential to know which wavelength
+ the test messages will be transmitted over. This value
+ corresponds to the wavelength at which the Test messages will be
+ transmitted over and has local significance. If there is no
+ ambiguity as to the wavelength over which the message will be
+ sent, then this value SHOULD be set to 0.
+
+13.9. BEGIN_VERIFY_ACK Class
+
+ Class = 9
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | VerifyDeadInterval | Verify_Transport_Response |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Lang Standards Track [Page 58]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ VerifyDeadInterval: 16 bits
+
+ If a Test message is not detected within the
+ VerifyDeadInterval, then a node will send the TestStatusFailure
+ message for that data link.
+
+ Verify_Transport_Response: 16 bits
+
+ The recipient of the BeginVerify message (and the future
+ recipient of the TEST messages) chooses the transport mechanism
+ from the various types that are offered by the transmitter of
+ the Test messages. One and only one bit MUST be set in the
+ verification transport response.
+
+ This object is non-negotiable.
+
+13.10. VERIFY_ID Class
+
+ Class = 10
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Verify_Id |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Verify_Id: 32 bits
+
+ This is used to differentiate Test messages from different TE
+ links and/or LMP peers. This is a node-unique value that is
+ assigned by the recipient of the BeginVerify message.
+
+ This object is non-negotiable.
+
+13.11. TE_LINK Class
+
+ Class = 11
+
+ o C-Type = 1, IPv4 TE_LINK
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 59]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags | (Reserved) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local_Link_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Remote_Link_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ o C-Type = 2, IPv6 TE_LINK
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags | (Reserved) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Local_Link_Id (16 bytes) +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Remote_Link_Id (16 bytes) +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ o C-Type = 3, Unnumbered TE_LINK
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags | (Reserved) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local_Link_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Remote_Link_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Reserved field should be sent as zero and ignored on receipt.
+
+
+
+
+Lang Standards Track [Page 60]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Flags: 8 bits
+
+ The following flags are defined. All other bit-values are
+ reserved and should be sent as zero and ignored on receipt.
+
+ 0x01 Fault Management Supported.
+
+ 0x02 Link Verification Supported.
+
+ Local_Link_Id:
+
+ This identifies the node's local Link_Id and MUST be non-zero.
+
+ Remote_Link_Id:
+
+ This identifies the remote node's Link_Id and MUST be non-zero.
+
+13.12. DATA_LINK Class
+
+ Class = 12
+
+ o C-Type = 1, IPv4 DATA_LINK
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags | (Reserved) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local_Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Remote_Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ // (Subobjects) //
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 61]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ o C-Type = 2, IPv6 DATA_LINK
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags | (Reserved) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Local_Interface_Id (16 bytes) +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Remote_Interface_Id (16 bytes) +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ // (Subobjects) //
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ o C-Type = 3, Unnumbered DATA_LINK
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags | (Reserved) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local_Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Remote_Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ // (Subobjects) //
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 62]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ The Reserved field should be sent as zero and ignored on receipt.
+
+ Flags: 8 bits
+
+ The following flags are defined. All other bit-values are
+ reserved and should be sent as zero and ignored on receipt.
+
+ 0x01 Interface Type: If set, the data link is a port, otherwise it
+ is a component link.
+
+ 0x02 Allocated Link: If set, the data link is currently allocated
+ for user traffic. If a single Interface_Id
+ is used for both the transmit and receive
+ data links, then this bit only applies to the
+ transmit interface.
+
+ 0x04 Failed Link: If set, the data link is failed and not
+ suitable for user traffic.
+
+ Local_Interface_Id:
+
+ This is the local identifier of the data link. This MUST be
+ node-wide unique and non-zero.
+
+ Remote_Interface_Id:
+
+ This is the remote identifier of the data link. This MUST be
+ non-zero.
+
+ Subobjects
+
+ The contents of the DATA_LINK object consist of a series of
+ variable-length data items called subobjects. The subobjects are
+ defined in Section 13.12.1 below.
+
+ A DATA_LINK object may contain more than one subobject. More than
+ one subobject of the same Type may appear if multiple capabilities
+ are supported over the data link.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 63]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+13.12.1. Data Link Subobjects
+
+ The contents of the DATA_LINK object include a series of variable-
+ length data items called subobjects. Each subobject has the form:
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
+ | Type | Length | (Subobject contents) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+
+
+ Type: 8 bits
+
+ The Type indicates the type of contents of the subobject.
+ Currently defined values are:
+
+ Type = 1, Interface Switching Type
+
+ Type = 2, Wavelength
+
+ Length: 8 bits
+
+ The Length contains the total length of the subobject in bytes,
+ including the Type and Length fields. The Length MUST be at
+ least 4, and MUST be a multiple of 4.
+
+13.12.1.1. Subobject Type 1: Interface Switching Type
+
+ 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 | Switching Type| EncType |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Minimum Reservable Bandwidth |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Maximum Reservable Bandwidth |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Switching Type: 8 bits
+
+ This is used to identify the local Interface Switching Type of the
+ TE link as defined in [RFC3471].
+
+ EncType: 8 bits
+
+ This is the encoding type of the data link. The defined EncType
+ values are consistent with the LSP Encoding Type values of
+ [RFC3471].
+
+
+
+Lang Standards Track [Page 64]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Minimum Reservable Bandwidth: 32 bits
+
+ This is measured in bytes per second and represented in IEEE
+ floating point format.
+
+ Maximum Reservable Bandwidth: 32 bits
+
+ This is measured in bytes per second and represented in IEEE
+ floating point format.
+
+ If the interface only supports a fixed rate, the minimum and maximum
+ bandwidth fields are set to the same value.
+
+13.12.1.2. Subobject Type 2: Wavelength
+
+ 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) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Wavelength |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Reserved field should be sent as zero and ignored on receipt.
+
+ Wavelength: 32 bits
+
+ This value indicates the wavelength carried over the port. Values
+ used in this field only have significance between two neighbors.
+
+13.13. CHANNEL_STATUS Class
+
+ Class = 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 65]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ o C-Type = 1, IPv4 INTERFACE_ID
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |A|D| Channel Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | : |
+ // : //
+ | : |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |A|D| Channel Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ o C-Type = 2, IPv6 INTERFACE_ID
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Interface_Id (16 bytes) +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |A|D| Channel Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | : |
+ // : //
+ | : |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Interface_Id (16 bytes) +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |A|D| Channel Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Lang Standards Track [Page 66]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ o C-Type = 3, Unnumbered INTERFACE_ID
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |A|D| Channel Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | : |
+ // : //
+ | : |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |A|D| Channel_Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Active bit: 1 bit
+
+ This indicates that the Channel is allocated to user traffic and
+ the data link should be actively monitored.
+
+ Direction bit: 1 bit
+
+ This indicates the direction (transmit/receive) of the data
+ channel referred to in the CHANNEL_STATUS object. If set, this
+ indicates the data channel is in the transmit direction.
+
+ Channel_Status: 30 bits
+
+ This indicates the status condition of a data channel. The
+ following values are defined. All other values are reserved.
+
+ 1 Signal Okay (OK): Channel is operational
+ 2 Signal Degrade (SD): A soft failure caused by a BER exceeding
+ a preselected threshold. The specific
+ BER used to define the threshold is
+ configured.
+ 3 Signal Fail (SF): A hard signal failure including (but not
+ limited to) loss of signal (LOS), loss of
+ frame (LOF), or Line AIS.
+
+ This object contains one or more Interface_Ids followed by a
+ Channel_Status field.
+
+ To indicate the status of the entire TE Link, there MUST be only one
+ Interface_Id, and it MUST be zero.
+
+
+
+Lang Standards Track [Page 67]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ This object is non-negotiable.
+
+13.14. CHANNEL_STATUS_REQUEST Class
+
+ Class = 14
+
+ o C-Type = 1, IPv4 INTERFACE_ID
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | : |
+ // : //
+ | : |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ This object contains one or more Interface_Ids.
+
+ The Length of this object is 4 + 4N in bytes, where N is the number
+ of Interface_Ids.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 68]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ o C-Type = 2, IPv6 INTERFACE_ID
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Interface_Id (16 bytes) +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | : |
+ // : //
+ | : |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Interface_Id (16 bytes) +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ This object contains one or more Interface_Ids.
+
+ The Length of this object is 4 + 16N in bytes, where N is the number
+ of Interface_Ids.
+
+ o C-Type = 3, Unnumbered INTERFACE_ID
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | : |
+ // : //
+ | : |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface_Id (4 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Lang Standards Track [Page 69]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ This object contains one or more Interface_Ids.
+
+ The Length of this object is 4 + 4N in bytes, where N is the number
+ of Interface_Ids.
+
+ This object is non-negotiable.
+
+13.15. ERROR_CODE Class
+
+ Class = 20
+
+ o C-Type = 1, BEGIN_VERIFY_ERROR
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ERROR CODE |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The following bit-values are defined in network byte order (i.e.,
+ big-endian byte order):
+
+ 0x01 = Link Verification Procedure not supported.
+ 0x02 = Unwilling to verify.
+ 0x04 = Unsupported verification transport mechanism.
+ 0x08 = Link_Id configuration error.
+ 0x10 = Unknown object C-Type.
+
+ All other bit-values are reserved and should be sent as zero and
+ ignored on receipt.
+
+ Multiple bits may be set to indicate multiple errors.
+
+ This object is non-negotiable.
+
+ If a BeginVerifyNack message is received with Error Code 2, the node
+ that originated the BeginVerify SHOULD schedule a BeginVerify
+ retransmission after Rf seconds, where Rf is a locally defined
+ parameter.
+
+ o C-Type = 2, LINK_SUMMARY_ERROR
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ERROR CODE |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Lang Standards Track [Page 70]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ The following bit-values are defined in network byte order (i.e.,
+ big-endian byte order):
+
+ 0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters.
+ 0x02 = Renegotiate LINK_SUMMARY parameters.
+ 0x04 = Invalid TE_LINK Object.
+ 0x08 = Invalid DATA_LINK Object.
+ 0x10 = Unknown TE_LINK object C-Type.
+ 0x20 = Unknown DATA_LINK object C-Type.
+
+ All other bit-values are reserved and should be sent as zero and
+ ignored on receipt.
+
+ Multiple bits may be set to indicate multiple errors.
+
+ This object is non-negotiable.
+
+14. References
+
+14.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
+ in MPLS Traffic Engineering (TE)", RFC 4201, October
+ 2005.
+
+ [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
+ Extensions in Support of Generalized Multi-Protocol Label
+ Switching (GMPLS)", RFC 4202, October 2005.
+
+ [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
+ and S. Molendini, "RSVP Refresh Overhead Reduction
+ Extensions", RFC 2961, April 2001.
+
+ [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
+ 2402, November 1998.
+
+ [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
+ Payload (ESP)", RFC 2406, November 1998.
+
+ [RFC2407] Piper, D., "The Internet IP Security Domain of
+ Interpretation for ISAKMP", RFC 2407, November 1998.
+
+ [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+
+
+
+Lang Standards Track [Page 71]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ [RFC3471] Berger, L., Ed., "Generalized MPLS - Signaling
+ Functional Description", RFC 3471, January 2003.
+
+14.2. Informative References
+
+ [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
+ Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
+ September 2003.
+
+ [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
+ System (IS-IS) Extensions for Traffic Engineering (TE)",
+ RFC 3784, June 2004.
+
+ [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+ and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+ Tunnels", RFC 3209, December 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 72]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+15. Security Considerations
+
+ There are number of attacks that an LMP protocol session can
+ potentially experience. Some examples include:
+
+ o an adversary may spoof control packets;
+
+ o an adversary may modify the control packets in transit;
+
+ o an adversary may replay control packets;
+
+ o an adversary may study a number of control packets and try to
+ break the key using cryptographic tools. If the
+ hash/encryption algorithm used has known weaknesses, then it
+ becomes easy for the adversary to discover the key using simple
+ tools.
+
+ This section specifies an IPsec-based security mechanism for LMP.
+
+15.1. Security Requirements
+
+ The following requirements are applied to the mechanism described in
+ this section.
+
+ o LMP security MUST be able to provide authentication, integrity,
+ and replay protection.
+
+ o For LMP traffic, confidentiality is not needed. Only
+ authentication is needed to ensure that the control packets
+ (packets sent along the LMP Control Channel) are originating
+ from the right place and have not been modified in transit.
+ LMP Test packets exchanged through the data links do not need
+ to be protected.
+
+ o For LMP traffic, protecting the identity of LMP end-points is
+ not commonly required.
+
+ o The security mechanism should provide for well defined key
+ management schemes. The key management schemes should be well
+ analyzed to be cryptographically secure. The key management
+ schemes should be scalable. In addition, the key management
+ system should be automatic.
+
+ o The algorithms used for authentication MUST be
+ cryptographically sound. Also, the security protocol MUST
+ allow for negotiating and using different authentication
+ algorithms.
+
+
+
+
+Lang Standards Track [Page 73]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+15.2. Security Mechanisms
+
+ IPsec is a protocol suite that is used to secure communication at the
+ network layer between two peers. This protocol is comprised of IP
+ Security architecture document [RFC2401], IKE [RFC2409], IPsec AH
+ [RFC2402], and IPsec ESP [RFC2406]. IKE is the key management
+ protocol for IP networks, while AH and ESP are used to protect IP
+ traffic. IKE is defined specific to IP domain of interpretation.
+
+ Considering the requirements described in Section 15.1, it is
+ recommended that, where security is needed for LMP, implementations
+ use IPsec as described below:
+
+ 1. Implementations of LMP over IPsec protocol SHOULD support manual
+ keying mode.
+
+ Manual keying mode provides an easy way to set up and diagnose
+ IPsec functionality.
+
+ However, note that manual keying mode cannot effectively support
+ features such as replay protection and automatic re-keying. An
+ implementer using manual keys must be aware of these limits.
+
+ It is recommended that an implementer use manual keying only for
+ diagnostic purposes and use dynamic keying protocol to make use of
+ features such as replay protection and automatic re-keying.
+
+ 2. IPsec ESP with trailer authentication in tunnel mode MUST be
+ supported.
+
+ 3. Implementations MUST support authenticated key exchange protocols.
+ IKE [RFC2409] MUST be used as the key exchange protocol if keys
+ are dynamically negotiated between peers.
+
+ 4. Implementation MUST use the IPsec DOI [RFC2407].
+
+ 5. For IKE protocol, the identities of the SAs negotiated in Quick
+ Mode represent the traffic that the peers agree to protect and are
+ comprised of address space, protocol, and port information.
+
+ For LMP over IPsec, it is recommended that the identity payload
+ for Quick mode contain the following information:
+
+ The identities MUST be of type IP addresses and the value of the
+ identities SHOULD be the IP addresses of the communicating peers.
+
+
+
+
+
+
+Lang Standards Track [Page 74]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ The protocol field MUST be UDP. The port field SHOULD be set to
+ zero to indicate port fields should be ignored. This implies all
+ UDP traffic between the peers must be sent through the IPsec
+ tunnel. If an implementation supports port-based selectors, it
+ can opt for a more finely grained selector by specifying the port
+ field to the LMP port. If, however, the peer does not use port-
+ based selectors, the implementation MUST fall back to using a port
+ selector value of 0.
+
+ 6. Aggressive mode of IKE negotiation MUST be supported.
+
+ When IPsec is configured to be used with a peer, all LMP messages
+ are expected to be sent over the IPsec tunnel (crypto channel).
+ Similarly, an LMP receiver configured to use Ipsec with a peer
+ should reject any LMP traffic that does not come through the
+ crypto channel.
+
+ The crypto channel can be pre-setup with the LMP neighbor, or the
+ first LMP message sent to the peer can trigger the creation of the
+ IPsec tunnel.
+
+ A set of control channels can share the same crypto channel. When
+ LMP Hellos are used to monitor the status of the control channel,
+ it is important to keep in mind that the keep-alive failure in a
+ control channel may also be due to a failure in the crypto
+ channel. The following method is recommended to ensure that an
+ LMP communication path between two peers is working properly.
+
+ o If LMP Hellos detect a failure on a control channel, switch to
+ an alternate control channel and/or try to establish a new
+ control channel.
+
+ o Ensure the health of the control channels using LMP Hellos. If
+ all control channels indicate a failure and it is not possible
+ to bring up a new control channel, tear down all existing
+ control channels. Also, tear down the crypto channel (both the
+ IKE SA and IPsec SAs).
+
+ o Reestablish the crypto channel. Failure to establish a crypto
+ channel indicates a fatal failure for LMP communication.
+
+ o Bring up the control channel. Failure to bring up the control
+ channel indicates a fatal failure for LMP communication.
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 75]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ When LMP peers are dynamically discovered (particularly the
+ initiator), the following points should be noted:
+
+ When using pre-shared key authentication in identity protection
+ mode (main mode), the pre-shared key is required to compute the
+ value of SKEYID (used for deriving keys to encrypt messages
+ during key exchange). In main mode of IKE, the pre-shared key
+ to be used has to be identified before receiving the peer's
+ identity payload. The pre-shared key is required for
+ calculating SKEYID. The only information available about the
+ peer at this point is its IP address from which the negotiation
+ came from. Keying off the IP address of a peer to get the
+ pre-shared key is not possible since the addresses are dynamic
+ and not known beforehand.
+
+ Aggressive mode key exchange can be used since identification
+ payloads are sent in the first message.
+
+ Note, however, that aggressive mode is prone to passive denial
+ of service attacks. Using a shared secret (group shared
+ secret) among a number of peers is strongly discouraged because
+ this opens up the solution to man-in-the-middle attacks.
+
+ Digital-signature-based authentication is not prone to such
+ problems. It is RECOMMENDED that a digital-signature-based
+ authentication mechanism be used where possible.
+
+ If pre-shared-key-based authentication is required, then
+ aggressive mode SHOULD be used. IKE pre-shared authentication
+ key values SHOULD be protected in a manner similar to the
+ user's account password.
+
+16. IANA Considerations
+
+ The IANA has assigned port number 701 to LMP.
+
+ In the following, guidelines are given for IANA assignment for each
+ LMP name space. Ranges are specified for Private Use, to be assigned
+ by Expert Review, and to be assigned by Standards Action (as defined
+ in [RFC2434].
+
+ Assignments made from LMP number spaces set aside for Private Use
+ (i.e., for proprietary extensions) need not be documented.
+ Independent LMP implementations using the same Private Use code
+ points will in general not interoperate, so care should be exercised
+ in using these code points in a multi-vendor network.
+
+
+
+
+
+Lang Standards Track [Page 76]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Assignments made from LMP number spaces to be assigned by Expert
+ Review are to be reviewed by an Expert designated by the IESG. The
+ intent in this document is that code points from these ranges are
+ used for Experimental extensions; as such, assignments MUST be
+ accompanied by Experimental RFCs. If deployment suggests that these
+ extensions are useful, then they should be described in Standards
+ Track RFCs, and new code points from the Standards Action ranges MUST
+ be assigned.
+
+ Assignments from LMP number spaces to be assigned by Standards Action
+ MUST be documented by a Standards Track RFC, typically submitted to
+ an IETF Working Group, but in any case following the usual IETF
+ procedures for Proposed Standards.
+
+ The Reserved bits of the LMP Common Header should be allocated by
+ Standards Action, pursuant to the policies outlined in [RFC2434].
+
+ LMP defines the following name spaces that require management:
+
+ - LMP Message Type.
+ - LMP Object Class.
+ - LMP Object Class type (C-Type). These are unique within the
+ Object Class.
+ - LMP Sub-object Class type (Type). These are unique within the
+ Object Class.
+
+ The LMP Message Type name space should be allocated as follows:
+ pursuant to the policies outlined in [RFC2434], the numbers in the
+ range 0-127 are allocated by Standards Action, 128-240 are allocated
+ through an Expert Review, and 241-255 are reserved for Private Use.
+
+ The LMP Object Class name space should be allocated as follows:
+ pursuant to the policies outlined in [RFC2434], the numbers in the
+ range of 0-127 are allocated by Standards Action, 128-247 are
+ allocated through an Expert Review, and 248-255 are reserved for
+ Private Use.
+
+ The policy for allocating values out of the LMP Object Class name
+ space is part of the definition of the specific Class instance. When
+ a Class is defined, its definition must also include a description of
+ the policy under which the Object Class names are allocated.
+
+ The policy for allocating values out of the LMP Sub-object Class name
+ space is part of the definition of the specific Class instance. When
+ a Class is defined, its definition must also include a description of
+ the policy under which sub-objects are allocated.
+
+
+
+
+
+Lang Standards Track [Page 77]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ The following name spaces have been assigned by IANA:
+
+ ------------------------------------------------------------------
+ LMP Message Type name space
+
+ o Config message (Message type = 1)
+
+ o ConfigAck message (Message type = 2)
+
+ o ConfigNack message (Message type = 3)
+
+ o Hello message (Message type = 4)
+
+ o BeginVerify message (Message type = 5)
+
+ o BeginVerifyAck message (Message type = 6)
+
+ o BeginVerifyNack message (Message type = 7)
+
+ o EndVerify message (Message type = 8)
+
+ o EndVerifyAck message (Message type = 9)
+
+ o Test message (Message type = 10)
+
+ o TestStatusSuccess message (Message type = 11)
+
+ o TestStatusFailure message (Message type = 12)
+
+ o TestStatusAck message (Message type = 13)
+
+ o LinkSummary message (Message type = 14)
+
+ o LinkSummaryAck message (Message type = 15)
+
+ o LinkSummaryNack message (Message type = 16)
+
+ o ChannelStatus message (Message type = 17)
+
+ o ChannelStatusAck message (Message type = 18)
+
+ o ChannelStatusRequest message (Message type = 19)
+
+ o ChannelStatusResponse message (Message type = 20)
+
+ ------------------------------------------------------------------
+
+
+
+
+
+Lang Standards Track [Page 78]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ LMP Object Class name space and Class type (C-Type)
+
+ o CCID Class name (1)
+
+ The CCID Object Class type name space should be allocated as follows:
+ pursuant to the policies outlined in [RFC2434], the numbers in the
+ range 0-111 are allocated by Standards Action, 112-119 are allocated
+ through an Expert Review, and 120-127 are reserved for Private Use.
+
+ - LOCAL_CCID (C-Type = 1)
+ - REMOTE_CCID (C-Type = 2)
+
+ o NODE_ID Class name (2)
+
+ The NODE ID Object Class type name space should be allocated as
+ follows: pursuant to the policies outlined in [RFC2434], the numbers
+ in the range 0-111 are allocated by Standards Action, 112-119 are
+ allocated through an Expert Review, and 120-127 are reserved for
+ Private Use.
+
+ - LOCAL_NODE_ID (C-Type = 1)
+ - REMOTE_NODE_ID (C-Type = 2)
+
+ o LINK_ID Class name (3)
+
+ The LINK_ID Object Class type name space should be allocated as
+ follows: pursuant to the policies outlined in [RFC2434], the numbers
+ in the range 0-111 are allocated by Standards Action, 112-119 are
+ allocated through an Expert Review, and 120-127 are reserved for
+ Private Use.
+
+ - IPv4 LOCAL_LINK_ID (C-Type = 1)
+ - IPv4 REMOTE_LINK_ID (C-Type = 2)
+ - IPv6 LOCAL_LINK_ID (C-Type = 3)
+ - IPv6 REMOTE_LINK_ID (C-Type = 4)
+ - Unnumbered LOCAL_LINK_ID (C-Type = 5)
+ - Unnumbered REMOTE_LINK_ID (C-Type = 6)
+
+ o INTERFACE_ID Class name (4)
+
+ The INTERFACE_ID Object Class type name space should be allocated as
+ follows: pursuant to the policies outlined in [RFC2434], the numbers
+ in the range 0-111 are allocated by Standards Action, 112-119 are
+ allocated through an Expert Review, and 120-127 are reserved for
+ Private Use.
+
+
+
+
+
+
+Lang Standards Track [Page 79]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ - IPv4 LOCAL_INTERFACE_ID (C-Type = 1)
+ - IPv4 REMOTE_INTERFACE_ID (C-Type = 2)
+ - IPv6 LOCAL_INTERFACE_ID (C-Type = 3)
+ - IPv6 REMOTE_INTERFACE_ID (C-Type = 4)
+ - Unnumbered LOCAL_INTERFACE_ID (C-Type = 5)
+ - Unnumbered REMOTE_INTERFACE_ID (C-Type = 6)
+
+ o MESSAGE_ID Class name (5)
+
+ The MESSAGE_ID Object Class type name space should be allocated as
+ follows: pursuant to the policies outlined in [RFC2434], the numbers
+ in the range 0-111 are allocated by Standards Action, 112-119 are
+ allocated through an Expert Review, and 120-127 are reserved for
+ Private Use.
+
+ - MESSAGE_ID (C-Type = 1)
+ - MESSAGE_ID_ACK (C-Type = 2)
+
+ o CONFIG Class name (6)
+
+ The CONFIG Object Class type name space should be allocated as
+ follows: pursuant to the policies outlined in [RFC2434], the numbers
+ in the range 0-111 are allocated by Standards Action, 112-119 are
+ allocated through an Expert Review, and 120-127 are reserved for
+ Private Use.
+
+ - HELLO_CONFIG (C-Type = 1)
+
+ o HELLO Class name (7)
+
+ The HELLO Object Class type name space should be allocated as
+ follows: pursuant to the policies outlined in [RFC2434], the numbers
+ in the range 0-111 are allocated by Standards Action, 112-119 are
+ allocated through an Expert Review, and 120-127 are reserved for
+ Private Use.
+
+ - HELLO (C-Type = 1)
+
+ o BEGIN_VERIFY Class name (8)
+
+ The BEGIN_VERIFY Object Class type name space should be allocated as
+ follows: pursuant to the policies outlined in [RFC2434], the numbers
+ in the range 0-111 are allocated by Standards Action, 112-119 are
+ allocated through an Expert Review, and 120-127 are reserved for
+ Private Use.
+
+ - Type 1 (C-Type = 1)
+
+
+
+
+Lang Standards Track [Page 80]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ o BEGIN_VERIFY_ACK Class name (9)
+
+ The BEGIN_VERIFY_ACK Object Class type name space should be allocated
+ as follows: pursuant to the policies outlined in [RFC2434], the
+ numbers in the range 0-111 are allocated by Standards Action, 112-119
+ are allocated through an Expert Review, and 120-127 are reserved for
+ Private Use.
+
+ - Type 1 (C-Type = 1)
+
+ o VERIFY_ID Class name (10)
+
+ The VERIFY_ID Object Class type name space should be allocated as
+ follows: pursuant to the policies outlined in [RFC2434], the numbers
+ in the range 0-111 are allocated by Standards Action, 112-119 are
+ allocated through an Expert Review, and 120-127 are reserved for
+ Private Use.
+
+ - Type 1 (C-Type = 1)
+
+ o TE_LINK Class name (11)
+
+ The TE_LINK Object Class type name space should be allocated as
+ follows: pursuant to the policies outlined in [RFC2434], the numbers
+ in the range 0-111 are allocated by Standards Action, 112-119 are
+ allocated through an Expert Review, and 120-127 are reserved for
+ Private Use.
+
+ - IPv4 TE_LINK (C-Type = 1)
+ - IPv6 TE_LINK (C-Type = 2)
+ - Unnumbered TE_LINK (C-Type = 3)
+
+ o DATA_LINK Class name (12)
+
+ The DATA_LINK Object Class type name space should be allocated as
+ follows: pursuant to the policies outlined in [RFC2434], the numbers
+ in the range 0-111 are allocated by Standards Action, 112-119 are
+ allocated through an Expert Review, and 120-127 are reserved for
+ private Use.
+
+ - IPv4 DATA_LINK (C-Type = 1)
+ - IPv6 DATA_LINK (C-Type = 2)
+ - Unnumbered DATA_LINK (C-Type = 3)
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 81]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ The DATA_LINK Sub-object Class name space should be allocated as
+ follows: pursuant to the policies outlined in [RFC2434], the numbers
+ in the range of 0-127 are allocated by Standards Action, 128-247 are
+ allocated through an Expert Review, and 248-255 are reserved for
+ private Use.
+
+ - Interface Switching Type (sub-object Type = 1)
+ - Wavelength (sub-object Type = 2)
+
+ o CHANNEL_STATUS Class name (13)
+
+ The CHANNEL_STATUS Object Class type name space should be allocated
+ as follows: pursuant to the policies outlined in [RFC2434], the
+ numbers in the range 0-111 are allocated by Standards Action, 112-119
+ are allocated through an Expert Review, and 120-127 are reserved for
+ Private Use.
+
+ - IPv4 INTERFACE_ID (C-Type = 1)
+ - IPv6 INTERFACE_ID (C-Type = 2)
+ - Unnumbered INTERFACE_ID (C-Type = 3)
+
+ o CHANNEL_STATUS_REQUESTClass name (14)
+
+ The CHANNEL_STATUS_REQUEST Object Class type name space should be
+ allocated as follows: pursuant to the policies outlined in [RFC2434],
+ the numbers in the range 0-111 are allocated by Standards Action,
+ 112-119 are allocated through an Expert Review, and 120-127 are
+ reserved for Private Use.
+
+ - IPv4 INTERFACE_ID (C-Type = 1)
+ - IPv6 INTERFACE_ID (C-Type = 2)
+ - Unnumbered INTERFACE_ID (C-Type = 3)
+
+ o ERROR_CODE Class name (20)
+
+ The ERROR_CODE Object Class type name space should be allocated as
+ follows: pursuant to the policies outlined in [RFC2434], the numbers
+ in the range 0-111 are allocated by Standards Action, 112-119 are
+ allocated through an Expert Review, and 120-127 are reserved for
+ private Use.
+
+ - BEGIN_VERIFY_ERROR (C-Type = 1)
+ - LINK_SUMMARY_ERROR (C-Type = 2)
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 82]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+17. Acknowledgements
+
+ The authors would like to thank Andre Fredette for his many
+ contributions to this document. We would also like to thank Ayan
+ Banerjee, George Swallow, Adrian Farrel, Dimitri Papadimitriou, Vinay
+ Ravuri, and David Drysdale for their insightful comments and
+ suggestions. We would also like to thank John Yu, Suresh Katukam,
+ and Greg Bernstein for their helpful suggestions for the in-band
+ control channel applicability.
+
+18. Contributors
+
+ Jonathan P. Lang
+ Sonos, Inc.
+ 223 E. De La Guerra St.
+ Santa Barbara, CA 93101
+
+ EMail: jplang@ieee.org
+
+
+ Krishna Mitra
+ Independent Consultant
+
+ EMail: kmitra@earthlink.net
+
+
+ John Drake
+ Calient Networks
+ 5853 Rue Ferrari
+ San Jose, CA 95138
+
+ EMail: jdrake@calient.net
+
+
+ Kireeti Kompella
+ Juniper Networks, Inc.
+ 1194 North Mathilda Avenue
+ Sunnyvale, CA 94089
+
+ EMail: kireeti@juniper.net
+
+
+ Yakov Rekhter
+ Juniper Networks, Inc.
+ 1194 North Mathilda Avenue
+ Sunnyvale, CA 94089
+
+ EMail: yakov@juniper.net
+
+
+
+Lang Standards Track [Page 83]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+ Lou Berger
+ Movaz Networks
+
+ EMail: lberger@movaz.com
+
+
+ Debanjan Saha
+ IBM Watson Research Center
+
+ EMail: dsaha@us.ibm.com
+
+
+ Debashis Basak
+ Accelight Networks
+ 70 Abele Road, Suite 1201
+ Bridgeville, PA 15017-3470
+
+ EMail: dbasak@accelight.com
+
+
+ Hal Sandick
+ Shepard M.S.
+ 2401 Dakota Street
+ Durham, NC 27705
+
+ EMail: sandick@nc.rr.com
+
+
+ Alex Zinin
+ Alcatel
+
+ EMail: alex.zinin@alcatel.com
+
+
+ Bala Rajagopalan
+ Intel Corp.
+ 2111 NE 25th Ave
+ Hillsboro, OR 97123
+
+ EMail: bala.rajagopalan@intel.com
+
+
+ Sankar Ramamoorthi
+ Juniper Networks, Inc.
+ 1194 North Mathilda Avenue
+ Sunnyvale, CA 94089
+
+ EMail: sankarr@juniper.net
+
+
+
+Lang Standards Track [Page 84]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+Contact Address
+
+ Jonathan P. Lang
+ Sonos, Inc.
+ 829 De La Vina, Suite 220
+ Santa Barbara, CA 93101
+
+ EMail: jplang@ieee.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lang Standards Track [Page 85]
+
+RFC 4204 Link Management Protocol (LMP) October 2005
+
+
+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.
+
+
+
+
+
+
+
+Lang Standards Track [Page 86]
+