draft-ietf-ccamp-lmp-07.txt   draft-ietf-ccamp-lmp-08.txt 
Network Working Group J. Lang, Editor Network Working Group J. Lang, Editor
Internet Draft Calient Networks Internet Draft (Rincon Networks)
Category: Standards Track November 2002 Category: Standards Track
Expires: May 2003 Expires: September 2003 March 2003
Link Management Protocol (LMP) Link Management Protocol (LMP)
draft-ietf-ccamp-lmp-07.txt draft-ietf-ccamp-lmp-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
management of TE links is not restricted to in-band messaging, but management of TE links is not restricted to in-band messaging, but
instead can be done using out-of-band techniques. This document instead can be done using out-of-band techniques. This document
specifies a link management protocol (LMP) that runs between specifies a link management protocol (LMP) that runs between
neighboring nodes and is used to manage TE links. Specifically, LMP neighboring nodes and is used to manage TE links. Specifically, LMP
will be used to maintain control channel connectivity, verify the will be used to maintain control channel connectivity, verify the
physical connectivity of the data links, correlate the link property physical connectivity of the data links, correlate the link property
information, suppress downstream alarms, and localize link failures information, suppress downstream alarms, and localize link failures
for protection/restoration purposes in multiple kinds of networks. for protection/restoration purposes in multiple kinds of networks.
Table of Contents Table of Contents
1 Introduction ................................................ 5 1 Introduction ................................................ 5
1.1 Terminology ............................................. 5 1.1 Terminology ............................................. 5
2 LMP Overview ................................................ 8 2 LMP Overview ................................................ 8
3 Control Channel Management .................................. 10 3 Control Channel Management .................................. 10
3.1 Parameter Negotiation ................................... 11 3.1 Parameter Negotiation ................................... 11
3.2 Hello Protocol .......................................... 12 3.2 Hello Protocol .......................................... 12
3.2.1 Hello Parameter Negotiation ...................... 12 3.2.1 Hello Parameter Negotiation ...................... 12
3.2.2 Fast Keep-alive .................................. 13 3.2.2 Fast Keep-alive .................................. 13
3.2.3 Control Channel Down ............................. 13 3.2.3 Control Channel Down ............................. 14
3.2.4 Degraded State ................................... 14 3.2.4 Degraded State ................................... 14
4 Link Property Correlation ................................... 14 4 Link Property Correlation ................................... 14
5 Verifying Link Connectivity ................................. 16 5 Verifying Link Connectivity ................................. 16
5.1 Example of Link Connectivity Verification ............... 18 5.1 Example of Link Connectivity Verification ............... 18
6 Fault Management ............................................ 20 6 Fault Management ............................................ 20
6.1 Fault Detection ......................................... 20 6.1 Fault Detection ......................................... 20
6.2 Fault Localization Procedure ............................ 20 6.2 Fault Localization Procedure ............................ 20
6.3 Examples of Fault Localization .......................... 21 6.3 Examples of Fault Localization .......................... 21
6.4 Channel Activation Indication ........................... 22 6.4 Channel Activation Indication ........................... 22
6.5 Channel Deactivation Indication ......................... 22 6.5 Channel Deactivation Indication ......................... 22
7 Message_Id Usage ............................................ 23 7 Message_Id Usage ............................................ 23
8 Graceful Restart ............................................ 24 8 Graceful Restart ............................................ 24
9 Addressing .................................................. 25 9 Addressing .................................................. 25
10 Exponential Back-off Procedures ............................. 25 10 Exponential Back-off Procedures ............................. 25
10.1 Operation............................................... 25 10.1 Operation............................................... 25
10.2 Retransmission Algorithm ............................... 26 10.2 Retransmission Algorithm ............................... 26
11 LMP Finite State Machines ................................... 27 11 LMP Finite State Machines ................................... 27
11.1 Control Channel FSM .................................... 27 11.1 Control Channel FSM .................................... 27
11.1.1 Control Channel States .......................... 27 11.1.1 Control Channel States .......................... 27
11.1.2 Control Channel Events .......................... 28 11.1.2 Control Channel Events .......................... 28
11.1.3 Control Channel FSM Description ................. 30 11.1.3 Control Channel FSM Description ................. 29
11.2 TE Link FSM ............................................ 31 11.2 TE Link FSM ............................................ 31
11.2.1 TE Link States .................................. 31 11.2.1 TE Link States .................................. 31
11.2.2 TE Link Events .................................. 31 11.2.2 TE Link Events .................................. 31
11.2.3 TE Link FSM Description ......................... 32 11.2.3 TE Link FSM Description ......................... 32
11.3 Data Link FSM .......................................... 32 11.3 Data Link FSM .......................................... 32
11.3.1 Data Link States ................................ 33 11.3.1 Data Link States ................................ 33
11.3.2 Data Link Events ................................ 33 11.3.2 Data Link Events ................................ 33
11.3.3 Active Data Link FSM Description ................ 35 11.3.3 Active Data Link FSM Description ................ 34
11.3.4 Passive Data Link FSM Description ............... 36 11.3.4 Passive Data Link FSM Description ............... 35
12 LMP Message Formats ......................................... 37 12 LMP Message Formats ......................................... 36
12.1 Common Header .......................................... 37 12.1 Common Header .......................................... 36
12.2 LMP Object Format ...................................... 38 12.2 LMP Object Format ...................................... 38
12.3 Parameter Negotiation Messages ......................... 39 12.3 Parameter Negotiation Messages ......................... 39
12.4 Hello Message .......................................... 41 12.4 Hello Message .......................................... 40
12.5 Link Verification Messages ............................. 41 12.5 Link Verification Messages ............................. 41
12.6 Link Summary Messages .................................. 45 12.6 Link Summary Messages .................................. 44
12.7 Fault Management Messages .............................. 46 12.7 Fault Management Messages .............................. 46
13 LMP Object Definitions ...................................... 48 13 LMP Object Definitions ...................................... 48
14 Intellectual Property Considerations ........................ 66 14 Intellectual Property Considerations ........................ 65
15 References .................................................. 66 15 References .................................................. 65
16 Security Considerations ..................................... 67 16 Security Considerations ..................................... 66
16.1 Security Requirements .................................. 67 16.1 Security Requirements .................................. 67
16.2 Security Mechanisms .................................... 68 16.2 Security Mechanisms .................................... 67
17 IANA Considerations ......................................... 69 17 IANA Considerations ......................................... 69
18 Acknowledgements ............................................ 72 18 Acknowledgements ............................................ 72
19 Contributors ................................................ 73 19 Contributors ................................................ 72
20 Contact Address ............................................. 73 20 Contact Address ............................................. 73
21 Full Copyright Statement .................................... 74 21 Full Copyright Statement .................................... 74
[Editor's note: "Changes from previous version" notes can be removed [Editor's note: "Changes from previous version" notes can be removed
prior to publication as an RFC.] prior to publication as an RFC.]
Changes from previous version: Changes from previous version:
o Editorial changes. o Editorial changes resulting from AD review.
o Updated Error Codes.
1. Introduction 1. Introduction
Networks are being developed with routers, switches, crossconnects, Networks are being developed with routers, switches, crossconnects,
DWDM systems, and add-drop multiplexors (ADMs) that use a common dense wavelength division multiplexed (DWDM) systems, and add-drop
control plane [e.g., Generalized MPLS (GMPLS)] to dynamically multiplexors (ADMs) that use a common control plane [e.g.,
allocate resources and to provide network survivability using Generalized MPLS (GMPLS)] to dynamically allocate resources and to
protection and restoration techniques. A pair of nodes may have provide network survivability using protection and restoration
thousands of interconnects, where each interconnect may consist of techniques. A pair of nodes may have thousands of interconnects,
multiple data links when multiplexing (e.g., Frame Relay DLCIs at where each interconnect may consist of multiple data links when
Layer 2, or TDM slots or WDM wavelengths at Layer 1) is used. For multiplexing (e.g., Frame Relay DLCIs at Layer 2, or time division
scalability purposes, multiple data links may be combined into a multiplexed (TDM) slots or wavelength division multiplexed (WDM)
single traffic-engineering (TE) link. 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 To enable communication between nodes for routing, signaling, and
link management, there must be a pair of IP interfaces that are link management, there must be a pair of IP interfaces that are
mutually reachable. We call such a pair of interfaces a control mutually reachable. We call such a pair of interfaces a control
channel. Note that "mutually reachable" does not imply that these channel. Note that "mutually reachable" does not imply that these
two interfaces are (directly) connected by an IP link; there may be two interfaces are (directly) connected by an IP link; there may be
an IP network between the two. Furthermore, the interface over an IP network between the two. Furthermore, the interface over which
which the control messages are sent/received may not be the same the control messages are sent/received may not be the same interface
interface over which the data flows. This document specifies a link over which the data flows. This document specifies a link management
management protocol (LMP) that runs between neighboring nodes and is protocol (LMP) that runs between neighboring nodes and is used to
used to manage TE links and verify reachability of the control manage TE links and verify reachability of the control channel.
channel.
In GMPLS, the control channels between two adjacent nodes are no In GMPLS, the control channels between two adjacent nodes are no
longer required to use the same physical medium as the data links longer required to use the same physical medium as the data links
between those nodes. For example, a control channel could use a between those nodes. For example, a control channel could use a
separate virtual circuit, wavelength, fiber, Ethernet link, an IP separate virtual circuit, wavelength, fiber, Ethernet link, an IP
tunnel routed over a separate management network, or a multi-hop IP tunnel routed over a separate management network, or a multi-hop IP
network. A consequence of allowing the control channel(s) between network. A consequence of allowing the control channel(s) between
two nodes to be logically or physically diverse from the associated two nodes to be logically or physically diverse from the associated
data links is that the health of a control channel does not data links is that the health of a control channel does not
necessarily correlate to the health of the data links, and vice- necessarily correlate to the health of the data links, and vice-
versa. Therefore, a clean separation between the fate of the versa. Therefore, a clean separation between the fate of the control
control channel and data links must be made. New mechanisms must be channel and data links must be made. New mechanisms must be
developed to manage the data links, both in terms of link developed to manage the data links, both in terms of link
provisioning and fault management. provisioning and fault management.
Among the tasks that LMP accomplishes is checking that the grouping 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 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 the same at both end points of the links -- this is called "link
property correlation". Also, LMP can communicate these link property correlation". Also, LMP can communicate these link
properties to the IGP module, which can then announce them to other properties to the IGP module, which can then announce them to other
nodes in the network. LMP can also tell the signaling module the nodes in the network. LMP can also tell the signaling module the
mapping between TE links and control channels. Thus, LMP performs a mapping between TE links and control channels. Thus, LMP performs a
skipping to change at page 6, line 28 skipping to change at page 6, line 29
Frame Relay switch is able to demultiplex an interface into virtual Frame Relay switch is able to demultiplex an interface into virtual
circuits based on DLCIs; similarly, a SONET crossconnect with OC-192 circuits based on DLCIs; similarly, a SONET crossconnect with OC-192
interfaces may be able to demultiplex the OC-192 stream into four interfaces may be able to demultiplex the OC-192 stream into four
OC-48 streams. If multiple interfaces are grouped together into a OC-48 streams. If multiple interfaces are grouped together into a
single TE link using link bundling [BUNDLE], then the link resources single TE link using link bundling [BUNDLE], then the link resources
must be identified using three levels: Link_Id, component interface must be identified using three levels: Link_Id, component interface
Id, and label identifying virtual circuit, timeslot, etc. Resource Id, and label identifying virtual circuit, timeslot, etc. Resource
allocation happens at the lowest level (labels), but physical allocation happens at the lowest level (labels), but physical
connectivity happens at the component link level. As another connectivity happens at the component link level. As another
example, consider the case where an optical switch (e.g., PXC) example, consider the case where an optical switch (e.g., PXC)
transparently switches OC-192 lightpaths. If multiple interfaces transparently switches OC-192 lightpaths. If multiple interfaces are
are once again grouped together into a single TE link, then link once again grouped together into a single TE link, then link
bundling [BUNDLE] is not required and only two levels of bundling [BUNDLE] is not required and only two levels of
identification are required: Link_Id and Port_Id. In this case, identification are required: Link_Id and Port_Id. In this case, both
both resource allocation and physical connectivity happen at the resource allocation and physical connectivity happen at the lowest
lowest level (i.e. port level). level (i.e. port level).
To ensure interworking between data links with different To ensure interworking between data links with different
multiplexing capabilities, LMP capable devices SHOULD allow sub- multiplexing capabilities, LMP capable devices SHOULD allow sub-
channels of a component link to be locally configured as (logical) channels of a component link to be locally configured as (logical)
data links. For example, if a Router with 4 OC-48 interfaces is 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 connected through a 4:1 MUX to a cross-connect with OC-192
interfaces, the cross-connect SHOULD be able to configure each sub- 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 channel (e.g., STS-48c SPE if the 4:1 MUX is a SONET MUX) as a data
link. link.
skipping to change at page 7, line 5 skipping to change at page 7, line 11
information about certain physical resources (and their properties) information about certain physical resources (and their properties)
into the information that is used by Constrained SPF for the purpose into the information that is used by Constrained SPF for the purpose
of path computation, and by GMPLS signaling. of path computation, and by GMPLS signaling.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The reader is assumed to be familiar with the terminology in [GMPLS- The reader is assumed to be familiar with the terminology in
SIG], [GMPLS-RTG], and [BUNDLE]. [RFC3471], [GMPLS-RTG], and [BUNDLE].
Bundled Link: Bundled Link:
As defined in [BUNDLE], a bundled link is a TE link such that for As defined in [BUNDLE], a bundled link is a TE link such that for
the purpose of GMPLS signaling a combination of <link identifier, the purpose of GMPLS signaling a combination of <link identifier,
label> is not sufficient to unambiguously identify the label> is not sufficient to unambiguously identify the
appropriate resources used by an LSP. A bundled link is composed appropriate resources used by an LSP. A bundled link is composed
of two or more component links. of two or more component links.
Control Channel: Control Channel:
skipping to change at page 7, line 32 skipping to change at page 7, line 38
Component Link: Component Link:
As defined in [BUNDLE], a component link is a subset of resources As defined in [BUNDLE], a component link is a subset of resources
of a TE Link such that (a) the partition is minimal, and (b) of a TE Link such that (a) the partition is minimal, and (b)
within each subset a label is sufficient to unambiguously within each subset a label is sufficient to unambiguously
identify the appropriate resources used by an LSP. identify the appropriate resources used by an LSP.
Data Link: Data Link:
A data link is a pair of interfaces that are used to transfer A data link is a pair of interfaces that are used to transfer
user data. Note that in GMPLS, the control channel(s) between user data. Note that in GMPLS, the control channel(s) between two
two adjacent nodes are no longer required to use the same adjacent nodes are no longer required to use the same physical
physical medium as the data links between those nodes. medium as the data links between those nodes.
Link Property Correlation: Link Property Correlation:
This is a procedure to correlate the local and remote properties This is a procedure to correlate the local and remote properties
of a TE link. of a TE link.
Multiplex Capability: Multiplex Capability:
The ability to multiplex/demultiplex a data stream into sub-rate The ability to multiplex/demultiplex a data stream into sub-rate
streams for switching purposes. streams for switching purposes.
skipping to change at page 8, line 16 skipping to change at page 8, line 23
As defined in [GMPLS-RTG], a TE link is a logical construct that As defined in [GMPLS-RTG], a TE link is a logical construct that
represents a way to group/map the information about certain represents a way to group/map the information about certain
physical resources (and their properties) that interconnect LSRs physical resources (and their properties) that interconnect LSRs
into the information that is used by Constrained SPF for the into the information that is used by Constrained SPF for the
purpose of path computation, and by GMPLS signaling. purpose of path computation, and by GMPLS signaling.
Transparent: Transparent:
A device is called X-transparent if it forwards incoming signals A device is called X-transparent if it forwards incoming signals
from input to output without examining or modifying the X aspect from input to output without examining or modifying the X aspect
of the signal. For example, a Frame Relay switch is network- of the signal. For example, a Frame Relay switch is network-layer
layer transparent; an all-optical switch is electrically transparent; an all-optical switch is electrically transparent.
transparent.
2. LMP Overview 2. LMP Overview
The two core procedures of LMP are control channel management and The two core procedures of LMP are control channel management and
link property correlation. Control channel management is used to link property correlation. Control channel management is used to
establish and maintain control channels between adjacent nodes. establish and maintain control channels between adjacent nodes.
This is done using a Config message exchange and a fast keep-alive This is done using a Config message exchange and a fast keep-alive
mechanism between the nodes. The latter is required if lower-level mechanism between the nodes. The latter is required if lower-level
mechanisms are not available to detect control channel failures. mechanisms are not available to detect control channel failures.
Link property correlation is used to synchronize the TE link Link property correlation is used to synchronize the TE link
skipping to change at page 8, line 47 skipping to change at page 8, line 53
transport mechanism for in-band messaging]. The link level encoding transport mechanism for in-band messaging]. The link level encoding
of the control channel is outside the scope of this document. of the control channel is outside the scope of this document.
An "LMP adjacency" is formed between two nodes when at least one bi- An "LMP adjacency" is formed between two nodes when at least one bi-
directional control channel is established between them. Multiple directional control channel is established between them. Multiple
control channels may be active simultaneously for each adjacency; control channels may be active simultaneously for each adjacency;
control channel parameters, however, MUST be individually negotiated control channel parameters, however, MUST be individually negotiated
for each control channel. If the LMP fast keep-alive is used over a 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, LMP Hello messages MUST be exchanged over the
control channel. Other LMP messages MAY be transmitted over any of control channel. Other LMP messages MAY be transmitted over any of
the active control channels between a pair of adjacent nodes. One the active control channels between a pair of adjacent nodes. One or
or more active control channels may be grouped into a logical more active control channels may be grouped into a logical control
control channel for signaling, routing, and link property channel for signaling, routing, and link property correlation
correlation purposes. purposes.
The link property correlation function of LMP is designed to The link property correlation function of LMP is designed to
aggregate multiple data links (ports or component links) into a TE aggregate multiple data links (ports or component links) into a TE
link and to synchronize the properties of the TE link. As part of link and to synchronize the properties of the TE link. As part of
the link property correlation function, a LinkSummary message the link property correlation function, a LinkSummary message
exchange is defined. The LinkSummary message includes the local and exchange is defined. The LinkSummary message includes the local and
remote Link_Ids, a list of all data links that comprise the TE link, remote Link_Ids, a list of all data links that comprise the TE link,
and various link properties. A LinkSummaryAck or LinkSummaryNack and various link properties. A LinkSummaryAck or LinkSummaryNack
message MUST be sent in response to the receipt of a LinkSummary message MUST be sent in response to the receipt of a LinkSummary
message indicating agreement or disagreement on the link properties. message indicating agreement or disagreement on the link properties.
LMP messages are transmitted reliably using Message_Ids and LMP messages are transmitted reliably using Message_Ids and
retransmissions. Message_Ids are carried in MESSAGE_ID objects. No retransmissions. Message_Ids are carried in MESSAGE_ID objects. No
more than one MESSAGE_ID object may be included in an LMP message. more than one MESSAGE_ID object may be included in an LMP message.
For control channel specific messages, the Message_Id is within the For control channel specific messages, the Message_Id is within the
scope of the control channel over which the message is sent. For TE 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 link specific messages, the Message_Id is within the scope of the
LMP adjacency. The value of the Message_Id is monotonically LMP adjacency. The value of the Message_Id is monotonically
increasing and only decreases when the value wraps. increasing and wraps when the maximum value is reached.
In this document, two additional LMP procedures are defined: link In this document, two additional LMP procedures are defined: link
connectivity verification and fault management. These procedures connectivity verification and fault management. These procedures are
are particularly useful when the control channels are physically particularly useful when the control channels are physically diverse
diverse from the data links. Link connectivity verification is used from the data links. Link connectivity verification is used for data
for data plane discovery, Interface_Id exchange (Interface_Ids are plane discovery, Interface_Id exchange (Interface_Ids are used in
used in GMPLS signaling, either as port labels or component link GMPLS signaling, either as port labels or component link
identifiers, depending on the configuration), and physical identifiers, depending on the configuration), and physical
connectivity verification. This is done by sending Test messages connectivity verification. This is done by sending Test messages
over the data links and TestStatus messages back over the control over the data links and TestStatus messages back over the control
channel. Note that the Test message is the only LMP message that channel. Note that the Test message is the only LMP message that
must be transmitted over the data link. The ChannelStatus message must be transmitted over the data link. The ChannelStatus message
exchange is used between adjacent nodes for both the suppression of exchange is used between adjacent nodes for both the suppression of
downstream alarms and the localization of faults for protection and downstream alarms and the localization of faults for protection and
restoration. restoration.
For LMP link connectivity verification, the Test message is For LMP link connectivity verification, the Test message is
transmitted over the data links. For X-transparent devices, this transmitted over the data links. For X-transparent devices, this
requires examining and modifying the X aspect of the signal. The requires examining and modifying the X aspect of the signal. The LMP
LMP link connectivity verification procedure is coordinated using a link connectivity verification procedure is coordinated using a
BeginVerify message exchange over a control channel. To support BeginVerify message exchange over a control channel. To support
various aspects of transparency, a Verify Transport Mechanism is various aspects of transparency, a Verify Transport Mechanism is
included in the BeginVerify and BeginVerifyAck messages. Note that included in the BeginVerify and BeginVerifyAck messages. Note that
there is no requirement that all data links must lose their there is no requirement that all data links must lose their
transparency simultaneously, but at a minimum, it must be possible transparency simultaneously, but at a minimum, it must be possible
to terminate them one at a time. There is also no requirement that to terminate them one at a time. There is also no requirement that
the control channel and TE link use the same physical medium; the control channel and TE link use the same physical medium;
however, the control channel MUST terminate on the same two nodes however, the control channel MUST terminate on the same two nodes
that the TE link spans. Since the BeginVerify message exchange that the TE link spans. Since the BeginVerify message exchange
coordinates the Test procedure, it also naturally coordinates the coordinates the Test procedure, it also naturally coordinates the
transition of the data links in and out of the transparent mode. transition of the data links in and out of the transparent mode.
The LMP fault management procedure is based on a ChannelStatus The LMP fault management procedure is based on a ChannelStatus
message exchange using the following messages: ChannelStatus, message exchange using the following messages: ChannelStatus,
ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse. ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse.
The ChannelStatus message is sent unsolicited and is used to notify 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 an LMP neighbor about the status of one or more data channels of a
TE link. The ChannelStatusAck message is used to acknowledge TE link. The ChannelStatusAck message is used to acknowledge receipt
receipt of the ChannelStatus message. The ChannelStatusRequest of the ChannelStatus message. The ChannelStatusRequest message is
message is used to query an LMP neighbor for the status of one or used to query an LMP neighbor for the status of one or more data
more data channels of a TE Link. The ChannelStatusResponse message channels of a TE Link. The ChannelStatusResponse message is used to
is used to acknowledge receipt of the ChannelStatusRequest message acknowledge receipt of the ChannelStatusRequest message and indicate
and indicate the states of the queried data links. the states of the queried data links.
3. Control Channel Management 3. Control Channel Management
To initiate an LMP adjacency between two nodes, one or more bi- To initiate an LMP adjacency between two nodes, one or more bi-
directional control channels MUST be activated. The control directional control channels MUST be activated. The control channels
channels can be used to exchange control-plane information such as can be used to exchange control-plane information such as link
link provisioning and fault management information (implemented provisioning and fault management information (implemented using a
using a messaging protocol such as LMP, proposed in this document), messaging protocol such as LMP, proposed in this document), path
path management and label distribution information (implemented management and label distribution information (implemented using a
using a signaling protocol such as RSVP-TE [RFC3209]), and network signaling protocol such as RSVP-TE [RFC3209]), and network topology
topology and state distribution information (implemented using and state distribution information (implemented using traffic
traffic engineering extensions of protocols such as OSPF [OSPF-TE] engineering extensions of protocols such as OSPF [OSPF-TE] and IS-IS
and IS-IS [ISIS-TE]). [ISIS-TE]).
For the purposes of LMP, the exact implementation of the control For the purposes of LMP, the exact implementation of the control
channel is not specified; it could be, for example, a separate channel is not specified; it could be, for example, a separate
wavelength or fiber, an Ethernet link, an IP tunnel through a wavelength or fiber, an Ethernet link, an IP tunnel through a
separate management network, or the overhead bytes of a data link. separate management network, or the overhead bytes of a data link.
Rather, a node-wide unique 32-bit non-zero integer control channel Rather, a node-wide unique 32-bit non-zero integer control channel
identifier (CC_Id) is assigned at each end of the control channel. identifier (CC_Id) is assigned at each end of the control channel.
This identifier comes from the same space as the unnumbered This identifier comes from the same space as the unnumbered
interface Id. Furthermore, LMP packets are run over UDP with an LMP interface Id. Furthermore, LMP packets are run over UDP with an LMP
port number. Thus, the link level encoding of the control channel port number. Thus, the link level encoding of the control channel is
is not part of the LMP specification. not part of the LMP specification.
To establish a control channel, the destination IP address on the To establish a control channel, the destination IP address on the
far end of the control channel must be known. This knowledge may be far end of the control channel must be known. This knowledge may be
manually configured or automatically discovered. Note that for in- manually configured or automatically discovered. Note that for in-
band signaling, a control channel could be explicitly configured on band signaling, a control channel could be explicitly configured on
a particular data link. In this case, the Config message exchange 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 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 to the control channel. This is done by sending the Config message to
the Multicast address (224.0.0.1). The ConfigAck and ConfigNack the Multicast address (224.0.0.1). The ConfigAck and ConfigNack
messages MUST be sent to the source IP address found in the IP messages MUST be sent to the source IP address found in the IP
skipping to change at page 11, line 7 skipping to change at page 11, line 14
implemented out-of-fiber. As such, control channel parameters MUST implemented out-of-fiber. As such, control channel parameters MUST
be negotiated over each individual control channel, and LMP Hello be negotiated over each individual control channel, and LMP Hello
packets MUST be exchanged over each control channel to maintain LMP packets MUST be exchanged over each control channel to maintain LMP
connectivity if other mechanisms are not available. Since control connectivity if other mechanisms are not available. Since control
channels are electrically terminated at each node, it may be channels are electrically terminated at each node, it may be
possible to detect control channel failures using lower layers possible to detect control channel failures using lower layers
(e.g., SONET/SDH). (e.g., SONET/SDH).
There are four LMP messages that are used to manage individual There are four LMP messages that are used to manage individual
control channels. They are the Config, ConfigAck, ConfigNack, and control channels. They are the Config, ConfigAck, ConfigNack, and
Hello messages. These messages MUST be transmitted on the channel Hello messages. These messages MUST be transmitted on the channel to
to which they refer. All other LMP messages may be transmitted over which they refer. All other LMP messages may be transmitted over any
any of the active control channels between a pair of LMP adjacent of the active control channels between a pair of LMP adjacent nodes.
nodes.
In order to maintain an LMP adjacency, it is necessary to have at In order to maintain an LMP adjacency, it is necessary to have at
least one active control channel between a pair of adjacent nodes least one active control channel between a pair of adjacent nodes
(recall that multiple control channels can be active simultaneously (recall that multiple control channels can be active simultaneously
between a pair of nodes). In the event of a control channel between a pair of nodes). In the event of a control channel failure,
failure, alternate active control channels can be used and it may be alternate active control channels can be used and it may be possible
possible to activate additional control channels as described below. to activate additional control channels as described below.
3.1. Parameter Negotiation 3.1. Parameter Negotiation
Control channel activation begins with a parameter negotiation Control channel activation begins with a parameter negotiation
exchange using Config, ConfigAck, and ConfigNack messages. The exchange using Config, ConfigAck, and ConfigNack messages. The
contents of these messages are built using LMP objects, which can be contents of these messages are built using LMP objects, which can be
either negotiable or non-negotiable (identified by the N bit in the either negotiable or non-negotiable (identified by the N bit in the
object header). Negotiable objects can be used to let LMP peers object header). Negotiable objects can be used to let LMP peers
agree on certain values. Non-negotiable objects are used for the agree on certain values. Non-negotiable objects are used for the
announcement of specific values that do not need, or do not allow, announcement of specific values that do not need, or do not allow,
skipping to change at page 11, line 39 skipping to change at page 11, line 45
To activate a control channel, a Config message MUST be transmitted To activate a control channel, a Config message MUST be transmitted
to the remote node, and in response, a ConfigAck message MUST be to the remote node, and in response, a ConfigAck message MUST be
received at the local node. The Config message contains the Local 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 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 reliable messaging, and a CONFIG object. It is possible that both
the local and remote nodes initiate the configuration procedure at the local and remote nodes initiate the configuration procedure at
the same time. To avoid ambiguities, the node with the higher the same time. To avoid ambiguities, the node with the higher
Node_Id wins the contention; the node with the lower Node_Id MUST Node_Id wins the contention; the node with the lower Node_Id MUST
stop transmitting the Config message and respond to the Config stop transmitting the Config message and respond to the Config
message it received. 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. Note that the problem may be solved by an operator
changing the Node_Ids.
The ConfigAck message is used to acknowledge receipt of the Config The ConfigAck message is used to acknowledge receipt of the Config
message and express agreement on ALL of the configured parameters message and express agreement on ALL of the configured parameters
(both negotiable and non-negotiable). (both negotiable and non-negotiable).
The ConfigNack message is used to acknowledge receipt of the Config The ConfigNack message is used to acknowledge receipt of the Config
message, indicate which (if any) non-negotiable CONFIG objects are message, indicate which (if any) non-negotiable CONFIG objects are
unacceptable, and propose alternate values for the negotiable unacceptable, and propose alternate values for the negotiable
parameters. parameters.
skipping to change at page 12, line 39 skipping to change at page 12, line 49
message at least every 150ms. The HelloDeadInterval indicates how message at least every 150ms. The HelloDeadInterval indicates how
long a device should wait to receive a Hello message before long a device should wait to receive a Hello message before
declaring a control channel dead, and is measured in milliseconds declaring a control channel dead, and is measured in milliseconds
(ms). (ms).
The HelloDeadInterval MUST be greater than the HelloInterval, and The HelloDeadInterval MUST be greater than the HelloInterval, and
SHOULD be at least 3 times the value of HelloInterval. If the fast SHOULD be at least 3 times the value of HelloInterval. If the fast
keep-alive mechanism of LMP is not used, the HelloInterval and keep-alive mechanism of LMP is not used, the HelloInterval and
HelloDeadInterval parameters MUST be set to zero. HelloDeadInterval parameters MUST be set to zero.
Suggested default values for the HelloInterval is 150 ms and for the The values for the HelloInterval and HelloDeadInterval should be
HelloDeadInterval is 500 ms. selected carefully to provide rapid response time to control channel
failures without causing congestion. 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 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 begin sending Hello messages. Once it has sent a Hello message and
received a valid Hello message (i.e., with expected sequence received a valid Hello message (i.e., with expected sequence
numbers; see Section 3.2.2), the control channel moves to the up 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 state. (It is also possible to move to the up state without sending
Hellos if other methods are used to indicate bi-directional control- Hellos if other methods are used to indicate bi-directional control-
channel connectivity.) If, however, a node receives a ConfigNack channel connectivity.) If, however, a node receives a ConfigNack
message instead of a ConfigAck message, the node MUST not send Hello message instead of a ConfigAck message, the node MUST not send Hello
messages and the control channel SHOULD NOT move to the up state. messages and the control channel SHOULD NOT move to the up state.
See Section 11.1 for the complete control channel FSM. See Section 11.1 for the complete control channel FSM.
3.2.2. Fast Keep-alive 3.2.2. Fast Keep-alive
Each Hello message contains two sequence numbers: the first sequence Each Hello message contains two sequence numbers: the first sequence
number (TxSeqNum) is the sequence number for the Hello message being number (TxSeqNum) is the sequence number for the Hello message being
sent and the second sequence number (RcvSeqNum) is the sequence sent and the second sequence number (RcvSeqNum) is the sequence
number of the last Hello message received from the adjacent node number of the last Hello message received from the adjacent node
over this control channel. over this control channel.
There are two special sequence numbers. TxSeqNum MUST NOT ever be There are two special sequence numbers. TxSeqNum MUST NOT ever be 0.
0. TxSeqNum = 1 is used to indicate that the sender has just TxSeqNum = 1 is used to indicate that the sender has just started or
started or has restarted and has no recollection of the last has restarted and has no recollection of the last TxSeqNum that was
TxSeqNum that was sent. Thus, the first Hello sent has a TxSeqNum sent. Thus, the first Hello sent has a TxSeqNum of 1 and an RxSeqNum
of 1 and an RxSeqNum of 0. When TxSeqNum reaches 2^32 -1, the next of 0. When TxSeqNum reaches (2^32)-1, the next sequence number used
sequence number used is 2, not 0 or 1, as these have special is 2, not 0 or 1, as these have special meanings.
meanings.
Under normal operation, the difference between the RcvSeqNum in a Under normal operation, the difference between the RcvSeqNum in a
Hello message that is received and the local TxSeqNum that is Hello message that is received and the local TxSeqNum that is
generated will be at most 1. This difference can be more than one generated will be at most 1. This difference can be more than one
only when a control channel restarts or when the values wrap. only when a control channel restarts or when the values wrap.
Since the 32-bit sequence numbers may wrap, the following expression 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 may be used to test if a newly received TxSeqNum value is less than
a previously received value: a previously received value:
skipping to change at page 13, line 45 skipping to change at page 13, line 52
verify that its peer is receiving its Hello messages. By including verify that its peer is receiving its Hello messages. By including
the RcvSeqNum in Hello packets, the local node will know which Hello the RcvSeqNum in Hello packets, the local node will know which Hello
packets the remote node has received. packets the remote node has received.
The following example illustrates how the sequence numbers operate. The following example illustrates how the sequence numbers operate.
Note that only the operation at one node is shown, and alternative Note that only the operation at one node is shown, and alternative
scenarios are possible: scenarios are possible:
1) After completing the configuration stage, Node A sends Hello 1) After completing the configuration stage, Node A sends Hello
messages to Node B with {TxSeqNum=1;RcvSeqNum=0}. messages to Node B with {TxSeqNum=1;RcvSeqNum=0}.
2) When Node A receives a Hello from Node B with
{TxSeqNum=1;RcvSeqNum=1}, it sends Hellos to Node B with 2) Node A receives a Hello from Node B with
{TxSeqNum=2;RcvSeqNum=1}. {TxSeqNum=1;RcvSeqNum=1}. When the HelloInterval expires on
3) When Node A receives a Hello from Node B with Node A, it sends Hellos to Node B with {TxSeqNum=2;RcvSeqNum=1}.
{TxSeqNum=2;RcvSeqNum=2}, it sends Hellos to Node B with
{TxSeqNum=3;RcvSeqNum=2}. 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}.
3.2.3. Control Channel Down 3.2.3. Control Channel Down
To allow bringing a control channel down gracefully for To allow bringing a control channel down gracefully for
administration purposes, a ControlChannelDown flag is available in administration purposes, a ControlChannelDown flag is available in
the Common Header of LMP packets. When data links are still in use 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 between a pair of nodes, a control channel SHOULD only be taken down
administratively when there are other active control channels that administratively when there are other active control channels that
can be used to manage the data links. can be used to manage the data links.
skipping to change at page 14, line 27 skipping to change at page 14, line 37
set and move the control channel to the down state. set and move the control channel to the down state.
3.2.4. Degraded State 3.2.4. Degraded State
A consequence of allowing the control channels to be physically A consequence of allowing the control channels to be physically
diverse from the associated data links is that there may not be any diverse from the associated data links is that there may not be any
active control channels available while the data links are still in active control channels available while the data links are still in
use. For many applications, it is unacceptable to tear down a link use. For many applications, it is unacceptable to tear down a link
that is carrying user traffic simply because the control channel is that is carrying user traffic simply because the control channel is
no longer available; however, the traffic that is using the data no longer available; however, the traffic that is using the data
links may no longer be guaranteed the same level of service. Hence links may no longer be guaranteed the same level of service. Hence,
the TE link is in a Degraded state. the TE link is in a Degraded state.
When a TE link is in the Degraded state, routing and signaling When a TE link is in the Degraded state, routing and signaling
SHOULD be notified so that new connections are not accepted and the SHOULD be notified so that new connections are not accepted and the
TE link is advertised with no unreserved resources. TE link is advertised with no unreserved resources.
4. Link Property Correlation 4. Link Property Correlation
As part of LMP, a link property correlation exchange is defined for As part of LMP, a link property correlation exchange is defined for
TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack
messages. The contents of these messages are built using LMP messages. The contents of these messages are built using LMP
objects, which can be either negotiable or non-negotiable objects, which can be either negotiable or non-negotiable
(identified by the N flag in the object header). Negotiable objects (identified by the N flag in the object header). Negotiable objects
can be used to let both sides agree on certain link parameters. can be used to let both sides agree on certain link parameters.
Non-negotiable objects are used for announcement of specific values Non-negotiable objects are used for announcement of specific values
that do not need, or do not allow, negotiation. that do not need, or do not allow, negotiation.
Each TE link has an identifier (Link_Id) that is assigned at each 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, end of the link. These identifiers MUST be the same type (i.e, IPv4,
IPv4, IPv6, unnumbered) at both ends. If a LinkSummary message is IPv6, unnumbered) at both ends. If a LinkSummary message is received
received with different local and remote TE link types, then a with different local and remote TE link types, then a
LinkSummaryNack message MUST be sent with Error Code "Bad TE Link LinkSummaryNack message MUST be sent with Error Code "Bad TE Link
Object". Similarly, each data link is assigned an identifier Object". Similarly, each data link is assigned an identifier
(Interface_Id) at each end. These identifiers MUST also be the same (Interface_Id) at each end. These identifiers MUST also be the same
type at both ends. If a LinkSummary message is received with type at both ends. If a LinkSummary message is received with
different local and remote Interface_Id types then a LinkSummaryNack different local and remote Interface_Id types then a LinkSummaryNack
message MUST be sent with Error Code "Bad Data Link Object". message MUST be sent with Error Code "Bad Data Link Object".
Link property correlation SHOULD be done before the link is brought Link property correlation SHOULD be done before the link is brought
up and MAY be done at any time a link is up and not in the up and MAY be done at any time a link is up and not in the
Verification process. Verification process.
skipping to change at page 15, line 52 skipping to change at page 16, line 10
it becomes free. If a LinkSummaryNack message includes negotiable it becomes free. If a LinkSummaryNack message includes negotiable
parameters, then acceptable values for those parameters MUST be parameters, then acceptable values for those parameters MUST be
included. If a LinkSummaryNack message is received and includes included. If a LinkSummaryNack message is received and includes
negotiable parameters, then the initiator of the LinkSummary message negotiable parameters, then the initiator of the LinkSummary message
SHOULD send a new LinkSummary message. The new LinkSummary message SHOULD send a new LinkSummary message. The new LinkSummary message
SHOULD include new values for the negotiable parameters. These SHOULD include new values for the negotiable parameters. These
values SHOULD take into account the acceptable values received in values SHOULD take into account the acceptable values received in
the LinkSummaryNack message. the LinkSummaryNack message.
It is possible that the LinkSummary message could grow quite large It is possible that the LinkSummary message could grow quite large
due to the number of DATA LINK objects. An LMP implementation due to the number of DATA LINK objects. An LMP implementation SHOULD
SHOULD be able to fragment when transmitting LMP messages, and MUST be able to fragment when transmitting LMP messages, and MUST be able
be able to re-assemble IP fragments when receiving LMP messages. to re-assemble IP fragments when receiving LMP messages.
5. Verifying Link Connectivity 5. Verifying Link Connectivity
In this section, an optional procedure is described that may be used In this section, an optional procedure is described that may be used
to verify the physical connectivity of the data links and to verify the physical connectivity of the data links and
dynamically learn (i.e., discover) the TE link and Interface_Id dynamically learn (i.e., discover) the TE link and Interface_Id
associations. The procedure SHOULD be done when establishing a TE associations. The procedure SHOULD be done when establishing a TE
link, and subsequently, on a periodic basis for all unallocated link, and subsequently, on a periodic basis for all unallocated
(free) data links of the TE link. (free) data links of the TE link.
skipping to change at page 16, line 39 skipping to change at page 16, line 48
(i.e., lose their transparency). To support various degrees of (i.e., lose their transparency). To support various degrees of
opaqueness (e.g., examining overhead bytes, terminating the IP opaqueness (e.g., examining overhead bytes, terminating the IP
payload, etc.), and hence different mechanisms to transport the Test payload, etc.), and hence different mechanisms to transport the Test
messages, a Verify Transport Mechanism field is included in the messages, a Verify Transport Mechanism field is included in the
BeginVerify and BeginVerifyAck messages. BeginVerify and BeginVerifyAck messages.
There is no requirement that all data links be terminated There is no requirement that all data links be terminated
simultaneously, but at a minimum, the data links MUST be able to be simultaneously, but at a minimum, the data links MUST be able to be
terminated one at a time. Furthermore, for the link verification terminated one at a time. Furthermore, for the link verification
procedure it is assumed that the nodal architecture is designed so procedure it is assumed that the nodal architecture is designed so
that messages can be sent and received over any data link. Note that messages can be sent and received over any data link. Note that
that this requirement is trivial for opaque devices since each data this requirement is trivial for opaque devices since each data link
link is electrically terminated and processed before being forwarded is electrically terminated and processed before being forwarded to
to the next opaque device, but that in transparent devices this is the next opaque device, but that in transparent devices this is an
an additional requirement. additional requirement.
To interconnect two nodes, a TE link is defined between them, and at 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 a minimum, there MUST be at least one active control channel between
the nodes. For link verification, a TE link MUST include at least the nodes. For link verification, a TE link MUST include at least
one data link. one data link.
Once a control channel has been established between the two nodes, Once a control channel has been established between the two nodes,
data link connectivity can be verified by exchanging Test messages data link connectivity can be verified by exchanging Test messages
over each of the data links specified in the TE link. It should be 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 noted that all LMP messages except the Test message are exchanged
skipping to change at page 18, line 41 skipping to change at page 18, line 49
Both the local and remote nodes SHOULD maintain the complete list of Both the local and remote nodes SHOULD maintain the complete list of
Interface_Id mappings for correlation purposes. Interface_Id mappings for correlation purposes.
5.1. Example of Link Connectivity Verification 5.1. Example of Link Connectivity Verification
Figure 1 shows an example of the link verification scenario that is 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 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 example, the TE link consists of three free ports (each transmitted
along a separate fiber) and is associated with a bi-directional along a separate fiber) and is associated with a bi-directional
control channel (indicated by a "c"). The verification process is control channel (indicated by a "c"). The verification process is as
as follows: follows:
o A sends a BeginVerify message over the control channel to B o A sends a BeginVerify message over the control channel to B
indicating it will begin verifying the ports that form the TE indicating it will begin verifying the ports that form the TE
link. The LOCAL_LINK_ID object carried in the BeginVerify link. The LOCAL_LINK_ID object carried in the BeginVerify
message carries the identifier (IP address or interface index) message carries the identifier (IP address or interface index)
that A assigns to the link. that A assigns to the link.
o Upon receipt of the BeginVerify message, B creates a Verify_Id 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 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 when B receives the Test messages from A, and these messages
carry the Verify_Id. B discovers the identifier (IP address or carry the Verify_Id. B discovers the identifier (IP address or
interface index) that A assigns to the TE link by examining the interface index) that A assigns to the TE link by examining the
LOCAL_LINK_ID object carried in the received BeginVerify LOCAL_LINK_ID object carried in the received BeginVerify
message. (If the data ports are not yet assigned to the TE 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 Link, the binding is limited to the Node_Id of A.) In response
to the BeginVerify message, B sends to A the BeginVerifyAck to the BeginVerify message, B sends to A the BeginVerifyAck
message. The LOCAL_LINK_ID object carried in the message. The LOCAL_LINK_ID object carried in the BeginVerifyAck
BeginVerifyAck message is used to carry the identifier (IP message is used to carry the identifier (IP address or
address or interface index) that B assigns to the TE link. The interface index) that B assigns to the TE link. The
REMOTE_LINK_ID object carried in the BeginVerifyAck message is REMOTE_LINK_ID object carried in the BeginVerifyAck message is
used to bind the Link_Ids assigned by both A and B. The used to bind the Link_Ids assigned by both A and B. The
Verify_Id is returned to A in the BeginVerifyAck message over Verify_Id is returned to A in the BeginVerifyAck message over
the control channel. the control channel.
o When A receives the BeginVerifyAck message, it begins o When A receives the BeginVerifyAck message, it begins
transmitting periodic Test messages over the first port transmitting periodic Test messages over the first port
(Interface Id=1). The Test message includes the Interface_Id (Interface Id=1). The Test message includes the Interface_Id
for the port and the Verify_Id that was assigned by B. for the port and the Verify_Id that was assigned by B.
o When B receives the Test messages, it maps the received o When B receives the Test messages, it maps the received
Interface_Id to its own local Interface_Id = 10 and transmits a Interface_Id to its own local Interface_Id = 10 and transmits a
skipping to change at page 20, line 11 skipping to change at page 20, line 17
+---------------------+ +---------------------+ +---------------------+ +---------------------+
Figure 1: Example of link connectivity between Node A and Node B. Figure 1: Example of link connectivity between Node A and Node B.
6. Fault Management 6. Fault Management
In this section, an optional LMP procedure is described that is used In this section, an optional LMP procedure is described that is used
to manage failures by rapid notification of the status of one or 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 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 within a TE link, and as such, the use of this procedure is
negotiated as part of the LinkSummary exchange. The procedure can negotiated as part of the LinkSummary exchange. The procedure can be
be used to rapidly isolate link failures and is designed to work for used to rapidly isolate link failures and is designed to work for
both unidirectional and bi-directional LSPs. both unidirectional and bi-directional LSPs.
An important implication of using transparent devices is that An important implication of using transparent devices is that
traditional methods that are used to monitor the health of allocated traditional methods that are used to monitor the health of allocated
data links in may no longer be appropriate. Instead, fault data links in may no longer be appropriate. Instead, fault detection
detection is delegated to the physical layer (i.e., loss of light or is delegated to the physical layer (i.e., loss of light or optical
optical monitoring of the data) instead of layer 2 or layer 3. monitoring of the data) instead of layer 2 or layer 3.
Recall that a TE link connecting two nodes may consist of a number 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 of data links. If one or more data links fail between two nodes, a
mechanism must be used for rapid failure notification so that mechanism must be used for rapid failure notification so that
appropriate protection/restoration mechanisms can be initiated. If appropriate protection/restoration mechanisms can be initiated. If
the failure is subsequently cleared, then a mechanism must be used the failure is subsequently cleared, then a mechanism must be used
to notify that the failure is clear and the channel status is OK. to notify that the failure is clear and the channel status is OK.
6.1. Fault Detection 6.1. Fault Detection
Fault detection should be handled at the layer closest to the Fault detection should be handled at the layer closest to the
failure; for optical networks, this is the physical (optical) layer. failure; for optical networks, this is the physical (optical) layer.
One measure of fault detection at the physical layer is detecting One measure of fault detection at the physical layer is detecting
loss of light (LOL). Other techniques for monitoring optical loss of light (LOL). Other techniques for monitoring optical signals
signals are still being developed and will not be further considered are still being developed and will not be further considered in this
in this document. However, it should be clear that the mechanism document. However, it should be clear that the mechanism used for
used for fault notification in LMP is independent of the mechanism fault notification in LMP is independent of the mechanism used to
used to detect the failure, but simply relies on the fact that a detect the failure, but simply relies on the fact that a failure is
failure is detected. detected.
6.2. Fault Localization Procedure 6.2. Fault Localization Procedure
In some situations, a data link failure between two nodes is In some situations, a data link failure between two nodes is
propagated downstream such that all the downstream nodes detect the propagated downstream such that all the downstream nodes detect the
failure without localizing the failure. To avoid multiple alarms failure without localizing the failure. To avoid multiple alarms
stemming from the same failure, LMP provides failure notification stemming from the same failure, LMP provides failure notification
through the ChannelStatus message. This message may be used to through the ChannelStatus message. This message may be used to
indicate that a single data channel has failed, multiple data indicate that a single data channel has failed, multiple data
channels have failed, or an entire TE link has failed. Failure channels have failed, or an entire TE link has failed. Failure
skipping to change at page 21, line 27 skipping to change at page 21, line 35
restoration procedures. restoration procedures.
If all of the data links of a TE link have failed, then the upstream 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 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 data link of the failed TE link. This is done by sending failure
notification in a ChannelStatus message identifying the TE Link notification in a ChannelStatus message identifying the TE Link
without including the Interface_Ids in the CHANNEL_STATUS object. without including the Interface_Ids in the CHANNEL_STATUS object.
6.3. Examples of Fault Localization 6.3. Examples of Fault Localization
In Fig. 2, a sample network is shown where four nodes are connected In Figure 2, a sample network is shown where four nodes are
in a linear array configuration. The control channels are bi- connected in a linear array configuration. The control channels are
directional and are labeled with a "c". All LSPs are also bi- bi-directional and are labeled with a "c". All LSPs are also bi-
directional. directional.
In the first example [see Fig. 2(a)], there is a failure on one 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 direction of the bi-directional LSP. Node 4 will detect the failure
and will send a ChannelStatus message to Node 3 indicating the and will send a ChannelStatus message to Node 3 indicating the
failure (e.g., LOL) to the corresponding upstream node. When Node 3 failure (e.g., LOL) to the corresponding upstream node. When Node 3
receives the ChannelStatus message from Node 4, it returns a receives the ChannelStatus message from Node 4, it returns a
ChannelStatusAck message back to Node 4 and correlates the failure ChannelStatusAck message back to Node 4 and correlates the failure
locally. When Node 3 correlates the failure and verifies that the locally. When Node 3 correlates the failure and verifies that the
failure is clear, it has localized the failure to the data link 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 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 ChannelStatus message to Node 4 indicating that the failure has been
localized. localized.
In the second example [see Fig. 2(b)], a single failure (e.g., fiber 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 cut) affects both directions of the bi-directional LSP. Node 2 (Node
(Node 3) will detect the failure of the upstream (downstream) 3) will detect the failure of the upstream (downstream) direction
direction and send a ChannelStatus message to the upstream (in terms and send a ChannelStatus message to the upstream (in terms of data
of data flow) node indicating the failure (e.g., LOL). flow) node indicating the failure (e.g., LOL). Simultaneously
Simultaneously (ignoring propagation delays), Node 1 (Node 4) will (ignoring propagation delays), Node 1 (Node 4) will detect the
detect the failure on the upstream (downstream) direction, and will failure on the upstream (downstream) direction, and will send a
send a ChannelStatus message to the corresponding upstream (in terms ChannelStatus message to the corresponding upstream (in terms of
of data flow) node indicating the failure. Node 2 and Node 3 will data flow) node indicating the failure. Node 2 and Node 3 will have
have localized the two directions of the failure. localized the two directions of the failure.
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+ Node1 + + Node2 + + Node3 + + Node4 + + Node1 + + Node2 + + Node3 + + Node4 +
+ +-- c ---+ +-- c ---+ +-- c ---+ + + +-- c ---+ +-- c ---+ +-- c ---+ +
----+---\ + + + + + + + ----+---\ + + + + + + +
<---+---\\--+--------+-------+---\ + + + /--+---> <---+---\\--+--------+-------+---\ + + + /--+--->
+ \--+--------+-------+---\\---+-------+---##---+---//--+---- + \--+--------+-------+---\\---+-------+---##---+---//--+----
+ + + + \---+-------+--------+---/ + + + + + \---+-------+--------+---/ +
+ + + + + + (a) + + + + + + + + (a) + +
----+-------+--------+---\ + + + + + ----+-------+--------+---\ + + + + +
skipping to change at page 22, line 34 skipping to change at page 22, line 40
LSP fails, (B) two data links corresponding to both LSP fails, (B) two data links corresponding to both
directions of a bi-directional LSP fail. The control channel directions of a bi-directional LSP fail. The control channel
connecting two nodes is indicated with a "c". connecting two nodes is indicated with a "c".
6.4. Channel Activation Indication 6.4. Channel Activation Indication
The ChannelStatus message may also be used to notify an LMP neighbor The ChannelStatus message may also be used to notify an LMP neighbor
that the data link should be actively monitored. This is called that the data link should be actively monitored. This is called
Channel Activation Indication. This is particularly useful in Channel Activation Indication. This is particularly useful in
networks with transparent nodes where the status of data links may networks with transparent nodes where the status of data links may
need to be triggered using control channel messages. For example, need to be triggered using control channel messages. For example, if
if a data link is pre-provisioned and the physical link fails after a data link is pre-provisioned and the physical link fails after
verification and before inserting user traffic, a mechanism is verification and before inserting user traffic, a mechanism is
needed to indicate the data link should be active or the failure may needed to indicate the data link should be active or the failure may
not be able to be detected. not be able to be detected.
The ChannelStatus message is used to indicate that a channel or The ChannelStatus message is used to indicate that a channel or
group of channels are now active. The ChannelStatusAck message MUST group of channels are now active. The ChannelStatusAck message MUST
be transmitted upon receipt of a ChannelStatus message. When a be transmitted upon receipt of a ChannelStatus message. When a
ChannelStatus message is received, the corresponding data link(s) ChannelStatus message is received, the corresponding data link(s)
MUST be put into the Active state. If upon putting them into the MUST be put into the Active state. If upon putting them into the
Active state, a failure is detected, the ChannelStatus message Active state, a failure is detected, the ChannelStatus message
skipping to change at page 23, line 20 skipping to change at page 23, line 27
MESSAGE_ID_ACK objects contain a Message_Id field. MESSAGE_ID_ACK objects contain a Message_Id field.
Only one MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP Only one MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP
message. message.
For control channel specific messages, the Message_Id field is For control channel specific messages, the Message_Id field is
within the scope of the CC_Id. For TE link specific messages, the within the scope of the CC_Id. For TE link specific messages, the
Message_Id field is within the scope of the LMP adjacency. Message_Id field is within the scope of the LMP adjacency.
The Message_Id field of the MESSAGE_ID object contains a generator- The Message_Id field of the MESSAGE_ID object contains a generator-
selected value. This value MUST be monotonically increasing. A selected value. This value MUST be monotonically increasing. A value
value is considered to be previously used when it has been sent in is considered to be previously used when it has been sent in an LMP
an LMP message with the same CC_Id (for control channel specific message with the same CC_Id (for control channel specific messages)
messages) or LMP adjacency (for TE Link specific messages). The or LMP adjacency (for TE Link specific messages). The Message_Id
Message_Id field of the MESSAGE_ID_ACK object contains the field of the MESSAGE_ID_ACK object contains the Message_Id field of
Message_Id field of the message being acknowledged. the message being acknowledged.
Unacknowledged messages sent with the MESSAGE_ID object SHOULD be Unacknowledged messages sent with the MESSAGE_ID object SHOULD be
retransmitted until the message is acknowledged or until a retry retransmitted until the message is acknowledged or until a retry
limit is reached (see also Section 10). limit is reached (see also Section 10).
Note that the 32-bit Message_Id value MAY wrap. The following 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 expression may be used to test if a newly received Message_Id value
is less than a previously received value: is less than a previously received value:
If ((int) old_id - (int) new_id > 0) { If ((int) old_id - (int) new_id > 0) {
skipping to change at page 24, line 31 skipping to change at page 24, line 36
This section describes the mechanism to resynchronize the LMP state This section describes the mechanism to resynchronize the LMP state
after a control plane restart. A control plane restart may occur after a control plane restart. A control plane restart may occur
when bringing up the first control channel after a control when bringing up the first control channel after a control
communications failure. A control communications failure may be the communications failure. A control communications failure may be the
result of an LMP adjacency failure or a nodal failure wherein 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 LMP control state is lost, but the data plane is unaffected. The
latter is detected by setting the "LMP Restart" bit in the Common 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 Header of the LMP messages. When the control plane fails due to the
loss of the control channel, the LMP link information should be loss of the control channel, the LMP link information should be
retained. It is possible that a node may be capable of retaining retained. It is possible that a node may be capable of retaining the
the LMP link information across a nodal failure. However, in both LMP link information across a nodal failure. However, in both cases
cases the status of the data channels MUST be synchronized. the status of the data channels MUST be synchronized.
It is assumed the Local Interface_Ids remain stable across a control It is assumed the Local Interface_Ids remain stable across a control
plane restart. plane restart.
After the control plane of a node restarts, the control channel(s) After the control plane of a node restarts, the control channel(s)
must be re-established using the procedures of Section 3.1. must be re-established using the procedures of Section 3.1.
If the control plane failure was the result of a nodal failure where 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 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 set in LMP messages until a Hello message is received with the
skipping to change at page 24, line 55 skipping to change at page 25, line 8
control channel is up and the LMP neighbor has detected the restart. control channel is up and the LMP neighbor has detected the restart.
The following assumes that the LMP component restart only occurred The following assumes that the LMP component restart only occurred
on one end of the TE Link. If the LMP component restart occurred on 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 both ends of the TE Link, the normal procedures for LinkSummary
should be used, as described in Section 4. should be used, as described in Section 4.
Once a control channel is up, the LMP neighbor MUST send a Once a control channel is up, the LMP neighbor MUST send a
LinkSummary message for each TE Link across the adjacency. All the LinkSummary message for each TE Link across the adjacency. All the
objects of the LinkSummary message MUST have the N-bit set to 0 objects of the LinkSummary message MUST have the N-bit set to 0
indicating that the parameters are non-negotiable. This provides indicating that the parameters are non-negotiable. This provides the
the local/remote Link_Id and Interface_Id mappings, the associated local/remote Link_Id and Interface_Id mappings, the associated data
data link parameters, and indication of which data links are link parameters, and indication of which data links are currently
currently allocated to user traffic. When a node receives the allocated to user traffic. When a node receives the LinkSummary
LinkSummary message, it checks its local configuration. If the node message, it checks its local configuration. If the node is capable
is capable of retaining the LMP link information across a restart, of retaining the LMP link information across a restart, it must
it must process the LinkSummary message as described in Section 4 process the LinkSummary message as described in Section 4 with the
with the exception that the allocated/de-allocated flag of the exception that the allocated/de-allocated flag of the DATA_LINK
DATA_LINK object received in the LinkSummary message MUST take object received in the LinkSummary message MUST take precedence over
precedence over any local value. If, however, the node was not any local value. If, however, the node was not capable of retaining
capable of retaining the LMP link information across a restart, the the LMP link information across a restart, the node MUST accept the
node MUST accept the data link parameters of the received data link parameters of the received LinkSummary message and respond
LinkSummary message and respond with a LinkSummaryAck message. with a LinkSummaryAck message.
Upon completion of the LinkSummary exchange, the node that has Upon completion of the LinkSummary exchange, the node that has
restarted the control plane SHOULD send a ChannelStatusRequest restarted the control plane SHOULD send a ChannelStatusRequest
message for that TE link. The node SHOULD also verify the message for that TE link. The node SHOULD also verify the
connectivity of all unallocated data channels. connectivity of all unallocated data channels.
9. Addressing 9. Addressing
All LMP messages are run over UDP with an LMP port number (except, 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 in some cases, the Test messages which may be limited by the
skipping to change at page 27, line 46 skipping to change at page 27, line 52
ConfRcv: The control channel is in the parameter negotiation ConfRcv: The control channel is in the parameter negotiation
state. In this state, the node is waiting for state. In this state, the node is waiting for
acceptable configuration parameters from the remote acceptable configuration parameters from the remote
side. Once such parameters are received and side. Once such parameters are received and
acknowledged, the FSM can transition to the Active acknowledged, the FSM can transition to the Active
state. state.
Active: In this state the node periodically sends a Hello Active: In this state the node periodically sends a Hello
message and is waiting to receive a valid Hello message and is waiting to receive a valid Hello
message. Once a valid Hello message is received, it message. Once a valid Hello message is received, it can
can transition to the up state. transition to the up state.
Up: The CC is in an operational state. The node receives Up: The CC is in an operational state. The node receives
valid Hello messages and sends Hello messages. valid Hello messages and sends Hello messages.
GoingDown: A CC may go into this state because of administrative GoingDown: A CC may go into this state because of administrative
action. While a CC is in this state, the node sets the action. While a CC is in this state, the node sets the
ControlChannelDown bit in all the messages it sends. ControlChannelDown bit in all the messages it sends.
11.1.2. Control Channel Events 11.1.2. Control Channel Events
Operation of the LMP control channel is described in terms of FSM Operation of the LMP control channel is described in terms of FSM
states and events. Control channel events are generated by the states and events. Control channel events are generated by the
underlying protocols and software modules, as well as by the packet underlying protocols and software modules, as well as by the packet
processing routines and FSMs of associated TE links. Every event processing routines and FSMs of associated TE links. Every event has
has its number and a symbolic name. Description of possible control its number and a symbolic name. Description of possible control
channel events is given below. channel events is given below.
1 : evBringUp: This is an externally triggered event indicating 1 : evBringUp: This is an externally triggered event indicating
that the control channel negotiation should begin. that the control channel negotiation should begin.
This event, for example, may be triggered by an This event, for example, may be triggered by an
operator command, by the successful completion of operator command, by the successful completion of
a control channel bootstrap procedure, or by a control channel bootstrap procedure, or by
configuration. Depending on the configuration, configuration. Depending on the configuration,
this will trigger either this will trigger either
1a) the sending of a Config message, 1a) the sending of a Config message,
skipping to change at page 29, line 12 skipping to change at page 29, line 18
9 : evAdminDown: The administrator has requested that the control 9 : evAdminDown: The administrator has requested that the control
channel is brought down administratively. channel is brought down administratively.
10: evNbrGoesDn: A packet with ControlChannelDown flag is received 10: evNbrGoesDn: A packet with ControlChannelDown flag is received
from the neighbor. from the neighbor.
11: evHelloRcvd: A Hello packet with expected SeqNum has been 11: evHelloRcvd: A Hello packet with expected SeqNum has been
received. received.
12: evHoldTimer: The HelloDeadInterval timer has expired indicating 12: evHoldTimer: The HelloDeadInterval timer has expired indicating
that no Hello packet has been received. This that no Hello packet has been received. This moves
moves the control channel back into the the control channel back into the Negotiation
Negotiation state, and depending on the local state, and depending on the local configuration,
configuration, this will trigger either this will trigger either
12a) the sending of periodic Config messages, 12a) the sending of periodic Config messages,
12b) a period of waiting to receive Config 12b) a period of waiting to receive Config
messages from the remote node. messages from the remote node.
13: evSeqNumErr: A Hello with unexpected SeqNum received and 13: evSeqNumErr: A Hello with unexpected SeqNum received and
discarded. discarded.
14: evReconfig: Control channel parameters have been reconfigured 14: evReconfig: Control channel parameters have been reconfigured
and require renegotiation. and require renegotiation.
skipping to change at page 30, line 7 skipping to change at page 29, line 43
message is resent. message is resent.
16: evHelloRet: The HelloInterval timer has expired and a Hello 16: evHelloRet: The HelloInterval timer has expired and a Hello
packet is sent. packet is sent.
17: evDownTimer: A timer has expired and no messages have been 17: evDownTimer: A timer has expired and no messages have been
received with the ControlChannelDown flag set. received with the ControlChannelDown flag set.
11.1.3. Control Channel FSM Description 11.1.3. Control Channel FSM Description
Figure 3 illustrates operation of the control channel FSM Figure 3 illustrates operation of the control channel FSM in a form
in a form of FSM state transition diagram. of FSM state transition diagram.
+--------+ +--------+
+----------------->| |<--------------+ +----------------->| |<--------------+
| +--------->| Down |<----------+ | | +--------->| Down |<----------+ |
| |+---------| |<-------+ | | | |+---------| |<-------+ | |
| || +--------+ | | | | || +--------+ | | |
| || | ^ 2,9| 2| 2| | || | ^ 2,9| 2| 2|
| ||1b 1a| | | | | | ||1b 1a| | | | |
| || v |2,9 | | | | || v |2,9 | | |
| || +--------+ | | | | || +--------+ | | |
skipping to change at page 33, line 19 skipping to change at page 33, line 15
messages are received through them. For clarity, separate FSMs are messages are received through them. For clarity, separate FSMs are
defined for the active/passive data links; however, a single set of defined for the active/passive data links; however, a single set of
data link states and events are defined. data link states and events are defined.
11.3.1. Data Link States 11.3.1. Data Link States
Any data link can be in one of the states described below. Every Any data link can be in one of the states described below. Every
state corresponds to a certain condition of the data link. state corresponds to a certain condition of the data link.
Down: The data link has not been put in the resource pool Down: The data link has not been put in the resource pool
(i.e., the link is not in service) (i.e., the link is not in service')
Test: The data link is being tested. An LMP Test message Test: The data link is being tested. An LMP Test message is
is periodically sent through the link. periodically sent through the link.
PasvTest: The data link is being checked for incoming test PasvTest: The data link is being checked for incoming test
messages. messages.
Up/Free: The link has been successfully tested and is now put Up/Free: The link has been successfully tested and is now put
in the pool of resources (in-service). The link has in the pool of resources (in-service). The link has
not yet been allocated to data traffic. not yet been allocated to data traffic.
Up/Alloc: The link is up and has been allocated for data Up/Alloc: The link is up and has been allocated for data
traffic. traffic.
skipping to change at page 37, line 7 skipping to change at page 36, line 37
+---------+ | +---------+ |
| |13 | | |13 |
|Up/Alloc |-----+ |Up/Alloc |-----+
| | | |
+---------+ +---------+
Figure 6: Passive LMP Data Link FSM Figure 6: Passive LMP Data Link FSM
12. LMP Message Formats 12. LMP Message Formats
All LMP messages are run over UDP with an LMP port number (except, All LMP messages (except, in some cases, the Test messages which,
in some cases, the Test messages are limited by the transport are limited by the transport mechanism for in-band messaging) are
mechanism for in-band messaging) and run over UDP with port number run over UDP with an LMP port number to be assigned by IANA.
xxx - TBA (to be assigned) by IANA.
12.1. Common Header 12.1. Common Header
In addition to the UDP header and standard IP header, all LMP In addition to the UDP header and standard IP header, all LMP
messages (except, in some cases, the Test messages which may be messages (except, in some cases, the Test messages which may be
limited by the transport mechanism for in-band messaging) have the limited by the transport mechanism for in-band messaging) have the
following common header: following common header:
0 1 2 3 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 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
skipping to change at page 37, line 36 skipping to change at page 37, line 12
The Reserved field should be sent as zero and ignored on receipt. 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 All values are defined in network byte order (i.e., big-endian byte
order). order).
Vers: 4 bits Vers: 4 bits
Protocol version number. This is version 1. Protocol version number. This is version 1.
Flags: 8 bits. The following values are defined. All other values Flags: 8 bits
are reserved and should be sent as zero and ignored on
receipt. The following bit-values are defined. All other bits are
reserved and should be sent as zero and ignored on receipt.
0x01: ControlChannelDown 0x01: ControlChannelDown
0x02: LMP Restart 0x02: LMP Restart
This bit is set to indicate that a nodal failure has This bit is set to indicate that a nodal failure has
occured and the LMP control state has been lost. This occured and the LMP control state has been lost. This
flag may be reset to 0 when a Hello message is received flag may be reset to 0 when a Hello message is received
with RcvSeqNum equal to the local TxSeqNum. with RcvSeqNum equal to the local TxSeqNum.
Msg Type: 8 bits. The following values are defined. All other Msg Type: 8 bits
values are reserved and should be sent as zero and ignored
on receipt. The following values are defined. All other values are reserved
1 = Config 1 = Config
2 = ConfigAck 2 = ConfigAck
3 = ConfigNack 3 = ConfigNack
4 = Hello 4 = Hello
5 = BeginVerify 5 = BeginVerify
6 = BeginVerifyAck 6 = BeginVerifyAck
7 = BeginVerifyNack 7 = BeginVerifyNack
skipping to change at page 41, line 24 skipping to change at page 40, line 52
12.4. Hello Message (Msg Type = 4) 12.4. Hello Message (Msg Type = 4)
The format of the Hello message is as follows: The format of the Hello message is as follows:
<Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO> <Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The Hello message MUST be periodically transmitted at least once The Hello message MUST be periodically transmitted at least once
every HelloInterval msec. If no Hello message is received within every HelloInterval msec. If no Hello message is received within the
the HelloDeadInterval, the control channel is assumed to have HelloDeadInterval, the control channel is assumed to have failed.
failed.
12.5. Link Verification Messages 12.5. Link Verification Messages
12.5.1. BeginVerify Message (Msg Type = 5) 12.5.1. BeginVerify Message (Msg Type = 5)
The BeginVerify message is sent over the control channel and is used The BeginVerify message is sent over the control channel and is used
to initiate the link verification process. The format is as to initiate the link verification process. The format is as follows:
follows:
<BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID> <BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> [<REMOTE_LINK_ID>] <MESSAGE_ID> [<REMOTE_LINK_ID>]
<BEGIN_VERIFY> <BEGIN_VERIFY>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
To limit the scope of Link Verification to a particular TE Link, the 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 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 field is zero, the data links can span multiple TE links and/or they
skipping to change at page 43, line 13 skipping to change at page 42, line 43
BeginVerifyNack message is received with such an ERROR_CODE, the BeginVerifyNack message is received with such an ERROR_CODE, the
node that originated the BeginVerify SHOULD schedule a BeginVerify node that originated the BeginVerify SHOULD schedule a BeginVerify
retransmission after Rf seconds, where Rf is a locally defined retransmission after Rf seconds, where Rf is a locally defined
parameter. parameter.
If the Verification Transport mechanism is not supported, the If the Verification Transport mechanism is not supported, the
ERROR_CODE MUST indicate, "Unsupported verification transport ERROR_CODE MUST indicate, "Unsupported verification transport
mechanism". mechanism".
If remote configuration of the Link_Id is not supported and the If remote configuration of the Link_Id is not supported and the
contents of the REMOTE_LINK_ID object (included in the BeginVerify content of the REMOTE_LINK_ID object (included in the BeginVerify
message) does not match any configured values, the ERROR_CODE MUST message) does not match any configured values, the ERROR_CODE MUST
indicate "Link_Id configuration error". indicate "Link_Id configuration error".
If a node receives a BeginVerify message and recognizes the If a node receives a BeginVerify message and recognizes the
BEGIN_VERIFY object but does not recognize the C-Type, the BEGIN_VERIFY object but does not recognize the C-Type, the
ERROR_CODE MUST indicate, "Unknown object C-Type". ERROR_CODE MUST indicate, "Unknown object C-Type".
12.5.4. EndVerify Message (Msg Type = 8) 12.5.4. EndVerify Message (Msg Type = 8)
The EndVerify message is sent over the control channel and is used The EndVerify message is sent over the control channel and is used
skipping to change at page 46, line 17 skipping to change at page 45, line 48
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The DATA_LINK objects MUST include acceptable values for all The DATA_LINK objects MUST include acceptable values for all
negotiable parameters. If the LinkSummaryNack includes DATA_LINK negotiable parameters. If the LinkSummaryNack includes DATA_LINK
objects for non-negotiable parameters, they MUST be copied from the objects for non-negotiable parameters, they MUST be copied from the
DATA_LINK objects received in the LinkSummary message. DATA_LINK objects received in the LinkSummary message.
If the LinkSummaryNack message is received and only includes If the LinkSummaryNack message is received and only includes
negotiable parameters, then a new LinkSummary message SHOULD be negotiable parameters, then a new LinkSummary message SHOULD be
sent. The values received in the new LinkSummary message SHOULD sent. The values received in the new LinkSummary message SHOULD take
take into account the acceptable parameters included in the into account the acceptable parameters included in the
LinkSummaryNack message. LinkSummaryNack message.
If the LinkSummary message is received with unacceptable non- If the LinkSummary message is received with unacceptable non-
negotiable parameters, the ERROR_CODE MUST indicate "Unacceptable negotiable parameters, the ERROR_CODE MUST indicate "Unacceptable
non-netotiable LINK_SUMMARY parameters." non-netotiable LINK_SUMMARY parameters."
If the LinkSummary message is received with unacceptable negotiable If the LinkSummary message is received with unacceptable negotiable
parameters, the ERROR_CODE MUST indicate "Renegotiate LINK_SUMMARY parameters, the ERROR_CODE MUST indicate "Renegotiate LINK_SUMMARY
parameters." parameters."
If the LinkSummary message is received with an invalid TE_LINK If the LinkSummary message is received with an invalid TE_LINK
object, the ERROR_CODE MUST indicate "Invalid TE_LINK object." object, the ERROR_CODE MUST indicate "Invalid TE_LINK object."
If the LinkSummary message is received with an invalid DATA_LINK If the LinkSummary message is received with an invalid DATA_LINK
object, the ERROR_CODE MUST indicate "Invalid DATA_LINK object." object, the ERROR_CODE MUST indicate "Invalid DATA_LINK object."
skipping to change at page 48, line 9 skipping to change at page 48, line 9
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
ChannelStatusRequest message being acknowledged. ChannelStatusRequest message being acknowledged.
13. LMP Object Definitions 13. LMP Object Definitions
13.1. CCID (Control Channel ID) Class 13.1. CCID (Control Channel ID) Class
Class = 1. Class = 1
o C-Type = 1, LOCAL_CCID o C-Type = 1, LOCAL_CCID
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC_Id: 32 bits CC_Id: 32 bits
skipping to change at page 48, line 37 skipping to change at page 48, line 37
o C-Type = 2, REMOTE_CCID o C-Type = 2, REMOTE_CCID
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC_Id: 32 bits CC_Id: 32 bits
This identifies the remote nodes CC_Id and MUST be non-zero. This identifies the remote node's CC_Id and MUST be non-zero.
This object is non-negotiable. This object is non-negotiable.
13.2. NODE_ID Class 13.2. NODE_ID Class
Class = 2. Class = 2
o C-Type = 1, LOCAL_NODE_ID o C-Type = 1, LOCAL_NODE_ID
0 1 2 3 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 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 (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node_Id: Node_Id:
skipping to change at page 50, line 4 skipping to change at page 49, line 50
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 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) + + Link_Id (16 bytes) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 5, Unnumbered LOCAL_LINK_ID o C-Type = 5, Unnumbered LOCAL_LINK_ID
o C-Type = 6, Unnumbered REMOTE_LINK_ID o C-Type = 6, Unnumbered REMOTE_LINK_ID
0 1 2 3 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 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) | | Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link_Id: Link_Id:
For LOCAL_LINK_ID, this identifies the senders Link associated For LOCAL_LINK_ID, this identifies the sender's Link associated
with the message. This value MUST be non-zero. with the message. This value MUST be non-zero.
For REMOTE_LINK_ID, this identifies the remote nodes Link_Id For REMOTE_LINK_ID, this identifies the remote node's Link_Id
and MUST be non-zero. and MUST be non-zero.
This object is non-negotiable. This object is non-negotiable.
13.4. INTERFACE_ID Class 13.4. INTERFACE_ID Class
Class = 4 Class = 4
o C-Type = 1, IPv4 LOCAL_INTERFACE_ID o C-Type = 1, IPv4 LOCAL_INTERFACE_ID
skipping to change at page 51, line 19 skipping to change at page 51, line 15
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 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface_Id: Interface_Id:
For the LOCAL_INTERFACE_ID, this identifies the data link. For the LOCAL_INTERFACE_ID, this identifies the data link.
This value MUST be node-wide unique and non-zero. This value MUST be node-wide unique and non-zero.
For the REMOTE_INTERFACE_ID, this identifies the remote nodes For the REMOTE_INTERFACE_ID, this identifies the remote node's
data link. The Interface_Id MUST be non-zero. data link. The Interface_Id MUST be non-zero.
This object is non-negotiable. This object is non-negotiable.
13.5. MESSAGE_ID Class 13.5. MESSAGE_ID Class
Class = 5. Class = 5
o C-Type=1, MessageId o C-Type=1, MessageId
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message_Id: Message_Id:
The Message_Id field is used to identify a message. This value The Message_Id field is used to identify a message. This value
is incremented and only decreases when the value wraps. This is incremented and only decreases when the value wraps. This is
is used for message acknowledgment. used for message acknowledgment.
This object is non-negotiable. This object is non-negotiable.
o C-Type = 2, MessageIdAck o C-Type = 2, MessageIdAck
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 52, line 24 skipping to change at page 52, line 17
Class = 6. Class = 6.
o C-Type = 1, HelloConfig o C-Type = 1, HelloConfig
0 1 2 3 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 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 | HelloDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloInterval: 16 bits. HelloInterval: 16 bits
Indicates how frequently the Hello packets will be sent and is Indicates how frequently the Hello packets will be sent and is
measured in milliseconds (ms). measured in milliseconds (ms).
HelloDeadInterval: 16 bits. HelloDeadInterval: 16 bits
If no Hello packets are received within the HelloDeadInterval, If no Hello packets are received within the HelloDeadInterval,
the control channel is assumed to have failed. The the control channel is assumed to have failed. The
HelloDeadInterval is measured in milliseconds (ms). The HelloDeadInterval is measured in milliseconds (ms). The
HelloDeadInterval MUST be greater than the HelloInterval, and HelloDeadInterval MUST be greater than the HelloInterval, and
SHOULD be at least 3 times the value of HelloInterval. SHOULD be at least 3 times the value of HelloInterval.
If the fast keep-alive mechanism of LMP is not used, the If the fast keep-alive mechanism of LMP is not used, the
HelloInterval and HelloDeadInterval MUST be set to zero. HelloInterval and HelloDeadInterval MUST be set to zero.
skipping to change at page 53, line 4 skipping to change at page 52, line 46
o C-Type = 1, Hello o C-Type = 1, Hello
0 1 2 3 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 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 | | TxSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RcvSeqNum | | RcvSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TxSeqNum: 32 bits TxSeqNum: 32 bits
This is the current sequence number for this Hello message. This is the current sequence number for this Hello message.
This sequence number will be incremented when the sequence This sequence number will be incremented when the sequence
number is reflected in the RcvSeqNum of a Hello packet that is number is reflected in the RcvSeqNum of a Hello packet that is
received over the control channel. received over the control channel.
TxSeqNum=0 is not allowed. TxSeqNum=0 is not allowed.
TxSeqNum=1 is used to indicate that the this is the first Hello TxSeqNum=1 is used to indicate that this is the first Hello
message sent over the control channel. message sent over the control channel.
RcvSeqNum: 32 bits RcvSeqNum: 32 bits
This is the sequence number of the last Hello message received This is the sequence number of the last Hello message received
over the control channel. RcvSeqNum=0 is used to indicate that over the control channel. RcvSeqNum=0 is used to indicate that
a Hello message has not yet been received. a Hello message has not yet been received.
This object is non-negotiable. This object is non-negotiable.
13.8. BEGIN_VERIFY Class 13.8. BEGIN_VERIFY Class
Class = 8. Class = 8
o C-Type = 1 o C-Type = 1
0 1 2 3 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 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 | | Flags | VerifyInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Data Links | | Number of Data Links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 53, line 50 skipping to change at page 53, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength | | Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt. The Reserved field should be sent as zero and ignored on receipt.
Flags: 16 bits Flags: 16 bits
The following flags are defined: The following flags are defined:
0x01 Verify all Links 0x0001 Verify all Links
If this bit is set, the verification process checks all If this bit is set, the verification process checks all
unallocated links; else it only verifies new ports or unallocated links; else it only verifies new ports or
component links that are to be added to this TE link. component links that are to be added to this TE link.
0x02 Data Link Type 0x0002 Data Link Type
If set, the data links to be verified are ports, If set, the data links to be verified are ports,
otherwise they are component links otherwise they are component links
VerifyInterval: 16 bits VerifyInterval: 16 bits
This is the interval between successive Test messages and is This is the interval between successive Test messages and is
measured in milliseconds (ms). measured in milliseconds (ms).
Number of Data Links: 32 bits Number of Data Links: 32 bits
This is the number of data links that will be verified. This is the number of data links that will be verified.
EncType: 8 bits EncType: 8 bits
This is the encoding type of the data link. The defined This is the encoding type of the data link. The defined EncType
EncType values are consistent with the LSP Encoding Type values values are consistent with the LSP Encoding Type values of
of [GMPLS-SIG]. [RFC3471].
Verify Transport Mechanism: 16 bits Verify Transport Mechanism: 16 bits
This defines the transport mechanism for the Test Messages. This defines the transport mechanism for the Test Messages.
The scope of this bit mask is restricted to each encoding type. The scope of this bit mask is restricted to each encoding type.
The local node will set the bits corresponding to the various The local node will set the bits corresponding to the various
mechanisms it can support for transmitting LMP test messages. mechanisms it can support for transmitting LMP test messages.
The receiver chooses the appropriate mechanism in the The receiver chooses the appropriate mechanism in the
BeginVerifyAck message. BeginVerifyAck message.
skipping to change at page 55, line 9 skipping to change at page 54, line 52
is capable of transmitting multiple wavelengths (e.g., a fiber is capable of transmitting multiple wavelengths (e.g., a fiber
or waveband-capable port), it is essential to know which or waveband-capable port), it is essential to know which
wavelength the test messages will be transmitted over. This wavelength the test messages will be transmitted over. This
value corresponds to the wavelength at which the Test messages value corresponds to the wavelength at which the Test messages
will be transmitted over and has local significance. If there will be transmitted over and has local significance. If there
is no ambiguity as to the wavelength over which the message is no ambiguity as to the wavelength over which the message
will be sent, then this value SHOULD be set to 0. will be sent, then this value SHOULD be set to 0.
13.9. BEGIN_VERIFY_ACK Class 13.9. BEGIN_VERIFY_ACK Class
Class = 9. Class = 9
o C-Type = 1 o C-Type = 1
0 1 2 3 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 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 | | VerifyDeadInterval | Verify_Transport_Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VerifyDeadInterval: 16 bits VerifyDeadInterval: 16 bits
If a Test message is not detected within the If a Test message is not detected within the
VerifyDeadInterval, then a node will send the TestStatusFailure VerifyDeadInterval, then a node will send the TestStatusFailure
skipping to change at page 55, line 37 skipping to change at page 55, line 28
The recipient of the BeginVerify message (and the future The recipient of the BeginVerify message (and the future
recipient of the TEST messages) chooses the transport mechanism recipient of the TEST messages) chooses the transport mechanism
from the various types that are offered by the transmitter of from the various types that are offered by the transmitter of
the Test messages. One and only one bit MUST be set in the the Test messages. One and only one bit MUST be set in the
verification transport response. verification transport response.
This object is non-negotiable. This object is non-negotiable.
13.10. VERIFY_ID Class 13.10. VERIFY_ID Class
Class = 10. Class = 10
o C-Type = 1 o C-Type = 1
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Verify_Id: 32 bits Verify_Id: 32 bits
This is used to differentiate Test messages from different TE This is used to differentiate Test messages from different TE
links and/or LMP peers. This is a node-unique value that is links and/or LMP peers. This is a node-unique value that is
assigned by the recipient of the BeginVerify message. assigned by the recipient of the BeginVerify message.
This object is non-negotiable. This object is non-negotiable.
13.11. TE_LINK Class 13.11. TE_LINK Class
Class = 11. Class = 11
o C-Type = 1, IPv4 TE_LINK o C-Type = 1, IPv4 TE_LINK
0 1 2 3 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 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) | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) | | Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 57, line 4 skipping to change at page 56, line 47
0 1 2 3 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 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) | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) | | Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) | | Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt. The Reserved field should be sent as zero and ignored on receipt.
Flags: 8 bits Flags: 8 bits
The following flags are defined. All other values are reserved
and should be sent as zero and ignored on receipt. 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. 0x01 Fault Management Supported.
0x02 Link Verification Supported. 0x02 Link Verification Supported.
Local_Link_Id: Local_Link_Id:
This identifies the nodes local Link_Id and MUST be non-zero. This identifies the node's local Link_Id and MUST be non-zero.
Remote_Link_Id: Remote_Link_Id:
This identifies the remote nodes Link_Id and MUST be non-zero. This identifies the remote node's Link_Id and MUST be non-zero.
13.12. DATA_LINK Class 13.12. DATA_LINK Class
Class = 12. Class = 12
o C-Type = 1, IPv4 DATA_LINK o C-Type = 1, IPv4 DATA_LINK
0 1 2 3 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 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) | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) | | Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 58, line 52 skipping to change at page 58, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Subobjects) // // (Subobjects) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt. The Reserved field should be sent as zero and ignored on receipt.
Flags: 8 bits Flags: 8 bits
The following flags are defined. All other values are reserved The following flags are defined. All other bit-values are
and should be sent as zero and ignored on receipt. reserved and should be sent as zero and ignored on receipt.
0x01 Interface Type: If set, the data link is a port, 0x01 Interface Type: If set, the data link is a port,
otherwise it is a component link. otherwise it is a component link.
0x02 Allocated Link: If set, the data link is currently 0x02 Allocated Link: If set, the data link is currently
allocated for user traffic. If a single allocated for user traffic. If a single
Interface_Id is used for both the Interface_Id is used for both the
transmit and receive data links, then transmit and receive data links, then
this bit only applies to the transmit this bit only applies to the transmit
interface. interface.
0x04 Failed Link: If set, the data link is failed and not 0x04 Failed Link: If set, the data link is failed and not
suitable for user traffic. suitable for user traffic.
Local_Interface_Id: Local_Interface_Id:
This is the local identifier of the data link. This MUST be This is the local identifier of the data link. This MUST be
node-wide unique and non-zero. node-wide unique and non-zero.
Remote_Interface_Id: Remote_Interface_Id:
skipping to change at page 59, line 30 skipping to change at page 59, line 9
Remote_Interface_Id: Remote_Interface_Id:
This is the remote identifier of the data link. This MUST be This is the remote identifier of the data link. This MUST be
non-zero. non-zero.
Subobjects Subobjects
The contents of the DATA_LINK object consist of a series of The contents of the DATA_LINK object consist of a series of
variable-length data items called subobjects. The subobjects variable-length data items called subobjects. The subobjects
are defined in section 13.12.1 below. are defined in Section 13.12.1 below.
A DATA_LINK object may contain more than one subobject. More than A DATA_LINK object may contain more than one subobject. More than
one subobject of the same Type may appear if multiple capabilities one subobject of the same Type may appear if multiple capabilities
are supported over the data link. are supported over the data link.
13.12.1. Data Link Subobjects 13.12.1. Data Link Subobjects
The contents of the DATA_LINK object include a series of variable- The contents of the DATA_LINK object include a series of variable-
length data items called subobjects. Each subobject has the form: length data items called subobjects. Each subobject has the form:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//------------ -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
| Type | Length | (Subobject contents) | | Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+
Type: 8 bits Type: 8 bits
The Type indicates the type of contents of the subobject. The Type indicates the type of contents of the subobject.
Currently defined values are: Currently defined values are:
Type = 1, Interface Switching Type Type = 1, Interface Switching Type
skipping to change at page 60, line 23 skipping to change at page 60, line 4
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 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 | | Type | Length | Switching Type| EncType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Reservable Bandwidth | | Minimum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Reservable Bandwidth | | Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Switching Type: 8 bits Switching Type: 8 bits
This is used to identify the local Interface Switching Type of This is used to identify the local Interface Switching Type of
the TE link as defined in [GMPLS-SIG]. the TE link as defined in [RFC3471].
EncType: 8 bits EncType: 8 bits
This is the encoding type of the data link. The defined This is the encoding type of the data link. The defined EncType
EncType values are consistent with the LSP Encoding Type values values are consistent with the LSP Encoding Type values of
of [GMPLS-SIG]. [RFC3471].
Minimum Reservable Bandwidth: 32 bits Minimum Reservable Bandwidth: 32 bits
This is measured in bytes per second and represented in IEEE This is measured in bytes per second and represented in IEEE
floating point format. floating point format.
Maximum Reservable Bandwidth: 32 bits Maximum Reservable Bandwidth: 32 bits
This is measured in bytes per second and represented in IEEE This is measured in bytes per second and represented in IEEE
floating point format. floating point format.
skipping to change at page 62, line 54 skipping to change at page 62, line 12
// : // // : //
| : | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) | | Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel_Status | |A|D| Channel_Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Active bit: 1 bit Active bit: 1 bit
This indicates that the Channel is allocated to user traffic and the This indicates that the Channel is allocated to user traffic
data link should be actively monitored. and the data link should be actively monitored.
Direction bit: 1 bit Direction bit: 1 bit
This indicates the direction (transmit/receive) of the data channel This indicates the direction (transmit/receive) of the data
referred to in the CHANNEL_STATUS object. If set, this indicates channel referred to in the CHANNEL_STATUS object. If set, this
the data channel is in the transmit direction. indicates the data channel is in the transmit direction.
Channel_Status: 30 bits Channel_Status: 30 bits
This indicates the status condition of a data channel. The This indicates the status condition of a data channel. The
following values are defined. All other values are reserved following values are defined. All other values are reserved.
and should be sent as zero and ignored on receipt.
1 Signal Okay (OK): Channel is operational 1 Signal Okay (OK): Channel is operational
2 Signal Degrade (SD): A soft failure caused by a BER 2 Signal Degrade (SD): A soft failure caused by a BER
exceeding a preselected threshold. The specific exceeding a preselected threshold. The specific BER
BER used to define the threshold is configured. used to define the threshold is configured.
3 Signal Fail (SF): A hard signal failure including (but not 3 Signal Fail (SF): A hard signal failure including (but not
limited to) loss of signal (LOS), loss of frame limited to) loss of signal (LOS), loss of frame
(LOF), or Line AIS. (LOF), or Line AIS.
This object contains one or more Interface_Ids followed by a This object contains one or more Interface_Ids followed by a
Channel_Status field. Channel_Status field.
To indicate the status of the entire TE Link, there MUST only be one To indicate the status of the entire TE Link, there MUST only be one
Interface_Id and it MUST be zero. Interface_Id and it MUST be zero.
skipping to change at page 65, line 7 skipping to change at page 64, line 15
This object contains one or more Interface_Ids. This object contains one or more Interface_Ids.
The Length of this object is 4 + 4N in bytes, where N is the number The Length of this object is 4 + 4N in bytes, where N is the number
of Interface_Ids. of Interface_Ids.
This object is non-negotiable. This object is non-negotiable.
13.15. ERROR_CODE Class 13.15. ERROR_CODE Class
Class = 20. Class = 20
o C-Type = 1, BEGIN_VERIFY_ERROR o C-Type = 1, BEGIN_VERIFY_ERROR
0 1 2 3 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 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 | | ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bit-values are defined in network byte order The following bit-values are defined in network byte order
(i.e., big-endian byte order): (i.e., big-endian byte order):
0x01 = Link Verification Procedure not supported. 0x01 = Link Verification Procedure not supported.
0x02 = Unwilling to verify. 0x02 = Unwilling to verify.
0x04 = Unsupported verification transport mechanism. 0x04 = Unsupported verification transport mechanism.
0x08 = Link_Id configuration error. 0x08 = Link_Id configuration error.
0x10 = Unknown object C-Type. 0x10 = Unknown object C-Type.
All other values are reserved and should be sent as zero and All other bit-values are reserved and should be sent as zero
ignored on receipt. and ignored on receipt.
Multiple bits may be set to indicate multiple errors. Multiple bits may be set to indicate multiple errors.
This object is non-negotiable. This object is non-negotiable.
If a BeginVerifyNack message is received with Error Code 2, the node If a BeginVerifyNack message is received with Error Code 2, the node
that originated the BeginVerify SHOULD schedule a BeginVerify that originated the BeginVerify SHOULD schedule a BeginVerify
retransmission after Rf seconds, where Rf is a locally defined retransmission after Rf seconds, where Rf is a locally defined
parameter. parameter.
skipping to change at page 66, line 5 skipping to change at page 65, line 12
The following bit-values are defined in network byte order The following bit-values are defined in network byte order
(i.e., big-endian byte order): (i.e., big-endian byte order):
0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters. 0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters.
0x02 = Renegotiate LINK_SUMMARY parameters. 0x02 = Renegotiate LINK_SUMMARY parameters.
0x04 = Invalid TE_LINK Object. 0x04 = Invalid TE_LINK Object.
0x08 = Invalid DATA_LINK Object. 0x08 = Invalid DATA_LINK Object.
0x10 = Unknown TE_LINK object C-Type. 0x10 = Unknown TE_LINK object C-Type.
0x20 = Unknown DATA_LINK object C-Type. 0x20 = Unknown DATA_LINK object C-Type.
All other values are reserved and should be sent as zero and All other bit-values are reserved and should be sent as zero
ignored on receipt. and ignored on receipt.
Multiple bits may be set to indicate multiple errors. Multiple bits may be set to indicate multiple errors.
This object is non-negotiable. This object is non-negotiable.
14. Intellectual Property Considerations 14. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
skipping to change at page 66, line 40 skipping to change at page 65, line 47
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering," (work in progress). MPLS Traffic Engineering," (work in progress).
[GMPLS-SIG] Ashwood-Smith, P., Banerjee, A., et al, "Generalized
MPLS - Signaling Functional Description," (work in
progress).
[GMPLS-RTG] Kompella, K., Rekhter, Y. et al, "Routing Extensions in [GMPLS-RTG] Kompella, K., Rekhter, Y. et al, "Routing Extensions in
Support of Generalized MPLS", (work in progress). Support of Generalized MPLS," (work in progress).
[RFC2961] Berger, L., Gan, D., et al, "RSVP Refresh Overhead [RFC2961] Berger, L., Gan, D., et al, "RSVP Refresh Overhead
Reduction Extensions," RFC 2961, April 2001. Reduction Extensions," RFC 2961, April 2001.
[RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", RFC
2402, November 1998 [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header," RFC
2402, November 1998.
[RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998 Payload (ESP)," RFC 2406, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of [RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998 Interpretation for ISAKMP," RFC 2407, November 1998
[RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange
(IKE)", RFC 2409, November 1998 (IKE)," RFC 2409, November 1998.
[RFC3471] Ashwood-Smith, P., Banerjee, A., et al, "Generalized
MPLS - Signaling Functional Description," RFC 3473,
January 2003.
15.2. Informative References 15.2. Informative References
[RFC3209] Awduche, D. O., Berger, L, et al, "Extensions to RSVP
for LSP Tunnels," Internet Draft, RFC3209 December 2001.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF," (work in progress). Extensions to OSPF," (work in progress).
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering," (work in progress). Engineering," (work in progress).
[RFC2401] Kent, S., Atkinson, R., "Security Architecture for the [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998 Internet Protocol," RFC 2401, November 1998
[RFC2434] Narten, T. and Alvestrand, H., "Guidelines for Writing [RFC2434] Narten, T. and Alvestrand, H., "Guidelines for Writing
an IANA Considerations Section in RFCs," RFC 2434, an IANA Considerations Section in RFCs," RFC 2434,
October 1998. October 1998.
[RFC3209] Awduche, D. O., Berger, L, et al, "Extensions to RSVP
for LSP Tunnels," Internet Draft, RFC 3209, December
2001.
16. Security Considerations 16. Security Considerations
There are number of attacks that an LMP protocol session can There are number of attacks that an LMP protocol session can
potentially experience. Some examples include: potentially experience. Some examples include:
o an adversary may spoof control packets o an adversary may spoof control packets
o an adversary may modify the control packets in transit o an adversary may modify the control packets in transit
o an adversary may replay control packets o an adversary may replay control packets
skipping to change at page 67, line 43 skipping to change at page 67, line 12
becomes easy for the adversary to discover the key using becomes easy for the adversary to discover the key using
simple tools. simple tools.
This section specifies an IPsec-based security mechanism for LMP. This section specifies an IPsec-based security mechanism for LMP.
16.1. Security Requirements 16.1. Security Requirements
The following requirements are applied to the mechanism described in The following requirements are applied to the mechanism described in
this section. this section.
o LMP security MUST be able to provide authentication, integrity o LMP security MUST be able to provide authentication,
and replay protection. integrity and replay protection.
o For LMP traffic, confidentiality is not needed. Only o For LMP traffic, confidentiality is not needed. Only
authentication is needed to ensure the control packets authentication is needed to ensure the control packets
(packets sent along the LMP Control Channel) are originating (packets sent along the LMP Control Channel) are originating
from the right place and have not been modified in transit. from the right place and have not been modified in transit.
LMP Test packets exchanged through the data links do not need LMP Test packets exchanged through the data links do not need
to be protected. to be protected.
o Security mechanism should provide for well defined key o Security mechanism should provide for well defined key
management schemes. The key management schemes should be well management schemes. The key management schemes should be well
analyzed to be cryptographically secure. The key management analyzed to be cryptographically secure. The key management
schemes should be scalable. schemes should be scalable.
o The algorithms used for authentication MUST be o The algorithms used for authentication MUST be
cryptographically sound. Also the security protocol MUST cryptographically sound. Also the security protocol MUST
allow for negotiating and using different authentication allow for negotiating and using different authentication
algorithms. algorithms.
16.2. Security Mechanisms 16.2. Security Mechanisms
IPsec is a protocol suite that is used to secure communication at the IPsec is a protocol suite that is used to secure communication at
network layer between two peers. This protocol is comprised of IP the network layer between two peers. This protocol is comprised of
Security architecture document [RFC2401], IKE [RFC2409], IPsec AH IP Security architecture document [RFC2401], IKE [RFC2409], IPsec AH
[RFC2402], and IPsec ESP [RFC2406]. IKE is the key management [RFC2402], and IPsec ESP [RFC2406]. IKE is the key management
protocol for IP networks while AH and ESP are used to protect IP protocol for IP networks while AH and ESP are used to protect IP
traffic. IKE is defined specific to IP domain of interpretation. traffic. IKE is defined specific to IP domain of interpretation.
Considering the requirements described in Section 16.1, it is Considering the requirements described in Section 16.1, it is
recommended that where security is needed for LMP, implementations recommended that where security is needed for LMP, implementations
use IPsec as described below: use IPsec as described below:
1. IPsec AH, tunnel mode SHOULD be used for packet authentication. 1. IPsec AH, tunnel mode SHOULD be used for packet authentication.
2. IKE [RFC2409] SHOULD be used as the key exchange mechanism. 2. IKE [RFC2409] SHOULD be used as the key exchange mechanism.
Implementations of LMP over IPsec protocol MUST support manual keying Implementations of LMP over IPsec protocol MUST support manual
mode and dynamic key exchange protocol using IKE. IKE implementation keying mode and dynamic key exchange protocol using IKE. IKE
SHOULD use the IPsec DOI [RFC2407]. implementation SHOULD use the IPsec DOI [RFC2407].
For IKE protocol, the identities of the SAs negotiated in Quick Mode For IKE protocol, the identities of the SAs negotiated in Quick Mode
represent the traffic that the peers agree to protect and are represent the traffic that the peers agree to protect and are
comprised of address space, protocol and port information. For LMP comprised of address space, protocol and port information. For LMP
over IPsec, it is recommended that the identity payload contain the over IPsec, it is recommended that the identity payload contain the
following information. The identities SHOULD be of type IP following information. The identities SHOULD be of type IP addresses
addresses and the value of the identities SHOULD be the IP addresses and the value of the identities SHOULD be the IP addresses of the
of the communicating peers. The protocol field SHOULD be IP protocol communicating peers. The protocol field SHOULD be IP protocol UDP
UDP (17). The port field SHOULD be set to zero to indicate port (17). The port field SHOULD be set to zero to indicate port fields
fields should be ignored. In LMP exchanges, the channel identifier should be ignored. In LMP exchanges, the channel identifier user by
user by the peer is not known beforehand, and hence cannot be used in the peer is not known beforehand, and hence cannot be used in the
the SA. This restriction implies that LMP authentication is SA. This restriction implies that LMP authentication is performed on
performed on a per LMP neighbor basis rather than on a per LMP a per LMP neighbor basis rather than on a per LMP control channel
control channel basis between two neighbors. basis between two neighbors.
All LMP messages are expected to be sent over the IPsec channel. The All LMP messages are expected to be sent over the IPsec channel. The
crypto channel (IKE SA and IPsec SAs) may be established on need crypto channel (IKE SA and IPsec SAs) may be established on need
basis or earlier. However, all LMP messages should be sent through basis or earlier. However, all LMP messages should be sent through
the crypto channel. the crypto channel.
A set of control channels can share the same crypto channel. When 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 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 is important to keep in mind that the keep-alive failure in a
channel may also be due to failure in the crypto channel. The control channel may also be due to failure in the crypto channel.
following method is recommended to ensure LMP communication path The following method is recommended to ensure LMP communication path
between two peers is working properly. between two peers is working properly.
- If LMP Hellos detect a failure on a control channel, switch to an - If LMP Hellos detect a failure on a control channel, switch to
alternate (backup) control channel and/or try to bring up a new an alternate (backup) control channel and/or try to bring up a
control channel. new control channel.
- Ensure the health of the control channels using LMP Hellos. If - Ensure the health of the control channels using LMP Hellos. If
all control channels indicate a failure and it is not possible to all control channels indicate a failure and it is not possible
bring up a new control channel, tear down all existing control to bring up a new control channel, tear down all existing
channels. Also tear down the crypto channel (both the IKE SA and control channels. Also tear down the crypto channel (both the
IPsec SAs). IKE SA and IPsec SAs).
- Reestablish the crypto channel. Failure to establish a crypto - Reestablish the crypto channel. Failure to establish a crypto
channel indicates a fatal failure for LMP communication. channel indicates a fatal failure for LMP communication.
- Bring up the control channel. Failure to bring up the control - Bring up the control channel. Failure to bring up the control
channel indicates a fatal failure for LMP communication. channel indicates a fatal failure for LMP communication.
o When LMP peers are dynamically discovered (particularly the o When LMP peers are dynamically discovered (particularly the
initiator), the following points should be noted if pre-shared initiator), the following points should be noted if pre-
key based authentication is used for setting up the crypto shared key based authentication is used for setting up the
channels. When using pre-shared key based authentication, the crypto channels. When using pre-shared key based
pre-shared key is required to compute the value of SKEYID authentication, the pre-shared key is required to compute the
(used for deriving keys to encrypt messages during key value of SKEYID (used for deriving keys to encrypt messages
exchange). In main mode, pre-shared key to be used has to be during key exchange). In main mode, pre-shared key to be used
identified from information in the IP header since SKEYID is has to be identified from information in the IP header since
calculated prior to the receipt of identification payloads. SKEYID is calculated prior to the receipt of identification
This is not possible if the IP addresses of the peer are payloads. This is not possible if the IP addresses of the
discovered dynamically. Aggressive mode of key exchange can peer are discovered dynamically. Aggressive mode of key
be used since identification payloads are sent in the first exchange can be used since identification payloads are sent
message. in the first message.
Note however that aggressive mode is prone to passive denial of Note however that aggressive mode is prone to passive denial of
service attacks. We also strongly discourage using a shared secret service attacks. We also strongly discourage using a shared secret
(group shared secret) among a number of peers as this opens up the (group shared secret) among a number of peers as this opens up the
solution to man-in-the middle attacks. solution to man-in-the middle attacks.
Digital signature based authentication is not prone to such problems. Digital signature based authentication is not prone to such
It is recommended using digital signature based authentication problems. It is recommended using digital signature based
mechanism where possible. If pre-shared key based authentication is authentication mechanism where possible. If pre-shared key based
required, then aggressive mode SHOULD be used. IKE pre-shared authentication is required, then aggressive mode SHOULD be used.
authentication key values SHOULD be protected in a manner similar to IKE pre-shared authentication key values SHOULD be protected in a
the user's account password. manner similar to the user's account password.
17. IANA Considerations 17. IANA Considerations
LMP requires that a UDP port number be assigned. LMP requires that a UDP port number be assigned.
LMP defines the following name spaces that require management: LMP defines the following name spaces that require management:
- LMP Message Type. - LMP Message Type.
- LMP Object Class. - LMP Object Class.
- LMP Object Class type (C-Type). These are unique within the - LMP Object Class type (C-Type). These are unique within the
Object Class. Object Class.
- LMP Sub-object Class type (Type). These are unique within the - LMP Sub-object Class type (Type). These are unique within the
Object Class. Object Class.
The LMP Message Type name space should be allocated as follows: The LMP Message Type name space should be allocated as follows:
pursuant to the policies outlined in [RFC2434], the numbers in the pursuant to the policies outlined in [RFC2434], the numbers in the
range 0-127 are allocated by Expert Review, 128-240 are allocated range 0-127 are allocated by Standards Action, 128-240 are allocated
through an IETF Consensus action, and 241-255 are reserved for through an Expert Review, and 241-255 are reserved for Private Use.
Private Use.
The LMP Object Class name space should be allocated as follows: The LMP Object Class name space should be allocated as follows:
pursuant to the policies outlined in [RFC2434], the numbers in the pursuant to the policies outlined in [RFC2434], the numbers in the
range of 0-127 are allocated by Expert Review, 128-247 are allocated range of 0-127 are allocated by Standards Action, 128-247 are
through an IETF Consensus action, and 248-255 are reserved for allocated through an Expert Review, and 248-255 are reserved for
Private Use. Private Use.
The LMP Sub-object Class name space should be allocated as follows: The LMP Sub-object Class name space should be allocated as follows:
pursuant to the policies outlined in [RFC2434], the numbers in the pursuant to the policies outlined in [RFC2434], the numbers in the
range of 0-127 are allocated by Expert Review, 128-247 are allocated range of 0-127 are allocated by Standards Action, 128-247 are
through an IETF Consensus action, and 248-255 are reserved for allocated through an Expert Review, and 248-255 are reserved for
Private Use. Private Use.
The LMP Object Class type name space should be allocated as follows: The LMP Object Class type name space should be allocated as follows:
pursuant to the policies outlined in [RFC2434], the numbers in the pursuant to the policies outlined in [RFC2434], the numbers in the
range 0-111 are allocated by Expert Review, 112-119 are allocated range 0-111 are allocated by Standards Action, 112-119 are allocated
through an IETF Consensus action, and 120-127 are reserved for through an Expert Review, and 120-127 are reserved for Private Use.
Private Use.
The following name spaces need to be assigned initially: The following name spaces need to be assigned initially:
[Note to RFC Editor: Please drop all text enclosed in parentheses in [Note to RFC Editor: Please drop all text enclosed in parentheses in
this section once the IANA assignments are made. The values are this section once the IANA assignments are made. The values are
included for reference only and should be considered unassigned.] included for reference only and should be considered unassigned.]
------------------------------------------------------------------ ------------------------------------------------------------------
LMP Message Type name space LMP Message Type name space
skipping to change at page 71, line 46 skipping to change at page 71, line 15
o NODE_ID Class name (suggested = 2) o NODE_ID Class name (suggested = 2)
- LOCAL_NODE_ID (suggested C-Type = 1) - LOCAL_NODE_ID (suggested C-Type = 1)
- REMOTE_NODE_ID (suggested C-Type = 2) - REMOTE_NODE_ID (suggested C-Type = 2)
o LINK_ID Class name (suggested = 3) o LINK_ID Class name (suggested = 3)
- IPv4 LOCAL_LINK_ID (suggested C-Type = 1) - IPv4 LOCAL_LINK_ID (suggested C-Type = 1)
- IPv4 REMOTE_LINK_ID (suggested C-Type = 2) - IPv4 REMOTE_LINK_ID (suggested C-Type = 2)
- IPv6 LOCAL_LINK_ID (suggested C-Type = 3) - IPv6 LOCAL_LINK_ID (suggested C-Type = 3)
- IPv6 REMOTE_LINK_ID (suggested C-Type = 4) - IPv6 REMOTE_LINK_ID (suggested C-Type = 4)
- unnumbered LOCAL_LINK_ID (suggested C-Type = 5) - Unnumbered LOCAL_LINK_ID (suggested C-Type = 5)
- unnumbered REMOTE_LINK_ID (suggested C-Type = 6) - Unnumbered REMOTE_LINK_ID (suggested C-Type = 6)
o INTERFACE_ID Class name (suggested = 4) o INTERFACE_ID Class name (suggested = 4)
- IPv4 LOCAL_INTERFACE_ID (suggested C-Type = 1) - IPv4 LOCAL_INTERFACE_ID (suggested C-Type = 1)
- IPv4 REMOTE_INTERFACE_ID (suggested C-Type = 2) - IPv4 REMOTE_INTERFACE_ID (suggested C-Type = 2)
- IPv6 LOCAL_INTERFACE_ID (suggested C-Type = 3) - IPv6 LOCAL_INTERFACE_ID (suggested C-Type = 3)
- IPv6 REMOTE_INTERFACE_ID (suggested C-Type = 4) - IPv6 REMOTE_INTERFACE_ID (suggested C-Type = 4)
- unnumbered LOCAL_INTERFACE_ID (suggested C-Type = 5) - Unnumbered LOCAL_INTERFACE_ID (suggested C-Type = 5)
- unnumbered REMOTE_INTERFACE_ID (suggested C-Type = 6) - Unnumbered REMOTE_INTERFACE_ID (suggested C-Type = 6)
o MESSAGE_ID Class name (suggested = 5) o MESSAGE_ID Class name (suggested = 5)
- MESSAGE_ID (suggested C-Type = 1) - MESSAGE_ID (suggested C-Type = 1)
- MESSAGE_ID_ACK (suggested C-Type = 2) - MESSAGE_ID_ACK (suggested C-Type = 2)
o CONFIG_ID Class name (suggested = 6) o CONFIG Class name (suggested = 6)
- HELLO_CONFIG (suggested C-Type = 1) - HELLO_CONFIG (suggested C-Type = 1)
o HELLO Class name (suggested = 7) o HELLO Class name (suggested = 7)
- HELLO (suggested C-Type = 1) - HELLO (suggested C-Type = 1)
o BEGIN_VERIFY Class name (suggested = 8) o BEGIN_VERIFY Class name (suggested = 8)
- Type 1 (suggested C-Type = 1) - Type 1 (suggested C-Type = 1)
o BEGIN_VERIFY_ACK Class name (suggested = 9) o BEGIN_VERIFY_ACK Class name (suggested = 9)
- Type 1 (suggested C-Type = 1) - Type 1 (suggested C-Type = 1)
o VERIFY_ID Class name (suggested = 10) o VERIFY_ID Class name (suggested = 10)
- Type 1 (suggested C-Type = 1) - Type 1 (suggested C-Type = 1)
o TE_LINK Class name (suggested = 11) o TE_LINK Class name (suggested = 11)
- IPv4 TE_LINK (suggested C-Type = 1) - IPv4 TE_LINK (suggested C-Type = 1)
- IPv6 TE_LINK (suggested C-Type = 2) - IPv6 TE_LINK (suggested C-Type = 2)
- unnumbered TE_LINK (suggested C-Type = 3) - Unnumbered TE_LINK (suggested C-Type = 3)
o DATA_LINK Class name (suggested = 12) o DATA_LINK Class name (suggested = 12)
- IPv4 DATA_LINK (suggested C-Type = 1) - IPv4 DATA_LINK (suggested C-Type = 1)
- IPv6 DATA_LINK (suggested C-Type = 2) - IPv6 DATA_LINK (suggested C-Type = 2)
- unnumbered DATA_LINK (suggested C-Type = 3) - Unnumbered DATA_LINK (suggested C-Type = 3)
- Interface Switching Type (suggested sub-object Type = 1) - Interface Switching Type (suggested sub-object Type = 1)
- Wavelength (suggested sub-object Type = 2) - Wavelength (suggested sub-object Type = 2)
o CHANNEL_STATUS Class name (suggested = 13) o CHANNEL_STATUS Class name (suggested = 13)
- IPv4 INTERFACE_ID (suggested C-Type = 1) - IPv4 INTERFACE_ID (suggested C-Type = 1)
- IPv6 INTERFACE_ID (suggested C-Type = 2) - IPv6 INTERFACE_ID (suggested C-Type = 2)
- unnumbered INTERFACE_ID (suggested C-Type = 3) - Unnumbered INTERFACE_ID (suggested C-Type = 3)
o CHANNEL_STATUS_REQUEST Class name (suggested = 14) o CHANNEL_STATUS_REQUEST Class name (suggested = 14)
- IPv4 INTERFACE_ID (suggested C-Type = 1) - IPv4 INTERFACE_ID (suggested C-Type = 1)
- IPv6 INTERFACE_ID (suggested C-Type = 2) - IPv6 INTERFACE_ID (suggested C-Type = 2)
- unnumbered INTERFACE_ID (suggested C-Type = 3) - Unnumbered INTERFACE_ID (suggested C-Type = 3)
o ERROR_CODE Class name (suggested = 20) o ERROR_CODE Class name (suggested = 20)
- BEGIN_VERIFY_ERROR (suggested C-Type = 1) - BEGIN_VERIFY_ERROR (suggested C-Type = 1)
- LINK_SUMMARY_ERROR (suggested C-Type = 2) - LINK_SUMMARY_ERROR (suggested C-Type = 2)
18. Acknowledgements 18. Acknowledgements
The authors would like to thank Andre Fredette for his many The authors would like to thank Andre Fredette for his many
contributions to this document. We would also like to thank Ayan contributions to this document. We would also like to thank Ayan
Banerjee, George Swallow, Andre Fredette, Adrian Farrel, Vinay Banerjee, George Swallow, Andre Fredette, Adrian Farrel, Dimitri
Ravuri, and David Drysdale for their insightful comments and Papadimitriou, Vinay Ravuri, and David Drysdale for their insightful
suggestions. We would also like to thank John Yu, Suresh Katukam, comments and suggestions. We would also like to thank John Yu,
and Greg Bernstein for their helpful suggestions for the in-band Suresh Katukam, and Greg Bernstein for their helpful suggestions for
control channel applicability. Finally, we would like to thank the in-band control channel applicability.
Dimitri Papadimitriou for his contributions to the SONET/SDH test
procedures.
19. Contributors 19. Contributors
Jonathan P. Lang Krishna Mitra Jonathan P. Lang Krishna Mitra
Calient Networks Independent Consultant Rincon Networks Independent Consultant
25 Castilian Drive email: kmitra@earthlink.net 110 El Paseo email: kmitra@earthlink.net
Goleta, CA 93117 Santa Barbara, CA 93101
Email: jplang@calient.net Email: jplang@ieee.org
John Drake Kireeti Kompella John Drake Kireeti Kompella
Calient Networks Juniper Networks, Inc. Calient Networks Juniper Networks, Inc.
5853 Rue Ferrari 1194 North Mathilda Avenue 5853 Rue Ferrari 1194 North Mathilda Avenue
San Jose, CA 95138 Sunnyvale, CA 94089 San Jose, CA 95138 Sunnyvale, CA 94089
email: jdrake@calient.net email: kireeti@juniper.net email: jdrake@calient.net email: kireeti@juniper.net
Yakov Rekhter Lou Berger Yakov Rekhter Lou Berger
Juniper Networks, Inc. Movaz Networks Juniper Networks, Inc. Movaz Networks
1194 North Mathilda Avenue email: lberger@movaz.com 1194 North Mathilda Avenue email: lberger@movaz.com
Sunnyvale, CA 94089 Sunnyvale, CA 94089
email: yakov@juniper.net email: yakov@juniper.net
Debanjan Saha Debashis Basak Debanjan Saha Debashis Basak
Tellium Optical Systems Accelight Networks IBM Watson Research Center Accelight Networks
2 Crescent Place 70 Abele Road, Suite 1201 email: dsaha@us.ibm.com 70 Abele Road, Suite 1201
Oceanport, NJ 07757-0901 Bridgeville, PA 15017-3470 Bridgeville, PA 15017-3470
email: dsaha@tellium.com email: dbasak@accelight.com email: dbasak@accelight.com
Hal Sandick Alex Zinin Hal Sandick Alex Zinin
Shepard M.S. Alcatel Shepard M.S. Alcatel
2401 Dakota Street email: zinin@psg.com 2401 Dakota Street email: alex.zinin@alcatel.com
Durham, NC 27705 Durham, NC 27705
email: sandick@nc.rr.com email: sandick@nc.rr.com
Bala Rajagopalan Sankar Ramamoorthi Bala Rajagopalan Sankar Ramamoorthi
Tellium Optical Systems Juniper Networks, Inc. Tellium Optical Systems Juniper Networks, Inc.
2 Crescent Place 1194 North Mathilda Avenue 2 Crescent Place 1194 North Mathilda Avenue
Oceanport, NJ 07757-0901 Sunnyvale, CA 94089 Oceanport, NJ 07757-0901 Sunnyvale, CA 94089
email: braja@tellium.com email: sankarr@juniper.net email: braja@tellium.com email: sankarr@juniper.net
20. Contact Address 20. Contact Address
Jonathan P. Lang Jonathan P. Lang
Calient Networks Rincon Networks
25 Castilian Drive 110, El Paseo
Goleta, CA 93117 Goleta, CA 93101
Email: jplang@calient.net Email: jplang@ieee.org
21. Full Copyright Statement 21. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/