draft-ietf-ccamp-lmp-01.txt   draft-ietf-ccamp-lmp-02.txt 
Network Working Group Jonathan P. Lang (Calient Networks) Network Working Group Jonathan P. Lang (Calient Networks)
Internet Draft Krishna Mitra (Calient Networks) Internet Draft Krishna Mitra (Calient Networks)
Expiration Date: March 2002 John Drake (Calient Networks) Expiration Date: May 2002 John Drake (Calient Networks)
Kireeti Kompella (Juniper Networks) Kireeti Kompella (Juniper Networks)
Yakov Rekhter (Juniper Networks) Yakov Rekhter (Juniper Networks)
Lou Berger (Movaz Networks) Lou Berger (Movaz Networks)
Debanjan Saha (Tellium) Debanjan Saha (Tellium)
Debashis Basak (Accelight Networks) Debashis Basak (Accelight Networks)
Hal Sandick (Nortel Networks) Hal Sandick (Nortel Networks)
Alex Zinin (Nexsi Systems) Alex Zinin (Nexsi Systems)
Bala Rajagopalan (Tellium) Bala Rajagopalan (Tellium)
September 2001 November 2001
Link Management Protocol (LMP) Link Management Protocol (LMP)
draft-ietf-ccamp-lmp-01.txt draft-ietf-ccamp-lmp-02.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 [RFC2026]. all provisions of Section 10 of RFC2026 [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 1, line 57 skipping to change at page 2, line 6
purposes. This draft specifies a link management protocol (LMP) that purposes. This draft specifies a link management protocol (LMP) that
runs between neighboring nodes and is used to manage TE links. runs between neighboring nodes and is used to manage TE links.
Specifically, LMP will be used to maintain control channel Specifically, LMP will be used to maintain control channel
connectivity, verify the physical connectivity of the data-bearing connectivity, verify the physical connectivity of the data-bearing
channels, correlate the link property information, and manage link channels, correlate the link property information, and manage link
failures. A unique feature of the fault management technique is failures. A unique feature of the fault management technique is
that it is able to localize failures in both opaque and transparent that it is able to localize failures in both opaque and transparent
networks, independent of the encoding scheme used for the data. networks, independent of the encoding scheme used for the data.
Table of Contents Table of Contents
1 Introduction ................................................ 3 1 Introduction ................................................ 3
2 LMP Overview ................................................ 4 2 LMP Overview ................................................ 4
3 Control Channel Management ................................... 6 3 Control Channel Management ................................... 6
3.1 Parameter Negotiation ................................... 8 3.1 Parameter Negotiation ................................... 7
3.2 Hello Protocol .......................................... 8 3.2 Hello Protocol .......................................... 8
3.2.1 Hello Parameter Negotiation ...................... 9 3.2.1 Hello Parameter Negotiation ...................... 8
3.2.2 Fast Keep-alive .................................. 9 3.2.2 Fast Keep-alive .................................. 9
3.2.3 Administrative Down .............................. 10 3.2.3 Control Channel Down ............................. 10
3.2.4 Degraded (DEG) State ............................. 10 3.2.4 Degraded (DEG) State ............................. 10
4 Link Property Correlation ................................... 11 4 Link Property Correlation ................................... 10
5 Verifying Link Connectivity ................................. 12 5 Verifying Link Connectivity ................................. 12
5.1 Example of Link Connectivity Verification ............... 14 5.1 Example of Link Connectivity Verification ............... 14
6 Fault Management ............................................ 15 6 Fault Management ............................................ 15
6.1 Fault Detection ......................................... 15 6.1 Fault Detection ......................................... 15
6.2 Fault Localization Procedure ............................ 16 6.2 Fault Localization Procedure ............................ 15
6.3 Examples of Fault Localization .......................... 16 6.3 Examples of Fault Localization .......................... 16
6.4 Channel Activation Indication ........................... 17 6.4 Channel Activation Indication ........................... 17
6.5 Channel Deactivation Indication ......................... 17 6.5 Channel Deactivation Indication ......................... 18
7 Message_Id Usage ............................................ 18 7 Message_Id Usage ............................................ 18
8 Graceful Restart ............................................ 19 8 Graceful Restart ............................................ 19
9 Addressing .................................................. 20 9 Addressing .................................................. 20
10 LMP Authentication .......................................... 20 10 LMP Authentication .......................................... 20
11 LMP Finite State Machine .................................... 20 11 IANA Considerations ......................................... 21
11.1 Control Channel FSM .................................... 20 12 LMP Finite State Machine .................................... 22
11.1.1 Control Channel States .......................... 20 12.1 Control Channel FSM .................................... 22
11.1.2 Control Channel Events .......................... 21 12.1.1 Control Channel States .......................... 22
11.1.3 Control Channel FSM Description ................. 24 12.1.2 Control Channel Events .......................... 22
11.2 TE Link FSM ............................................ 25 12.1.3 Control Channel FSM Description ................. 25
11.2.1 TE link States .................................. 25 12.2 TE Link FSM ............................................ 26
11.2.2 TE link Events .................................. 25 12.2.1 TE link States .................................. 26
11.2.3 TE link FSM Description ......................... 25 12.2.2 TE link Events .................................. 26
11.3 Data Link FSM .......................................... 26 12.2.3 TE link FSM Description ......................... 27
11.3.1 Data Link States ................................ 26 12.3 Data Link FSM .......................................... 27
11.3.2 Data Link Events ................................ 27 12.3.1 Data Link States ................................ 28
11.3.3 Active Data Link FSM Description ................ 29 12.3.2 Data Link Events ................................ 28
11.3.4 Passive Data Link FSM Description ............... 30 12.3.3 Active Data Link FSM Description ................ 30
12 LMP Message Formats ......................................... 31 12.3.4 Passive Data Link FSM Description ............... 31
12.1 Common Header .......................................... 31 13 LMP Message Formats ......................................... 32
12.2 LMP Object Format ...................................... 33 13.1 Common Header .......................................... 32
12.3Authentication .......................................... 33 13.2 LMP Object Format ...................................... 34
12.4 Parameter Negotiation .................................. 36 13.3Authentication .......................................... 34
12.5 Hello .................................................. 37 13.4 Parameter Negotiation .................................. 37
12.6 Link Verification ...................................... 38 13.5 Hello .................................................. 38
12.7 Link Summary ........................................... 41 13.6 Link Verification ...................................... 39
12.8 Fault Management ....................................... 42 13.7 Link Summary ........................................... 42
13 LMP Object Definitions ...................................... 43 13.8 Fault Management ....................................... 43
14 Security Conderations ....................................... 61 14 LMP Object Definitions ...................................... 45
15 References .................................................. 61 15 Security Conderations ....................................... 63
16 Acknowledgments ............................................. 63 16 References .................................................. 64
17 Authors' Addresses ......................................... 63 17 Acknowledgments ............................................. 65
18 Authors' Addresses ......................................... 65
Changes from previous version: Changes from previous version:
o Added section on graceful restart o Added IANI Considerations section.
o Modified the Common Header and Object formats to support IPv6. o Added clarifying text to the MessageId section.
o Introduced ChannelStatus and ChannelStatusAck messages to o Added clarifying text to the ChannelStatus section for fault
encompass ChannelFail, ChannelFailAck, ChannelActive, localization.
ChannelActiveAck, ChannelDeactive, and ChannelDeactiveAck o Added Data Link Subobject to DATA_LINK object.
messages.
o Introduced ChannelStatusRequest and ChannelStatusResponse
messages.
o Removed LINK_ID from Test messages as INTERFACE_ID is node
unique.
o Made editorial changes
o Made corrections to the FSMs
o Added Error Codes
1. Introduction 1. Introduction
Future networks will consist of photonic switches (PXCs), optical Future networks will consist of photonic switches (PXCs), optical
crossconnects (OXCs), routers, switches, DWDM systems, and add-drop crossconnects (OXCs), routers, switches, DWDM systems, and add-drop
multiplexors (ADMs) that use a common control plane [e.g., multiplexors (ADMs) that use a common control plane [e.g.,
Generalized MPLS (GMPLS)] to dynamically allocate resources and to Generalized MPLS (GMPLS)] to dynamically allocate resources and to
provide network survivability using protection and restoration provide network survivability using protection and restoration
techniques. A pair of nodes (e.g., two PXCs) may be connected by techniques. A pair of nodes (e.g., two PXCs) may be connected by
thousands of fibers, and each fiber may be used to transmit multiple thousands of fibers, and each fiber may be used to transmit multiple
skipping to change at page 1, line 489 skipping to change at page 10, line 17
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 2) When Node A receives a Hello from Node B with
{TxSeqNum=1;RcvSeqNum=1}, it sends Hellos to Node B with {TxSeqNum=1;RcvSeqNum=1}, it sends Hellos to Node B with
{TxSeqNum=2;RcvSeqNum=1}. {TxSeqNum=2;RcvSeqNum=1}.
3) When Node A receives a Hello from Node B with 3) When Node A receives a Hello from Node B with
{TxSeqNum=2;RcvSeqNum=2}, it sends Hellos to Node B with {TxSeqNum=2;RcvSeqNum=2}, it sends Hellos to Node B with
{TxSeqNum=3;RcvSeqNum=2}. {TxSeqNum=3;RcvSeqNum=2}.
3.2.3. Administrative 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.
When bringing a control channel DOWN administratively, a node MUST When bringing a control channel DOWN administratively, a node MUST
set the ControlChannelDown flag in all LMP messages sent over the set the ControlChannelDown flag in all LMP messages sent over the
skipping to change at page 1, line 620 skipping to change at page 12, line 43
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 this requirement is trivial for DXCs (and OEO devices in that this requirement is trivial for DXCs (and OEO devices in
general) since each data link is terminated and processed general) since each data link is terminated and processed
electronically before being forwarded to the next OEO device, but electronically before being forwarded to the next OEO device, but
that in PXCs (and transparent devices in general) this is an that in PXCs (and transparent devices in general) this is 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. A TE link MUST include at least one data link. the nodes. For link verification, a TE link MUST include at least
one data link.
Once a control channel has been established between the two nodes, 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
over the control channels and that Hello messages continue to be over the control channels and that Hello messages continue to be
exchanged over each control channel during the data link exchanged over each control channel during the data link
verification process. The Test message is sent over the data link verification process. The Test message is sent over the data link
that is being verified. Data links are tested in the transmit that is being verified. Data links are tested in the transmit
direction as they are unidirectional, and therefore, it may be direction as they are unidirectional, and therefore, it may be
skipping to change at page 1, line 695 skipping to change at page 14, line 16
node within an observation period (specified by the node within an observation period (specified by the
VerifyDeadInterval), the remote node will send a TestStatusFailure VerifyDeadInterval), the remote node will send a TestStatusFailure
message over the control channel indicating that the verification of message over the control channel indicating that the verification of
the physical connectivity of the data link has failed. When the the physical connectivity of the data link has failed. When the
local node receives a TestStatusFailure message, it SHOULD mark the local node receives a TestStatusFailure message, it SHOULD mark the
data link as FAILED and send a TestStatusAck message to the remote data link as FAILED and send a TestStatusAck message to the remote
node. When all the data links on the list have been tested, the node. When all the data links on the list have been tested, the
local node SHOULD send an EndVerify message to indicate that testing local node SHOULD send an EndVerify message to indicate that testing
is complete on this link. is complete on this link.
If the local/remote data link mappings are known, then the link
verification procedure SHOULD be optimized by testing the data links
in a defined order known to both nodes. The suggested criteria for
this ordering is in increasing value of the Remote_Interface_ID.
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 PXC A and PXC B is added. In this executed when a link between PXC A and PXC 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 as control channel (indicated by a "c"). The verification process is as
skipping to change at page 1, line 793 skipping to change at page 16, line 15
all of the downstream nodes may detect LOL and indicate a failure. all of the downstream nodes may detect LOL and indicate a failure.
To avoid multiple alarms stemming from the same failure, LMP To avoid multiple alarms stemming from the same failure, LMP
provides a failure notification through the ChannelStatus message. provides a failure notification through the ChannelStatus message.
This message may be used to indicate that a single data channel has This message may be used to indicate that a single data channel has
failed, multiple data channels have failed, or an entire TE link has failed, multiple data channels have failed, or an entire TE link has
failed. Failure correlation is done locally at each node upon failed. Failure correlation is done locally at each node upon
receipt of the failure notification. receipt of the failure notification.
As part of the fault localization, a downstream node (downstream in As part of the fault localization, a downstream node (downstream in
terms of data flow) that detects data link failures will send a terms of data flow) that detects data link failures will send a
ChannelStatus message to its upstream neighbor (bundling together ChannelStatus message to its upstream neighbor indicating that a
the notification of all of the failed data links). An upstream node failure has occurred (bundling together the notification of all of
that receives the ChannelStatus message MUST send a ChannelStatusAck the failed data links). An upstream node that receives the
message to the downstream node indicating it has received the ChannelStatus message MUST send a ChannelStatusAck message to the
ChannelStatus message. The upstream node should correlate the downstream node indicating it has received the ChannelStatus
failure to see if the failure is also detected locally (including message. The upstream node should correlate the failure to see if
ingress side) for the corresponding LSP(s). If, for example, the the failure is also detected locally (including ingress side) for
failure is clear on the input of the upstream node or internally, the corresponding LSP(s). If, for example, the failure is clear on
then the upstream node will have localized the failure. Once the the input of the upstream node or internally, then the upstream node
failure has been localized, the signaling protocols can be used to will have localized the failure. Once the failure is correlated,
initiate span or path protection/restoration procedures. the upstream node SHOULD send a ChannelStatus message to the
downstream node indicating that the channel is failed or is ok. If
a ChannelStatus message is not received by the downstream node, it
SHOULD send a ChannelStatusRequest message for the channel in
question. Once the failure has been localized, the signaling
protocols can be used to initiate span or path
protection/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 PXCs are connected In Fig. 2, a sample network is shown where four PXCs are connected
skipping to change at page 1, line 882 skipping to change at page 18, line 8
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 MUST Active state, a failure is detected, the ChannelStatus message MUST
be transmitted as described in Section 6.2. be transmitted as described in Section 6.2.
6.5. Channel Deactivation Indication 6.5. Channel Deactivation 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 no longer needs to be monitored. This is the that the data link no longer needs to be monitored. This is the
counterpart to the Channel Active Indication. counterpart to the Channel Active Indication.
The ChannelStatusAck message MUST be transmitted upon receipt of a When a ChannelStatus message is received with Channel Deactive
ChannelStatus message. When a ChannelStatus message is received, Indication, the corresponding data link(s) MUST be taken out of the
the corresponding data link(s) MUST be taken out of the Active Active state.
state.
7. Message_Id Usage 7. Message_Id Usage
The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP
messages to support reliable message delivery. This section messages to support reliable message delivery. This section
describes the usage of these objects. The MESSAGE_ID and describes the usage of these objects. The MESSAGE_ID and
MESSAGE_ID_ACK objects contain a Message_Id field. Only one MESSAGE_ID_ACK objects contain a Message_Id field. Only one
MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP message. MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP message.
For control channel specific messages, the Message_Id field is For control channel specific messages, the Message_Id field is
skipping to change at page 1, line 928 skipping to change at page 18, line 54
If ((int) old_id ű (int) new_id > 0) { If ((int) old_id ű (int) new_id > 0) {
New value is less than old value; New value is less than old value;
} }
Nodes processing incoming messages SHOULD check to see if a newly Nodes processing incoming messages SHOULD check to see if a newly
received message is out of order and can be ignored. Out-of-order received message is out of order and can be ignored. Out-of-order
messages can be identified by examining the value in the Message_Id messages can be identified by examining the value in the Message_Id
field. field.
If the message is a ChannelStatus message (i.e., the message If the message is a Config message, and the Message_Id value is less
indicates the state of the data channels) and the Message_Id value than the largest Message_Id value previously received from the
is less than the largest value previously received from the sender sender for the CCID, then the message SHOULD be treated as being out
for the specified TE link, then the receiver SHOULD check the value of order.
previously received for the state of each data channel included in
the ChannelStatus message. If the value is greater than the most If the message is a LinkSummary message and the Message_Id value is
recently received value associated with at least one of the data less than the largest Message_Id value previously received from the
channels included in the message, the message MUST NOT be treated as sender for the TE Link, then the message SHOULD be treated as being
out of order; otherwise the message SHOULD be treated as being out out of order.
of order. However, the state of any data channel MUST NOT be updated
if the value is less than the most recently received value If the message is a ChannelStatus message and the Message_Id value
is less than the largest Message_Id value previously received from
the sender for the specified TE link, then the receiver SHOULD check
the Message_Id value previously received for the state of each data
channel included in the ChannelStatus message. If the Message_Id
value is greater than the most recently received Message_Id value
associated with at least one of the data channels included in the
message, the message MUST NOT be treated as out of order; otherwise
the message SHOULD be treated as being out of order. However, the
state of any data channel MUST NOT be updated if the Message_Id
value is less than the most recently received Message_Id value
associated with the data channel. associated with the data channel.
If the message is not a ChannelStatus message, and the Message_Id All other messages MUST NOT be treated as out-of-order.
value is less than the largest value previously received from the
sender for the LMP adjacency (or CCID, for control channel specific
messages), then the message SHOULD be treated as being out of order.
8. Graceful Restart 8. Graceful Restart
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 an LMP adjacency when bringing up the first control channel after an LMP adjacency
has failed, or as a result of an LMP component restart. The latter has failed, or as a result of an LMP component restart. The latter
is detected by setting the ˘Control Plane Restart÷ bit in the Common is detected by setting the ˘Control Plane 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 (rather than an LMP component restart), loss of the control channel (rather than an LMP component restart),
skipping to change at page 1, line 1029 skipping to change at page 21, line 7
information. Authentication information itself is appended to the information. Authentication information itself is appended to the
LMP packet. It is not considered to be a part of the LMP packet, but LMP packet. It is not considered to be a part of the LMP packet, but
is transferred in the same IP packet. is transferred in the same IP packet.
When the Authentication flag is set in the LMP packet header, an When the Authentication flag is set in the LMP packet header, an
authentication data block is attached to the packet. This block has authentication data block is attached to the packet. This block has
a standard authentication header and a data portion. The contents of a standard authentication header and a data portion. The contents of
the data portion depend on the authentication type. Currently, only the data portion depend on the authentication type. Currently, only
MD5 is supported for LMP. MD5 is supported for LMP.
11. LMP Finite State Machines 11. IANA Considerations
11.1. Control Channel FSM LMP defines the following name spaces which require management:
- Message Type Name Space.
- Class and class type name spaces for LMP objects.
The following sections provide guidelines for managing these name
spaces.
11.1. Message Type Name Space
LMP divides the name space for message types into two ranges. The
following are the guidelines for managing these ranges:
- Message Types 0 - 49 and 60 - 255: These message types are part of
the LMP base protocol. Following the policies outlined in [IANA],
message types in this range are allocated through an IETF
Consensus action.
- Message Types 50 - 59: Message types in this range are reserved
for UNI LMP extensions and the allocation in this range is the
responsibility of the OIF for supporting UNI signaling. IANA
management of this range of the Message Type name space is
unnecessary.
11.2. Object Class Name Space
LMP divides the name space for object classes into two ranges. The
following are the guidelines for managing these ranges:
- Classes 0 - 49 and 60 - 127: Object types in this range are part
of the LMP base protocol. Following the policies outlined in
[IANA], class types in this range are allocated through an IETF
Consensus action. Within each class, 256 class types are possible.
The allocation of class types for base LMP objects are described
in this draft and these are subject to IETF consensus action.
- Classes 50 - 59 are reserved for UNI LMP extensions and the
allocation in this range is the responsibility of the OIF for
supporting UNI signaling. IANA management of this range of the
class name space, and the underlying class types, is unnecessary.
12. LMP Finite State Machines
12.1. Control Channel FSM
The control channel FSM defines the states and logics of operation The control channel FSM defines the states and logics of operation
of an LMP control channel. The description of FSM state transitions of an LMP control channel. The description of FSM state transitions
and associated actions is given in Section 3. and associated actions is given in Section 3.
11.1.1. Control Channel States 12.1.1. Control Channel States
A control channel can be in one of the states described below. A control channel can be in one of the states described below.
Every state corresponds to a certain condition of the control Every state corresponds to a certain condition of the control
channel and is usually associated with a specific type of LMP channel and is usually associated with a specific type of LMP
message that is periodically transmitted to the far end. message that is periodically transmitted to the far end.
Down: This is the initial control channel state. In this Down: This is the initial control channel state. In this
state, no attempt is being made to bring the control state, no attempt is being made to bring the control
channel up and no LMP messages are sent. The control channel up and no LMP messages are sent. The control
channel parameters should be set to the initial values. channel parameters should be set to the initial values.
skipping to change at page 1, line 1070 skipping to change at page 22, line 47
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 transition to the UP state. can 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 two reasons: GoingDown: A CC may go into this state because of administrative
administrative action, and a ControlChannelDown bit action. While a CC is in this state, the node sets the
received in an LMP message. While a CC is in this ControlChannelDown bit in all the messages it sends.
state, the node sets the ControlChannelDown bit in all
the messages it sends.
11.1.2. Control Channel Events 12.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 its number and a symbolic name. Description of possible control has 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 or by the successful completion operator command, by the successful completion of
of a control channel bootstrap procedure. a control channel bootstrap procedure, or by
Depending on the configuration, this will trigger configuration. Depending on the configuration,
either this will trigger either
1a) the sending of a Config message, 1a) the sending of a Config message,
1b) a period of waiting to receive a Config 1b) a period of waiting to receive a Config
message from the remote node. message from the remote node.
2 : evCCDn: This event is generated when there is indication 2 : evCCDn: This event is generated when there is indication
that the control channel is no longer available. that the control channel is no longer available.
3 : evConfDone: This event indicates a ConfigAck message has been 3 : evConfDone: This event indicates a ConfigAck message has been
received, acknowledging the Config parameters. received, acknowledging the Config parameters.
skipping to change at page 1, line 1161 skipping to change at page 25, line 5
15: evConfRet: A retransmission timer has expired and a Config 15: evConfRet: A retransmission timer has expired and a Config
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 12.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 of FSM state transition diagram. in a form of FSM state transition diagram.
+--------+ +--------+
+----------------->| |<--------------+ +----------------->| |<--------------+
| +--------->| Down |<----------+ | | +--------->| Down |<----------+ |
| |+---------| |<-------+ | | | |+---------| |<-------+ | |
| || +--------+ | | | | || +--------+ | | |
| || | ^ 2,9,10| 2| 2| | || | ^ 2,9,10| 2| 2|
skipping to change at page 1, line 1214 skipping to change at page 26, line 8
+--------+ +--------+
| ^ | ^
| | | |
+---+ +---+
11,13,16 11,13,16
Figure 3: Control Channel FSM Figure 3: Control Channel FSM
Event evCCDn always forces the FSM to the Down State. Events Event evCCDn always forces the FSM to the Down State. Events
evHoldTimer evReconfig always force the FSM to the Negotiation state evHoldTimer evReconfig always force the FSM to the Negotiation state
(either ConfigSnd or ConfigRcv). (either ConfigSnd or ConfigRcv).
11.2. TE Link FSM 12.2. TE Link FSM
The TE Link FSM defines the states and logics of operation of an LMP The TE Link FSM defines the states and logics of operation of an LMP
TE Link. TE Link.
11.2.1. TE Link States 12.2.1. TE Link States
An LMP TE link can be in one of the states described below. Every An LMP TE link can be in one of the states described below. Every
state corresponds to a certain condition of the TE link and is state corresponds to a certain condition of the TE link and is
usually associated with a specific type of LMP message that is usually associated with a specific type of LMP message that is
periodically transmitted to the far end via the associated control periodically transmitted to the far end via the associated control
channel or in-band via the data links. channel or in-band via the data links.
Down: There are no control channels available and no data Down: There are no data links allocated to the TE link.
links are allocated to the TE link.
Init: Data links have been allocated to the TE link, but the
configuration has not yet been synchronized with the LMP
neighbor.
Up: This is the normal operational state of the TE link. At Up: This is the normal operational state of the TE link. At
least one primary CC is required to be operational least one primary CC is required to be operational
between the nodes sharing the TE link. between the nodes sharing the TE link.
Degraded: In this state, all primary CCs are down, but the TE link Degraded: In this state, all primary CCs are down, but the TE link
still includes some allocated data links. still includes some allocated data links.
11.2.2. TE Link Events 12.2.2. TE Link Events
Operation of the LMP TE link is described in terms of FSM states and Operation of the LMP TE link is described in terms of FSM states and
events. TE Link events are generated by the packet processing events. TE Link events are generated by the packet processing
routines and by the FSMs of the associated primary control routines and by the FSMs of the associated primary control
channel(s) and the data links. Every event has its number and a channel(s) and the data links. Every event has its number and a
symbolic name. Description of possible control channel events is symbolic name. Description of possible control channel events is
given below. given below.
1 : evDCUp: One or more data channels are UP and 1 : evDCUp: One or more data channels have been enabled and
LinkSummaryAck message has been received assigned to the TE Link.
acknowledging the TE link configuration. 2 : evSumAck: LinkSummary message received and positively
2 : evCCUp: First active CC goes Up. acknowledged.
3 : evCCDown: Last active CC goes Down. 3 : evSumNack: LinkSummary message received and negatively
4 : evDCDown: Last data channel of TE link has been removed. acknowledged.
This should not be done in the DEGRADE state as 4 : evRcvAck: LinkSummaryAck message received acknowledging
it will lead to inconsistencies. the TE Link Configuration.
5 : evSummaryNack1: Data channels are not carrying data traffic and 5 : evRcvNack: LinkSummaryNack message received.
LinkSummaryNack message has been received 6 : evSumRet: Retransmission timer has expired and LinkSummary
indicating misconfiguration of non-negotiable message is resent.
parameters for all data channels. 7 : evCCUp: First active control channel goes up.
6 : evSummaryNack2: One or more data channels are carrying data 8 : evCCDown: Last active control channel goes down.
traffic and LinkSummaryNack message has been
received. 9 : evDCDown: Last data channel of TE Link has been removed.
11.2.3. TE Link FSM Description
12.2.3. TE Link FSM Description
Figure 4 illustrates operation of the LMP TE Link FSM in a form of Figure 4 illustrates operation of the LMP TE Link FSM in a form of
FSM state transition diagram. FSM state transition diagram.
3,7,8
+--+
| |
| v
+--------+ +--------+
+------------>| |<-+ | |
| | Down | |5 +------------>| Down |<---------+
| | |--+ | | | |
4| +--------+ | +--------+ |
| | ^ | | ^ |
| 1| 5| | 1| |9 |
| v | |
| +--------+ |
| | |<-+ |
| | Init | |3,5,6 |9
| | |--+ 7,8 |
9| +--------+ |
| | | | | |
| 2,4| |
| v | | v |
+--------+ 2 +--------+ +--------+ 7 +--------+ |
| |------>| | | |------>| |----------+
| Deg | | Up | | Deg | | Up |
| |<------| | | |<------| |
+--------+ 3 +--------+ +--------+ 8 +--------+
| ^ | ^
| | | |
+--+ +--+
6 2,3,4,5,6
Figure 4: LMP TE Link FSM Figure 4: LMP TE Link FSM
In the above FSM, the sub-states that may be implemented when the In the above FSM, the sub-states that may be implemented when the
link verification procedure is used have been omitted. link verification procedure is used have been omitted.
11.3. Data Link FSM 12.3. Data Link FSM
The data link FSM defines the states and logics of operation of a The data link FSM defines the states and logics of operation of a
port or component link within an LMP TE link. Operation of a data port or component link within an LMP TE link. Operation of a data
link is described in terms of FSM states and events. Data-bearing link is described in terms of FSM states and events. Data-bearing
links can either be in the active (transmitting) mode, where Test links can either be in the active (transmitting) mode, where Test
messages are transmitted from them, or the passive (receiving) mode, messages are transmitted from them, or the passive (receiving) mode,
where Test messages are received through them. For clarity, where Test messages are received through them. For clarity,
separate FSMs are defined for the active/passive data-bearing links; separate FSMs are defined for the active/passive data-bearing links;
however, a single set of data link states and events are defined. however, a single set of data link states and events are defined.
11.3.1. Data Link States 12.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 TE link. state corresponds to a certain condition of the TE 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 periodically sent through the link. is periodically sent through the link.
skipping to change at page 1, line 1326 skipping to change at page 28, line 33
not yet been allocated to data traffic. not yet been allocated to data traffic.
Up/Allocated: The link is UP and has been allocated for data Up/Allocated: The link is UP and has been allocated for data
traffic. traffic.
Degraded: The link was in the Up/Allocated state when the last Degraded: The link was in the Up/Allocated state when the last
CC associated with data link's TE Link has gone down. CC associated with data link's TE Link has gone down.
The link is put in the Degraded state, since it is The link is put in the Degraded state, since it is
still being used for data LSP. still being used for data LSP.
11.3.2. Data Link Events 12.3.2. Data Link Events
Data bearing link events are generated by the packet processing Data bearing link events are generated by the packet processing
routines and by the FSMs of the associated control channel and the routines and by the FSMs of the associated control channel and the
TE link. Every event has its number and a symbolic name. TE link. Every event has its number and a symbolic name.
Description of possible data link events is given below: Description of possible data link events is given below:
1 :evCCUp: CC has gone up. 1 :evCCUp: CC has gone up.
2 :evCCDown: LMP neighbor connectivity is lost. This indicates 2 :evCCDown: LMP neighbor connectivity is lost. This indicates
the last LMP control channel has failed between the last LMP control channel has failed between
neighboring nodes. neighboring nodes.
skipping to change at page 1, line 1378 skipping to change at page 30, line 5
(b) an EndVerify messages has been received and the (b) an EndVerify messages has been received and the
VerifyDeadInterval has not yet expired. VerifyDeadInterval has not yet expired.
9 :evLnkAlloc: The data link has been allocated. 9 :evLnkAlloc: The data link has been allocated.
10:evLnkDealloc: The data link has been deallocated. 10:evLnkDealloc: The data link has been deallocated.
11:evTestRet: A retransmission timer has expired and the Test 11:evTestRet: A retransmission timer has expired and the Test
message is resent. message is resent.
12:evSummaryFail:The LinkSummary did not match for this data port. 12:evSummaryFail:The LinkSummary did not match for this data port.
13:evLocalizeFail:A Failure has been localized to this data link. 13:evLocalizeFail:A Failure has been localized to this data link.
14:evdcDown: The data channel is no longer available. 14:evdcDown: The data channel is no longer available.
11.3.3. Active Data Link FSM Description 12.3.3. Active Data Link FSM Description
Figure 5 illustrates operation of the LMP active data link FSM in a Figure 5 illustrates operation of the LMP active data link FSM in a
form of FSM state transition diagram. form of FSM state transition diagram.
+------+ +------+
+------------->| | +------------->| |<-------+
| +--------->| Down |<-----+ | +--------->| Down | |
| | +----| | | | | +----| |<-----+ |
| | | +------+ | | | | +------+ | |
| | |5b 3| ^ | | | |5b 3| ^ | |
| | | | |2,7 | | | | | |2,7 | |
| | | v | | | | | v | | |
| | | +------+ | | | | +------+ | |
| | | | |<-+ | | | | | |<-+ | |
| | | | Test | |11 | | | | | Test | |11 | |
| | | | |--+ | | | | | |--+ | |
| | | +------+ | | | | +------+ | |
| | | 5a| 3^ | | | | 5a| 3^ | |
| | | | | | | | | | | | |
| | | v | | | | | v | | |
| |2,12 | +---------+ | | |2,12 | +---------+ | |
| | +-->| |14 | | | +-->| |14 | |
| | | Up/Free |----+ | | | Up/Free |----+ |
| +---------| | | | +---------| | |
| +---------+ | | +---------+ |
| 9| ^ | | 9| ^ |
| | | | | | | |
|10 v |10 | |10 v |10 |
+-----+ 2 +---------+ | +-----+ 2 +---------+ |
| |<--------| | |13,14 | |<--------| |13 |
| Deg | |Up/Alloc |----+ | Deg | |Up/Alloc |------+
| |-------->| | | |-------->| |
+-----+ 1 +---------+ +-----+ 1 +---------+
Figure 5: Active LMP Data Link FSM Figure 5: Active LMP Data Link FSM
11.3.4. Passive Data Link FSM Description 12.3.4. Passive Data Link FSM Description
Figure 6 illustrates operation of the LMP passive data link FSM in a Figure 6 illustrates operation of the LMP passive data link FSM in a
form of FSM state transition diagram. form of FSM state transition diagram.
+------+ +------+
+------------->| | +------------->| |<------+
| +---------->| Down |<----+ | +---------->| Down | |
| | +-----| | | | | +-----| |<----+ |
| | | +------+ | | | | +------+ | |
| | |5b 4| ^ | | | |5b 4| ^ | |
| | | | |2,8 | | | | | |2,8 | |
| | | v | | | | | v | | |
| | | +----------+ | | | | +----------+ | |
| | | | PasvTest | | | | | | PasvTest | | |
| | | +----------+ | | | | +----------+ | |
| | | 6| 4^ | | | | 6| 4^ | |
| | | | | |14 | | | | | | |
| | | v | | | | | v | | |
| |2,12 | +---------+ | | |2,12 | +---------+ | |
| | +--->| Up/Free | | | | +--->| Up/Free |14 | |
| | | |---+ | | | |---+ |
| +----------| | | | +----------| | |
| +---------+ | | +---------+ |
| 9| ^ | | 9| ^ |
| | | | | | | |
|10 v |10 | |10 v |10 |
+-----+ +---------+ | +-----+ +---------+ |
| | 2 | | | | | 2 | |13 |
| Deg |<--------|Up/Alloc |---+ | Deg |<--------|Up/Alloc |-----+
| |-------->| | | |-------->| |
+-----+ 1 +---------+ +-----+ 1 +---------+
Figure 6: Passive LMP Data Link FSM Figure 6: Passive LMP Data Link FSM
12. LMP Message Formats 13. LMP Message Formats
All LMP messages are IP encoded (except, in some cases, the Test All LMP messages are IP encoded (except, in some cases, the Test
messages are limited by the transport mechanism for in-band messages are limited by the transport mechanism for in-band
messaging) with protocol number xxx - TBA (to be assigned) by IANA. messaging) with protocol number xxx - TBA (to be assigned) by IANA.
12.1. Common Header 13.1. Common Header
In addition to the standard IP header, all LMP messages (except, in In addition to the standard IP header, all LMP messages (except, in
some cases, the Test messages which are limited by the transport some cases, the Test messages which are limited by the transport
mechanism for in-band messaging) have the following common header: mechanism for in-band messaging) have the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | (Reserved) | Flags | Msg Type | | Vers | (Reserved) | Flags | Msg Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 1, line 1559 skipping to change at page 34, line 10
Checksum: 16 bits Checksum: 16 bits
The standard IP checksum of the entire contents of the LMP The standard IP checksum of the entire contents of the LMP
message, starting with the LMP message header. This checksum is message, starting with the LMP message header. This checksum is
calculated as the 16-bit one's complement of the one's calculated as the 16-bit one's complement of the one's
complement sum of all the 16-bit words in the packet. If the complement sum of all the 16-bit words in the packet. If the
packet's length is not an integral number of 16-bit words, the packet's length is not an integral number of 16-bit words, the
packet is padded with a byte of zero before calculating the packet is padded with a byte of zero before calculating the
checksum. checksum.
12.2. LMP Object Format 13.2. LMP Object Format
LMP messages are built using objects. Each object is identified by LMP messages are built using objects. Each object is identified by
its Object Class and Class-type. Each object has a name, which is its Object Class and Class-type. Each object has a name, which is
always capitalized in this document. LMP objects can be either always capitalized in this document. LMP objects can be either
negotiable or non-negotiable (identified by the N bit in the TLV negotiable or non-negotiable (identified by the N bit in the TLV
header). Negotiable objects can be used to let the devices agree on header). Negotiable objects can be used to let the devices agree on
certain values. Non-negotiable Objects are used for announcement of certain values. Non-negotiable Objects are used for announcement of
specific values that do not need or do not allow negotiation. specific values that do not need or do not allow negotiation.
The format of the LMP object is as follows: The format of the LMP object is as follows:
skipping to change at page 1, line 1589 skipping to change at page 34, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N: 1 bit N: 1 bit
The N flag indicates if the object is negotiable (N=1) or non- The N flag indicates if the object is negotiable (N=1) or non-
negotiable (N=0). negotiable (N=0).
C-Type: 7 bits C-Type: 7 bits
Class-type within an Object Class. Values are defined in Class-type within an Object Class. Values are defined in
Appendix A. Section 14.
Class: 8 bits Class: 8 bits
The Class indicates the Object type. Each Object has a name, The Class indicates the Object type. Each Object has a name,
which is always capitalized in this document. which is always capitalized in this document.
Length: 16 bits Length: 16 bits
The Length field indicates the length of the Object in bytes. The Length field indicates the length of the Object in bytes.
12.3. Authentication 13.3. Authentication
When authentication is used for LMP, the authentication itself is When authentication is used for LMP, the authentication itself is
appended to the LMP packet. It is not considered to be a part of appended to the LMP packet. It is not considered to be a part of
the LMP packet, but is transmitted in the same IP packet as shown the LMP packet, but is transmitted in the same IP packet as shown
below: below:
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 1, line 1623 skipping to change at page 35, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// LMP Payload // // LMP Payload //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Authentication Block // // Authentication Block //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The authentication block looks as follows: The authentication block consists of an 8 byte header followed by the
data portion shown as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Auth Type | Key ID | Auth Data Len | | 0 | Auth Type | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number | | Cryptographic Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| MD5 Signature (16) | | MD5 Signature (16) |
| | | |
skipping to change at page 1, line 1729 skipping to change at page 37, line 26
(a) The received digest is set aside. (a) The received digest is set aside.
(b) A new digest is calculated, as specified in the previous (b) A new digest is calculated, as specified in the previous
section. section.
(c) The calculated and received digests are compared. If they (c) The calculated and received digests are compared. If they
do not match, the LMP packet is discarded. If they do do not match, the LMP packet is discarded. If they do
match, the LMP protocol packet is accepted as authentic, and match, the LMP protocol packet is accepted as authentic, and
the "cryptographic sequence number" in the control channel's the "cryptographic sequence number" in the control channel's
data structure is set to the sequence number found in the data structure is set to the sequence number found in the
packet's LMP header. packet's LMP header.
12.4. Parameter Negotiation Messages 13.4. Parameter Negotiation Messages
12.4.1. Config Message (MsgType = 1) 13.4.1. Config Message (MsgType = 1)
The Config message is used in the control channel negotiation phase The Config message is used in the control channel negotiation phase
of LMP. The contents of the Config message are built using LMP of LMP. The contents of the Config message are built using LMP
objects. The format of the Config message is as follows: objects. The format of the Config message is as follows:
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID> <Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG> <LOCAL_NODE_ID> <CONFIG>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The MESSAGE_ID is within the scope of the CCID. The MESSAGE_ID is within the scope of the CCID.
The Config message MUST be periodically transmitted until (1) it The Config message MUST be periodically transmitted until (1) it
receives a ConfigAck or ConfigNack message, (2) a timeout expires receives a ConfigAck or ConfigNack message, (2) a timeout expires
and no ConfigAck or ConfigNack message has been received, or (3) it and no ConfigAck or ConfigNack message has been received, or (3) it
receives a Config message from the remote node and has lost the receives a Config message from the remote node and has lost the
contention (e.g., the Node Id of the remote node is higher than the contention (e.g., the Node Id of the remote node is higher than the
Node Id of the local node). Both the retransmission interval and Node Id of the local node). Both the retransmission interval and
the timeout period are local configuration parameters. the timeout period are local configuration parameters.
12.4.2. ConfigAck Message (MsgType = 2) 13.4.2. ConfigAck Message (MsgType = 2)
The ConfigAck message is used to acknowledge receipt of the Config The ConfigAck message is used to acknowledge receipt of the Config
message and indicate agreement on all parameters. message and indicate agreement on all parameters.
<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID> <ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_CCID> <MESSAGE_ID_ACK>
<REMOTE_NODE_ID> <REMOTE_NODE_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID
objects MUST be obtained from the Config message being acknowledged. objects MUST be obtained from the Config message being acknowledged.
12.4.3. ConfigNack Message (MsgType = 3) 13.4.3. ConfigNack Message (MsgType = 3)
The ConfigNack message is used to acknowledge receipt of the Config The ConfigNack message is used to acknowledge receipt of the Config
message and indicate disagreement on non-negotiable parameters or message and indicate disagreement on non-negotiable parameters or
propose other values for negotiable parameters. Parameters where propose other values for negotiable parameters. Parameters where
agreement was reached MUST NOT be included in the ConfigNack agreement was reached MUST NOT be included in the ConfigNack
Message. The format of the ConfigNack message is as follows: Message. The format of the ConfigNack message is as follows:
<ConfigNack Message> ::= <Common Header> <LOCAL_CCID> <ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID> <LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID>
skipping to change at page 1, line 1805 skipping to change at page 38, line 53
parameters, they MUST be copied from the CONFIG objects received in parameters, they MUST be copied from the CONFIG objects received in
the Config message. The ERROR_CODE MUST indicate ˘Unacceptable non- the Config message. The ERROR_CODE MUST indicate ˘Unacceptable non-
negotiable CONFIG parameter.÷ negotiable CONFIG parameter.÷
If the ConfigNack message is received and only includes CONFIG If the ConfigNack message is received and only includes CONFIG
objects that are negotiable, then a new Config message SHOULD be objects that are negotiable, then a new Config message SHOULD be
sent. The values in the CONFIG object of the new Config message sent. The values in the CONFIG object of the new Config message
SHOULD take into account the acceptable values included in the SHOULD take into account the acceptable values included in the
ConfigNack message. ConfigNack message.
12.5. Hello Message (MsgType = 4) 13.5. Hello Message (MsgType = 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 HelloDeadInterval, the control channel is assumed to have the HelloDeadInterval, the control channel is assumed to have
failed. failed.
12.6. Link Verification 13.6. Link Verification
12.6.1. BeginVerify Message (MsgType = 5) 13.6.1. BeginVerify Message (MsgType = 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.
skipping to change at page 1, line 1849 skipping to change at page 39, line 45
The REMOTE_LINK_ID MUST be non-zero if included. The REMOTE_LINK_ID MUST be non-zero if included.
The BeginVerify message MUST be periodically transmitted until (1) The BeginVerify message MUST be periodically transmitted until (1)
the node receives either a BeginVerifyAck or BeginVerifyNack message the node receives either a BeginVerifyAck or BeginVerifyNack message
to accept or reject the verify process or (2) a timeout expires and to accept or reject the verify process or (2) a timeout expires and
no BeginVerifyAck or BeginVerifyNack message has been received. no BeginVerifyAck or BeginVerifyNack message has been received.
Both the retransmission interval and the timeout period are local Both the retransmission interval and the timeout period are local
configuration parameters. configuration parameters.
12.6.2. BeginVerifyAck Message (MsgType = 6) 13.6.2. BeginVerifyAck Message (MsgType = 6)
When a BeginVerify message is received and Test messages are ready When a BeginVerify message is received and Test messages are ready
to be processed, a BeginVerifyAck message MUST be transmitted. to be processed, a BeginVerifyAck message MUST be transmitted.
<BeginVerifyAck Message> ::= <Common Header> <LOCAL_LINK_ID> <BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK> <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
<VERIFY_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The LOCAL_LINK_ID may be included if the local/remote Link Id
mapping is known or learned through the BeginVerify message.
The LOCAL_LINK_ID MUST be non-zero if included.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the The contents of the MESSAGE_ID_ACK object MUST be obtained from the
BeginVerify message being acknowledged. BeginVerify message being acknowledged.
The VERIFY_ID object contains a node-unique value that is assigned The VERIFY_ID object contains a node-unique value that is assigned
by the generator of the BeginVerifyAck message. This value is used by the generator of the BeginVerifyAck message. This value is used
to uniquely identify the Verification process from multiple LMP to uniquely identify the Verification process from multiple LMP
neighbors and/or parallel Test procedures between the same LMP neighbors and/or parallel Test procedures between the same LMP
neighbors. neighbors.
12.6.3. BeginVerifyNack Message (MsgType = 7) 13.6.3. BeginVerifyNack Message (MsgType = 7)
If a BeginVerify message is received and a node is unwilling or If a BeginVerify message is received and a node is unwilling or
unable to begin the Verification procedure, a BeginVerifyNack unable to begin the Verification procedure, a BeginVerifyNack
message MUST be transmitted. message MUST be transmitted.
<BeginVerifyNack Message> ::= <Common Header> <LOCAL_LINK_ID> <BeginVerifyNack Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID_ACK> <ERROR_CODE> <MESSAGE_ID_ACK> <ERROR_CODE>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
skipping to change at page 1, line 1904 skipping to change at page 40, line 54
ERROR_CODE MUST indicate ˘Unsupported verification transport ERROR_CODE MUST indicate ˘Unsupported verification transport
mechanism÷. mechanism÷.
If remote configuration of the TE Link Id is not supported and the If remote configuration of the TE Link Id is not supported and the
REMOTE_LINK_ID object (included in the BeginVerify message) does not REMOTE_LINK_ID object (included in the BeginVerify message) does not
match any configured values, the ERROR_CODE MUST indicate ˘TE Link match any configured values, the ERROR_CODE MUST indicate ˘TE Link
Id configuration error÷. Id configuration error÷.
The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2. The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2.
12.6.4. EndVerify Message (MsgType = 8) 13.6.4. EndVerify Message (MsgType = 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
to terminate the link verification process. The EndVerify message to terminate the link verification process. The EndVerify message
may be sent at any time the initiating node desires to end the may be sent at any time the initiating node desires to end the
Verify procedure. The format is as follows: Verify procedure. The format is as follows:
<EndVerify Message> ::= <Common Header> <MESSAGE_ID> <VERIFY_ID> <EndVerify Message> ::= <Common Header> <MESSAGE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The EndVerify message will be periodically transmitted until (1) an The EndVerify message will be periodically transmitted until (1) an
EndVerifyAck message has been received or (2) a timeout expires and EndVerifyAck message has been received or (2) a timeout expires and
no EndVerifyAck message has been received. Both the retransmission no EndVerifyAck message has been received. Both the retransmission
interval and the timeout period are local configuration parameters. interval and the timeout period are local configuration parameters.
12.6.5. EndVerifyAck Message (MsgType =9) 13.6.5. EndVerifyAck Message (MsgType =9)
The EndVerifyAck message is sent over the control channel and is The EndVerifyAck message is sent over the control channel and is
used to acknowledge the termination of the link verification used to acknowledge the termination of the link verification
process. The format is as follows: process. The format is as follows:
<EndVerifyAck Message> ::= <Common Header> <VERIFY_ID> <EndVerifyAck Message> ::= <Common Header> <VERIFY_ID>
<MESSAGE_ID_ACK> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the The contents of the MESSAGE_ID_ACK object MUST be obtained from the
EndVerify message being acknowledged. EndVerify message being acknowledged.
12.6.6. Test Message (MsgType = 10) 13.6.6. Test Message (MsgType = 10)
The Test message is transmitted over the data link and is used to The Test message is transmitted over the data link and is used to
verify its physical connectivity. Unless explicitly stated below, verify its physical connectivity. Unless explicitly stated in the
Verify Transport Mechanism description for the BEGIN_VERIFY class,
this is transmitted as an IP packet with payload format as follows: this is transmitted as an IP packet with payload format as follows:
<Test Message> ::= <Common Header> <VERIFY_ID> <LOCAL_INTERFACE_ID> <Test Message> ::= <Common Header> <VERIFY_ID> <LOCAL_INTERFACE_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
Note that this message is sent over a data link and NOT over the Note that this message is sent over a data link and NOT over the
control channel. control channel. The transport mechanism for the Test message is
negotiated using Verify Transport Mechanism field of the BeginVerify
Object and the Verify Transport Response field of the BeginVerifyAck
Object (see Sections 14.9 and 14.10).
The local (transmitting) node sends a given Test message The local (transmitting) node sends a given Test message
periodically (at least once every VerifyInterval ms) on the periodically (at least once every VerifyInterval ms) on the
corresponding data link until (1) it receives a correlating corresponding data link until (1) it receives a correlating
TestStatusSuccess or TestStatusFailure message on the control TestStatusSuccess or TestStatusFailure message on the control
channel from the remote (receiving) node or (2) all active control channel from the remote (receiving) node or (2) all active control
channels between the two nodes have failed. The remote node will channels between the two nodes have failed. The remote node will
send a given TestStatus message periodically over the control send a given TestStatus message periodically over the control
channel until it receives either a correlating TestStatusAck message channel until it receives either a correlating TestStatusAck message
or an EndVerify message is received over the control channel. or an EndVerify message is received over the control channel.
12.6.7. TestStatusSuccess Message (MsgType = 11) 13.6.7. TestStatusSuccess Message (MsgType = 11)
The TestStatusSuccess message is transmitted over the control The TestStatusSuccess message is transmitted over the control
channel and is used to transmit the mapping between the local channel and is used to transmit the mapping between the local
Interface Id and the Interface Id that was received in the Test Interface Id and the Interface Id that was received in the Test
message. message.
<TestStatus Message> ::= <Common Header> <LOCAL_LINK_ID> <TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <LOCAL_INTERFACE_ID> <MESSAGE_ID> <LOCAL_INTERFACE_ID>
<REMOTE_INTERFACE_ID> <VERIFY_ID> <REMOTE_INTERFACE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the REMOTE_INTERFACE_ID object MUST be obtained from The contents of the REMOTE_INTERFACE_ID object MUST be obtained from
the corresponding Test message being positively acknowledged. the corresponding Test message being positively acknowledged.
12.6.8. TestStatusFailure Message (MsgType = 12) 13.6.8. TestStatusFailure Message (MsgType = 12)
The TestStatusFailure message is transmitted over the control The TestStatusFailure message is transmitted over the control
channel and is used to indicate that the Test message was not channel and is used to indicate that the Test message was not
received. received.
<TestStatus Message> ::= <Common Header> <MESSAGE_ID> <VERIFY_ID> <TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID>
<VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
12.6.9. TestStatusAck Message (MsgType = 13) 13.6.9. TestStatusAck Message (MsgType = 13)
The TestStatusAck message is used to acknowledge receipt of the The TestStatusAck message is used to acknowledge receipt of the
TestStatusSuccess or TestStatusFailure messages. TestStatusSuccess or TestStatusFailure messages.
<TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID> <VERIFY_ID>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The contents of the MESSAGE_ID_ACK object MUST be obtained from the The contents of the MESSAGE_ID_ACK object MUST be obtained from the
TestStatusSuccess or TestStatusFailure message being acknowledged. TestStatusSuccess or TestStatusFailure message being acknowledged.
12.7. Link Summary Messages 13.7. Link Summary Messages
12.7.1. LinkSummary Message (MsgType = 14) 13.7.1. LinkSummary Message (MsgType = 14)
The LinkSummary message is used to synchronize the Interface Ids and The LinkSummary message is used to synchronize the Interface Ids and
correlate the properties of the TE link. The format of the correlate the properties of the TE link. The format of the
LinkSummary message is as follows: LinkSummary message is as follows:
<LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK> <LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
<DATA_LINK> [<DATA_LINK>...] <DATA_LINK> [<DATA_LINK>...]
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
The LinkSummary message can be exchanged at any time a link is not The LinkSummary message can be exchanged at any time a link is not
in the Verification process. The LinkSummary message MUST be in the Verification process. The LinkSummary message MUST be
periodically transmitted until (1) the node receives a periodically transmitted until (1) the node receives a
LinkSummaryAck or LinkSummaryNack message or (2) a timeout expires LinkSummaryAck or LinkSummaryNack message or (2) a timeout expires
and no LinkSummaryAck or LinkSummaryNack message has been received. and no LinkSummaryAck or LinkSummaryNack message has been received.
Both the retransmission interval and the timeout period are local Both the retransmission interval and the timeout period are local
configuration parameters. configuration parameters.
12.7.2. LinkSummaryAck Message (MsgType = 15) 13.7.2. LinkSummaryAck Message (MsgType = 15)
The LinkSummaryAck message is used to indicate agreement on the The LinkSummaryAck message is used to indicate agreement on the
Interface Id synchronization and acceptance/agreement on all the Interface Id synchronization and acceptance/agreement on all the
link parameters. It is on the reception of this message that the link parameters. It is on the reception of this message that the
local node makes the TE Link Id associations. local node makes the TE Link Id associations.
<LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
12.7.3. LinkSummaryNack Message (MsgType = 16) 13.7.3. LinkSummaryNack Message (MsgType = 16)
The LinkSummaryNack message is used to indicate disagreement on non- The LinkSummaryNack message is used to indicate disagreement on non-
negotiated parameters or propose other values for negotiable negotiated parameters or propose other values for negotiable
parameters. Parameters where agreement was reached MUST NOT be parameters. Parameters where agreement was reached MUST NOT be
included in the LinkSummaryNack Object. included in the LinkSummaryNack Object.
<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK> <LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> [<DATA_LINK>...] <ERROR_CODE> [<DATA_LINK>...]
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
skipping to change at page 1, line 2052 skipping to change at page 43, line 54
LinkSummary TLVs received in the LinkSummary message. LinkSummary TLVs 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 into account the acceptable parameters included in the take into account the acceptable parameters included in the
LinkSummaryNack message. LinkSummaryNack message.
The LinkSummaryNack message uses LINK_SUMMARY_ERROR_ C-Type 3. The LinkSummaryNack message uses LINK_SUMMARY_ERROR_ C-Type 3.
12.8. Fault Management Messages 13.8. Fault Management Messages
12.8.1. ChannelStatus Message (MsgType = 17)
13.8.1. ChannelStatus Message (MsgType = 17)
The ChannelStatus message is sent over the control channel and is The ChannelStatus message is sent over the control channel and is
used to notify an LMP neighbor of the status of a data. A node that used to notify an LMP neighbor of the status of a data link. A node
receives a ChannelStatus message MUST respond with a that receives a ChannelStatus message MUST respond with a
ChannelStatusAck message. The format is as follows: ChannelStatusAck message. The format is as follows:
<ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID> <ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <CHANNEL_STATUS> <MESSAGE_ID> <CHANNEL_STATUS>
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
If the CHANNEL_STATUS object does not include any Interface Ids, If the CHANNEL_STATUS object does not include any Interface Ids,
then this indicates the entire TE Link has failed. then this indicates the entire TE Link has failed.
12.8.2. ChannelStatusAck Message (MsgType = 18) 13.8.2. ChannelStatusAck Message (MsgType = 18)
The ChannelStatusAck message is used to acknowledge receipt of the The ChannelStatusAck message is used to acknowledge receipt of the
ChannelStatus Message. The format is as follows: ChannelStatus Message. The format is as follows:
<ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
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 object MUST be obtained from the
ChannelStatus message being acknowledged. ChannelStatus message being acknowledged.
12.8.3. ChannelStatusRequest Message (MsgType = 19) 13.8.3. ChannelStatusRequest Message (MsgType = 19)
The ChannelStatusRequest message is sent over the control channel The ChannelStatusRequest message is sent over the control channel
and is used to request the status of one or more data link(s). A and is used to request the status of one or more data link(s). A
node that receives a ChannelStatusRequest message MUST respond with node that receives a ChannelStatusRequest message MUST respond with
a ChannelStatus message. The format is as follows: a ChannelStatusResponse message. The format is as follows:
<ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID> <ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <MESSAGE_ID>
[<CHANNEL_STATUS_REQUEST>] [<CHANNEL_STATUS_REQUEST>]
The above transmission order SHOULD be followed. The above transmission order SHOULD be followed.
If the CHANNEL_STATUS_REQUEST object is not included, then the If the CHANNEL_STATUS_REQUEST object is not included, then the
ChannelStatusRequest is being used to request the status of ALL of ChannelStatusRequest is being used to request the status of ALL of
the data link(s) of the TE Link. the data link(s) of the TE Link.
12.8.4. ChannelStatusResponse Message (MsgType = 20) 13.8.4. ChannelStatusResponse Message (MsgType = 20)
The ChannelStatusResponse message is used to acknowledge receipt of The ChannelStatusResponse message is used to acknowledge receipt of
the ChannelStatusRequest Message and notify the LMP neighbor of the the ChannelStatusRequest Message and notify the LMP neighbor of the
status of the data channel(s). The format is as follows: status of the data channel(s). The format is as follows:
<ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK> <ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK>
<CHANNEL_STATUS> <CHANNEL_STATUS>
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 14. LMP Object Definitions
13.1. CCID (Control Channel ID) Classes 14.1. CCID (Control Channel ID) Classes
14.1.1. LOCAL_CCID Class
13.1.1. LOCAL_CCID Class
Class = 1. Class = 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id | | CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC_Id: 32 bits CC_Id: 32 bits
This MUST be node-wide unique and non-zero. The CC_Id This MUST be node-wide unique and non-zero. The CC_Id
identifies the control channel of the sender associated with identifies the control channel of the sender associated with
the message. the message.
This Object is non-negotiable. This Object is non-negotiable.
13.1.2. REMOTE_CCID Class 14.1.2. REMOTE_CCID Class
Class = 2. Class = 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id | | CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC_Id: 32 bits CC_Id: 32 bits
This identifies the remote nodeĂs 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 Classes 14.2. NODE_ID Classes
13.2.1. LOCAL_NODE_ID Class 14.2.1. LOCAL_NODE_ID Class
Class = 3. Class = 3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) | | Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node_Id: Node_Id:
This identities the node that originated the LMP packet. This identities the node that originated the LMP packet.
This Object is non-negotiable. This Object is non-negotiable.
13.2.2. REMOTE _NODE_ID Class 14.2.2. REMOTE _NODE_ID Class
Class = 4. Class = 4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) | | Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node_Id: Node_Id:
This identities the remote node. This identities the remote node.
This Object is non-negotiable. This Object is non-negotiable.
13.3. LINK _ID Classes 14.3. LINK _ID Classes
13.3.1. LOCAL_LINK_ID Class 14.3.1. LOCAL_LINK_ID Class
Class = 5 Class = 5
o IPv4, C-Type = 1 o IPv4, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) | | Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 1, line 2234 skipping to change at page 47, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Reserved for OIF, C-Type = 4 o Reserved for OIF, C-Type = 4
Link_Id: Link_Id:
This identifies the senderĂs Link associated with the message. This identifies the senderĂs Link associated with the message.
This Object is non-negotiable. This Object is non-negotiable.
13.3.2. REMOTE _LINK_ID Class 14.3.2. REMOTE _LINK_ID Class
Class = 6 Class = 6
o IPv4, C-Type = 1 o IPv4, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) | | Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 1, line 2276 skipping to change at page 48, line 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Reserved for OIF, C-Type = 4 o Reserved for OIF, C-Type = 4
Link_Id: Link_Id:
This identifies the remote nodeĂs Link Id and MUST be non-zero. This identifies the remote nodeĂs Link Id and MUST be non-zero.
This Object is non-negotiable. This Object is non-negotiable.
13.4. INTERFACE_ID Classes 14.4. INTERFACE_ID Classes
13.4.1. LOCAL_INTERFACE_ID Class 14.4.1. LOCAL_INTERFACE_ID Class
Class = 7 Class = 7
o IPv4, C-Type = 1 o IPv4, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) | | Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 1, line 2311 skipping to change at page 49, line 4
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Unnumbered, C-Type = 3 o Unnumbered, C-Type = 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) | | Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface_Id: Interface_Id:
This identifies the data link (either port or component link). This identifies the data link (either port or component link).
This is within the scope of a Link_Id. The Interface_Id MUST The Interface_Id MUST be node-wide unique and non-zero.
be node-wide unique and non-zero.
This Object is non-negotiable. This Object is non-negotiable.
13.4.2. REMOTE _INTERFACE_ID Class 14.4.2. REMOTE _INTERFACE_ID Class
Class = 8. Class = 8.
o IPv4, C-Type = 1 o IPv4, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) | | Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 1, line 2357 skipping to change at page 49, line 48
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) | | Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface_Id: Interface_Id:
This identifies the remote nodeĂs data link (either port or This identifies the remote nodeĂs data link (either port or
component link). This is within the scope of the remote nodeĂs component link). The Interface Id MUST be non-zero.
Link Id. The Interface Id MUST be non-zero.
This Object is non-negotiable. This Object is non-negotiable.
13.5. MESSAGE_ID Class 14.5. MESSAGE_ID Class
Class = 9. Class = 9.
o MessageId, C-Type = 1 o MessageId, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 used for message acknowledgment. is used for message acknowledgment.
This Object is non-negotiable. This Object is non-negotiable.
13.6. MESSAGE_ID_ACK Class 14.6. MESSAGE_ID_ACK Class
Class = 10. Class = 10.
o MessageIdAck, C-Type = 1 o MessageIdAck, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id | | Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message_Id: Message_Id:
The Message_Id field is used to identify the message being The Message_Id field is used to identify the message being
acknowledged. This value is copied from the MESSAGE_ID object acknowledged. This value is copied from the MESSAGE_ID object
of the message being acknowledged. of the message being acknowledged.
This Object is non-negotiable. This Object is non-negotiable.
13.7. CONFIG Class 14.7. CONFIG Class
Class = 11. Class = 11.
o HelloConfig, C-Type = 1 o HelloConfig, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval | | HelloInterval | HelloDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 1, line 2430 skipping to change at page 51, line 16
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.
13.8. HELLO Class 14.8. HELLO Class
Class = 12 Class = 12
o Type 1 Hello, C-Type = 1 o Type 1 Hello, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxSeqNum | | TxSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 1, line 2464 skipping to change at page 51, line 50
booted or restarted. booted or restarted.
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 reserved to indicate over the control channel. RcvSeqNum=0 is reserved to indicate
that a Hello message has not yet been received. that a Hello message has not yet been received.
This Object is non-negotiable. This Object is non-negotiable.
13.9. BEGIN_VERIFY Class 14.9. BEGIN_VERIFY Class
Class = 13. Class = 13.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EncType | Verify Transport Mechanism | | EncType | (Reserved) | Verify Transport Mechanism |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitRate | | BitRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength | | Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 16 bits Flags: 16 bits
The following flags are defined: The following flags are defined:
skipping to change at page 1, line 2505 skipping to change at page 52, line 39
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: 16 bits EncType: 8 bits
This is the encoding type of the data link and is required for This is the encoding type of the data link. The defined
the purpose of testing where the data links are not required to
be the same encoding type as the control channel. The defined
EncType values are consistent with the Link Encoding Type EncType values are consistent with the Link Encoding Type
values of [OSPF-GEN] and [ISIS-GEN]. values of [GMPLSSIG]
Verify Transport Mechanism: 16 bits Verify Transport Mechanism: 16 bits
This defines the transport mechanism for the Test Messages. The This defines the transport mechanism for the Test Messages. The
scope of this bit mask is restricted to each link encoding scope of this bit mask is restricted to each link encoding
type. The local node will set the bits corresponding to the type. The local node will set the bits corresponding to the
various mechanisms it can support for transmitting LMP test various mechanisms it can support for transmitting LMP test
messages. The receiver chooses the appropriate mechanism in the messages. The receiver chooses the appropriate mechanism in the
BeginVerifyAck message. BeginVerifyAck message.
skipping to change at page 1, line 2550 skipping to change at page 53, line 32
Note that this Test Message format is only valid when Note that this Test Message format is only valid when
the Interface_Id is either IPv4 or unnumbered. the Interface_Id is either IPv4 or unnumbered.
0x02 DCCS: Capable of transmitting Test messages using the DCC 0x02 DCCS: Capable of transmitting Test messages using the DCC
Section Overhead bytes with an HDLC framing format. Section Overhead bytes with an HDLC framing format.
0x04 DCCL: Capable of transmitting Test messges using the DCC 0x04 DCCL: Capable of transmitting Test messges using the DCC
Line Overhead bytes with an HDLC framing format. Line Overhead bytes with an HDLC framing format.
0x08 Payload: Capable of transmitting Test messages in the 0x08 Payload: Capable of transmitting Test messages in the
payload using Packet over SONET framing using the payload using Packet over SONET framing using the
encoding type specified in the EncType field. encoding type specified in the EncType field.
communicating using POS.
For GigE Encoding Type, the following flags are defined: TBD For GigE Encoding Type, the following flags are defined: TBD
For 10GigE Encoding Type, the following flags are defined: TBD For 10GigE Encoding Type, the following flags are defined: TBD
BitRate: 32 bits BitRate: 32 bits
This is the bit rate of the data link over which the Test This is the bit rate of the data link over which the Test
messages will be transmitted and is expressed in bytes per messages will be transmitted and is expressed in bytes per
second. second.
skipping to change at page 1, line 2573 skipping to change at page 53, line 54
When a data link is assigned to a port or component link that is When a data link is assigned to a port or component link that is
capable of transmitting multiple wavelengths (e.g., a fiber or capable of transmitting multiple wavelengths (e.g., a fiber or
waveband-capable port), it is essential to know which wavelength the waveband-capable port), it is essential to know which wavelength the
test messages will be transmitted over. This value corresponds to test messages will be transmitted over. This value corresponds to
the wavelength at which the Test messages will be transmitted over the wavelength at which the Test messages will be transmitted over
and has local significance. If there is no ambiguity as to the and has local significance. If there is no ambiguity as to the
wavelength over which the message will be sent, then this value wavelength over which the message will be sent, then this value
SHOULD be set to 0. SHOULD be set to 0.
13.10. BEGIN_VERIFY_ACK Class 14.10. BEGIN_VERIFY_ACK Class
Class = 14. Class = 14.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 1, line 2601 skipping to change at page 54, line 29
Verify_Transport_Response: 16 bits Verify_Transport_Response: 16 bits
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.11. VERIFY_ID Class 14.11. VERIFY_ID Class
Class = 15. Class = 15.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyId | | VerifyId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VerifyId: 32 bits VerifyId: 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.12. TE_LINK Class 14.12. TE_LINK Class
Class = 16. Class = 16.
o IPv4, C-Type = 1 o IPv4, 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 | (Reserved) | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 1, line 2689 skipping to change at page 56, line 13
0x02 Link Verification Supported. 0x02 Link Verification Supported.
Local_Link_Id: Local_Link_Id:
This identifies the nodeĂs 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 nodeĂs Link Id and MUST be non-zero. This identifies the remote nodeĂs Link Id and MUST be non-zero.
13.13. DATA_LINK Class 14.13. DATA_LINK Class
Class = 17. Class = 17.
o IPv4, C-Type = 1 o IPv4, 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 | (Reserved) | | Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) | | Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) | | Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | (Reserved) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // (Subobjects) //
| Minimum Reservable Bandwidth | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6, C-Type = 2 o IPv6, C-Type = 2
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 1, line 2734 skipping to change at page 57, line 4
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Remote_Interface_Id (16 bytes) + + Remote_Interface_Id (16 bytes) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | (Reserved) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // (Subobjects) //
| Minimum Reservable Bandwidth | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Unnumbered, C-Type = 3 o Unnumbered, C-Type = 3
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) | | Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | (Reserved) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // (Subobjects) //
| Minimum Reservable Bandwidth | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits Flags: 8 bits
The following flags are defined. All other values are The following flags are defined. All other values are
reserved. reserved.
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. allocated for user traffic. If a single
Interface_Id is used for both the
transmit and receive data links, then
this bit only applies to the transmit
interface.
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:
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
The contents of the DATA_LINK object consist of a series of
variable-length data items called subobjects. The subobjects
are defined in section 14.13.1 below.
A DATA_LINK object may contain more than one subobject. If more
than one subobject of the same Type appears, only the first
subobject of that Type is meaningful. Subsequent subobjects of the
same Type MAY be ignored.
14.13.1. Data Link Subobjects
The contents of the DATA_LINK object include a series of variable-
length data items called subobjects. Each subobject has the form:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+
| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+
Type: 8 bits
The Type indicates the type of contents of the subobject.
Currently defined values are:
1 Interface Switching Capability
Length: 8 bits
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length MUST be at
least 4, and MUST be a multiple of 4.
14.13.1.1. Subobject 1: Interface Switching Capability
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Switching Cap | EncType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Switching Capability: 8 bits Switching Capability: 8 bits
This is used to identify the local Interface Switching This is used to identify the local Interface Switching
Capability of the TE link. See [LSP-HIER]. Capability of the TE link. See [LSP-HIER].
Encoding: 8 bits EncType: 8 bits
The Encoding field contains one of the values specified in This is the encoding type of the data link. The defined
Section 3.1.1 of [GMPLS-S] EncType values are consistent with the Link Encoding Type
Minimum Reservable Bandwidth: 32 bits values of [GMPLSSIG].
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.
If the interface only supports a fixed rate, the minimum and maximum If the interface only supports a fixed rate, the minimum and maximum
bandwidth fields are set to the same value. bandwidth fields are set to the same value.
13.14. CHANNEL_STATUS Class 14.14. CHANNEL_STATUS Class
Class = 18 Class = 18
o IPv4, C-Type = 1 o IPv4, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Status | |A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
// : // // : //
| : | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Status | |A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6, C-Type = 2 o IPv6, C-Type = 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Interface Id (16 bytes) + + Interface Id (16 bytes) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Status | |A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
// : // // : //
| : | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Interface Id (16 bytes) + + Interface Id (16 bytes) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Status | |A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Unnumbered, C-Type = 3 o Unnumbered, C-Type = 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Status | |A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
// : // // : //
| : | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Status | |A| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Active bit: 1 bit
This indicates that the Channel is allocated to user traffic and the
data link should be actively monitored.
Channel_Status: 32 bits Channel_Status: 32 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.
1 Active: Channel is allocated to user traffic 1 Signal Okay (OK): Channel is operational
2 Deactive: Channel is free from user traffic 2 Signal Degrade (SD): A soft failure caused by a BER
3 Signal Okay (OK): Channel is operational
4 Signal Degrade (SD): A soft failure caused by a BER
exceeding a preselected threshold. The specific exceeding a preselected threshold. The specific
BER used to define the threshold is configured. BER used to define the threshold is configured.
5 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
Interface Id and it MUST be zero.
This Object is non-negotiable. This Object is non-negotiable.
13.15. CHANNEL_STATUS_REQUEST Class 14.15. CHANNEL_STATUS_REQUEST Class
Class = 19 Class = 19
o IPv4, C-Type = 1 o IPv4, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 1, line 2966 skipping to change at page 62, line 32
| Interface Id (4 bytes) | | Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.16. ERROR_CODE Class 14.16. ERROR_CODE Class
Class = 20. Class = 20.
o CONFIG_ERROR, C-Type = 1 o CONFIG_ERROR, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE | | ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 1, line 3028 skipping to change at page 63, line 44
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: The following bit-values are defined:
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 = Bad Received REMOTE_LINK_ID 0x04 = Bad Received Remote_Link_Id
All other values are Reserved. All other values are Reserved.
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. Security Considerations 15. Security Considerations
LMP exchanges may be authenticated using the Cryptographic LMP exchanges may be authenticated using the Cryptographic
authentication option. MD5 is currently the only message digest authentication option. MD5 is currently the only message digest
algorithm specified. algorithm specified.
15. References 16. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3," BCP 9, RFC 2026, October 1996. 3," BCP 9, RFC 2026, October 1996.
[LAMBDA] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., [LAMBDA] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R.,
"Multi-Protocol Lambda Switching: Combining MPLS Traffic "Multi-Protocol Lambda Switching: Combining MPLS Traffic
Engineering Control with Optical Crossconnects," Engineering Control with Optical Crossconnects,"
Internet Draft, draft-awduche-mpls-te-optical-03.txt, Internet Draft, draft-awduche-mpls-te-optical-03.txt,
(work in progress), April 2001. (work in progress), April 2001.
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., ˘Link Bundling in [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., ˘Link Bundling in
MPLS Traffic Engineering,÷ Internet Draft, draft- MPLS Traffic Engineering,÷ Internet Draft, draft-
kompella-mpls-bundle-05.txt, (work in progress), February kompella-mpls-bundle-05.txt, (work in progress), February
skipping to change at page 1, line 3073 skipping to change at page 64, line 38
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering," Internet Draft,draft-ietf-isis-traffic- Engineering," Internet Draft,draft-ietf-isis-traffic-
02.txt, (work in progress), September 2000. 02.txt, (work in progress), September 2000.
[OSPF] Moy, J., "OSPF Version 2," RFC 2328, April 1998. [OSPF] Moy, J., "OSPF Version 2," RFC 2328, April 1998.
[LMP-DWDM] Fredette, A., Snyder, E., Shantigram, J., et al, ˘Link [LMP-DWDM] Fredette, A., Snyder, E., Shantigram, J., et al, ˘Link
Management Protocol (LMP) for WDM Transmission Systems,÷ Management Protocol (LMP) for WDM Transmission Systems,÷
Internet Draft, draft-fredette-lmp-wdm-01.txt, (work in Internet Draft, draft-fredette-lmp-wdm-01.txt, (work in
progress), March 2001. progress), March 2001.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm," RFC [MD5] Rivest, R., "The MD5 Message-Digest Algorithm," RFC
1321, April 1992. 1321, April 1992.
[OSPF-GEN] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF [GMPLSSIG] Ashwood-Smith, P., Banerjee, A., et al, ˘Generalized
Extensions in Support of Generalized MPLS," Internet MPLS - Signaling Functional Description,÷ Internet Draft,
Draft, draft-kompella-ospf-gmpls-extensions-01.txt, draft-ietf-mpls-generalized-signaling-06.txt, (work in
(work in progress), February 2001. progress), October 2001.
[ISIS-GEN] Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS
Extensions in Support of Generalized MPLS," Internet
Draft, draft-ietf-gmpls-extensions-02.txt, (work in
progress), February 2001.
[LSP-HIER] Kompella, K. and Rekhter, Y., ˘LSP Hierarchy with MPLS [LSP-HIER] Kompella, K. and Rekhter, Y., ˘LSP Hierarchy with MPLS
TE,÷ Internet Draft, draft-ietf-mpls-lsp-hierarchy- TE,÷ Internet Draft, draft-ietf-mpls-lsp-hierarchy-
02.txt, (work in progress), February 2001. 02.txt, (work in progress), February 2001.
[GMPLS-S] Ashwood-Smith, P., Banerjee, A., Berger, L., et al,
˘Generalized MPLS - Signaling Functional Description,÷
Internet Draft, draft-ietf-mpls-generalized-signaling-
05.txt, (work in progress), July 2001.
16. Acknowledgments 17. Acknowledgments
The authors would like to thank Ayan Banerjee, George Swallow, Andre The authors would like to thank Ayan Banerjee, George Swallow, Andre
Fredette, Adrian Farrel, and Vinay Ravuri for their insightful Fredette, Adrian Farrel, and Vinay Ravuri for their insightful
comments and suggestions. We would also like to thank John Yu, comments and suggestions. We would also like to thank John Yu,
Suresh Katukam, and Greg Bernstein for their helpful suggestions for Suresh Katukam, and Greg Bernstein for their helpful suggestions for
the in-band control channel applicability. the in-band control channel applicability.
17. Author's Addresses 18. Author's Addresses
Jonathan P. Lang Krishna Mitra Jonathan P. Lang Krishna Mitra
Calient Networks Calient Networks Calient Networks Calient Networks
25 Castilian Drive 5853 Rue Ferrari 25 Castilian Drive 5853 Rue Ferrari
Goleta, CA 93117 San Jose, CA 95138 Goleta, CA 93117 San Jose, CA 95138
Email: jplang@calient.net email: krishna@calient.net Email: jplang@calient.net email: krishna@calient.net
John Drake Kireeti Kompella John Drake Kireeti Kompella
Calient Networks Juniper Networks, Inc. Calient Networks Juniper Networks, Inc.
5853 Rue Ferrari 385 Ravendale Drive 5853 Rue Ferrari 385 Ravendale Drive
 End of changes. 

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