idnits 2.17.1 draft-ietf-mpls-lmp-02.txt: -(2863): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2882): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 212: '...Each control channel MUST individually...' RFC 2119 keyword, line 214: '... channel MUST exchange LMP hello pac...' RFC 2119 keyword, line 217: '... messages MAY be transmitted over an...' RFC 2119 keyword, line 235: '...maryNack message MUST be sent in respo...' RFC 2119 keyword, line 256: '... links MUST be opaque (i.e., able to...' (64 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When a node has either sent or received a ConfigAck message, it may begin sending Hello messages. Once it has both sent and received a Hello message, the control channel moves to the UP state. If, however, a node receives a ConfigNack message instead of a ConfigAck message, the node MUST not send Hello messages. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-awduche-mpls-te-optical-02 -- Possible downref: Normative reference to a draft: ref. 'LAMBDA' == Outdated reference: A later version (-04) exists of draft-ceuppens-mpls-optical-00 -- Possible downref: Normative reference to a draft: ref. 'PERF-MON' == Outdated reference: A later version (-05) exists of draft-kompella-mpls-bundle-04 -- Possible downref: Normative reference to a draft: ref. 'BUNDLE' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-07 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-03 == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-03 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-03) exists of draft-fredette-lmp-wdm-00 -- Possible downref: Normative reference to a draft: ref. 'LMP-DWDM' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- No information found for draft-kompella-ospf-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'OSPF-GEN' -- No information found for draft-kompella-isis-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ISIS-GEN' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-01 Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jonathan P. Lang (Calient Networks) 3 Internet Draft Krishna Mitra (Calient Networks) 4 Expiration Date: September 2001 John Drake (Calient Networks) 5 Kireeti Kompella (Juniper Networks) 6 Yakov Rekhter (Juniper Networks) 7 Lou Berger (Movaz Networks) 8 Debanjan Saha (Tellium) 9 Debashis Basak (Accelight Networks) 10 Hal Sandick (Nortel Networks) 11 Alex Zinin (Cisco Systems) 12 Bala Rajagopalan (Tellium) 14 Link Management Protocol (LMP) 16 draft-ietf-mpls-lmp-02.txt 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026 [RFC2026]. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet- Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 Future networks will consist of photonic switches, optical 42 crossconnects, and routers that may be configured with control 43 channels, links, and bundled links. This draft specifies a link 44 management protocol (LMP) that runs between neighboring nodes and is 45 used to manage traffic engineering (TE) links. Specifically, LMP 46 will be used to maintain control channel connectivity, verify the 47 physical connectivity of the data-bearing channels, correlate the 48 link property information, and manage link failures. A unique 49 feature of the fault management technique is that it is able to 50 localize failures in both opaque and transparent networks, 51 independent of the encoding scheme used for the data. 53 Table of Contents 55 1. Introduction ................................................ 3 56 2. LMP Overview ................................................ 4 57 3. Control Channel Management .................................. 6 58 3.1 Parameter Negotiation ................................... 7 59 3.2 Hello Protocol .......................................... 8 60 3.2.1 Hello Parameter Negotiation ...................... 8 61 3.2.2 Fast Keep-alive .................................. 9 62 3.2.3 Control Channel Availability ..................... 10 63 3.2.4 Taking a Control Channel Down Administratively ... 10 64 3.2.5 Degraded (DEG) State ............................. 10 65 4. Link Property Correlation ................................... 11 66 5. Verfifying Link Connectivity ................................ 12 67 5.1 Example of Link Connectivity ............................ 14 68 6. Fault Management ............................................ 15 69 6.1 Fault Detection ......................................... 16 70 6.2 Fault Localization Mechanism ............................ 16 71 6.3 Channel Activation Indication............................ 16 72 6.4 Examples of Fault Localization .......................... 17 73 7. LMP Authentication .......................................... 18 74 8. LMP Finite State Machine .................................... 18 75 8.1 Control Channel FSM ..................................... 18 76 8.1.1 Control Channel States ........................... 19 77 8.1.2 Control Channel Events ........................... 19 78 8.1.3 Control Channel FSM Description .................. 22 79 8.2 TE Link FMS ............................................. 23 80 8.2.1 TE link States ................................... 23 81 8.2.2 TE link Events ................................... 24 82 8.2.3 TE link FSM Description .......................... 26 83 8.3 Data Link FSM ........................................ 27 84 8.3.1 Data Link States ................................. 27 85 8.3.2 Data Link Events ................................. 27 86 8.3.3 Active Data Link FSM Description ................. 29 87 8.3.4 Passive Data Link FSM Description ................ 30 88 9. LMP Message Formats ......................................... 30 89 9.1 Common Header ........................................... 30 90 9.2 LMP TLV Format .......................................... 33 91 9.3 Parameter Negotiation ................................... 36 92 9.4 Hello ................................................... 39 93 9.5 Link Verification ....................................... 40 94 9.6 Link Summary ............................................ 48 95 9.7 Fault Management ........................................ 53 96 10 Security Conderations........................................ 58 97 11. References ................................................. 58 98 12. Acknowledgments ............................................ 60 99 13. Authors' Addresses ........................................ 60 100 Changes from previous version: 102 o Added LMP length field to the common header. 103 o Decoupled control channel and TE Link dependence. Removed 104 control channel switchover procedure. 105 o Modified the FSMs to align with current procedures. 106 o Modified ConfigAck & ConfigNack to echo the NodeId received in 107 the Config message. 108 o Modified the Test messages to include VerifyId (provided by 109 remote node) to differentiate test messages from different TE- 110 links or LMP peers when testing in parallel. 111 o Added Link Mux Capability to LinkSummary. 112 o Added flags to LinkSummary indicating status of the ports or 113 component links. 114 o Added Channel Activate messages to Fault Management procedure. 115 o General Text clarification including: 116 o difference between port and component link 117 o use of control channels 119 1. Introduction 121 Future networks will consist of photonic switches (PXCs), optical 122 crossconnects (OXCs), routers, switches, DWDM systems, and add-drop 123 multiplexors (ADMs) that use the Generalized MPLS (GMPLS) control 124 plane to dynamically provision resources and to provide network 125 survivability using protection and restoration techniques. A pair 126 of nodes (e.g., two PXCs) may be connected by thousands of fibers, 127 and each fiber may be used to transmit multiple wavelengths if DWDM 128 is used. Furthermore, multiple fibers and/or multiple wavelengths 129 may be combined into a single traffic-engineering (TE) link for 130 routing purposes. To enable communication between nodes for 131 routing, signaling, and link management, a control channel must be 132 established between the node pair. This draft specifies a link 133 management protocol (LMP) that runs between neighboring nodes and is 134 used to manage TE links. 136 In this draft, we will follow the naming convention of [LAMBDA] and 137 use OXC to refer to all categories of optical crossconnects, 138 irrespective of the internal switching fabric. We distinguish 139 between crossconnects that require opto-electronic conversion, 140 called digital crossconnects (DXCs), and those that are all-optical, 141 called photonic switches or photonic crossconnects (PXCs) - referred 142 to as pure crossconnects in [LAMBDA], because the transparent nature 143 of PXCs introduces new restrictions for monitoring and managing the 144 data links (see [PERF-MON] for proposed extensions to MPLS for 145 performance monitoring in photonic networks). LMP can be used for 146 any type of node, enhancing the functionality of traditional DXCs 147 and routers, while enabling PXCs and DWDMs to intelligently 148 interoperate in heterogeneous optical networks. 150 In GMPLS, the control channel between two adjacent nodes is no 151 longer required to use the same physical medium as the data-bearing 152 links between those nodes. For example, a control channel could use 153 a separate wavelength or fiber, an Ethernet link, or an IP tunnel 154 through a separate management network. A consequence of allowing 155 the control channel(s) between two nodes to be physically diverse 156 from the associated data links is that the health of a control 157 channel does not necessarily correlate to the health of the data 158 links, and vice-versa. Therefore, a clean separation between the 159 fate of the control channel and data-bearing links must be made. 160 Furthermore, new mechanisms must be developed to manage the data- 161 bearing links, both in terms of link provisioning and fault 162 localization. 164 For the purposes of this document, a data-bearing link may be either 165 a "port" or a "component link" depending on its multiplexing 166 capability; component links are multiplex capable, whereas ports are 167 not multiplex capable. This distinction is important since the 168 management of such links (including, for example, resource 169 allocation, label assignment, and their physical verification) is 170 different based on their multiplexing capability. For example, a 171 SONET crossconnect with OC-192 interfaces may be able to demultiplex 172 the OC-192 stream into four OC-48 streams. If multiple interfaces 173 are grouped together into a single TE link using link bundling 174 [BUNDLE], then the link resources must be identified using three 175 levels: TE link Id, component interface Id, and timeslot label. 176 Resource allocation happens at the lowest level (timeslots), but 177 physical connectivity happens at the component link level. As 178 another example, consider the case where a PXC transparently 179 switches OC-192 lightpaths. If multiple interfaces are once again 180 grouped together into a single TE link, then link bundling [BUNDLE] 181 is not required and only two levels of identification are required: 182 TE link Id and port Id. Both resource allocation and physical 183 connectivity happen at the lowest level (i.e. port level). LMP is 184 designed to support aggregation of one or more data-bearing links 185 into a TE link (either ports into TE links, or component links into 186 TE links). 188 2. LMP Overview 190 LMP runs between a pair of nodes and includes a core set of 191 functions; two additional tools are defined in this draft to extend 192 the functionality of LMP and are optional. The core function set 193 includes control channel management and link property correlation. 194 Control channel management is used to establish and maintain control 195 channel connectivity between neighboring nodes. This is done using 196 lightweight Hello messages that act as a fast keep-alive mechanism 197 between the nodes. Link property correlation consists of a 198 LinkSummary message exchange that is used to synchronize the link 199 properties (e.g., local/remote Interface ID mappings) between the 200 adjacent nodes. 202 LMP requires that a pair of nodes have at least one active bi- 203 directional control channel between them. This control channel may 204 be implemented using two uni-directional control channels that are 205 coupled together using the LMP Hello messages. All LMP messages are 206 IP encoded [except, in some cases, the Test Message which may be 207 limited by the transport mechanism for in-band messaging]; the link 208 level encoding of the control channel is outside the scope of this 209 document. 211 In LMP, multiple control channels may be active simultaneously 212 between a pair of nodes. Each control channel MUST individually 213 negotiate the control channel parameters, and each active control 214 channel MUST exchange LMP hello packets to maintain LMP 215 connectivity. If a group of control channels share a common node 216 pair and support the same LMP capabilities, then LMP control 217 messages MAY be transmitted over any of the active control channels 218 of that group without coordination between the local and remote 219 nodes. LMP also allows secondary (or backup) control channels to be 220 defined. For example, data-bearing may be used as backup control 221 channels provided control channel traffic has preemptive priority 222 over the data traffic on the link. Secondary control channels only 223 become active control channels when the switchover is complete and 224 they inherit the configuration properties of the primary control 225 channel that is being switched over to it. 227 The link property correlation function of LMP is designed to 228 aggregate multiple ports or component links into a TE link, and to 229 synchronize the properties of the TE link. As part of the link 230 property correlation function, a LinkSummary message exchange is 231 defined. The LinkSummary message includes the local and remote TE 232 Link Id, a list of all ports or component links that comprise the TE 233 link, and various link properties. In addition, TLVs may be 234 included further describing the TE link. A LinkSummaryAck or 235 LinkSummaryNack message MUST be sent in response to the receipt of a 236 LinkSummary message indicating agreement or disagreement of the link 237 properties. 239 In this draft, two additional tools are defined that extend the 240 functionality of LMP: link connectivity verification and fault 241 management. These tools are particularly useful when the control 242 channel is transmitted out-of-band from the data-bearing links. 243 Link connectivity verification is used to verify the physical 244 connectivity between the nodes and exchange the Interface Ids 245 (either Port Ids or Component Interface Ids, depending on the 246 configuration); these Ids are used in GMPLS signaling. The 247 procedure uses in-band Test messages that are sent over the data- 248 bearing links and TestStatus messages that are transmitted over the 249 control channel. The fault management scheme uses ChannelActive and 250 ChannelFail message exchanges between a pair of nodes to localize 251 failures in both opaque and transparent networks, independent of the 252 encoding scheme used for the data. As a result, both local span and 253 end-to-end path protection/restoration procedures can be initiated. 255 For the LMP Test procedure, the free (unallocated) data-bearing 256 links MUST be opaque (i.e., able to be terminated); however, once a 257 data link is allocated, it may become transparent. The LMP Test 258 procedure is coordinated using a BeginVerify message exchange over 259 the control channel. To support various degrees of transparency 260 (e.g., examining overhead bytes, terminating the payload, etc.), and 261 hence, different mechanisms to transport the Test messages, a Verify 262 Transport Mechanism is included in the BeginVerify and 263 BeginVerifyAck messages. Note that there is no requirement that all 264 of the data-bearing links must be terminated simultaneously, but at 265 a minimum, they must be able to be terminated one at a time. There 266 is also no requirement that the control channel and TE link share 267 the same physical medium; however, the control channel MUST 268 terminate on the same two nodes that the TE link spans. Since the 269 BeginVerify message exchange coordinates the Test procedure, it also 270 naturally coordinates the transition of the data links between 271 opaque and transparent modes. 273 The LMP fault management procedure is based on two message 274 exchanges: ChannelActive and ChannelFail. The ChannelActive message 275 is used to indicate that one or more data-bearing channels are now 276 carrying user data. This is particularly useful for detecting 277 unidirectional channel failures in the transparent case. Receipt of 278 a ChannelActive message MUST be acknowledged with a ChannelActiveAck 279 message, the data-bearing channels MUST move to the ACTIVE state (if 280 not already there), and fault monitoring SHOULD be verified for the 281 corresponding data channels. The ChannelFail message is used to 282 indicate that one or more active data channels or an entire TE link 283 have failed. Receipt of a ChannelFail message MUST be acknowledged 284 with either a ChannelFailNack or ChannelFailAck message, depending 285 on if the channel failure is CLEAR or not in the adjacent node. 287 The organization of the remainder of this document is as follows. 288 In Section 3, we discuss the role of the control channel and the 289 messages used to establish and maintain link connectivity. In 290 Section 4, the link property correlation function using the 291 LinkSummary message is described. The link verification procedure 292 is discussed in Section 5. In Section 6, we show how LMP will be 293 used to isolate link and channel failures within the optical 294 network. Several finite state machines (FSMs) are given in Section 295 7 and the message formats are defined in Section 8. 297 3. Control channel management 299 To initiate an LMP session between two nodes, a bi-directional 300 control channel MUST be established. The control channel can be 301 used to exchange MPLS control-plane information such as link 302 provisioning and fault isolation information (implemented using a 303 messaging protocol such as LMP, proposed in this draft), path 304 management and label distribution information (implemented using a 305 signaling protocol such as RSVP-TE [RSVP-TE] or CR-LDP [CR-LDP]), 306 and network topology and state distribution information (implemented 307 using traffic engineering extensions of protocols such as OSPF 308 [OSPF-TE] and IS-IS [ISIS-TE]). For the purposes of LMP, we do not 309 specify the exact implementation of the control channel; it could 310 be, for example, a separate wavelength or fiber, an Ethernet link, 311 an IP tunnel through a separate management network, or the overhead 312 bytes of a data-bearing link. Rather, we assign a node-wide unique 313 32-bit non-zero integer control channel identifier (CCId) to each 314 direction of the control channel. One possible way to assign a CCId 315 is to use the IP address or ifindex of the interface. Furthermore, 316 we define the control channel messages (which have control channel 317 identifiers in them) to be IP encoded. This allows the control 318 channel implementation to encompass both in-band and out-of-band 319 mechanisms; including the case where the control channel messages 320 are transmitted separately from the associated data link(s). 321 Furthermore, since the messages are sent directly over IP, the link 322 level encoding is not part of LMP. 324 The control channel can be either explicitly configured or 325 automatically selected, however, for the purpose of this document we 326 will assume the control channel is explicitly configured. Note that 327 for in-band signaling, a control channel could be allocated to a 328 data-bearing link; however, this is not true when the control 329 channel is transmitted separately from the data links. 331 Control channels exist independently of TE links and multiple 332 control channels may be active simultaneously between a pair of 333 nodes. The control channels may also be used for transmitting and 334 receiving signaling and routing messages. Each LMP control channel 335 MUST individually negotiate the control channel parameters, and each 336 active control channel MUST exchange LMP Hello packets to maintain 337 LMP connectivity. If a group of control channels share a common 338 node pair and support the same LMP capabilities, then LMP control 339 channel messages (except Config, ConfigAck, ConfigNack, and Hello) 340 may be transmitted over any of the active control channels without 341 coordination between the local and remote nodes. 343 For LMP, it is essential that at least one control channel is always 344 available. In the event of a control channel failure, it may be 345 possible to use an alternate active control channel without 346 coordination as mentioned above. Since control channels are 347 electrically terminated at each node, lower layers (e.g., SONET/SDH) 348 may also be used to detect control channel failures. 350 3.1. Parameter Negotiation 352 For LMP, a generic parameter negotiation exchange is defined using 353 Config, ConfigAck, and ConfigNack messages. The contents of these 354 messages are built using TLV triplets. Config TLVs can be either 355 negotiable or non-negotiable (identified by the N flag in the TLV 356 header). Negotiable TLVs can be used to let the devices agree on 357 certain values. Non-negotiable TLVs are used for announcement of 358 specific values that do not need, or do not allow, negotiation. 360 To initiate the configuration procedure, a node MUST transmit Config 361 messages to the remote node. It is possible that both the local and 362 remote nodes initiate the configuration procedure at effectively the 363 same time. To avoid ambiguities, the node with the higher Node Id 364 wins the contention; the node with the lower Node Id SHOULD stop 365 transmitting the Config message and respond to the Config messages 366 it receives. 368 The Config message MUST be periodically transmitted until (1) it 369 receives a ConfigAck or ConfigNack message, (2) a timeout expires 370 and no ConfigAck or ConfigNack message has been received, or (3) it 371 receives a Config message from the remote node and has lost the 372 contention (e.g., the Node Id of the remote node is higher than the 373 Node Id of the local node). Both the retransmission interval and 374 the timeout period are local configuration parameters. 376 The Config message MUST include the LMP Capability TLV and the 377 HelloConfig TLV. 379 The ConfigAck message is used to acknowledge receipt of the Config 380 message and express agreement on ALL of the configured parameters 381 (both negotiable and non-negotiable). The ConfigNack message is 382 used to acknowledge receipt of the Config message, indicate which 383 (if any) non-negotiable parameters are unacceptable, and propose 384 alternate values for the negotiable parameters. 386 3.2. Hello protocol 388 Once a control channel is configured between two neighboring nodes, 389 a Hello protocol will be used to establish and maintain control 390 channel connectivity between the nodes and to detect control channel 391 failures. The Hello protocol of LMP is intended to be a lightweight 392 keep-alive mechanism that will react to control channel failures 393 rapidly so that IGP Hellos are not lost and the associated link- 394 state adjacencies are not removed unnecessarily. Furthermore, the 395 RSVP Hello of [RSVP-TE] is not needed since the LMP Hellos will 396 detect link layer failures. 398 The Hello protocol consists of two phases: a negotiation phase and a 399 keep-alive phase. Negotiation MUST only be done when the control 400 channel is in the CONFIG state, and is used to exchange the CCIds 401 and agree upon the parameters used in the keep-alive phase. The 402 keep-alive phase consists of a fast lightweight Hello message 403 exchange. 405 3.2.1. Hello Parameter Negotiation 407 Before sending Hello messages as part of the keep-alive phase, the 408 HelloInterval and HelloDeadInterval parameters MUST be agreed upon. 409 These parameters are exchanged as a HelloConfig TLV object in the 410 Config message. The HelloInterval indicates how frequently LMP 411 Hello messages will be sent, and is measured in milliseconds (ms). 412 For example, if the value were 100, then the transmitting node would 413 send the Hello message at least every 100ms. The HelloDeadInterval 414 indicates how long a device should wait to receive a Hello message 415 before declaring a control channel dead, and is measured in 416 milliseconds (ms). The HelloDeadInterval MUST be greater than the 417 HelloInterval, and SHOULD be at least 3 times the value of 418 HelloInterval. 420 When a node has either sent or received a ConfigAck message, it may 421 begin sending Hello messages. Once it has both sent and received a 422 Hello message, the control channel moves to the UP state. If, 423 however, a node receives a ConfigNack message instead of a ConfigAck 424 message, the node MUST not send Hello messages. 426 In the event that multiple control channels are run over the same 427 physical control channel interface, the parameter negotiation phase 428 is run multiple times. The various LMP parameter negotiation 429 messages associated with their corresponding control channels are 430 tagged with their node-wide unique identifiers (CCIds). 432 3.2.2. Fast Keep-alive 434 Each Hello message contains two sequence numbers: the first sequence 435 number (TxSeqNum) is the sequence number for this Hello message and 436 the second sequence number (RcvSeqNum) is the sequence number of the 437 last Hello message received over this control channel from the 438 adjacent node. Each node increments its sequence number when it sees 439 its current sequence number reflected in Hellos received from its 440 peer. The sequence numbers start at 1 and wrap around back to 2; 0 441 is used in the RcvSeqNum to indicate that a Hello has not yet been 442 seen and 1 is used in the TxSeqNum to indicate a control channel 443 boot/reboot. 445 Under normal operation, the difference between the RcvSeqNum in a 446 Hello message that is received and the local TxSeqNum that is 447 generated will be at most 1. There are two cases where this 448 difference can be more than 1: when a control channel reboots and 449 when switching over to a backup control channel. 451 Having sequence numbers in the Hello messages allows each node to 452 verify that its peer is receiving its Hello messages. This provides 453 a two-fold service. First, the remote node will detect that a 454 control channel has rebooted if TxSeqNum=1. If this occurs, the 455 remote node will indicate its knowledge of the reboot by setting 456 RcvSeqNum=1 in the Hello messages that it sends and SHOULD wait to 457 receive a Hello message with TxSeqNum=2 before transmitting any 458 messages other than Hello messages. Second, by including the 459 RcvSeqNum in Hello packets, the local node will know which Hello 460 packets the remote node has received. 462 The following example illustrates how the sequence numbers operate: 464 1) After completing the configuration stage, Node A sends a Hello 465 message with {TxSeqNum=1;RcvSeqNum=0}. 466 2) When Node A receives a Hello with {TxSeqNum=1;RcvSeqNum=1}, it 467 sends Hellos with {TxSeqNum=2;RcvSeqNum=1}. 468 3) After some time, the control channel on Node B reboots. 469 4) Node A is sending Hellos with {TxSeqNum=45;RcvSeqNum=44} and 470 receives a Hello from Node B with {TxSeqNum=1;RcvSeqNum=0}, 471 indicating that Node B has rebooted. Node A sends Hello 472 messages with {TxSeqNum=45;RcvSeqNum=1}. 473 4) When Node A receives a Hello with {TxSeqNum=2;RcvSeqNum=45}, it 474 sends Hellos with {TxSeqNum=46;RcvSeqNum=2}. 476 3.2.3. Control Channel Availability 478 As mentioned above, LMP requires that a bi-directional control 479 channel is available, and LMP includes mechanisms to ensure that a 480 control channel is available. Control channels may need to be 481 switched as a result of the associated physical control channel 482 interface or link failure, or for administration purposes (e.g., 483 routine fiber maintenance). During these times, peer connectivity 484 must be maintained to ensure that unnecessary rerouting of user 485 traffic is avoided and false failures are not reported. 487 If multiple active control channels share a common node pair and 488 support the same LMP capabilities, then any of the active control 489 channels may be used without coordination between the local and 490 remote nodes. 492 3.2.4. Taking a Control Channel Down Administratively 494 To ensure that bringing a control channel DOWN for administration 495 purposes is done gracefully, a ControlChannelDown flag is available 496 in the Common Header of LMP packets. When data links (ports or 497 component links) are still in use between a pair of nodes, a control 498 channel SHOULD only be taken down administratively when there are 499 other active control channels that can be used to manage the data 500 links. 502 When a node receives LMP packets with ControlChannelDown = 1, it 503 must first verify that it is able to bring the control channel down 504 on its end. Once the verification is done, it must set the 505 ControlChannelDown flag to 1 on all of the LMP packets that it 506 sends. When the node that initiated the ControlChannelDown 507 procedure receives LMP packets with ControlChannelDown = 1, it may 508 then stop sending Hello packets. 510 3.2.5. Degraded State 512 A consequence of allowing the control channels and data links to be 513 transmitted along a separate medium is that the TE link may be in a 514 state where no active control channels are available, but the data 515 links (ports or component links) are still in use. For many 516 applications, it is unacceptable to tear down a link that is 517 carrying user traffic simply because the control channel is no 518 longer available; however, the traffic that is using the data links 519 may no longer be guaranteed the same level of service. Hence the TE 520 link is in a Degraded state. 522 When a TE link is in the Degraded state, routing and signaling 523 SHOULD be notified so that new connections are not accepted and 524 resources are no longer advertised for the TE link. 526 4. Link Property Correlation 528 As part of LMP, a link property correlation exchange is defined 529 using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages. 530 The contents of these messages are built using TLV triplets. 531 LinkSummary TLVs can be either negotiable or non-negotiable 532 (identified by the N flag in the TLV header). Negotiable TLVs can 533 be used to let both sides agree on certain link parameters. Non- 534 negotiable TLVs are used for announcment of specific values that do 535 not need, or do not allow, negotiation. 537 The LinkSummary message is used to aggregate multiple data links 538 (either ports or component links) into a TE link; exchange, 539 correlate, or change TE link parameters; and exchange, correlate, or 540 change Interface Ids (either Port Ids or Component Interface Ids). 542 The LinkSummary message can be exchanged at any time a link is UP 543 and not in the Verification process. The LinkSummary mesasge MUST 544 be periodically transmitted until (1) the node receives a 545 LinkSummaryAck or LinkSummaryNack message or (2) a timeout expires 546 and no LinkSummaryAck or LinkSummaryNack message has been received. 547 Both the retransmission interval and the timeout period are local 548 configuration parameters. 550 If the LinkSummary message is received from a remote node and the 551 Interface Id mappings match those that are stored locally, then the 552 two nodes have agreement on the Verification process (see Section 553 5). If the verification procedure is not used, the LinkSummary 554 message can be used to verify agreement on manual configuration. 556 Furthermore, any protection definitions that are included in the 557 LinkSummary message MUST be accepted or rejected by the local node. 558 The LinkSummaryAck message is used to signal agreement on the 559 Interface Id mappings and link property definitions. Otherwise, a 560 LinkSummaryNack message MUST be transmitted, indicating which 561 Interface mappings are not correct and/or which link properties are 562 not accepted. If a LinkSummaryNack message indicates that the 563 Interface Id mappings are not correct and the link verification 564 procedure is enabled, the link verification process SHOULD be 565 repeated for all mismatched free data links; if an allocated data 566 link has a mapping mismatch, it SHOULD be flagged and verified when 567 it becomes free. 569 It is possible that the LinkSummary message could grow quite large 570 due to the number of Data Link TLVs. Since the LinkSummary message 571 is IP encoded, normal IP fragmentation should be used if the 572 resulting PDU exceeds the MTU. 574 5. Verifying Link Connectivity 576 In this section, we describe an optional mechanism that may be used 577 to verify the physical connectivity of the data-bearing links 578 (either ports or component links). The use of this procedure is 579 negotiated as part of the configuration exchange using the 580 Verification Procedure flag of the LMP Capability TLV. The 581 procedure SHOULD be done when establishing a TE link, and 582 subsequently, on a periodic basis for all unallocated (free) data 583 links of the TE link. 585 A unique characteristic of all-optical PXCs is that the data-bearing 586 links are not terminated at the PXC, but instead passes through 587 transparently. This characteristic of PXCs poses a challenge for 588 validating the connectivity of the data links since shining 589 unmodulated light through a link may not result in received light at 590 the next PXC. This is because there may be terminating (or opaque) 591 elements, such as DWDM equipment, in between the PXCs. Therefore, 592 to ensure proper verification of data link connectivity, we require 593 that until the links are allocated, they must be opaque. To support 594 various degrees of opaqueness (e.g., examining overhead bytes, 595 terminating the payload, etc.), and hence different mechanisms to 596 transport the Test messages, a Verify Transport Mechanism is 597 included in the BeginVerify and BeginVerifyAck messages. There is 598 no requirement that all data links be terminated simultaneously, but 599 at a minimum, the data links must be able to be terminated one at a 600 time. Furthermore, we assume that the nodal architecture is 601 designed so that messages can be sent and received over any data 602 link. Note that this requirement is trivial for DXCs (and OEO 603 devices in general) since each data link is received electronically 604 before being forwarded to the next DXC, but that in PXCs this is an 605 additional requirement. 607 To interconnect two nodes, a TE link is added between them, and at a 608 minimum, there MUST be at least one active control channel between 609 the nodes. A TE link MUST include at least one data link. 611 Once a control channel has been established between the two nodes, 612 data link connectivity can be verified by exchanging Ping-type Test 613 messages over each of the data links specified in the bundled link. 614 It should be noted that all LMP messages except for the Test message 615 are exchanged over the control channel and that Hello messages 616 continue to be exchanged over the control channel during the data 617 link verification process. The Test message is sent over the data 618 link that is being verified. Data links are tested in the transmit 619 direction as they are uni-directional, and as such, it may be 620 possible for both nodes to exchange the Test messages 621 simultaneously. 623 To initiate the link verification process, the local node MUST send 624 a BeginVerify message over the control channel. The BeginVerify 625 message contains fields for the local and remote TE Link Ids. When 626 non-zero, these fields limit the scope of the data links being 627 verified to the corresponding TE link; if the fields are zero, the 628 data links can span multiple TE links and/or they may comprise a TE 629 link that is yet to be configured. The BeginVerify message contains 630 the number of data links that are to be verified; the interval 631 (called VerifyInterval) at which the Test messages will be sent; the 632 encoding scheme, the transport mechanisms that are supported, and 633 data rate for Test messages; when the data links correspond to 634 fibers, the wavelength over which the Test messages will be 635 transmitted is also included. 637 The BeginVerify message MUST be periodically transmitted until (1) 638 the node receives either a BeginVerifyAck or BeginVerifyNack message 639 to accept or reject the verify process or (2) a timeout expires and 640 no BeginVerifyAck or BeginVerifyNack message has been received. 641 Both the retransmission interval and the timeout period are local 642 configuration parameters. 644 If the remote node receives a BeginVerify message and it is ready to 645 process Test messages, it MUST send a BeginVerifyAck message back to 646 the local node specifying the desired transport mechanism for the 647 TEST messages. The remote node includes a 32-bit node unique 648 VerifyID in the BeginVerifyAck message. The VerifyID is then used 649 in all corresponding Test messages to differentiate them from 650 different LMP peers and/or parallel Test procedures. When the local 651 node receives a BeginVerifyAck message from the remote node, it may 652 begin testing the data links by transmitting periodic Test messages 653 over each data link. The Test message includes the Verify Id and 654 the local Interface Id for the associated data link. The remote 655 node MUST send either a TestStatusSuccess or a TestStatusFailure 656 message in response for each data link. A TestStatusAck message 657 MUST be sent to confirm receipt of the TestStatusSuccess and 658 TestStatusFailure messages. 660 The local (transmitting) node sends a given Test message 661 periodically (at least once every VerifyInterval ms) on the 662 corresponding data link until (1) it receives a correlating 663 TestStatusSuccess or TestStatusFailure message on the control 664 channel from the remote (receiving) node or (2) all active control 665 channels between the two nodes have failed. The remote node will 666 send a given TestStatus message periodically over the control 667 channel until it receives either a correlating TestStatusAck message 668 or an EndVerify message is received over the control channel. 670 It is also permissible for the sender to terminate the Test 671 procedure without receiving a TestStatusSuccess or TestStatusFailure 672 message by sending an EndVerify message. Message correlation is 673 done using message identifiers and the Verify Id; this enables 674 verification of data links, belonging to different link bundles or 675 LMP sessions, in parallel. 677 When the Test message is detected at a node, the received Interface 678 Id (used in GMPLS as either a Port Id or Component Interface Id 679 depending on the configuration) is recorded and mapped to the local 680 Interface Id for that channel. The receipt of a TestStatusSuccess 681 message indicates that the Test message was detected at the remote 682 node and the physical connectivity of the data link has been 683 verified. The TestStatusSuccess message includes the local 684 Interface Id and the remote Interface Id (received in the Test 685 message), along with the VerifyId received in the Test message. 686 When the TestStatusSuccess message is received, the local node 687 SHOULD mark the data link as UP, send a TestStatusAck message to the 688 remote node, and begin testing the next data link. If, however, the 689 Test message is not detected at the remote node within an 690 observation period (specified by the VerifyDeadInterval), the remote 691 node will send a TestStatusFailure message over the control channel 692 indicating that the verification of the physical connectivity of the 693 data link has failed. When the local node receives a 694 TestStatusFailure message, it will mark the data link as FAILED, 695 send a TestStatusAck message to the remote node, and begin testing 696 the next data link. When all the data links on the list have been 697 tested, the local node SHOULD send an EndVerify message to indicate 698 that testing has been completed on this link. The EndVerify message 699 will be periodically transmitted until an EndVerifyAck message has 700 been received. 702 Both the local and remote nodes SHOULD maintain the complete list of 703 Interface Id mappings for correlation purposes. 705 5.1. Example of Link Connectivity 707 Figure 1 shows an example of the link verification scenario that is 708 executed when a link between PXC A and PXC B is added. In this 709 example, the TE link consists of three free ports (each transmitted 710 along a separate fiber) and is associated with a bi-directional 711 control channel (indicated by a "c"). The verification process is as 712 follows: PXC A sends a BeginVerify message over the control channel 713 �c� to PXC B indicating it will begin verifying the ports. PXC B 714 receives the BeginVerify message and returns the BeginVerifyAck 715 message over the control channel to PXC A. When PXC A receives the 716 BeginVerifyAck message, it begins transmitting periodic Test 717 messages over the first port (Interface Id=1). When PXC B receives 718 the Test messages, it maps the received Interface Id to its own 719 local Interface Id = 10 and transmits a TestStatusSuccess message 720 over the control channel back to PXC A. The TestStatusSuccess 721 message will include both the local and received Interface Ids for 722 the port. PXC A will send a TestStatusAck message over the control 723 channel back to PXC B indicating it received the TestStatusSuccess 724 message. The process is repeated until all of the ports are 725 verified. At this point, PXC A will send an EndVerify message over 726 the control channel to PXC B to indicate that testing is complete 727 and PXC B will respond by sending an EndVerifyAck message over the 728 control channel back to PXC A. 730 +---------------------+ +---------------------+ 731 + + + + 732 + PXC A +<-------- c --------->+ PXC B + 733 + + + + 734 + + + + 735 + 1 +--------------------->+ 10 + 736 + + + + 737 + + + + 738 + 2 + /---->+ 11 + 739 + + /----/ + + 740 + + /---/ + + 741 + 3 +----/ + 12 + 742 + + + + 743 + + + + 744 + 4 +--------------------->+ 14 + 745 + + + + 746 +---------------------+ +---------------------+ 748 Figure 2: Example of link connectivity between PXC A and PXC B. 750 6. Fault Management 752 In this section, we describe an optional LMP mechanism that is used 753 to manage failures by rapidly locating link or channel failures. 754 The use of this procedure is negotiated as part of the configuration 755 exchange using the Fault Management Procedure flag of the LMP 756 Capability TLV. As before, we assume each link has a bi-directional 757 control channel that is always available for inter-node 758 communication and that the control channel spans a single hop 759 between two neighboring nodes. The case where a control channel is 760 no longer available between two nodes is beyond the scope of this 761 draft. The mechanism used to rapidly isolate link failures is 762 designed to work for unidirectional LSPs, and can be easily extended 763 to work for bi-directional LSPs; however, for the purposes of this 764 document, we only discuss the operation when the LSPs are 765 unidirectional. 767 Recall that a TE link connecting two nodes may consist of a number 768 of data links (ports or component links). If one or more data links 769 fail between two nodes, a mechanism must be used to rapidly locate 770 the failure so that appropriate protection/restoration mechanisms 771 can be initiated. An important implication of using PXCs is that 772 traditional methods that are used to monitor the health of allocated 773 data links in OEO nodes (e.g., DXCs) may no longer be appropriate, 774 since PXCs are transparent to the bit-rate, format, and wavelength. 775 Instead, fault detection is delegated to the physical layer (i.e., 776 loss of light or optical monitoring of the data) instead of layer 2 777 or layer 3. 779 6.1. Fault Detection 781 As mentioned earlier, fault detection must be handled at the layer 782 closest to the failure; for optical networks, this is the physical 783 (optical) layer. One measure of fault detection at the physical 784 layer is simply detecting loss of light (LOL). Other techniques for 785 monitoring optical signals are still being developed and will not be 786 further considered in this document. However, it should be clear 787 that the mechanism used to locate the failure is independent of the 788 mechanism used to detect the failure, but simply relies on the fact 789 that a failure is detected. 791 6.2. Fault Localization Mechanism 793 If data links fail between two PXCs, the power monitoring system in 794 all of the downstream nodes may detect LOL and indicate a failure. 795 To correlate multiple failures between a pair of nodes, a monitoring 796 window can be used in each node to determine if a single data link 797 has failed or if multiple data links (possibly an entire TE link) 798 have failed. 800 As part of the fault localization, a downstream node that detects 801 data link failures will send a ChannelFail message to its upstream 802 neighbor (bundling together the notification of all of the failed 803 data links). An upstream node that receives the ChannelFail message 804 will correlate the failure to see if there is a failure on the 805 corresponding LSP(s). If the failure has also been detected on the 806 input port(s) of the upstream node, the node will return a 807 ChannelFailAck message to the downstream node (bundling together the 808 notification of all the data links), indicating that it too has 809 detected a failure. If, however, the fault is CLEAR in the upstream 810 node (e.g., there is no LOL on the corresponding input channels), 811 then the upstream node will have localized the failure and will 812 return a ChannelFailNack message to the downstream node. Once the 813 failure has been localized, the signaling protocols can be used to 814 initiate span or path protection/restoration procedures. 816 If all of the data links of a TE link have failed, then the upstream 817 node MAY be notified of the TE link failure without specifying that 818 each data link of the TE link has failed. To do this, the Interface 819 Id of the ChannelFail subobject MUST be 0. 821 6.3. Channel Activiation Indication 823 The ChannelActive message is the counterpart to the ChannelFail 824 message described in Section 6.2 and is used to notify the 825 downstream neighboring node that the data link is in the Active 826 state. This is particularly useful in networks with transparent 827 nodes where the status of data links may need to be triggered using 828 control channel messages. For example, if a data link is pre- 829 provisioned and the physical link fails after verification and 830 before inserting user traffic, the pair of nodes need a mechanism to 831 indicate the data link is active or they may not be able to detect 832 the failure. 834 The ChannelActive message is used to indicate that a channel or 835 group of channels are now active. The ChannelActiveAck message MUST 836 be transmitted upon receipt of a ChannelActive message. When a 837 ChannelActive message is received, the corresponding data link(s) 838 MUST be put into the Active state. If upon putting them into the 839 Active state, a failure is detected, the ChannelFail message MUST be 840 transmitted as described in Section 6.2. 842 6.4. Examples of Fault Localization 844 In Fig. 2, a sample network is shown where four PXCs are connected 845 in a linear array configuration. The control channels are bi- 846 directional and are labeled with a "c". All LSPs are uni- 847 directional going left to right. 849 In the first example [see Fig. 2(A)], there is a failure on a single 850 data link between PXC2 and PXC3. Both PXC3 and PXC4 will detect the 851 failure and each node will send a ChannelFail message to the 852 corresponding upstream node (PXC3 will send a message to PXC2 and 853 PXC4 will send a message to PXC3). When PXC3 receives the 854 ChannelFail message from PXC4, it will correlate the failure and 855 return a ChannelFailAck message back to PXC4. Upon receipt of the 856 ChannelFailAck message, PXC4 will move the associated ports into a 857 standby state. When PXC2 receives the ChannelFail message from PXC3, 858 it will correlate the failure, verify that it is CLEAR, localize the 859 failure to the data link between PXC2 and PXC3, and send a 860 ChannelFailNack message back to PXC3. 862 In the second example [see Fig. 2(B)], there is a failure on three 863 data links between PXC3 and PXC4. In this example, PXC4 has 864 correlated the failures and will send a bundled ChannelFail message 865 for the three failures to PXC3. PXC3 will correlate the failures, 866 localize them to the channels between PXC3 and PXC4, and return a 867 bundled ChannelFailNack message back to PXC4. 869 In the last example [see Fig. 2(C)], there is a failure on the 870 tributary link of the ingress node (PXC1) to the network. Each 871 downstream node will detect the failure on the corresponding input 872 ports and send a ChannelFail message to the upstream neighboring 873 node. When PXC2 receives the message from PXC3, it will correlate 874 the ChannelFail message and return a ChannelFailAck message to PXC3 875 (PXC3 and PXC4 will also act accordingly). Since PXC1 is the ingress 876 node to the optical network, it will correlate the failure and 877 localize the failure to the data link between itself and the network 878 element outside the optical network. 880 +-------+ +-------+ +-------+ +-------+ 881 + PXC 1 + + PXC 2 + + PXC 3 + + PXC 4 + 882 + +-- c ---+ +-- c ---+ +-- c ---+ + 883 ----+---\ + + + + + + + 884 + \--+--------+-------+---\ + + + /--+---> 885 ----+---\ + + + \---+-------+---##---+---/ + 886 + \--+--------+-------+--------+-------+---##---+-------+---> 887 ----+-------+--------+-------+--------+-------+---##---+-------+---> 888 ----+-------+--------+---\ + + + (B) + + 889 + + + \--+---##---+--\ + + + 890 + + + + (A) + \ + + + 891 -##-+--\ + + + + \--+--------+-------+---> 892 (C) + \ + + /--+--------+---\ + + + 893 + \--+--------+---/ + + \--+--------+-------+---> 894 + + + + + + + + 895 +-------+ +-------+ +-------+ +-------+ 897 Figure 3: We show three types of data link failures (indicated 898 by ## in the figure): (A) a single data link fails 899 between two PXCs, (B) three data links fail between 900 two PXCs, and (C) a single data link fails on the 901 tributary input of PXC 1. The control channel 902 connecting two PXCs is indicated with a "c". 904 7. LMP Authentication 906 LMP authentication is optional (included in the Common Header) and, 907 if used, MUST be supported by both sides of the control channel. The 908 method used to authenticate LMP packets is based on the 909 authentication technique used in [OSPF]. This uses cryptographic 910 authentication using MD5. 912 As a part of the LMP authentication mechanism, a flag is included in 913 the LMP common header indicating the presence of authentication 914 information. Authentication information itself is appended to the 915 LMP packet. It is not considered to be a part of the LMP packet, but 916 is transferred in the same IP packet. 918 When the Authentication flag is set in the LMP packet header, an 919 authentication data block is attached to the packet. This block has 920 a standard authentication header and a data portion. The contents of 921 the data portion depend on the authentication type. Currently, only 922 MD5 is supported for LMP. 924 8. LMP Finite State Machines 926 8.1. Control Channel FSM 927 The control channel FSM defines the states and logics of operation 928 of an LMP control channel. The description of FSM state transitions 929 and associated actions is given in Section 3. 931 8.1.1. Control Channel States 933 A control channel can be in one of the states described below. 934 Every state corresponds to a certain condition of the control 935 channel and is usually associated with a specific type of LMP 936 message that is periodically transmitted to the far end. 938 Down: This is the initial control channel state. In this 939 state, no attempt is being made to bring the control 940 channel up and no LMP messages are sent. The control 941 channel parameters should be set to the initial values. 943 ConfigSnd: The control channel is in the parameter negotiation 944 state. In this state the node periodically sends a 945 Config message, and is expecting the other side to 946 reply with either a ConfigAck or ConfigNack message. 947 The FSM does not transition into the Active state until 948 the remote side positively acknowledges the parameters. 950 ConfRcv: The control channel is in the parameter negotiation 951 state. In this state, the node is waiting for 952 acceptable configuration parameters from the remote 953 side. Once such parameters are received and 954 acknowledged, the FSM can transition to the Active 955 state. 957 Active: In this state the node periodically sends a Hello 958 message and is waiting to receive a valid Hello 959 message. Once a valid Hello message is received, it 960 can transition to the UP state. 962 Up: The CC is in an operational state. The node receives 963 valid Hello messages and sends Hello messages. 965 GoingDown: A CC may go into this state because of two reasons: 966 administrative action, and a ControlChannelDown bit 967 received in an LMP message. While a CC is in this 968 state, the node sets the ControlChannelDown bit in all 969 the messages it sends. 971 8.1.2. Control Channel Events 973 Operation of the LMP control channel is described in terms of FSM 974 states and events. Control channel Events are generated by the 975 underlying protocols and software modules, as well as by the packet 976 processing routines and FSMs of associated TE links. Every event 977 has its number and a symbolic name. Description of possible control 978 channel events is given below. 980 1 : evBringUp: This is an externally triggered event indicating 981 that the control channel negotiation should begin. 982 This event, for example, may be triggered by a 983 provisioner command or by the successful 984 completion of a control channel bootstrap 985 procedure. Depending on the configuration, this 986 will trigger either 987 1a) the sending of a Config message, 988 1b) a period of waiting to receive a Config 989 message from the remote node. 991 2 : evCCDn: This event is generated when there is indication 992 that the control channel is no longer available. 994 3 : evConfDone: This event indicates a ConfigAck message has been 995 received, acknowledging the Config parameters. 997 4 : evConfErr: This event indicates a ConfigNack message has been 998 received, rejecting the Config parameters. 1000 5 : evNewConfOK: New Config message was received from neighbor and 1001 positively Acknowledged. 1003 6 : evNewConfErr: New Config message was received from neighbor and 1004 rejected with a ConfigNack message. 1006 7 : evContenWin: New Config message was received from neighbor at 1007 the same time a Config message was sent to the 1008 neighbor. The Local node wins the contention. As 1009 a result, the received Config message is ignored. 1011 8 : evContenLost: New Config message was received from neighbor at 1012 the same time a Config message was sent to the 1013 neighbor. The Local node looses the contention. 1014 As a result, the node must (positively or 1015 negatively) respond to the Config message. 1017 9 : evAdminDown: The administrator has requested that the control 1018 channel is brought down administratively. 1020 10: evDownOk: A packet with the LinkDown flag has been received 1021 and the local node was the initiator of the link 1022 down procedure. 1024 11: evDownErr: A timer has expired indicating that the other node 1025 did not start setting the LinkDown flag in its 1026 messages. 1028 12: evNbrGoesDn: A packet with LinkDown flag is received from the 1029 neighbor. 1031 13: evHelloRcvd: A Hello packet with expected SeqNum has been 1032 received. 1034 14: evHoldTimer: The HelloDeadInterval timer has expired indicating 1035 that no Hello packet has been received. This 1036 moves the control channel back into the 1037 Negotiation state, and depending on the local 1038 configuration, this will trigger either 1039 14a) the sending of periodic Config messages, 1040 14b) a period of waiting to receive Config 1041 messages from the remote node. 1043 15: evSeqNumErr: A Hello with unexpected SeqNum received and 1044 discarded. 1046 16: evReconfig: Control channel parameters have been reconfigured 1047 and require renegotiation. 1048 17: evConfRet: A retransmission timer has expired and a Config 1049 message is resent. 1050 18: evHelloRet: The HelloInterval timer has expired and a Hello 1051 packet is sent. 1053 8.1.3 Control Channel FSM Description 1055 Figure 4 illustrates operation of the control channel FSM 1056 in a form of FSM state transition diagram. 1058 +--------+ 1059 +----------->| |<--------------+ 1060 | | Down |<----------+ | 1061 | +--------| |<-------+ | | 1062 | | +--------+ | | | 1063 | | | ^ 2| 2| 2| 1064 | |1b 1a| | | | | 1065 | | v | 2 | | | 1066 | | +--------+ | | | 1067 | | +->| |<------+| | | 1068 | | 4,7,| |ConfSnd | || | | 1069 | | 17 +--| |<----+ || | | 1070 | | +--------+ | || | | 1071 | | 3| | | || | | 1072 | | +--------+ |8 4,14a| || | | 1073 | | | v | || | | 1074 | +-|----->+--------+ | || | | 1075 | | +->| |-----|-|+ | | 1076 | | 6| |ConfRcv | | | | | 1077 | | +--| |<--+ | | | | 1078 | | +--------+ | | | | | 1079 | | 5| ^ | | | | | 1080 | +--------+ | | | | | | | 1081 | | | | | | | | | 1082 |10,2 v v |6,14b | | | | | 1083 +--------+ +--------+ | | | | | 1084 | | +--| |---|-+ | | | 1085 | GoingDn| 5,18| | Active |-------|---+ | 1086 | | +->| | | | | 1087 +--------+ +--------+ | | | 1088 ^ 13| ^ | | | 1089 | | |5 | | | 1090 | v | 6,14b| | | 1091 |9,12 +--------+ | |14a,16 | 1092 +------------| |---+ | | 1093 | Up |-------+ | 1094 | |---------------+ 1095 +--------+ 1096 | ^ 1097 | | 1098 +---+ 1099 13,15,18 1100 Figure 4: Control Channel FSM 1102 Event evCCDn always forces the FSM to the Down State. Events 1103 evHoldTimer evReconfig always force the FSM to the Negotiation state 1104 (either ConfigSnd or ConfigRcv). 1106 8.2 TE Link FSM 1108 The TE Link FSM defines the states and logics of operation of an LMP 1109 TE Link. 1111 8.2.1 TE Link States 1113 An LMP TE link can be in one of the states described below. Every 1114 state corresponds to a certain condition of the TE link and is 1115 usually associated with a specific type of LMP message that is 1116 periodically transmitted to the far end via the associated control 1117 channel or in-band via the data links. 1119 Down: There are no control channels available and no data 1120 links are allocated to the TE link. 1122 LinkVrf: In this state, the link verification procedure is 1123 performed for the data links of the TE link. LinkVrf is 1124 a composite state that consists of two substates 1125 described below. 1127 VrfBegin: This state is valid only for the side initiating the 1128 verification process. In this state, the node 1129 periodically sends a BeginVerify message and expects an 1130 BeginVerifyAck or BeginVerifyNack message. The 1131 BeginVerify messages include information about the data 1132 links in the BegVerify state. 1134 VrfProcess: In this state, two FSMs are performing the link 1135 verification procedure. The initiator periodically sends 1136 Test messages over the data links in the Testing state 1137 and waits for TestStatus messages to be received over a 1138 control channel. The passive side listens for incoming 1139 link test messages on the data links in the PasvTst 1140 state. 1142 VrfResult: In this state, the passive side periodically retransmits 1143 the TestStatus messages for the data links verified 1144 during the link verification procedure and waits for 1145 acknowledgement. Once all messages have been 1146 acknowledged, the passive side can go out of VrfResult 1147 state. The initiator waits for the incoming TestStatus 1148 message and goes out of it after receiving and 1149 acknowledging TestStatus messages for all data links. 1150 Note that the initiator must be prepared to receive and 1151 acknowledge the TestStatus messages even after it has 1152 transitioned out of the VrfResult state. 1154 Summary: In this state, the new TE link configuration is 1155 announced by periodically sending the LinkSummary 1156 messages over the control channel. 1158 Up: This is the normal operational state of the TE link. At 1159 least one primary CC is required to be operational 1160 between the nodes sharing the TE link. 1162 Degraded: In this state, all primary CCs are down, but the TE link 1163 still includes some allocated data links. 1165 STDBY: A ChannelFail message has been received indicating a 1166 failure has been detected on the far-end node of the TE 1167 link. The failure is locally correlated to determine if 1168 the failure can be localized to the TE link or if the 1169 failure is further upstream along the path. 1171 8.2.2 TE Link Events 1173 Operation of the LMP TE link is described in terms of FSM states and 1174 events. TE Link events are generated by the packet processing 1175 routines and by the FSMs of the associated primary control 1176 channel(s) and the data links. Every event has its number and a 1177 symbolic name. Description of possible control channel events is 1178 given below. 1180 1 : evCCUp: First primary CC goes Up 1181 2 : evCCDown: Last primary CC goes Down 1182 3 : evVerDone: Verification done; EndVerifyAck message 1183 received. 1184 4 : evVerify: An external event indicates that the Link 1185 verification procedure should begin. 1186 5 : evRecnfReq: TE link has been reconfigured and the new 1187 configuration needs to be announced/agreed upon. 1188 6 : evSummaryAck: LinkSummaryAck message has been received 1189 acknowledging the TE link configuration. 1190 7 : evLastCompDn: The last allocated data link has been freed. 1191 8 : evStartVer: BeginVerifyAck message has been received 1192 indicating the remote node is ready to start 1193 link verification. 1194 9 : evTELinkOk: An external event has indicated that the TE link 1195 is available. 1196 10: evBeginRet: Retransmission timer expires and no 1197 BeginVerifyAck or BeginVerifyNack message has 1198 been received. BeginVerify message is resent. 1199 11: evSummaryRet: Retransmission timer expires and no 1200 LinkSummaryAck or LinkSummaryNack message has 1201 been received. LinkSummary message is resent. 1202 12: evChannFail: ChannelFail message is received for TE link. 1203 The failure is locally correlated and either a 1204 ChannelFailAck or a ChannelFailNack message is 1205 transmitted. 1206 13: evNodeReBoot: The neighboring node has rebooted. 1207 14: evSummaryNack1: LinkSummaryNack message has been received 1208 indicating negotiable parameters not accepted. 1210 15: evSummaryNack2 LinkSummaryNack message received indicating 1211 misconfiguration of non-negotiable parameters. 1212 Free ports that are misconfigured are moved to 1213 Down state. Allocated ports that are 1214 misconfigured are flagged. 1215 16: evSummaryNack3: LinkSummaryNack message has been received 1216 indicating misconfiguration of non-negotiable 1217 parameters for all ports. 1219 8.2.3 TE Link FSM Description 1221 Figure 5 illustrates operation of the LMP TE Link FSM in a form of 1222 FSM state transition diagram. 1224 +--------+ 1225 +------------>| | 1226 | +----->| Down | 1227 | | +----| | 1228 | | | +--------+ 1229 | | | | 1230 | | | 4| 1231 | | |9 | 1232 | | | v 1233 | | | +--------+ 1234 | | | 2 | |<-+ 1235 | +---|-|----| VrfBeg | |10 1236 | | | | | |--+ 1237 | | | | +--------+ 1238 | | | | 8| ^ 1239 | | | | | | 1240 | | | | | +---------+ 1241 | | | | v | 1242 | | | | +-------+ | 1243 | | | | 2 | | | 1244 | +---|-|----|VrfProc| | 1245 | | | | | | | 1246 | | | | +-------+ | 1247 | | | | 3| | 1248 | | | | | +----------+ 1249 | | | | v |4 | 1250 | | | | 16 +-------+ | 1251 | | +-|----| |<-+ | 1252 | | +--->|Summary| |11,14 | 1253 | | +--------| |--+ | 1254 | | |2 +-------+ | 1255 | | | 6,15| ^ | 1256 | | | | | | 1257 | | | | | | 1258 |7 | | | | | 1259 | v v v |5,13 | 1260 +--------+ +--------+ | 1261 | |1 | |--------+ 1262 | Deg |------>| Up | 4 1263 | |<------| | 1264 +--------+ 2+--------+ 1265 | ^ 1266 | | 1267 +--+ 1268 12 1270 Figure 5: LMP TE Link FSM 1272 8.3 Data Link FSM 1274 The data link FSM defines the states and logics of operation of a 1275 port or component link within an LMP TE link. Operation of a data 1276 link is described in terms of FSM states and events. Data-bearing 1277 links can either be in the active (transmitting) state, where Test 1278 messages are transmitted from them, or the passive (receiving) 1279 state, where Test messages are received through them. For clarity, 1280 we define separate FSMs for the active/passive data-bearing links; 1281 however, we define a single set of data link states and events. 1283 8.3.1 Data Link States 1285 Any data link can be in one of the states described below. Every 1286 state corresponds to a certain condition of the TE link. 1288 Down: The data link has not been put in the resource pool. 1290 Test: The data link is being tested. An LMP Test message 1291 is periodically sent through the link. 1293 PasvTest: The data link is being checked for incoming test 1294 messages. 1296 Retest: The data link is being re-validated. An LMP Test 1297 message is periodically sent through the link. 1299 PasvRetest: The data link is being checked for incoming 1300 test.messages as part of link re-validation. 1302 Up/Free: The link has been successfully tested and is now put 1303 in the pool of resources. The link has not yet been 1304 allocated to data traffic. 1306 Up/Allocated: The link has been allocated for data traffic. 1308 Degraded: The link was in the Up/Allocated state when the last 1309 CC associated with data link's TE Link has gone down. 1310 The link is put in the Degraded state, since it is 1311 still being used for data LSP. 1313 TstRecv: A Test message has been detected on the data link and 1314 a TestStatusSuccess message has been sent to the 1315 transmitter over the control channel. 1317 8.3.2 Data Link Events 1319 Data bearing link events are generated by the packet processing 1320 routines and by the FSMs of the associated control channel and the 1321 TE link. Every event has its number and a symbolic name. 1322 Description of possible data link events is given below: 1324 1 :evCCUp: CC has gone up. 1325 2 :evCCDown: LMP neighbor connectivity is lost. This indicates 1326 the last LMP control channel has failed between 1327 neighboring nodes. 1328 3 :evStartTst: This is an external event that triggers the sending 1329 of Test messages over the data bearing link. 1331 4 :evStartPsv: This is an external event that triggers the 1332 listening for Test messages over the data bearing 1333 link. 1335 5 :evTestOK: Link verification was successful and the link can 1336 be used for path establishment. 1337 (a) This event indicates the Link Verification 1338 procedure (see Section 5) was successful 1339 for this data link and a TestStatusSuccess 1340 message was received over the control 1341 channel. 1342 (b) This event indicates the link is ready for 1343 path establishment, but the Link 1344 Verification procedure was not used. For 1345 in-band signaling of the control channel, 1346 the control channel establishment may be 1347 sufficient to verify the link. 1348 6 :evTestRcv: Test message was received over the data port and a 1349 TestStatusSuccess message is transmitted over the 1350 control channel. 1351 7 :evTestFail: Link verification returned negative results. This 1352 could be because (a) a ChannelStatusFailure message 1353 was received, or (b) an EndVerifyAck message was 1354 received without receiving a ChannelStatusSuccess 1355 or ChannelStatusFailure message for the data link. 1356 8 :evPsvTestFail:Link verification returned negative results. This 1357 indicates that a Test message was not detected and 1358 either (a) the VerifyDeadInterval has expired or 1359 (b) an EndVerifyAck messages has been received and 1360 the VerifyDeadInterval has not yet expired. 1361 9 :evLnkAlloc: The data link has been allocated. 1362 10:evLnkDealloc: The data link has been deallocated. 1363 11:evTestRet: A retransmission timer has expired and the Test 1364 message is resent. 1366 11:evVerifyAbrt: The other side did not confirm it is ready to 1367 perform link verification. 1368 12:evSummaryFail:The LinkSummary did not match for this data port. 1370 7.3.3 Active Data Link FSM Description 1372 Figure 6 illustrates operation of the LMP active data link FSM in a 1373 form of FSM state transition diagram. 1375 +------+ 1376 +------------->| | 1377 | +--------->| Down |<---------+ 1378 | | +----| | | 1379 | | | +------+ | 1380 | | |5b 3| ^ | 1381 | | | | |2,7 | 1382 | | | v | | 1383 | | | +------+ | 1384 | | | | |<-+ | 1385 | | | | Test | |11 | 1386 | | | | |--+ | 1387 | | | +------+ | 1388 | | | 5a| | 1389 | | | | |2,7 1390 | | | v | 1391 | |2,12 | +---------+ 3 +--------+ 1392 | | +-->| |---->| | 1393 | | | Up/Free | | Retest | 1394 | +---------| |<----| | 1395 | +---------+ 5a +--------+ 1396 | 9| ^ 1397 | | | 1398 |10 v |10 1399 +-----+ 2 +---------+ 1400 | |<--------| | 1401 | Deg | |Up/Alloc | 1402 | |-------->| | 1403 +-----+ 1 +---------+ 1405 Figure 6: Active LMP Data Link FSM 1407 8.3.3 Passive Data Link FSM Description 1409 Figure 7 illustrates operation of the LMP passive data link FSM in a 1410 form of FSM state transition diagram. 1412 +------+ 1413 +----------->| | 1414 | +-------->| Down |<-----------+ 1415 | | +-----| | | 1416 | | | +------+ | 1417 | | |5b 4| ^ | 1418 | | | | |2 | 1419 | | | v | | 1420 | | | +----------+ | 1421 | | | | PasvTest | | 1422 | | | +----------+ | 1423 | | | 6| | 1424 | | | | |2 1425 | | | v | 1426 | |2,12 | +---------+ 4 +------------+ 1427 | | +--->| Up/Free |---->| | 1428 | | | | | PasvRetest | 1429 | +----------| |<----| | 1430 | +---------+ 5b +------------+ 1431 | 9| ^ 1432 | | | 1433 |10 v |10 1434 +-----+ +---------+ 1435 | | 2 | | 1436 | Deg |<--------|Up/Alloc | 1437 | |-------->| | 1438 +-----+ 1 +---------+ 1440 Figure 7: Passive LMP Data Link FSM 1441 9. LMP Message Formats 1443 All LMP messages are IP encoded (except, in some cases, the Test 1444 message are limited by the transport mechanism for in-band 1445 messaging) with protocol Id = 140 (value not yet assigned by IANA). 1447 9.1. Common Header 1449 In addition to the standard IP header, all LMP messages (except, in 1450 some cases, the Test messages are limited by the transport mechanism 1451 for in-band messaging) have the following common header: 1453 0 1 2 3 1454 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 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | Vers | (Reserved) | Flags | Msg Type | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | LMP Length | Checksum | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Local Control Channel Id | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 Vers: 4 bits 1465 Protocol version number. This is version 1. 1467 Flags: 8 bits. The following values are defined. All other values 1468 are reserved. 1470 0x01: ControlChannelDown 1472 0x02: Node Reboot 1474 This bit is set to indicate the node has rebooted. This 1475 flag may be reset to 0 when a Hello message is received 1476 with RcvSeqNum equal to the local TxSeqNum. 1478 0x04: DWDM Node 1480 If this bit is set, the node is identifying itself as a 1481 DWDM system. This is used when running LMP-DWDM 1482 extensions as defined in [LMP-DWDM]. 1484 0x08: Authenticatino 1486 When set, this bit indicates that an authentication 1487 block is attached at the end of the LMP message. See 1488 Sections 7 and 8.3 for more details. 1490 Msg Type: 8 bits. The following values are defined. All other 1491 values are reserved. 1493 1 = Config 1495 2 = ConfigAck 1497 3 = ConfigNack 1499 4 = Hello 1501 5 = BeginVerify 1503 6 = BeginVerifyAck 1505 7 = BeginVerifyNack 1507 8 = EndVerify 1509 9 = EndVerifyAck 1510 10 = Test 1512 11 = TestStatusSuccess 1514 12 = TestStatusFailure 1516 13 = TestStatusAck 1518 14 = LinkSummary 1520 15 = LinkSummaryAck 1522 16 = LinkSummaryNack 1524 17 = ChannelFail 1526 18 = ChannelFailAck 1528 19 = ChannelFailNack 1530 20 = ChannelActive 1532 21 = ChannelActiveAck 1534 All of the messages are sent over the control channel EXCEPT 1535 the Test message which is sent over the data link that is being 1536 tested. 1538 LMP Length: 16 bits 1540 The total length of this LMP message in bytes, including the 1541 common header and any variable-length objects that follow. 1543 Checksum: 16 bits 1545 The standard IP checksum of the entire contents of the LMP 1546 message, starting with the LMP message header. This checksum is 1547 calculated as the 16-bit one's complement of the one's 1548 complement sum of all the 16-bit words in the packet. If the 1549 packet's length is not an integral number of 16-bit words, the 1550 packet is padded with a byte of zero before calculating the 1551 checksum. 1553 Local Control Channel Id: 32 bits 1555 The Local Control Channel Id (CCId) identifies the control 1556 channel of the sender associated with the message and is node- 1557 wide unique. This value MAY be ignored upon receipt of the 1558 Test message. 1560 9.2 LMP TLV Format 1562 Many LMP messages are TLV based. The format the LMP TLV is as 1563 follows: 1565 0 1 2 3 1566 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 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 |N| Type | Length | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | | 1571 // (TLV Object) // 1572 | | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 N: 1 bit 1577 The N flag indicates if the object is a negotiable parameter 1578 (N=1) or a non-negotiable parameter (N=0). 1580 Type: 15 bits 1582 The Type field indicates the TLV type. 1584 Length: 16 bits 1586 The Length field indicates the length of the TLV object in 1587 bytes. 1589 9.3 Authentication 1591 When authentication is used for LMP, the authentication itself is 1592 appended to the LMP packet. It is not considered to be a part of 1593 the LMP packet, but is transmitted in the same IP packet as shown 1594 below: 1596 0 1 2 3 1597 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 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | | 1600 // LMP Common Header // 1601 | | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | | 1604 // LMP Payload // 1605 | | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | | 1608 // Authentication Block // 1609 | | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 The authentication block looks as follows: 1612 0 1 2 3 1613 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 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | 0 | Auth Type | Key ID | Auth Data Len | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 | Cryptographic Sequence Number | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 | | 1620 | MD5 Signature (16) | 1621 | | 1622 | | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 Auth Type: 8 bits 1627 This defines the type of authentication used for LMP 1628 messages. The following authentication types are 1629 defined, all other are reserved for future use: 1631 0 No authentication 1632 1 Cryptographic authentication 1634 Key ID: 8 bits 1636 This field is defined only for cryptographic 1637 authentication. 1639 Auth Data Length: 8 bits 1640 This field contains the length of the data portion of the 1641 authentication block. 1643 LMP authentication is performed on a per control channel basis. The 1644 packet authentication procedure is very similar to the one used in 1645 OSPF, including multiple key support, key management, etc. The 1646 details specific to LMP are defined below. 1648 Sending authenticated packets 1649 ----------------------------- 1651 When a packet needs to be sent over a control channel and an 1652 authentication method is configured for it, the Authentication flag 1653 in the LMP header is set to 1, the LMP Length field is set to the 1654 length of the LMP packet only, not including the authentication 1655 block. 1657 1) The Checksum field in the LMP packet is set to zero (this will 1658 make the receiving side drop the packet if authentication is not 1659 supported). 1660 2) The LMP authentication header is filled out properly. The message 1661 digest is calculated over the LMP packet together with the LMP 1662 authentication header. The input to the message digest 1663 calculation consists of the LMP packet, the LMP authentication 1664 header, and the secret key. When using MD5 as the authentication 1665 algorithm, the message digest calculation proceeds as follows: 1667 (a) The authentication header is appended to the LMP packet. 1668 (b) The 16 byte MD5 key is appended after the LMP authentication 1669 header. 1670 (c) Trailing pad and length fields are added, as specified in 1671 [MD5]. 1672 (d) The MD5 authentication algorithm is run over the 1673 concatenation of the LMP packet, authentication header, 1674 secret key, pad and length fields, producing a 16 byte 1675 message digest (see [MD5]). 1676 (e) The MD5 digest is written over the secret key (i.e., appended 1677 to the original authentication header). 1679 The authentication block is added to the IP packet right after the 1680 LMP packet, so IP packet length includes the length of both LMP 1681 packet and LMP authentication blocks. 1683 Receiving authenticated packets 1684 ------------------------------- 1686 When an LMP packet with the Authentication flag set has been received 1687 on a control channel that is configured for authentication, it must 1688 be authenticated. The value of the Authentication field MUST match 1689 the authentication type configured for the control channel (if any). 1691 If an LMP protocol packet is accepted as authentic, processing of the 1692 packet continues. Packets that fail authentication are discarded. 1693 Note that the checksum field in the LMP packet header is not checked 1694 when the packet is authenticated. 1696 (1) Locate the receiving control channel's configured key having Key 1697 ID equal to that specified in the received LMP authentication 1698 block. If the key is not found, or if the key is not valid for 1699 reception (i.e., current time does not fall into the key's 1700 active time frame), the LMP packet is discarded. 1701 (2) If the cryptographic sequence number found in the LMP 1702 authentication header is less than the cryptographic sequence 1703 number recorded in the control channel data structure, the LMP 1704 packet is discarded. 1705 (3) Verify the message digest in the data portion of the 1706 authentication block in the following steps: 1707 (a) The received digest is set aside. 1708 (b) A new digest is calculated, as specified in the previous 1709 section. 1710 (c) The calculated and received digests are compared. If they 1711 do not match, the LMP packet is discarded. If they do 1712 match, the LMP protocol packet is accepted as authentic, and 1713 the "cryptographic sequence number" in the control channel's 1714 data structure is set to the sequence number found in the 1715 packet's LMP header. 1717 9.4 Parameter Negotiation 1719 9.4.1 Config Message (MsgType = 1) 1721 The Config message is used in the negotiation phase of LMP. The 1722 contents of the Config message are built using TLV triplets. TLVs 1723 can be either negotiable or non-negotiable (identified by the N flag 1724 in the TLV header). Negotiable TLVs can be used to let the devices 1725 agree on certain values. Non-negotiable TLVs are used for 1726 announcement of specific values that do not need or do not allow 1727 negotiation. The format of the Config message is as follows: 1729 ::= 1731 The Config Object has the following format: 1733 0 1 2 3 1734 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 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Node ID | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | MessageId | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | | 1741 // (Config TLVs) // 1742 | | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 Node ID: 32 bits. 1747 This is the Node ID for the node. 1749 MessageId: 32 bits. 1751 When combined with the CCId, the MessageId field uniquely 1752 identifies a message. This value is incremented and only 1753 decreases when the value wraps. This is used for message 1754 acknowledgment. 1756 9.4.1.1 HelloConfig TLV 1758 The HelloConfig TLV is TLV Type=1 and is defined as follows: 1760 0 1 2 3 1761 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 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 |N| 1 | 4 | 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 | HelloInterval | HelloDeadInterval | 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 The Length field of HelloConfig is always set to 4. 1770 N: 1 bit 1772 The N flag indicates if the parameter is negotiable (N=1) or 1773 non-negotiable (N=0). 1775 HelloInterval: 16 bits. 1777 Indicates how frequently the Hello packets will be sent and is 1778 measured in milliseconds (ms). 1780 HelloDeadInterval: 16 bits. 1782 If no Hello packets are received within the HelloDeadInterval, 1783 the control channel is assumed to have failed and is measured 1784 in milliseconds (ms). 1786 9.4.1.2 LMP Capability TLV 1788 The LMP Capability TLV is TLV Type=2 and is defined as follows: 1790 0 1 2 3 1791 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 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 |N| 2 | 4 | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | Capability Flags | 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 The Length field of LMP Capability TLV is always set to 4. 1800 N: 1 bit 1802 The N flag indicates if the parameter is negotiable (N=1) or 1803 non-negotiable (N=0). 1805 Capability Flags: 32 bits 1807 The Capability Flags indicate which extended LMP procedures 1808 will be supported. A value of 0 indicates that only the base 1809 LMP procedures are supported. More than one bit may be set to 1810 indicate multiple extended LMP procedures are supported. 1812 The following flags are defined: 1814 0x01 Link Verification Procedure 1816 0x02 Fault Management Procedure 1817 0x04 LMP-DWDM Procedure. See [LMP-DWDM]. 1819 9.4.2 ConfigAck Message (MsgType = 2) 1821 The ConfigAck message is used to indicate the receipt of the Config 1822 message and indicate agreement on all parameters. 1824 ::= 1826 The ConfigAck Object has the following format: 1828 0 1 2 3 1829 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 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 | Node ID | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | MessageId | 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | Rcv Node ID | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | Rcv CCId | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 Node ID: 32 bits. 1842 This is the Node ID for the node sending the ConfigAck message. 1844 MessageId: 32 bits. 1846 This is copied from the Config message being acknowledged. 1848 Rcv Node ID: 32 bits. 1850 This is copied from the Config message being acknowledged. 1852 Rcv CCId: 32 bits 1854 This is the Control Channel Id copied from the Common Header of 1855 the Config message being acknowledged. 1857 9.4.3 ConfigNack Message (MsgType = 3) 1859 The ConfigNack message is used to indicate disagreement on non- 1860 negotiable parameters or propose other values for negotiable 1861 parameters. Parameters where agreement was reached MUST NOT be 1862 included in the ConfigNack Object. The format of the ConfigNack 1863 message is as follows: 1865 ::= 1867 The ConfigNack Object has the following format: 1869 0 1 2 3 1870 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 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | Node ID | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | MessageId | 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 | Rcv Node ID | 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 | Rcv CCId | 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 | | 1881 // (Config TLVs) // 1882 | | 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 Node ID: 32 bits. 1887 This is the Node ID for the node. 1889 MessageId: 32 bits. 1891 This is copied from the Config message being negatively 1892 acknowledged. 1894 Rcv Node ID: 32 bits. 1896 This is copied from the Config message being acknowledged. 1898 Rcv CCId: 32 bits 1900 This is the Control Channel Id copied from the Common Header of 1901 the Config message being negatively acknowledged. 1903 The Config TLVs MUST include acceptable values for all negotiable 1904 parameters. If the ConfigNack includes Config TLVs for non- 1905 negotiable parameters, they MUST be copied from the Config TLVs 1906 received in the Config message. 1908 9.5 Hello Message (MsgType = 4) 1910 The format of the Hello message is as follows: 1912 ::= . 1914 The Hello object format is shown below: 1916 0 1 2 3 1917 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 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | TxSeqNum | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 | RcvSeqNum | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 TxSeqNum: 32 bits 1926 This is the current sequence number for this Hello message. 1927 This sequence number will be incremented when either (a) the 1928 sequence number is reflected in the RcvSeqNum of a Hello packet 1929 that is received over the control channel, or (b) the Hello 1930 packet is transmitted over a backup control channel. 1932 TxSeqNum=0 is not allowed. 1934 TxSeqNum=1 is reserved to indicate that a node has booted or 1935 rebooted. 1937 RcvSeqNum: 32 bits 1939 This is the sequence number of the last Hello message received 1940 over the control channel. RcvSeqNum=0 is reserved to indicate 1941 that a Hello message has not yet been received. 1943 9.6 Link Verification 1945 9.6.1 BeginVerify Message (MsgType = 5) 1947 The BeginVerify message is sent over the control channel and is used 1948 to initiate the link verification process. The format is as 1949 follows: 1951 ::= 1953 The BeginVerify object has the following format: 1955 0 1 2 3 1956 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 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 | Flags | VerifyInterval | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | MessageId | 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 | Local TE Link Id | 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 | Remote TE Link Id | 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 | Number of Data Links | 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 | EncType | Verify Transport Mechanism | 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 | BitRate | 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | Wavelength | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 Flags: 16 bits 1977 The following flags are defined: 1978 0x01 TE Link type 1979 If this bit is set, the TE Link Id is numbered; 1980 otherwise the TE Link Id is unnumbered. 1981 0x02 Verify all Links 1982 If this bit is set, the verification process checks all 1983 unallocated links; else it only verifies new ports or 1984 component links that have been added to this TE link. 1985 0x04 Data Link Type 1986 If set, the data links to be verified are ports, 1987 otherwise they are component links 1989 VerifyInterval: 16 bits 1991 This is the interval between successive Test messages and is 1992 measured in milliseconds (ms). 1994 MessageId: 32 bits 1996 When combined with the CCId, the MessageId field uniquely 1997 identifies a message. This value is incremented and only 1998 decreases when the value wraps. This is used for message 1999 acknowledgment in the BeginVerifyAck and BeginVerifyNack 2000 messages. 2002 Local TE Link Id: 32 bits 2004 This identifies the TE LinkId of the local node, which may be 2005 numbered or unnumbered (see Flags), for the ports or component 2006 links that are being verified. If this value is set to 0, the 2007 port or component links to be verified are not yet locally 2008 assigned to a TE link. 2010 Remote TE Link Id: 32 bits 2012 This identifies the TE Link Id of the remote node, which may be 2013 numbered or unnumbered (see Flags), for the ports or component 2014 links that are being verified. If this value is set to 0, the 2015 local node has no knowledge of the remote TE Link Id. It is 2016 expected that for unnumbered TE Link�s this will be set to 0. 2018 Number of Data Links: 32 bits 2020 This is the number of data links that will be verified. 2022 EncType: 16 bits 2023 This is the encoding type of the data link and is required for 2024 the purpose of testing where the data links are not required to 2025 be the same encoding type as the control channel. The defined 2026 EncType values are consistent with the Link Encoding Type 2027 values of [OSPF-GEN] and [ISIS-GEN]. 2029 Verify Transport Mechanism: 16 bits 2031 This defines the transport mechanism for the Test Messages. The 2032 scope of this bit mask is restricted to each link encoding 2033 type. The local node will set the bits corresponding to the 2034 various mechanisms it can support for transmitting LMP test 2035 messages. The receiver chooses the appropriate mechanism in the 2036 BeginVerifyAck message. 2038 For SONET/SDH Encoding Type, the following flags are defined: 2039 0x01 Capable of communicating using JO overhead bytes. 2040 Test Message is transmitted using the J0 bytes. 2041 0x02 Capable of communicating using Section DCC bytes. 2042 Test Message is transmitted using the DCC Section 2043 Overhead bytes with an HDLC framing format. 2044 0x04 Capable of communicating using Line DCC bytes. 2045 Test Message is transmitted using the DCC Line Overhead 2046 bytes with an HDLC framing format. 2047 0x08 Capable of communicating using POS. 2048 Test Message is transmitted using Packet over SONET 2049 framing using the encoding type specified in the 2050 EncType field. 2052 For GigE Encoding Type, the following flags are defined: TBD 2054 For 10GigE Encoding Type, the following flags are defined: TBD 2056 BitRate: 32 bits 2058 This is the bit rate of the data link over which the Test 2059 messages will be transmitted and is expressed in bytes per 2060 second. 2062 Wavelength: 32 bits 2064 When a data link is assigned to a port or component link that 2065 is capable of transmitting multiple wavelengths (e.g., a fiber 2066 or waveband-capable port), it is essential to know which 2067 wavelength the test messages will be transmitted over. This 2068 value corresponds to the wavelength at which the Test messages 2069 will be transmitted over and is measured in nanometers (nm). 2070 If each data link corresponds to a separate wavelength and 2071 there is no ambiguity as to the wavelength over which the 2072 message will be sent, than this value SHOULD be set to 0. 2074 9.6.2 BeginVerifyAck Message (MsgType = 6) 2076 When a BeginVerify message is received and Test messages are ready 2077 to be processed, a BeginVerifyAck message MUST be transmitted. 2079 ::= 2081 The BeginVerifyAck object has the following format: 2083 0 1 2 3 2084 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 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 | MessageId | 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 | Rcv CCId | 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 | VerifyDeadInterval | Verify Transport Response | 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 | VerfifyId | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 MessageId: 32 bits 2096 This is copied from the BeginVerify message being acknowledged. 2098 Rcv CCId: 32 bits 2100 This is the Control Channel Id copied from the Common Header of 2101 the BeginVerify message being negatively acknowledged. 2103 VerifyDeadInterval: 16 bits 2105 If a Test message is not detected within the 2106 VerifyDeadInterval, then a node will send the TestStatusFailure 2107 message for that data link. 2109 Verification Transport Response: 16 bits 2111 It is illegal to set more than one bit in the verification 2112 transport response. The recipient of the BeginVerify message 2113 (and the future recipient of the TEST messages) chooses the 2114 transport mechanism from the various types that are offered by 2115 the transmitter of the Test messages. 2117 VerifyId: 32 bits 2119 This is used to differentiate Test messages from different TE 2120 links and/or LMP peers. The recipient of the BeginVerify 2121 message assigns this value and it MUST node unique. This is a 2122 node-unique value that is assigned by the recipient of the 2123 BeginVerify message. 2125 9.6.3 BeginVerifyNack Message (MsgType = 7) 2126 If a BeginVerify message is received and a node is unwilling or 2127 unable to begin the Verification procedure, a BeginVerifyNack 2128 message MUST be transmitted. 2130 ::= 2132 The BeginVerifyNack object has the following format: 2134 0 1 2 3 2135 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 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 | MessageId | 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 | Rcv CCId | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | Error Code | (Reserved) | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 MessageId: 32 bits 2146 This is copied from the BeginVerify message being negatively 2147 acknowledged. 2149 Rcv CCId: 32 bits 2151 This is the Control Channel Id copied from the Common Header of 2152 the BeginVerify message being negatively acknowledged. 2154 Error Code: 16 bits 2156 The following values are defined: 2157 1 = Unwilling to verify at this time 2158 2 = TE Link Id configuration error 2159 3 = Unsupported verification transport mechanism 2161 If a BeginVerifyNack message is received with Error Code 1, the node 2162 that originated the BeginVerify SHOULD schedule a BeginVerify 2163 retransmission after Rf seconds, where Rf is a locally defined 2164 parameter. 2166 9.6.4 EndVerify Message (MsgType = 8) 2168 The EndVerify message is sent over the control channel and is used 2169 to terminate the link verification process. The EndVerify message 2170 may be sent at any time a node desires to end the Verify procedure. 2171 The format is as follows: 2173 ::= 2175 The EndVerify object has the following format: 2177 0 1 2 3 2178 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 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 | MessageId | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 | VerifyId | 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 MessageId: 32 bits 2187 When combined with the CCId, the MessageId field uniquely 2188 identifies a message. This value is incremented and only 2189 decreases when the value wraps. This is used for message 2190 acknowledgement in the EndVerifyAck message. 2192 VerifyId: 32 bits 2194 This is the VerifyId corresponding to the link verification 2195 process that is being terminated. 2197 9.6.5 EndVerifyAck Message (MsgType =9) 2199 The EndVerifyAck message is sent over the control channel and is 2200 used to acknowledge the termination of the link verification 2201 process. The format is as follows: 2203 ::= 2205 The EndVerifyAck object has the following format: 2207 0 1 2 3 2208 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 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 | MessageId | 2211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2212 | Rcv CCId | 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 MessageId: 32 bits 2217 This is copied from the EndVerify message being acknowledged. 2219 Rcv CCId: 32 bits 2221 This is the Control Channel Id copied from the Common Header of 2222 the EndVerify message being acknowledged. 2224 9.6.6 Test Message 2226 The Test message is transmitted over the data link and is used to 2227 verify its physical connectivity. Unless explicitly stated below, 2228 this is transmitted as an IP packet with payload format as follows: 2230 ::= 2232 The Test object has the following format: 2234 0 1 2 3 2235 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 2236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 | VerifyId | 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 | Interface Id | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 VerifyId: 32 bits 2244 The VerifyId identifies the link verification procedure with 2245 which the data link verification is associated. 2247 Interface Id: 32 bits 2249 The Interface Id identifies the data link (either port or 2250 component link) over which this message is sent. A valid 2251 Interface Id MUST be nonzero. 2253 Note that this message is sent over a data link and NOT over the 2254 control channel. 2256 9.6.7 TestStatusSuccess Message (MsgType = 10) 2258 The TestStatusSuccess message is transmitted over the control 2259 channel and is used to transmit the mapping between the local 2260 Interface Id and the Interface Id that was received in the Test 2261 message. 2263 ::= 2265 The TestStatusSuccess object has the following format: 2267 0 1 2 3 2268 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 2269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2270 | MessageId | 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 | Received Interface Id | 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 | Local Interface Id | 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 | VerifyId | 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 MessageId: 32 bits 2280 When combined with the CCId, the MessageId field uniquely 2281 identifies a message. This value is incremented and only 2282 decreases when the value wraps. This is used for message 2283 acknowledgement in the TestStatusAck message. 2285 Received Interface Id: 32 bits 2287 This is the value of the Interface Id that was received in the 2288 Test message. A valid Interface Id MUST be nonzero. 2290 Local Interface Id: 32 bits 2292 This is the local value of the Interface Id. A valid Interface 2293 Id MUST be nonzero. 2295 VerifyId: 32 bits 2297 The VerifyId identifies the link verification procedure with 2298 which the data link is associated. 2300 9.6.8 TestStatusFailure Message (MsgType = 11) 2302 The TestStatusFailure message is transmitted over the control 2303 channel and is used to indicate that the Test message was not 2304 received. 2306 ::= 2308 The TestStatusFailure object has the following format: 2310 0 1 2 3 2311 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 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 | MessageId | 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | VerifyId | 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2318 MessageId: 32 bits 2320 When combined with the CCId and MsgType, the MessageId field 2321 uniquely identifies a message. This value is incremented and 2322 only decreases when the value wraps. This is used for message 2323 acknowledgement in the TestStatusAck message. 2325 VerifyId: 32 bits 2327 The VerifyId identifies the link verification procedure for 2328 which the timer has expired and no TEST messages have been 2329 received. 2331 9.6.9 TestStatusAck Message (MsgType = 12) 2333 The TestStatusAck message is used to acknowledge receipt of the 2334 TestStatusSuccess or TestStatusFailure messages. 2336 ::= 2338 The TestStatusAck object has the following format: 2340 0 1 2 3 2341 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 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 | MessageId | 2344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2345 | Rcv CCId | 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 MessageId: 32 bits 2350 This is copied from the TestStatusSuccess or TestStatusFailure 2351 message being acknowledged. 2353 Rcv CCId: 32 bits 2355 This is the Control Channel Id copied from the Common Header of 2356 the TestStatusSuccess or TestStatusFailure message being 2357 acknowledged. 2359 9.7 Link Summary Messages 2361 9.7.1 LinkSummary Message (MsgType = 13) 2363 The LinkSummary message is used to synchronize the Interface Ids and 2364 correlate the properties of the TE link. The format of the 2365 LinkSummary message is as follows: 2367 ::= 2369 The LinkSummary Object has the following format: 2371 0 1 2 3 2372 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 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 | MessageId | 2375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2376 | | 2377 // (LinkSummary TLVs) // 2378 | | 2379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 MessageId: 32 bits 2382 When combined with the CCId, the MessageId field uniquely 2383 identifies a message. This value is incremented and only 2384 decreases when the value wraps. This is used for message 2385 acknowledgement in the LinkSummaryAck and LinkSummaryNack 2386 messages. 2388 9.7.1.1 TE Link TLV 2390 The TE Link TLV is TLV Type=3 and is defined as follows: 2392 0 1 2 3 2393 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 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 |0| 3 | 0xC | 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 | Flags | Link Mux Cap | Prot. Type | (Reserved) | 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | Local TE Link Id | 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | Received TE Link Id | 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 The TE Link TLV is non-negotiable. 2406 Flags: 8 bits 2408 The following flags are defined: 2409 0x01 TE Link Id Type 2410 If this bit is set, the TE Link Id is numbered; 2411 otherwise the TE Link Id is unnumbered. 2413 Link Mux Cap: 8 bits 2415 This is used to identify the associated 2416 multiplexing/demultiplexing capability of the TE link. See 2417 [LSP-HIER]. 2419 Protection Type: 8 bits 2421 The Protection Type Flags indicate the link protection, if any, 2422 that is used. Multiple bits may be set when multiple link 2423 protection types are available. The following flags are 2424 defined: 2426 0x01 Extra Traffic 2428 Indicates that the TE link is protecting one or more 2429 (primary) link(s). Any LSPs using a link of this 2430 type will be lost if the primary links being 2431 protected fail. 2433 0x02 Unprotected 2434 Indicates that the link is unprotected. 2436 0x04 Shared (M:N) 2438 Indicates that the link is protected using a M:N 2439 shared protection scheme. 2441 0x08 Dedicated 1:1 2443 Indicates that the link is protected using a 1:1 2444 dedicated link protection scheme, 2446 0x10 Dedicated 1+1 2448 Indicates that the link is protected using a 1+1 2449 dedicated link protection scheme. 2451 Local TE Link Id: 32 bits 2453 This identifies the TE link of the local node, which may be 2454 numbered or unnumbered (see Flags). 2456 Remote TE Link Id: 32 bits 2458 This identifies the TE link of the remote node, which may be 2459 numbered or unnumbered (see Flags). If the local node has no 2460 knowledge of the remote TE Link Id, this value MUST be set to 2461 0. 2463 9.7.1.2 Data-link TLV 2465 The Data Link TLV is TLV Type=4 and is defined as follows: 2467 0 1 2 3 2468 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 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2470 |0| 4 | Length | 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 | Flags | Link Type | (Reserved) | 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 | Local Interface Id | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 | Received Interface Id | 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2478 | | 2479 // (Data-link sub-TLVs) // 2480 | | 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 The Data Link TLV is non-negotiable. 2485 Length: 16 bits 2487 The Length of the Primary Data Link TLV including all data-link sub- 2488 TLVs. 2490 Flags: 8 bits 2492 The following flags are defined. All other values are 2493 reserved. 2495 0x01 Interface Type: If set, the data link is a port, 2496 otherwise it is a component link. 2497 0x02 Allocated Link: If set, the data link is currently 2498 allocated for user traffic. 2500 Link Type: 8 bits 2502 This is used to identify the encoding type of the data link. 2503 See [OSPF-GEN] or [ISIS-TE]. 2505 Local Interface Id: 32 bits 2507 This is the local value of the Interface Id (for the port or 2508 component link) or CCId (for control channel). 2510 Received Interface Id: 32 bits 2512 This is the value of the corresponding Interface Id. If this 2513 is a port or component link, then this is the value that was 2514 received in the Test message. If this is the primary control 2515 channel, then this is the value that is received in all of the 2516 Verify messages. 2518 9.7.1.3 Data Link Sub-TLV 2520 The data link sub-TLV is used to provide characteristics of the 2521 data-bearing links. Currently, there are no data link sub-TLVs 2522 defined. 2524 9.7.2 LinkSummaryAck Message (MsgType = 14) 2526 The LinkSummaryAck message is used to indicate agreement on the 2527 Interface Id synchronization and acceptance/agreement on all the 2528 link parameters. It is on the reception of this message that the 2529 local node makes the TE Link Id associations. 2531 ::= 2533 The LinkSummaryAck object has the following format: 2535 0 1 2 3 2536 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 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 | Flags | Reserved | 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 | MessageId | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | Rcv CCId | 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | Local TE Link Id | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | Remote TE Link Id | 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2550 Flags: 8 bits 2552 The following flags are defined: 2553 0x01 TE Link Id type 2554 If this bit is set, the TE Link Id is numbered; 2555 otherwise the TE Link Id is unnumbered. 2557 MessageId: 32 bits 2559 This is copied from the LinkSummary message being acknowledged. 2561 Rcv CCId: 32 bits 2563 This is the Control Channel Id copied from the Common Header of 2564 the LinkSummary message being acknowledged. 2566 Local TE Link Id: 32 bits 2568 This identifies the TE Link Id of the local node, which may be 2569 numbered or unnumbered (see Flags). 2571 Remote TE Link Id: 32 bits 2573 This identifies the TE Link Id of the remote node, which may be 2574 numbered or unnumbered (see Flags). 2576 9.7.3 LinkSummaryNack Message (MsgType = 15) 2578 The LinkSummaryNack message is used to indicate disagreement on non- 2579 negotiated parameters or propose other values for negotiable 2580 parameters. Parameters where agreement was reached MUST NOT be 2581 included in the LinkSummaryNack Object. 2583 ::= 2585 The LinkSummaryNack object has the following format: 2587 0 1 2 3 2588 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 2589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2590 | MessageId | 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2592 | Rcv CCId | 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 | | 2595 // (LinkSummary TLVs) // 2596 | | 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2599 MessageId: 32 bits 2601 This is copied from the LinkSummary message being negatively 2602 acknowledged. 2604 Rcv CCId: 32 bits 2606 This is the Control Channel Id copied from the Common Header of 2607 the LinkSummary message being negatively acknowledged. 2609 The LinkSummary TLVs MUST include acceptable values for all 2610 negotiable parameters. If the LinkSummaryNack includes LinkSummary 2611 TLVs for non-negotiable parameters, they MUST be copied from the 2612 LinkSummary TLVs received in the LinkSummary message. 2614 9.8 Fault Management Messages 2616 9.8.1 ChannelFail Message (MsgType = 16) 2618 The ChannelFail message is sent over the control channel and is used 2619 to notify a neighboring node that a data link (port or component 2620 link) failure has been detected. A neighboring node that receives a 2621 ChannelFail message MUST respond with either a ChannelFailAck or a 2622 ChannelFailNack message indicating that a failure has also been 2623 detected in the corresponding data link in the neighboring node. 2624 The format is as follows: 2626 ::= 2628 The format of the ChannelFail object is as follows: 2630 0 1 2 3 2631 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 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 | MessageId | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | Local TE Link Id | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | | 2638 // (Failure TLVs) // 2639 | | 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 MessageId: 32 bits 2643 When combined with the CCId, the MessageId field uniquely 2644 identifies a message. This value is incremented and only 2645 decreases when the value wraps. This is used for message 2646 acknowledgement in the ChannelFailAck and ChannelFailNack 2647 messages. 2649 Local TE Link Id: 32 bits 2651 This is the local TE Link Id for the failed TE link. 2653 If no Failure TLVs are included, the ChannelFail message indicates 2654 the entire TE Link has failed. 2656 9.8.1.2 Failed Channel TLV 2658 The Failed Channel TLV is TLV Type=5. This TLV contains one or more 2659 Failed Channels of a TE link and has the following format: 2661 0 1 2 3 2662 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 2663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2664 |0| 5 | Length | 2665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2666 | | 2667 // (Local Interface Ids) // 2668 | | 2669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 The Failed Channel TLV is non-negotiable. 2673 Length: 16 bits 2675 The Length has a minimum value of 0x08 and MUST be a multiple 2676 of 4. 2678 Local TE Link Id: 32 bits 2680 This is the local TE Link Id within which the data link has 2681 failed. 2683 Local Interface Id: 32 bits 2685 This is the local Interface Id (either Port Id or Component 2686 Interface Id) of the data link that has failed. This is within 2687 the scope of the TE Link Id. Multiple Local Interface Ids may 2688 be placed into a single Failed Channel TLV if they belong to 2689 the same TE Link. 2691 9.8.2 ChannelFailAck Message (MsgType = 17) 2692 The ChannelFailAck message is used to indicate that all of the 2693 reported failures in the ChannelFail message also have failures on 2694 the corresponding input channels. The format is as follows: 2696 ::= 2698 The ChannelFailureAck object has the following format: 2700 0 1 2 3 2701 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 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 | MessageId | 2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2705 | Rcv CCId | 2706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2708 MessageId: 32 bits 2710 This is copied from the ChannelFail message being acknowledged. 2712 Rcv CCId: 32 bits 2714 This is the Control Channel Id copied from the Common Header of 2715 the ChannelFail message being acknowledged. 2717 9.8.3 ChannelFailNack Message (MsgType = 18) 2719 The ChannelFailNack message is used to indicate that the reported 2720 failures are CLEAR in the upstream node, and hence, the failure has 2721 been isolated between the two nodes. 2723 ::= 2725 The ChannelFailNack object has the following format: 2727 0 1 2 3 2728 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 2729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2730 | MessageId | 2731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 | Rcv CCId | 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 | | 2735 // (Failure TLVs) // 2736 | | 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2739 MessageId: 32 bits 2741 This is copied from the ChannelFail message being negatively 2742 acknowledged. 2744 Rcv CCId: 32 bits 2746 This is the Control Channel Id copied from the Common Header of 2747 the ChannelFail message being negatively acknowledged. 2749 9.8.4 ChannelActive Message (MsgType = 19) 2751 The ChannelActive message is sent over the control channel and is 2752 used to notify a neighboring node that a data link (port or 2753 component link) is now carrying user data traffic. A 2754 ChannelActiveAck message MUST be sent to acknowledge receipt of the 2755 ChannelActive message. The format is as follows: 2757 ::= 2759 The format of the ChannelActive object is as follows: 2761 0 1 2 3 2762 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 2763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2764 | MessageId | 2765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 | Local TE Link Id | 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 | | 2769 // (Active TLVs) // 2770 | | 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 MessageId: 32 bits 2775 When combined with the CCId, the MessageId field uniquely 2776 identifies a message. This value is incremented and only 2777 decreases when the value wraps. This is used for message 2778 acknowledgement in the ChannelActiveAck message. 2780 Local TE Link Id: 32 bits 2782 This is the local TE Link Id within which the data link has 2783 become active. 2785 There MUST be at least one Active TLV. 2787 9.8.4.1 Active Channel TLV 2789 The Active Channel TLV is TLV Type=6. This TLV contains one or more 2790 Active Channels of a TE link and has the following format: 2792 0 1 2 3 2793 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 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2795 |0| 6 | Length | 2796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2797 | | 2798 // (Local Interface Ids) // 2799 | | 2800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2802 The Active Channel TLV is non-negotiable. 2804 Length: 16 bits 2806 The Length has a minimum value of 0x08 and MUST be a multiple 2807 of 4. 2809 Local Interface Id: 32 bits 2811 This is the local Interface Id (either Port Id or Component 2812 Interface Id) of the data link that has become active. This is 2813 within the scope of the TE Link Id. Multiple Local Interface 2814 Ids may be placed into a single Active Channel TLV if they 2815 belong to the same TE Link. 2817 9.8.5 ChannelActiveAck Message (MsgType = 20) 2819 The ChannelActiveAck message is used to acknowledge receipt of the 2820 ChannelActive message. The format is as follows: 2822 ::= 2824 The ChannelActiveAck object has the following format: 2826 0 1 2 3 2827 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 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 | MessageId | 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2831 | Rcv CCId | 2832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2834 MessageId: 32 bits 2836 This is copied from the ChannelActive message being 2837 acknowledged. 2839 Rcv CCId: 32 bits 2841 This is the Control Channel Id copied from the Common Header of 2842 the ChannelActive message being acknowledged. 2844 10. Security Considerations 2846 LMP exchanges may be authenticated using the Cryptographic 2847 authentication option. MD5 is currently the only message digest 2848 algorithm specified. 2850 11. References 2852 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2853 3," BCP 9, RFC 2026, October 1996. 2854 [LAMBDA] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., 2855 "Multi-Protocol Lambda Switching: Combining MPLS Traffic 2856 Engineering Control with Optical Crossconnects," 2857 Internet Draft, draft-awduche-mpls-te-optical-02.txt, 2858 (work in progress), July 2000. 2859 [PERF-MON] Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski, 2860 J., Edwards, W. L., "Performance Monitoring in Photonic 2861 Networks," Internet Draft, draft-ceuppens-mpls-optical- 2862 00.txt, (work in progress), March 2000. 2863 [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., �Link Bundling in 2864 MPLS Traffic Engineering,� Internet Draft, draft- 2865 kompella-mpls-bundle-04.txt, (work in progress), November 2866 2000. 2867 [RSVP-TE] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., 2868 Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP 2869 Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp- 2870 tunnel-07.txt, (work in progress), August 2000. 2871 [CR-LDP] Jamoussi, B., et al, "Constraint-Based LSP Setup using 2872 LDP," Internet Draft, draft-ietf-mpls-cr-ldp-03.txt, 2873 (work in progress), September 1999. 2874 [OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to 2875 OSPF," Internet Draft, draft-katz-yeung-ospf-traffic- 2876 03.txt, (work in progress), August 2000. 2877 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 2878 Engineering," Internet Draft,draft-ietf-isis-traffic- 2879 02.txt, (work in progress), September 2000. 2880 [OSPF] Moy, J., "OSPF Version 2," RFC 2328, April 1998. 2881 [LMP-DWDM] Fredette, A., Snyder, E., Shantigram, J., et al, �Link 2882 Management Protocol (LMP) for WDM Transmission Systems,� 2883 Internet Draft, draft-fredette-lmp-wdm-00.txt, (work in 2884 progress), December 2000. 2885 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 2886 1321, April 1992. 2887 [OSPF-GEN] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF 2888 Extensions in Support of Generalized MPLS," Internet 2889 Draft, draft-kompella-ospf-extensions-00.txt, (work in 2890 progress), July 2000. 2891 [ISIS-GEN] Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS 2892 Extensions in Support of Generalized MPLS," Internet 2893 Draft, draft-kompella-isis-extensions-00.txt, (work in 2894 progress), July 2000. 2896 [LSP-HIER] Kompella, K. and Rekhter, Y., �LSP Hierarchy with MPLS 2897 TE,� Internet Draft, draft-ietf-mpls-lsp-hierarchy- 2898 01.txt, (work in progress), September 2000. 2900 12. Acknowledgments 2902 The authors would like to thank Ayan Banerjee, George Swallow, Andre 2903 Fredette, and Adrian Farrel for their insightful comments and 2904 suggestions. We would also like to thank John Yu, Suresh Katukan, 2905 and Greg Bernstein for their helpful suggestions for the in-band 2906 control channel applicability. 2908 13. Author's Addresses 2910 Jonathan P. Lang Krishna Mitra 2911 Calient Networks Calient Networks 2912 25 Castilian Drive 5853 Rue Ferrari 2913 Goleta, CA 93117 San Jose, CA 95138 2914 Email: jplang@calient.net email: krishna@calient.net 2916 John Drake Kireeti Kompella 2917 Calient Networks Juniper Networks, Inc. 2918 5853 Rue Ferrari 385 Ravendale Drive 2919 San Jose, CA 95138 Mountain View, CA 94043 2920 email: jdrake@calient.net email: kireeti@juniper.net 2922 Yakov Rekhter Lou Berger 2923 Juniper Networks, Inc. Movaz Networks 2924 385 Ravendale Drive email: lberger@movaz.com 2925 Mountain View, CA 94043 2926 email: yakov@juniper.net 2928 Debanjan Saha Debashis Basak 2929 Tellium Optical Systems Accelight Networks 2930 2 Crescent Place 70 Abele Road, Suite 1201 2931 Oceanport, NJ 07757-0901 Bridgeville, PA 15017-3470 2932 email:dsaha@tellium.com email: dbasak@accelight.com 2934 Hal Sandick Alex Zinin 2935 Nortel Networks Cisco Systems 2936 email: hsandick@nortelnetworks.com 150 W. Tasman Dr. 2937 San Jose, CA 95134 2938 email: azinin@cisco.com 2939 Bala Rajagopalan 2940 Tellium Optical Systems 2941 2 Crescent Place 2942 Oceanport, NJ 07757-0901 2943 email: braja@tellium.com