idnits 2.17.1 draft-ietf-ccamp-lmp-10.txt: -(3436): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3467): 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: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 44) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 sent a Hello message and received a valid Hello message (i.e., with expected sequence numbers; see Section 3.2.2), the control channel moves to the up state. (It is also possible to move to the up state without sending Hellos if other methods are used to indicate bi-directional control-channel connectivity. For example, indication of bi-directional connectivity may be learned from the transport layer.) If, however, a node receives a ConfigNack message instead of a ConfigAck message, the node MUST not send Hello messages and the control channel SHOULD NOT move to the up state. See Section 11.1 for the complete control channel FSM. -- 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.) -- The document date (October 2003) is 7499 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'BUNDLE' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-RTG' ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Lang, Editor 3 Internet Draft (Rincon Networks) 4 Category: Standards Track 5 Expires: April 2004 October 2003 7 Link Management Protocol (LMP) 9 draft-ietf-ccamp-lmp-10.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 For scalability purposes, multiple data links can be combined to 35 form a single traffic engineering (TE) link. Furthermore, the 36 management of TE links is not restricted to in-band messaging, but 37 instead can be done using out-of-band techniques. This document 38 specifies a link management protocol (LMP) that runs between a pair 39 of nodes and is used to manage TE links. Specifically, LMP will be 40 used to maintain control channel connectivity, verify the physical 41 connectivity of the data links, correlate the link property 42 information, suppress downstream alarms, and localize link failures 43 for protection/restoration purposes in multiple kinds of networks. 45 Table of Contents 47 1 Introduction ................................................ 5 48 1.1 Terminology ............................................. 5 49 2 LMP Overview ................................................ 8 50 3 Control Channel Management .................................. 10 51 3.1 Parameter Negotiation ................................... 11 52 3.2 Hello Protocol .......................................... 12 53 3.2.1 Hello Parameter Negotiation ...................... 12 54 3.2.2 Fast Keep-alive .................................. 13 55 3.2.3 Control Channel Down ............................. 14 56 3.2.4 Degraded State ................................... 14 57 4 Link Property Correlation ................................... 15 58 5 Verifying Link Connectivity ................................. 16 59 5.1 Example of Link Connectivity Verification ............... 19 60 6 Fault Management ............................................ 20 61 6.1 Fault Detection ......................................... 20 62 6.2 Fault Localization Procedure ............................ 21 63 6.3 Examples of Fault Localization .......................... 21 64 6.4 Channel Activation Indication ........................... 22 65 6.5 Channel Deactivation Indication ......................... 23 66 7 Message_Id Usage ............................................ 23 67 8 Graceful Restart ............................................ 24 68 9 Addressing .................................................. 25 69 10 Exponential Back-off Procedures ............................. 26 70 10.1 Operation............................................... 26 71 10.2 Retransmission Algorithm ............................... 27 72 11 LMP Finite State Machines ................................... 27 73 11.1 Control Channel FSM .................................... 27 74 11.1.1 Control Channel States .......................... 27 75 11.1.2 Control Channel Events .......................... 28 76 11.1.3 Control Channel FSM Description ................. 30 77 11.2 TE Link FSM ............................................ 31 78 11.2.1 TE Link States .................................. 31 79 11.2.2 TE Link Events .................................. 31 80 11.2.3 TE Link FSM Description ......................... 32 81 11.3 Data Link FSM .......................................... 33 82 11.3.1 Data Link States ................................ 33 83 11.3.2 Data Link Events ................................ 33 84 11.3.3 Active Data Link FSM Description ................ 35 85 11.3.4 Passive Data Link FSM Description ............... 35 86 12 LMP Message Formats ......................................... 36 87 12.1 Common Header .......................................... 36 88 12.2 LMP Object Format ...................................... 38 89 12.3 Parameter Negotiation Messages ......................... 39 90 12.4 Hello Message .......................................... 40 91 12.5 Link Verification Messages ............................. 41 92 12.6 Link Summary Messages .................................. 44 93 12.7 Fault Management Messages .............................. 46 94 13 LMP Object Definitions ...................................... 47 95 14 Intellectual Property Considerations ........................ 64 96 15 References .................................................. 65 97 16 Security Considerations ..................................... 66 98 16.1 Security Requirements .................................. 66 99 16.2 Security Mechanisms .................................... 67 100 17 IANA Considerations ......................................... 69 101 18 Acknowledgements ............................................ 75 102 19 Contributors ................................................ 75 103 20 Contact Address ............................................. 75 104 21 Full Copyright Statement .................................... 77 106 [Editor's note: "Changes from previous version" notes can be removed 107 prior to publication as an RFC.] 109 Changes from previous version: 111 o Editorial changes resulting from IESG review. 113 o The following changes were made to the Security Considerations 114 section: 116 - Removed stale text about channel identifier. 118 - Made changes to ensure manual keying is a SHOULD and dynamic 119 keying is a MUST. For dynamic key exchange protocols IKE MUST 120 be the key exchange protocol. 122 - Text was added to indicate a more specific selector can be used 123 by specifying the ports explicitly. 125 - Added text about the caveats of using manual keying. 127 - Made ESP Tunnel mode a MUST. 129 1. Introduction 131 Networks are being developed with routers, switches, crossconnects, 132 dense wavelength division multiplexed (DWDM) systems, and add-drop 133 multiplexors (ADMs) that use a common control plane [e.g., 134 Generalized MPLS (GMPLS)] to dynamically allocate resources and to 135 provide network survivability using protection and restoration 136 techniques. A pair of nodes may have thousands of interconnects, 137 where each interconnect may consist of multiple data links when 138 multiplexing (e.g., Frame Relay DLCIs at Layer 2, time division 139 multiplexed (TDM) slots or wavelength division multiplexed (WDM) 140 wavelengths at Layer 1) is used. For scalability purposes, multiple 141 data links may be combined into a single traffic-engineering (TE) 142 link. 144 To enable communication between nodes for routing, signaling, and 145 link management, there must be a pair of IP interfaces that are 146 mutually reachable. We call such a pair of interfaces a control 147 channel. Note that "mutually reachable" does not imply that these 148 two interfaces are (directly) connected by an IP link; there may be 149 an IP network between the two. Furthermore, the interface over which 150 the control messages are sent/received may not be the same interface 151 over which the data flows. This document specifies a link management 152 protocol (LMP) that runs between a pair of nodes and is used to 153 manage TE links and verify reachability of the control channel. For 154 the purposes of this document, such nodes are considered "LMP 155 neighbors" or simply "neighboring nodes". 157 In GMPLS, the control channels between two adjacent nodes are no 158 longer required to use the same physical medium as the data links 159 between those nodes. For example, a control channel could use a 160 separate virtual circuit, wavelength, fiber, Ethernet link, an IP 161 tunnel routed over a separate management network, or a multi-hop IP 162 network. A consequence of allowing the control channel(s) between 163 two nodes to be logically or physically diverse from the associated 164 data links is that the health of a control channel does not 165 necessarily correlate to the health of the data links, and vice- 166 versa. Therefore, a clean separation between the fate of the control 167 channel and data links must be made. New mechanisms must be 168 developed to manage the data links, both in terms of link 169 provisioning and fault management. 171 Among the tasks that LMP accomplishes is checking that the grouping 172 of links into TE links as well as the properties of those links are 173 the same at both end points of the links -- this is called "link 174 property correlation". Also, LMP can communicate these link 175 properties to the IGP module, which can then announce them to other 176 nodes in the network. LMP can also tell the signaling module the 177 mapping between TE links and control channels. Thus, LMP performs a 178 valuable "glue" function in the control plane. 180 Note that while the existence of the control network (single or 181 multi-hop) is necessary for enabling communication, it is by no 182 means sufficient. For example, if the two interfaces are separated 183 by an IP network, faults in the IP network may result in the lack of 184 an IP path from one interface to another, and therefore in an 185 interruption of communication between the two interfaces. On the 186 other hand, not every failure in the control network affects a given 187 control channel, hence the need for establishing and managing 188 control channels. 190 For the purposes of this document, a data link may be considered by 191 each node that it terminates on as either a 'port' or a 'component 192 link' depending on the multiplexing capability of the endpoint on 193 that link; component links are multiplex capable, whereas ports are 194 not multiplex capable. This distinction is important since the 195 management of such links (including, for example, resource 196 allocation, label assignment, and their physical verification) is 197 different based on their multiplexing capability. For example, a 198 Frame Relay switch is able to demultiplex an interface into virtual 199 circuits based on DLCIs; similarly, a SONET crossconnect with OC-192 200 interfaces may be able to demultiplex the OC-192 stream into four 201 OC-48 streams. If multiple interfaces are grouped together into a 202 single TE link using link bundling [BUNDLE], then the link resources 203 must be identified using three levels: Link_Id, component interface 204 Id, and label identifying virtual circuit, timeslot, etc. Resource 205 allocation happens at the lowest level (labels), but physical 206 connectivity happens at the component link level. As another 207 example, consider the case where an optical switch (e.g., PXC) 208 transparently switches OC-192 lightpaths. If multiple interfaces are 209 once again grouped together into a single TE link, then link 210 bundling [BUNDLE] is not required and only two levels of 211 identification are required: Link_Id and Port_Id. In this case, both 212 resource allocation and physical connectivity happen at the lowest 213 level (i.e. port level). 215 To ensure interworking between data links with different 216 multiplexing capabilities, LMP capable devices SHOULD allow sub- 217 channels of a component link to be locally configured as (logical) 218 data links. For example, if a Router with 4 OC-48 interfaces is 219 connected through a 4:1 MUX to a cross-connect with OC-192 220 interfaces, the cross-connect should be able to configure each sub- 221 channel (e.g., STS-48c SPE if the 4:1 MUX is a SONET MUX) as a data 222 link. 224 LMP is designed to support aggregation of one or more data links 225 into a TE link (either ports into TE links, or component links into 226 TE links). The purpose of forming a TE link is to group/map the 227 information about certain physical resources (and their properties) 228 into the information that is used by Constrained SPF for the purpose 229 of path computation, and by GMPLS signaling. 231 1.1. Terminology 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 235 document are to be interpreted as described in [RFC2119]. 237 The reader is assumed to be familiar with the terminology in 238 [RFC3471], [GMPLS-RTG], and [BUNDLE]. 240 Bundled Link: 242 As defined in [BUNDLE], a bundled link is a TE link such that for 243 the purpose of GMPLS signaling a combination of is not sufficient to unambiguously identify the 245 appropriate resources used by an LSP. A bundled link is composed 246 of two or more component links. 248 Control Channel: 250 A control channel is a pair of mutually reachable interfaces that 251 are used to enable communication between nodes for routing, 252 signaling, and link management. 254 Component Link: 256 As defined in [BUNDLE], a component link is a subset of resources 257 of a TE Link such that (a) the partition is minimal, and (b) 258 within each subset a label is sufficient to unambiguously 259 identify the appropriate resources used by an LSP. 261 Data Link: 263 A data link is a pair of interfaces that are used to transfer 264 user data. Note that in GMPLS, the control channel(s) between two 265 adjacent nodes are no longer required to use the same physical 266 medium as the data links between those nodes. 268 Link Property Correlation: 270 This is a procedure to correlate the local and remote properties 271 of a TE link. 273 Multiplex Capability: 275 The ability to multiplex/demultiplex a data stream into sub-rate 276 streams for switching purposes. 278 Node_Id: 280 For a node running OSPF, the LMP Node_Id is the same as the 281 address contained in the OSPF Router Address TLV. For a node 282 running IS-IS and advertising the TE Router ID TLV, the Node_Id 283 is the same as the advertised Router ID. 285 Port: 287 An interface that terminates a data link. 289 TE Link: 291 As defined in [GMPLS-RTG], a TE link is a logical construct that 292 represents a way to group/map the information about certain 293 physical resources (and their properties) that interconnect LSRs 294 into the information that is used by Constrained SPF for the 295 purpose of path computation, and by GMPLS signaling. 297 Transparent: 299 A device is called X-transparent if it forwards incoming signals 300 from input to output without examining or modifying the X aspect 301 of the signal. For example, a Frame Relay switch is network-layer 302 transparent; an all-optical switch is electrically transparent. 304 2. LMP Overview 306 The two core procedures of LMP are control channel management and 307 link property correlation. Control channel management is used to 308 establish and maintain control channels between adjacent nodes. 309 This is done using a Config message exchange and a fast keep-alive 310 mechanism between the nodes. The latter is required if lower-level 311 mechanisms are not available to detect control channel failures. 312 Link property correlation is used to synchronize the TE link 313 properties and verify the TE link configuration. 315 LMP requires that a pair of nodes have at least one active bi- 316 directional control channel between them. Each direction of the 317 control channel is identified by a Control Channel Id (CC_Id), and 318 the two directions are coupled together using the LMP Config message 319 exchange. Except for Test messages, which may be limited by the 320 transport mechanism for in-band messaging, all LMP packets are run 321 over UDP with an LMP port number. The link level encoding of the 322 control channel is outside the scope of this document. 324 An "LMP adjacency" is formed between two nodes when at least one bi- 325 directional control channel is established between them. Multiple 326 control channels may be active simultaneously for each adjacency; 327 control channel parameters, however, MUST be individually negotiated 328 for each control channel. If the LMP fast keep-alive is used over a 329 control channel, LMP Hello messages MUST be exchanged over the 330 control channel. Other LMP messages MAY be transmitted over any of 331 the active control channels between a pair of adjacent nodes. One or 332 more active control channels may be grouped into a logical control 333 channel for signaling, routing, and link property correlation 334 purposes. 336 The link property correlation function of LMP is designed to 337 aggregate multiple data links (ports or component links) into a TE 338 link and to synchronize the properties of the TE link. As part of 339 the link property correlation function, a LinkSummary message 340 exchange is defined. The LinkSummary message includes the local and 341 remote Link_Ids, a list of all data links that comprise the TE link, 342 and various link properties. A LinkSummaryAck or LinkSummaryNack 343 message MUST be sent in response to the receipt of a LinkSummary 344 message indicating agreement or disagreement on the link properties. 346 LMP messages are transmitted reliably using Message_Ids and 347 retransmissions. Message_Ids are carried in MESSAGE_ID objects. No 348 more than one MESSAGE_ID object may be included in an LMP message. 349 For control channel specific messages, the Message_Id is within the 350 scope of the control channel over which the message is sent. For TE 351 link specific messages, the Message_Id is within the scope of the 352 LMP adjacency. The value of the Message_Id is monotonically 353 increasing and wraps when the maximum value is reached. 355 In this document, two additional LMP procedures are defined: link 356 connectivity verification and fault management. These procedures are 357 particularly useful when the control channels are physically diverse 358 from the data links. Link connectivity verification is used for data 359 plane discovery, Interface_Id exchange (Interface_Ids are used in 360 GMPLS signaling, either as port labels or component link 361 identifiers, depending on the configuration), and physical 362 connectivity verification. This is done by sending Test messages 363 over the data links and TestStatus messages back over the control 364 channel. Note that the Test message is the only LMP message that 365 must be transmitted over the data link. The ChannelStatus message 366 exchange is used between adjacent nodes for both the suppression of 367 downstream alarms and the localization of faults for protection and 368 restoration. 370 For LMP link connectivity verification, the Test message is 371 transmitted over the data links. For X-transparent devices, this 372 requires examining and modifying the X aspect of the signal. The LMP 373 link connectivity verification procedure is coordinated using a 374 BeginVerify message exchange over a control channel. To support 375 various aspects of transparency, a Verify Transport Mechanism is 376 included in the BeginVerify and BeginVerifyAck messages. Note that 377 there is no requirement that all data links must lose their 378 transparency simultaneously, but at a minimum, it must be possible 379 to terminate them one at a time. There is also no requirement that 380 the control channel and TE link use the same physical medium; 381 however, the control channel MUST be terminated by the same two 382 control elements that control the TE link. Since the BeginVerify 383 message exchange coordinates the Test procedure, it also naturally 384 coordinates the transition of the data links in and out of the 385 transparent mode. 387 The LMP fault management procedure is based on a ChannelStatus 388 message exchange using the following messages: ChannelStatus, 389 ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse. 390 The ChannelStatus message is sent unsolicited and is used to notify 391 an LMP neighbor about the status of one or more data channels of a 392 TE link. The ChannelStatusAck message is used to acknowledge receipt 393 of the ChannelStatus message. The ChannelStatusRequest message is 394 used to query an LMP neighbor for the status of one or more data 395 channels of a TE Link. The ChannelStatusResponse message is used to 396 acknowledge receipt of the ChannelStatusRequest message and indicate 397 the states of the queried data links. 399 3. Control Channel Management 401 To initiate an LMP adjacency between two nodes, one or more bi- 402 directional control channels MUST be activated. The control channels 403 can be used to exchange control-plane information such as link 404 provisioning and fault management information (implemented using a 405 messaging protocol such as LMP, proposed in this document), path 406 management and label distribution information (implemented using a 407 signaling protocol such as RSVP-TE [RFC3209]), and network topology 408 and state distribution information (implemented using traffic 409 engineering extensions of protocols such as OSPF [OSPF-TE] and IS-IS 410 [ISIS-TE]). 412 For the purposes of LMP, the exact implementation of the control 413 channel is not specified; it could be, for example, a separate 414 wavelength or fiber, an Ethernet link, an IP tunnel through a 415 separate management network, or the overhead bytes of a data link. 416 Rather, each node assigns a node-wide unique 32-bit non-zero integer 417 control channel identifier (CC_Id). This identifier comes from the 418 same space as the unnumbered interface Id. Furthermore, LMP packets 419 are run over UDP with an LMP port number. Thus, the link level 420 encoding of the control channel is not part of the LMP 421 specification. 423 To establish a control channel, the destination IP address on the 424 far end of the control channel must be known. This knowledge may be 425 manually configured or automatically discovered. Note that for in- 426 band signaling, a control channel could be explicitly configured on 427 a particular data link. In this case, the Config message exchange 428 can be used to dynamically learn the IP address on the far end of 429 the control channel. This is done by sending the Config message with 430 the unicast IP source address and the multicast IP destination 431 address (224.0.0.1 or ff02::1). The ConfigAck and ConfigNack 432 messages MUST be sent to the source IP address found in the IP 433 header of the received Config message. 435 Control channels exist independently of TE links and multiple 436 control channels may be active simultaneously between a pair of 437 nodes. Individual control channels can be realized in different 438 ways; one might be implemented in-fiber while another one may be 439 implemented out-of-fiber. As such, control channel parameters MUST 440 be negotiated over each individual control channel, and LMP Hello 441 packets MUST be exchanged over each control channel to maintain LMP 442 connectivity if other mechanisms are not available. Since control 443 channels are electrically terminated at each node, it may be 444 possible to detect control channel failures using lower layers 445 (e.g., SONET/SDH). 447 There are four LMP messages that are used to manage individual 448 control channels. They are the Config, ConfigAck, ConfigNack, and 449 Hello messages. These messages MUST be transmitted on the channel to 450 which they refer. All other LMP messages may be transmitted over any 451 of the active control channels between a pair of LMP adjacent nodes. 453 In order to maintain an LMP adjacency, it is necessary to have at 454 least one active control channel between a pair of adjacent nodes 455 (recall that multiple control channels can be active simultaneously 456 between a pair of nodes). In the event of a control channel failure, 457 alternate active control channels can be used and it may be possible 458 to activate additional control channels as described below. 460 3.1. Parameter Negotiation 462 Control channel activation begins with a parameter negotiation 463 exchange using Config, ConfigAck, and ConfigNack messages. The 464 contents of these messages are built using LMP objects, which can be 465 either negotiable or non-negotiable (identified by the N bit in the 466 object header). Negotiable objects can be used to let LMP peers 467 agree on certain values. Non-negotiable objects are used for the 468 announcement of specific values that do not need, or do not allow, 469 negotiation. 471 To activate a control channel, a Config message MUST be transmitted 472 to the remote node, and in response, a ConfigAck message MUST be 473 received at the local node. The Config message contains the Local 474 Control Channel Id (CC_Id), the sender's Node_Id, a Message_Id for 475 reliable messaging, and a CONFIG object. It is possible that both 476 the local and remote nodes initiate the configuration procedure at 477 the same time. To avoid ambiguities, the node with the higher 478 Node_Id wins the contention; the node with the lower Node_Id MUST 479 stop transmitting the Config message and respond to the Config 480 message it received. If the Node_Ids are equal, then one (or both) 481 nodes have been misconfigured. The nodes MAY continue to retransmit 482 Config messages in hopes that the misconfiguration is corrected. 483 Note that the problem may be solved by an operator changing the 484 Node_Ids on one or both nodes. 486 The ConfigAck message is used to acknowledge receipt of the Config 487 message and express agreement on ALL of the configured parameters 488 (both negotiable and non-negotiable). 490 The ConfigNack message is used to acknowledge receipt of the Config 491 message, indicate which (if any) non-negotiable CONFIG objects are 492 unacceptable, and propose alternate values for the negotiable 493 parameters. 495 If a node receives a ConfigNack message with acceptable alternate 496 values for negotiable parameters, the node SHOULD transmit a Config 497 message using these values for those parameters. 499 If a node receives a ConfigNack message with unacceptable alternate 500 values, the node MAY continue to retransmit Config messages in hopes 501 that the misconfiguration is corrected. Note that the problem may be 502 solved by an operator changing parameters on one or both nodes. 504 In the case where multiple control channels use the same physical 505 interface, the parameter negotiation exchange is performed for each 506 control channel. The various LMP parameter negotiation messages are 507 associated with their corresponding control channels by their node- 508 wide unique identifiers (CC_Ids). 510 3.2. Hello Protocol 512 Once a control channel is activated between two adjacent nodes, the 513 LMP Hello protocol can be used to maintain control channel 514 connectivity between the nodes and to detect control channel 515 failures. The LMP Hello protocol is intended to be a lightweight 516 keep-alive mechanism that will react to control channel failures 517 rapidly so that IGP Hellos are not lost and the associated link- 518 state adjacencies are not removed unnecessarily. 520 3.2.1. Hello Parameter Negotiation 522 Before sending Hello messages, the HelloInterval and 523 HelloDeadInterval parameters MUST be agreed upon by the local and 524 remote nodes. These parameters are exchanged in the Config message. 525 The HelloInterval indicates how frequently LMP Hello messages will 526 be sent, and is measured in milliseconds (ms). For example, if the 527 value were 150, then the transmitting node would send the Hello 528 message at least every 150ms. The HelloDeadInterval indicates how 529 long a device should wait to receive a Hello message before 530 declaring a control channel dead, and is measured in milliseconds 531 (ms). 533 The HelloDeadInterval MUST be greater than the HelloInterval, and 534 SHOULD be at least 3 times the value of HelloInterval. If the fast 535 keep-alive mechanism of LMP is not used, the HelloInterval and 536 HelloDeadInterval parameters MUST be set to zero. 538 The values for the HelloInterval and HelloDeadInterval should be 539 selected carefully to provide rapid response time to control channel 540 failures without causing congestion. As such, different values will 541 likely be configured for different control channel implementations. 542 When the control channel is implemented over a directly connected 543 link, the suggested default values for the HelloInterval is 150 ms 544 and for the HelloDeadInterval is 500 ms. 546 When a node has either sent or received a ConfigAck message, it may 547 begin sending Hello messages. Once it has sent a Hello message and 548 received a valid Hello message (i.e., with expected sequence 549 numbers; see Section 3.2.2), the control channel moves to the up 550 state. (It is also possible to move to the up state without sending 551 Hellos if other methods are used to indicate bi-directional control- 552 channel connectivity. For example, indication of bi-directional 553 connectivity may be learned from the transport layer.) If, however, 554 a node receives a ConfigNack message instead of a ConfigAck message, 555 the node MUST not send Hello messages and the control channel SHOULD 556 NOT move to the up state. See Section 11.1 for the complete control 557 channel FSM. 559 3.2.2. Fast Keep-alive 561 Each Hello message contains two sequence numbers: the first sequence 562 number (TxSeqNum) is the sequence number for the Hello message being 563 sent and the second sequence number (RcvSeqNum) is the sequence 564 number of the last Hello message received from the adjacent node 565 over this control channel. 567 There are two special sequence numbers. TxSeqNum MUST NOT ever be 0. 568 TxSeqNum = 1 is used to indicate that the sender has just started or 569 has restarted and has no recollection of the last TxSeqNum that was 570 sent. Thus, the first Hello sent has a TxSeqNum of 1 and an RxSeqNum 571 of 0. When TxSeqNum reaches (2^32)-1, the next sequence number used 572 is 2, not 0 or 1, as these have special meanings. 574 Under normal operation, the difference between the RcvSeqNum in a 575 Hello message that is received and the local TxSeqNum that is 576 generated will be at most 1. This difference can be more than one 577 only when a control channel restarts or when the values wrap. 579 Since the 32-bit sequence numbers may wrap, the following expression 580 may be used to test if a newly received TxSeqNum value is less than 581 a previously received value: 583 If ((int) old_id - (int) new_id > 0) { 584 New value is less than old value; 585 } 587 Having sequence numbers in the Hello messages allows each node to 588 verify that its peer is receiving its Hello messages. By including 589 the RcvSeqNum in Hello packets, the local node will know which Hello 590 packets the remote node has received. 592 The following example illustrates how the sequence numbers operate. 593 Note that only the operation at one node is shown, and alternative 594 scenarios are possible: 596 1) After completing the configuration stage, Node A sends Hello 597 messages to Node B with {TxSeqNum=1;RcvSeqNum=0}. 599 2) Node A receives a Hello from Node B with 600 {TxSeqNum=1;RcvSeqNum=1}. When the HelloInterval expires on 601 Node A, it sends Hellos to Node B with {TxSeqNum=2;RcvSeqNum=1}. 603 3) Node A receives a Hello from Node B with 604 {TxSeqNum=2;RcvSeqNum=2}. When the HelloInterval expires on Node 605 A, it sends Hellos to Node B with {TxSeqNum=3;RcvSeqNum=2}. 607 3.2.3. Control Channel Down 609 To allow bringing a control channel down gracefully for 610 administration purposes, a ControlChannelDown flag is available in 611 the Common Header of LMP packets. When data links are still in use 612 between a pair of nodes, a control channel SHOULD only be taken down 613 administratively when there are other active control channels that 614 can be used to manage the data links. 616 When bringing a control channel down administratively, a node MUST 617 set the ControlChannelDown flag in all LMP messages sent over the 618 control channel. The node that initiated the control channel down 619 procedure may stop sending Hello messages after HelloDeadInterval 620 seconds have passed, or if it receives an LMP message over the same 621 control channel with the ControlChannelDown flag set. 623 When a node receives an LMP packet with the ControlChannelDown flag 624 set, it SHOULD send a Hello message with the ControlChannelDown flag 625 set and move the control channel to the down state. 627 3.2.4. Degraded State 629 A consequence of allowing the control channels to be physically 630 diverse from the associated data links is that there may not be any 631 active control channels available while the data links are still in 632 use. For many applications, it is unacceptable to tear down a link 633 that is carrying user traffic simply because the control channel is 634 no longer available; however, the traffic that is using the data 635 links may no longer be guaranteed the same level of service. Hence, 636 the TE link is in a Degraded state. 638 When a TE link is in the Degraded state, routing and signaling 639 SHOULD be notified so that new connections are not accepted and the 640 TE link is advertised with no unreserved resources. 642 4. Link Property Correlation 644 As part of LMP, a link property correlation exchange is defined for 645 TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack 646 messages. The contents of these messages are built using LMP 647 objects, which can be either negotiable or non-negotiable 648 (identified by the N flag in the object header). Negotiable objects 649 can be used to let both sides agree on certain link parameters. 650 Non-negotiable objects are used for announcement of specific values 651 that do not need, or do not allow, negotiation. 653 Each TE link has an identifier (Link_Id) that is assigned at each 654 end of the link. These identifiers MUST be the same type (i.e, IPv4, 655 IPv6, unnumbered) at both ends. If a LinkSummary message is received 656 with different local and remote TE link types, then a 657 LinkSummaryNack message MUST be sent with Error Code "Bad TE Link 658 Object". Similarly, each data link is assigned an identifier 659 (Interface_Id) at each end. These identifiers MUST also be the same 660 type at both ends. If a LinkSummary message is received with 661 different local and remote Interface_Id types then a LinkSummaryNack 662 message MUST be sent with Error Code "Bad Data Link Object". 664 Link property correlation SHOULD be done before the link is brought 665 up and MAY be done at any time a link is up and not in the 666 Verification process. 668 The LinkSummary message is used to verify for consistency the TE and 669 data link information on both sides. Link Summary messages are also 670 used to aggregate multiple data links (either ports or component 671 links) into a TE link; exchange, correlate (to determine 672 inconsistencies), or change TE link parameters; and exchange, 673 correlate (to determine inconsistencies), or change Interface_Ids 674 (used either Port_Ids or component link identifiers). 676 The LinkSummary message includes a TE_LINK object followed by one or 677 more DATA_LINK objects. The TE_LINK object identifies the TE link's 678 local and remote Link_Id and indicates support for fault management 679 and link verification procedures for that TE link. The DATA_LINK 680 objects are used to characterize the data links that comprise the TE 681 link. These objects include the local and remote Interface_Ids, and 682 may include one or more sub-objects further describing the 683 properties of the data links. 685 If the LinkSummary message is received from a remote node and the 686 Interface_Id mappings match those that are stored locally, then the 687 two nodes have agreement on the Verification procedure (see Section 688 5) and data link identification configuration. If the verification 689 procedure is not used, the LinkSummary message can be used to verify 690 agreement on manual configuration. 692 The LinkSummaryAck message is used to signal agreement on the 693 Interface_Id mappings and link property definitions. Otherwise, a 694 LinkSummaryNack message MUST be transmitted, indicating which 695 Interface mappings are not correct and/or which link properties are 696 not accepted. If a LinkSummaryNack message indicates that the 697 Interface_Id mappings are not correct and the link verification 698 procedure is enabled, the link verification process SHOULD be 699 repeated for all mismatched free data links; if an allocated data 700 link has a mapping mismatch, it SHOULD be flagged and verified when 701 it becomes free. If a LinkSummaryNack message includes negotiable 702 parameters, then acceptable values for those parameters MUST be 703 included. If a LinkSummaryNack message is received and includes 704 negotiable parameters, then the initiator of the LinkSummary message 705 SHOULD send a new LinkSummary message. The new LinkSummary message 706 SHOULD include new values for the negotiable parameters. These 707 values SHOULD take into account the acceptable values received in 708 the LinkSummaryNack message. 710 It is possible that the LinkSummary message could grow quite large 711 due to the number of DATA LINK objects. An LMP implementation SHOULD 712 be able to fragment when transmitting LMP messages, and MUST be able 713 to re-assemble IP fragments when receiving LMP messages. 715 5. Verifying Link Connectivity 717 In this section, an optional procedure is described that may be used 718 to verify the physical connectivity of the data links and 719 dynamically learn (i.e., discover) the TE link and Interface_Id 720 associations. The procedure SHOULD be done when establishing a TE 721 link, and subsequently, on a periodic basis for all unallocated 722 (free) data links of the TE link. 724 Support for this procedure is indicated by setting the "Link 725 Verification Supported" flag in the TE_LINK object of the 726 LinkSummary message. 728 If a BeginVerify message is received and link verification is not 729 supported for the TE link, then a BeginVerifyNack message MUST be 730 transmitted with Error Code indicating, "Link Verification Procedure 731 not supported for this TE Link." 733 A unique characteristic of transparent devices is that the data is 734 not modified or examined in normal operation. This characteristic 735 poses a challenge for validating the connectivity of the data links 736 and establish the label mappings. Therefore, to ensure proper 737 verification of data link connectivity, it is required that until 738 the data links are allocated for user traffic, they must be opaque 739 (i.e., lose their transparency). To support various degrees of 740 opaqueness (e.g., examining overhead bytes, terminating the IP 741 payload, etc.), and hence different mechanisms to transport the Test 742 messages, a Verify Transport Mechanism field is included in the 743 BeginVerify and BeginVerifyAck messages. 745 There is no requirement that all data links be terminated 746 simultaneously, but at a minimum, the data links MUST be able to be 747 terminated one at a time. Furthermore, for the link verification 748 procedure it is assumed that the nodal architecture is designed so 749 that messages can be sent and received over any data link. Note that 750 this requirement is trivial for opaque devices since each data link 751 is electrically terminated and processed before being forwarded to 752 the next opaque device, but that in transparent devices this is an 753 additional requirement. 755 To interconnect two nodes, a TE link is defined between them, and at 756 a minimum, there MUST be at least one active control channel between 757 the nodes. For link verification, a TE link MUST include at least 758 one data link. 760 Once a control channel has been established between the two nodes, 761 data link connectivity can be verified by exchanging Test messages 762 over each of the data links specified in the TE link. It should be 763 noted that all LMP messages except the Test message are exchanged 764 over the control channels and that Hello messages continue to be 765 exchanged over each control channel during the data link 766 verification process. The Test message is sent over the data link 767 that is being verified. Data links are tested in the transmit 768 direction as they are unidirectional, and therefore, it may be 769 possible for both nodes to (independently) exchange the Test 770 messages simultaneously. 772 To initiate the link verification procedure, the local node MUST 773 send a BeginVerify message over a control channel. To limit the 774 scope of Link Verification to a particular TE Link, the local 775 Link_Id MUST be non-zero. If this field is zero, the data links can 776 span multiple TE links and/or they may comprise a TE link that is 777 yet to be configured. For the case where the local Link_Id field is 778 zero, the "Verify all Links" flag of the BEGIN_VERIFY object is used 779 to distinguish between data links that span multiple TE links and 780 those that have not yet been assigned to a TE link. Specifically, 781 verification of data links that span multiple TE links is indicated 782 by setting the local Link_Id field to zero and setting the "Verify 783 all Links" flag. Verification of data links that have not yet been 784 assigned to a TE link is indicated by setting the local Link_Id 785 field to zero and clearing the "Verify all Links" flag. 787 The BeginVerify message also contains the number of data links that 788 are to be verified; the interval (called VerifyInterval) at which 789 the Test messages will be sent; the encoding scheme and transport 790 mechanisms that are supported; the data rate for Test messages; and, 791 when the data links correspond to fibers, the wavelength identifier 792 over which the Test messages will be transmitted. 794 If the remote node receives a BeginVerify message and it is ready to 795 process Test messages, it MUST send a BeginVerifyAck message back to 796 the local node specifying the desired transport mechanism for the 797 TEST messages. The remote node includes a 32-bit node unique 798 Verify_Id in the BeginVerifyAck message. The Verify_Id MAY be 799 randomly selected, however, it MUST NOT overlap any other Verify_Id 800 currently being used by the node selecting it. The Verify_Id is 801 then used in all corresponding verification messages to 802 differentiate them from different LMP peers and/or parallel Test 803 procedures. When the local node receives a BeginVerifyAck message 804 from the remote node, it may begin testing the data links by 805 transmitting periodic Test messages over each data link. The Test 806 message includes the Verify_Id and the local Interface_Id for the 807 associated data link. The remote node MUST send either a 808 TestStatusSuccess or a TestStatusFailure message in response for 809 each data link. A TestStatusAck message MUST be sent to confirm 810 receipt of the TestStatusSuccess and TestStatusFailure messages. 811 Unacknowledged TestStatusSuccess and TestStatusFailure messages 812 SHOULD be retransmitted until the message is acknowledged or until a 813 retry limit is reached (see also Section 10). 815 It is also permissible for the sender to terminate the Test 816 procedure anytime after sending the BeginVerify message. An 817 EndVerify message SHOULD be sent for this purpose. 819 Message correlation is done using message identifiers and the 820 Verify_Id; this enables verification of data links, belonging to 821 different link bundles or LMP sessions, in parallel. 823 When the Test message is received, the received Interface_Id (used 824 in GMPLS as either a Port label or component link identifier 825 depending on the configuration) is recorded and mapped to the local 826 Interface_Id for that data link, and a TestStatusSuccess message 827 MUST be sent. The TestStatusSuccess message includes the local 828 Interface_Id along with the Interface_Id and Verify_Id received in 829 the Test message. The receipt of a TestStatusSuccess message 830 indicates that the Test message was detected at the remote node and 831 the physical connectivity of the data link has been verified. When 832 the TestStatusSuccess message is received, the local node SHOULD 833 mark the data link as up and send a TestStatusAck message to the 834 remote node. If, however, the Test message is not detected at the 835 remote node within an observation period (specified by the 836 VerifyDeadInterval), the remote node MUST send a TestStatusFailure 837 message over the control channel indicating that the verification of 838 the physical connectivity of the data link has failed. When the 839 local node receives a TestStatusFailure message, it SHOULD mark the 840 data link as FAILED and send a TestStatusAck message to the remote 841 node. When all the data links on the list have been tested, the 842 local node SHOULD send an EndVerify message to indicate that testing 843 is complete on this link. 845 If the local/remote data link mappings are known, then the link 846 verification procedure can be optimized by testing the data links in 847 a defined order known to both nodes. The suggested criterion for 848 this ordering is in increasing value of the remote Interface_Id. 850 Both the local and remote nodes SHOULD maintain the complete list of 851 Interface_Id mappings for correlation purposes. 853 5.1. Example of Link Connectivity Verification 855 Figure 1 shows an example of the link verification scenario that is 856 executed when a link between Node A and Node B is added. In this 857 example, the TE link consists of three free ports (each transmitted 858 along a separate fiber) and is associated with a bi-directional 859 control channel (indicated by a "c"). The verification process is as 860 follows: 861 o A sends a BeginVerify message over the control channel to B 862 indicating it will begin verifying the ports that form the TE 863 link. The LOCAL_LINK_ID object carried in the BeginVerify 864 message carries the identifier (IP address or interface index) 865 that A assigns to the link. 866 o Upon receipt of the BeginVerify message, B creates a Verify_Id 867 and binds it to the TE Link from A. This binding is used later 868 when B receives the Test messages from A, and these messages 869 carry the Verify_Id. B discovers the identifier (IP address or 870 interface index) that A assigns to the TE link by examining the 871 LOCAL_LINK_ID object carried in the received BeginVerify 872 message. (If the data ports are not yet assigned to the TE 873 Link, the binding is limited to the Node_Id of A.) In response 874 to the BeginVerify message, B sends to A the BeginVerifyAck 875 message. The LOCAL_LINK_ID object carried in the BeginVerifyAck 876 message is used to carry the identifier (IP address or 877 interface index) that B assigns to the TE link. The 878 REMOTE_LINK_ID object carried in the BeginVerifyAck message is 879 used to bind the Link_Ids assigned by both A and B. The 880 Verify_Id is returned to A in the BeginVerifyAck message over 881 the control channel. 882 o When A receives the BeginVerifyAck message, it begins 883 transmitting periodic Test messages over the first port 884 (Interface Id=1). The Test message includes the Interface_Id 885 for the port and the Verify_Id that was assigned by B. 886 o When B receives the Test messages, it maps the received 887 Interface_Id to its own local Interface_Id = 10 and transmits a 888 TestStatusSuccess message over the control channel back to Node 889 A. The TestStatusSuccess message includes both the local and 890 received Interface_Ids for the port as well as the Verify_Id. 891 The Verify_Id is used to determine the local/remote TE link 892 identifiers (IP addresses or interface indices) for which the 893 data links belong. 894 o A will send a TestStatusAck message over the control channel 895 back to B indicating it received the TestStatusSuccess message. 896 o The process is repeated until all of the ports are verified. 897 o At this point, A will send an EndVerify message over the 898 control channel to B to indicate that testing is complete. 900 o B will respond by sending an EndVerifyAck message over the 901 control channel back to A. 903 Note that this procedure can be used to "discover" the 904 connectivity of the data ports. 906 +---------------------+ +---------------------+ 907 + + + + 908 + Node A +<-------- c --------->+ Node B + 909 + + + + 910 + + + + 911 + 1 +--------------------->+ 10 + 912 + + + + 913 + + + + 914 + 2 + /---->+ 11 + 915 + + /----/ + + 916 + + /---/ + + 917 + 3 +----/ + 12 + 918 + + + + 919 + + + + 920 + 4 +--------------------->+ 14 + 921 + + + + 922 +---------------------+ +---------------------+ 924 Figure 1: Example of link connectivity between Node A and Node B. 926 6. Fault Management 928 In this section, an optional LMP procedure is described that is used 929 to manage failures by rapid notification of the status of one or 930 more data channels of a TE Link. The scope of this procedure is 931 within a TE link, and as such, the use of this procedure is 932 negotiated as part of the LinkSummary exchange. The procedure can be 933 used to rapidly isolate data link and TE link failures, and is 934 designed to work for both unidirectional and bi-directional LSPs. 936 An important implication of using transparent devices is that 937 traditional methods that are used to monitor the health of allocated 938 data links in may no longer be appropriate. Instead, fault detection 939 is delegated to the physical layer (i.e., loss of light or optical 940 monitoring of the data) instead of layer 2 or layer 3. 942 Recall that a TE link connecting two nodes may consist of a number 943 of data links. If one or more data links fail between two nodes, a 944 mechanism must be used for rapid failure notification so that 945 appropriate protection/restoration mechanisms can be initiated. If 946 the failure is subsequently cleared, then a mechanism must be used 947 to notify that the failure is clear and the channel status is OK. 949 6.1. Fault Detection 950 Fault detection should be handled at the layer closest to the 951 failure; for optical networks, this is the physical (optical) layer. 952 One measure of fault detection at the physical layer is detecting 953 loss of light (LOL). Other techniques for monitoring optical signals 954 are still being developed and will not be further considered in this 955 document. However, it should be clear that the mechanism used for 956 fault notification in LMP is independent of the mechanism used to 957 detect the failure, but simply relies on the fact that a failure is 958 detected. 960 6.2. Fault Localization Procedure 962 In some situations, a data link failure between two nodes is 963 propagated downstream such that all the downstream nodes detect the 964 failure without localizing the failure. To avoid multiple alarms 965 stemming from the same failure, LMP provides failure notification 966 through the ChannelStatus message. This message may be used to 967 indicate that a single data channel has failed, multiple data 968 channels have failed, or an entire TE link has failed. Failure 969 correlation is done locally at each node upon receipt of the failure 970 notification. 972 To localize a fault to a particular link between adjacent nodes, a 973 downstream node (downstream in terms of data flow) that detects data 974 link failures will send a ChannelStatus message to its upstream 975 neighbor indicating that a failure has been detected (bundling 976 together the notification of all of the failed data links). An 977 upstream node that receives the ChannelStatus message MUST send a 978 ChannelStatusAck message to the downstream node indicating it has 979 received the ChannelStatus message. The upstream node should 980 correlate the failure to see if the failure is also detected locally 981 for the corresponding LSP(s). If, for example, the failure is clear 982 on the input of the upstream node or internally, then the upstream 983 node will have localized the failure. Once the failure is 984 correlated, the upstream node SHOULD send a ChannelStatus message to 985 the downstream node indicating that the channel is failed or is ok. 986 If a ChannelStatus message is not received by the downstream node, 987 it SHOULD send a ChannelStatusRequest message for the channel in 988 question. Once the failure has been localized, the signaling 989 protocols may be used to initiate span or path protection and 990 restoration procedures. 992 If all of the data links of a TE link have failed, then the upstream 993 node MAY be notified of the TE link failure without specifying each 994 data link of the failed TE link. This is done by sending failure 995 notification in a ChannelStatus message identifying the TE Link 996 without including the Interface_Ids in the CHANNEL_STATUS object. 998 6.3. Examples of Fault Localization 1000 In Figure 2, a sample network is shown where four nodes are 1001 connected in a linear array configuration. The control channels are 1002 bi-directional and are labeled with a "c". All LSPs are also bi- 1003 directional. 1005 In the first example [see Fig. 2(a)], there is a failure on one 1006 direction of the bi-directional LSP. Node 4 will detect the failure 1007 and will send a ChannelStatus message to Node 3 indicating the 1008 failure (e.g., LOL) to the corresponding upstream node. When Node 3 1009 receives the ChannelStatus message from Node 4, it returns a 1010 ChannelStatusAck message back to Node 4 and correlates the failure 1011 locally. When Node 3 correlates the failure and verifies that the 1012 failure is clear, it has localized the failure to the data link 1013 between Node 3 and Node 4. At that time, Node 3 should send a 1014 ChannelStatus message to Node 4 indicating that the failure has been 1015 localized. 1017 In the second example [see Fig. 2(b)], a single failure (e.g., fiber 1018 cut) affects both directions of the bi-directional LSP. Node 2 (Node 1019 3) will detect the failure of the upstream (downstream) direction 1020 and send a ChannelStatus message to the upstream (in terms of data 1021 flow) node indicating the failure (e.g., LOL). Simultaneously 1022 (ignoring propagation delays), Node 1 (Node 4) will detect the 1023 failure on the upstream (downstream) direction, and will send a 1024 ChannelStatus message to the corresponding upstream (in terms of 1025 data flow) node indicating the failure. Node 2 and Node 3 will have 1026 localized the two directions of the failure. 1028 +-------+ +-------+ +-------+ +-------+ 1029 + Node1 + + Node2 + + Node3 + + Node4 + 1030 + +-- c ---+ +-- c ---+ +-- c ---+ + 1031 ----+---\ + + + + + + + 1032 <---+---\\--+--------+-------+---\ + + + /--+---> 1033 + \--+--------+-------+---\\---+-------+---##---+---//--+---- 1034 + + + + \---+-------+--------+---/ + 1035 + + + + + + (a) + + 1036 ----+-------+--------+---\ + + + + + 1037 <---+-------+--------+---\\--+---##---+--\ + + + 1038 + + + \--+---##---+--\\ + + + 1039 + + + + (b) + \\--+--------+-------+---> 1040 + + + + + \--+--------+-------+---- 1041 + + + + + + + + 1042 +-------+ +-------+ +-------+ +-------+ 1044 Figure 2: Two types of data link failures are shown 1045 (indicated by ## in the figure): (A) a data link 1046 corresponding to the downstream direction of a bi-directional 1047 LSP fails, (B) two data links corresponding to both 1048 directions of a bi-directional LSP fail. The control channel 1049 connecting two nodes is indicated with a "c". 1051 6.4. Channel Activation Indication 1052 The ChannelStatus message may also be used to notify an LMP neighbor 1053 that the data link should be actively monitored. This is called 1054 Channel Activation Indication. This is particularly useful in 1055 networks with transparent nodes where the status of data links may 1056 need to be triggered using control channel messages. For example, if 1057 a data link is pre-provisioned and the physical link fails after 1058 verification and before inserting user traffic, a mechanism is 1059 needed to indicate the data link should be active or the failure may 1060 not be able to be detected. 1062 The ChannelStatus message is used to indicate that a channel or 1063 group of channels are now active. The ChannelStatusAck message MUST 1064 be transmitted upon receipt of a ChannelStatus message. When a 1065 ChannelStatus message is received, the corresponding data link(s) 1066 MUST be put into the Active state. If upon putting them into the 1067 Active state, a failure is detected, the ChannelStatus message 1068 SHOULD be transmitted as described in Section 6.2. 1070 6.5. Channel Deactivation Indication 1072 The ChannelStatus message may also be used to notify an LMP neighbor 1073 that the data link no longer needs to be actively monitored. This 1074 is the counterpart to the Channel Active Indication. 1076 When a ChannelStatus message is received with Channel Deactive 1077 Indication, the corresponding data link(s) MUST be taken out of the 1078 Active state. 1080 7. Message_Id Usage 1082 The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP 1083 messages to support reliable message delivery. This section 1084 describes the usage of these objects. The MESSAGE_ID and 1085 MESSAGE_ID_ACK objects contain a Message_Id field. 1087 Only one MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP 1088 message. 1090 For control channel specific messages, the Message_Id field is 1091 within the scope of the CC_Id. For TE link specific messages, the 1092 Message_Id field is within the scope of the LMP adjacency. 1094 The Message_Id field of the MESSAGE_ID object contains a generator- 1095 selected value. This value MUST be monotonically increasing. A value 1096 is considered to be previously used when it has been sent in an LMP 1097 message with the same CC_Id (for control channel specific messages) 1098 or LMP adjacency (for TE Link specific messages). The Message_Id 1099 field of the MESSAGE_ID_ACK object contains the Message_Id field of 1100 the message being acknowledged. 1102 Unacknowledged messages sent with the MESSAGE_ID object SHOULD be 1103 retransmitted until the message is acknowledged or until a retry 1104 limit is reached (see also Section 10). 1106 Note that the 32-bit Message_Id value may wrap. The following 1107 expression may be used to test if a newly received Message_Id value 1108 is less than a previously received value: 1110 If ((int) old_id - (int) new_id > 0) { 1111 New value is less than old value; 1112 } 1114 Nodes processing incoming messages SHOULD check to see if a newly 1115 received message is out of order and can be ignored. Out-of-order 1116 messages can be identified by examining the value in the Message_Id 1117 field. If a message is determined to be out-of-order, that message 1118 should be silently dropped. 1120 If the message is a Config message, and the Message_Id value is less 1121 than the largest Message_Id value previously received from the 1122 sender for the CC_Id, then the message SHOULD be treated as being 1123 out-of-order. 1125 If the message is a LinkSummary message and the Message_Id value is 1126 less than the largest Message_Id value previously received from the 1127 sender for the TE Link, then the message SHOULD be treated as being 1128 out-of-order. 1130 If the message is a ChannelStatus message and the Message_Id value 1131 is less than the largest Message_Id value previously received from 1132 the sender for the specified TE link, then the receiver SHOULD check 1133 the Message_Id value previously received for the state of each data 1134 channel included in the ChannelStatus message. If the Message_Id 1135 value is greater than the most recently received Message_Id value 1136 associated with at least one of the data channels included in the 1137 message, the message MUST NOT be treated as out of order; otherwise 1138 the message SHOULD be treated as being out of order. However, the 1139 state of any data channel MUST NOT be updated if the Message_Id 1140 value is less than the most recently received Message_Id value 1141 associated with the data channel. 1143 All other messages MUST NOT be treated as out-of-order. 1145 8. Graceful Restart 1147 This section describes the mechanism to resynchronize the LMP state 1148 after a control plane restart. A control plane restart may occur 1149 when bringing up the first control channel after a control 1150 communications failure. A control communications failure may be the 1151 result of an LMP adjacency failure or a nodal failure wherein the 1152 LMP control state is lost, but the data plane is unaffected. The 1153 latter is detected by setting the "LMP Restart" bit in the Common 1154 Header of the LMP messages. When the control plane fails due to the 1155 loss of the control channel, the LMP link information should be 1156 retained. It is possible that a node may be capable of retaining the 1157 LMP link information across a nodal failure. However, in both cases 1158 the status of the data channels MUST be synchronized. 1160 It is assumed the Node_Id and Local Interface_Ids remain stable 1161 across a control plane restart. 1163 After the control plane of a node restarts, the control channel(s) 1164 must be re-established using the procedures of Section 3.1. When re- 1165 establishing control channels, the Config message SHOULD be sent 1166 using the unicast IP source and destination addresses. 1168 If the control plane failure was the result of a nodal failure where 1169 the LMP control state is lost, then the "LMP Restart" flag MUST be 1170 set in LMP messages until a Hello message is received with the 1171 RcvSeqNum equal to the local TxSeqNum. This indicates that the 1172 control channel is up and the LMP neighbor has detected the restart. 1174 The following assumes that the LMP component restart only occurred 1175 on one end of the TE Link. If the LMP component restart occurred on 1176 both ends of the TE Link, the normal procedures for LinkSummary 1177 should be used, as described in Section 4. 1179 Once a control channel is up, the LMP neighbor MUST send a 1180 LinkSummary message for each TE Link across the adjacency. All the 1181 objects of the LinkSummary message MUST have the N-bit set to 0 1182 indicating that the parameters are non-negotiable. This provides the 1183 local/remote Link_Id and Interface_Id mappings, the associated data 1184 link parameters, and indication of which data links are currently 1185 allocated to user traffic. When a node receives the LinkSummary 1186 message, it checks its local configuration. If the node is capable 1187 of retaining the LMP link information across a restart, it must 1188 process the LinkSummary message as described in Section 4 with the 1189 exception that the allocated/de-allocated flag of the DATA_LINK 1190 object received in the LinkSummary message MUST take precedence over 1191 any local value. If, however, the node was not capable of retaining 1192 the LMP link information across a restart, the node MUST accept the 1193 data link parameters of the received LinkSummary message and respond 1194 with a LinkSummaryAck message. 1196 Upon completion of the LinkSummary exchange, the node that has 1197 restarted the control plane SHOULD send a ChannelStatusRequest 1198 message for that TE link. The node SHOULD also verify the 1199 connectivity of all unallocated data channels. 1201 9. Addressing 1203 All LMP messages are run over UDP with an LMP port number (except, 1204 in some cases, the Test messages which may be limited by the 1205 transport mechanism for in-band messaging). The destination address 1206 of the IP packet MAY be either the address learned in the 1207 Configuration procedure (i.e., the Source IP address found in the IP 1208 header of the received Config message), an IP address configured on 1209 the remote node, or the Node_Id. The Config message is an exception 1210 as described below. 1212 The manner in which a Config message is addressed may depend on the 1213 signaling transport mechanism. When the transport mechanism is a 1214 point-to-point link, Config messages SHOULD be sent to the Multicast 1215 address (224.0.0.1 or ff02::1). Otherwise, Config messages MUST be 1216 sent to an IP address on the neighboring node. This may be 1217 configured at both ends of the control channel or may be 1218 automatically discovered. 1220 10. Exponential Back-off Procedures 1222 This section is based on [RFC2961] and provides exponential back-off 1223 procedures for message retransmission. Implementations MUST use the 1224 described procedures or their equivalent. 1226 10.1. Operation 1228 The following operation is one possible mechanism for exponential 1229 back-off retransmission of unacknowledged LMP messages. The sending 1230 node retransmits the message until an acknowledgement message is 1231 received or until a retry limit is reached. When the sending node 1232 receives the acknowledgement, retransmission of the message is 1233 stopped. The interval between message retransmission is governed by 1234 a rapid retransmission timer. The rapid retransmission timer starts 1235 at a small interval and increases exponentially until it reaches a 1236 threshold. 1238 The following time parameters are useful to characterize the 1239 procedures: 1241 Rapid retransmission interval Ri: 1243 Ri is the initial retransmission interval for unacknowledged 1244 messages. After sending the message for the first time, the 1245 sending node will schedule a retransmission after Ri 1246 milliseconds. 1248 Rapid retry limit Rl: 1250 Rl is the maximum number of times a message will be transmitted 1251 without being acknowledged. 1253 Increment value Delta: 1255 Delta governs the speed with which the sender increases the 1256 retransmission interval. The ratio of two successive 1257 retransmission intervals is (1 + Delta). 1259 Suggested default values for an initial retransmission interval (Ri) 1260 of 500ms, a power of 2 exponential back-off (Delta = 1) and a retry 1261 limit of 3. 1263 10.2. Retransmission Algorithm 1265 After a node transmits a message requiring acknowledgement, it 1266 should immediately schedule a retransmission after Ri seconds. If a 1267 corresponding acknowledgement message is received before Ri seconds, 1268 then message retransmission SHOULD be canceled. Otherwise, it will 1269 retransmit the message after (1+Delta)*Ri seconds. The 1270 retransmission will continue until either an appropriate 1271 acknowledgement message is received or the rapid retry limit, Rl, 1272 has been reached. 1274 A sending node can use the following algorithm when transmitting a 1275 message that requires acknowledgement: 1277 Prior to initial transmission, initialize Rk = Ri and Rn = 0. 1279 while (Rn++ < Rl) { 1280 transmit the message; 1281 wake up after Rk milliseconds; 1282 Rk = Rk * (1 + Delta); 1283 } 1284 /* acknowledged message or no reply from receiver and Rl 1285 reached*/ 1286 do any needed clean up; 1287 exit; 1289 Asynchronously, when a sending node receives a corresponding 1290 acknowledgment message, it will change the retry count, Rn, to Rl. 1292 Note that the transmitting node does not advertise or negotiate the 1293 use of the described exponential back-off procedures in the Config 1294 or LinkSummary messages. 1296 11. LMP Finite State Machines 1298 11.1. Control Channel FSM 1300 The control channel FSM defines the states and logics of operation 1301 of an LMP control channel. 1303 11.1.1. 1304 Control Channel States 1306 A control channel can be in one of the states described below. 1307 Every state corresponds to a certain condition of the control 1308 channel and is usually associated with a specific type of LMP 1309 message that is periodically transmitted to the far end. 1311 Down: This is the initial control channel state. In this 1312 state, no attempt is being made to bring the control 1313 channel up and no LMP messages are sent. The control 1314 channel parameters should be set to the initial values. 1316 ConfSnd: The control channel is in the parameter negotiation 1317 state. In this state the node periodically sends a 1318 Config message, and is expecting the other side to 1319 reply with either a ConfigAck or ConfigNack message. 1320 The FSM does not transition into the Active state until 1321 the remote side positively acknowledges the parameters. 1323 ConfRcv: The control channel is in the parameter negotiation 1324 state. In this state, the node is waiting for 1325 acceptable configuration parameters from the remote 1326 side. Once such parameters are received and 1327 acknowledged, the FSM can transition to the Active 1328 state. 1330 Active: In this state the node periodically sends a Hello 1331 message and is waiting to receive a valid Hello 1332 message. Once a valid Hello message is received, it can 1333 transition to the up state. 1335 Up: The CC is in an operational state. The node receives 1336 valid Hello messages and sends Hello messages. 1338 GoingDown: A CC may go into this state because of administrative 1339 action. While a CC is in this state, the node sets the 1340 ControlChannelDown bit in all the messages it sends. 1342 11.1.2. 1343 Control Channel Events 1345 Operation of the LMP control channel is described in terms of FSM 1346 states and events. Control channel events are generated by the 1347 underlying protocols and software modules, as well as by the packet 1348 processing routines and FSMs of associated TE links. Every event has 1349 its number and a symbolic name. Description of possible control 1350 channel events is given below. 1352 1 : evBringUp: This is an externally triggered event indicating 1353 that the control channel negotiation should begin. 1354 This event, for example, may be triggered by an 1355 operator command, by the successful completion of 1356 a control channel bootstrap procedure, or by 1357 configuration. Depending on the configuration, 1358 this will trigger either 1359 1a) the sending of a Config message, 1360 1b) a period of waiting to receive a Config 1361 message from the remote node. 1363 2 : evCCDn: This event is generated when there is indication 1364 that the control channel is no longer available. 1366 3 : evConfDone: This event indicates a ConfigAck message has been 1367 received, acknowledging the Config parameters. 1369 4 : evConfErr: This event indicates a ConfigNack message has been 1370 received, rejecting the Config parameters. 1372 5 : evNewConfOK: New Config message was received from neighbor and 1373 positively acknowledged. 1375 6 : evNewConfErr: New Config message was received from neighbor and 1376 rejected with a ConfigNack message. 1378 7 : evContenWin: New Config message was received from neighbor at 1379 the same time a Config message was sent to the 1380 neighbor. The local node wins the contention. As 1381 a result, the received Config message is ignored. 1383 8 : evContenLost: New Config message was received from neighbor at 1384 the same time a Config message was sent to the 1385 neighbor. The local node loses the contention. 1386 8a) The Config message is positively 1387 acknowledged. 1388 8b) The Config message is negatively 1389 acknowledged. 1391 9 : evAdminDown: The administrator has requested that the control 1392 channel is brought down administratively. 1394 10: evNbrGoesDn: A packet with ControlChannelDown flag is received 1395 from the neighbor. 1397 11: evHelloRcvd: A Hello packet with expected SeqNum has been 1398 received. 1400 12: evHoldTimer: The HelloDeadInterval timer has expired indicating 1401 that no Hello packet has been received. This moves 1402 the control channel back into the Negotiation 1403 state, and depending on the local configuration, 1404 this will trigger either 1405 12a) the sending of periodic Config messages, 1406 12b) a period of waiting to receive Config 1407 messages from the remote node. 1409 13: evSeqNumErr: A Hello with unexpected SeqNum received and 1410 discarded. 1412 14: evReconfig: Control channel parameters have been reconfigured 1413 and require renegotiation. 1415 15: evConfRet: A retransmission timer has expired and a Config 1416 message is resent. 1418 16: evHelloRet: The HelloInterval timer has expired and a Hello 1419 packet is sent. 1421 17: evDownTimer: A timer has expired and no messages have been 1422 received with the ControlChannelDown flag set. 1424 11.1.3. 1425 Control Channel FSM Description 1427 Figure 3 illustrates operation of the control channel FSM in a form 1428 of FSM state transition diagram. 1430 +--------+ 1431 +----------------->| |<--------------+ 1432 | +--------->| Down |<----------+ | 1433 | |+---------| |<-------+ | | 1434 | || +--------+ | | | 1435 | || | ^ 2,9| 2| 2| 1436 | ||1b 1a| | | | | 1437 | || v |2,9 | | | 1438 | || +--------+ | | | 1439 | || +->| |<------+| | | 1440 | || 4,7,| |ConfSnd | || | | 1441 | || 14,15+--| |<----+ || | | 1442 | || +--------+ | || | | 1443 | || 3,8a| | | || | | 1444 | || +---------+ |8b 14,12a| || | | 1445 | || | v | || | | 1446 | |+-|------>+--------+ | || | | 1447 | | | +->| |-----|-|+ | | 1448 | | |6,14| |ConfRcv | | | | | 1449 | | | +--| |<--+ | | | | 1450 | | | +--------+ | | | | | 1451 | | | 5| ^ | | | | | 1452 | | +---------+ | | | | | | | 1453 | | | | | | | | | | 1454 | | v v |6,12b | | | | | 1455 | |10 +--------+ | | | | | 1456 | +----------| | | | | | | 1457 | | +--| Active |---|-+ | | | 1458 10,17| | 5,16| | |-------|---+ | 1459 +-------+ 9 | 13 +->| | | | | 1460 | Going |<--|----------+--------+ | | | 1461 | Down | | 11| ^ | | | 1462 +-------+ | | |5 | | | 1463 ^ | v | 6,12b| | | 1464 |9 |10 +--------+ | |12a,14 | 1465 | +----------| |---+ | | 1466 | | Up |-------+ | 1467 +------------------| |---------------+ 1468 +--------+ 1469 | ^ 1470 | | 1471 +---+ 1472 11,13,16 1474 Figure 3: Control Channel FSM 1476 Event evCCDn always forces the FSM to the down state. Events 1477 evHoldTimer evReconfig always force the FSM to the Negotiation state 1478 (either ConfSnd or ConfRcv). 1480 11.2. TE Link FSM 1482 The TE Link FSM defines the states and logics of operation of the 1483 LMP TE Link. 1485 11.2.1. 1486 TE Link States 1488 An LMP TE link can be in one of the states described below. Every 1489 state corresponds to a certain condition of the TE link and is 1490 usually associated with a specific type of LMP message that is 1491 periodically transmitted to the far end via the associated control 1492 channel or in-band via the data links. 1494 Down: There are no data links allocated to the TE link. 1496 Init: Data links have been allocated to the TE link, but the 1497 configuration has not yet been synchronized with the LMP 1498 neighbor. The LinkSummary message is periodically 1499 transmitted to the LMP neighbor. 1501 Up: This is the normal operational state of the TE link. At 1502 least one LMP control channel is required to be 1503 operational between the nodes sharing the TE link. As 1504 part of normal operation, the LinkSummary message may be 1505 periodically transmitted to the LMP neighbor or 1506 generated by an external request. 1508 Degraded: In this state, all LMP control channels are down, but 1509 the TE link still includes some data links that are 1510 allocated to user traffic. 1512 11.2.2. 1513 TE Link Events 1515 Operation of the LMP TE link is described in terms of FSM states and 1516 events. TE Link events are generated by the packet processing 1517 routines and by the FSMs of the associated control channel(s) and 1518 the data links. Every event has its number and a symbolic name. 1519 Description of possible events is given below. 1521 1 : evDCUp: One or more data channels have been enabled and 1522 assigned to the TE Link. 1524 2 : evSumAck: LinkSummary message received and positively 1525 acknowledged. 1527 3 : evSumNack: LinkSummary message received and negatively 1528 acknowledged. 1530 4 : evRcvAck: LinkSummaryAck message received acknowledging 1531 the TE Link Configuration. 1533 5 : evRcvNack: LinkSummaryNack message received. 1535 6 : evSumRet: Retransmission timer has expired and LinkSummary 1536 message is resent. 1538 7 : evCCUp: First active control channel goes up. 1540 8 : evCCDown: Last active control channel goes down. 1542 9 : evDCDown: Last data channel of TE Link has been removed. 1544 11.2.3. 1545 TE Link FSM Description 1547 Figure 4 illustrates operation of the LMP TE Link FSM in a form of 1548 FSM state transition diagram. 1550 3,7,8 1551 +--+ 1552 | | 1553 | v 1554 +--------+ 1555 | | 1556 +------------>| Down |<---------+ 1557 | | | | 1558 | +--------+ | 1559 | | ^ | 1560 | 1| |9 | 1561 | v | | 1562 | +--------+ | 1563 | | |<-+ | 1564 | | Init | |3,5,6 |9 1565 | | |--+ 7,8 | 1566 9| +--------+ | 1567 | | | 1568 | 2,4| | 1569 | v | 1571 +--------+ 7 +--------+ | 1572 | |------>| |----------+ 1573 | Deg | | Up | 1574 | |<------| | 1575 +--------+ 8 +--------+ 1576 | ^ 1577 | | 1578 +--+ 1579 2,3,4,5,6 1581 Figure 4: LMP TE Link FSM 1583 In the above FSM, the sub-states that may be implemented when the 1584 link verification procedure is used have been omitted. 1586 11.3. Data Link FSM 1588 The data link FSM defines the states and logics of operation of a 1589 data link within an LMP TE link. Operation of a data link is 1590 described in terms of FSM states and events. Data links can either 1591 be in the active (transmitting) mode, where Test messages are 1592 transmitted from them, or the passive (receiving) mode, where Test 1593 messages are received through them. For clarity, separate FSMs are 1594 defined for the active/passive data links; however, a single set of 1595 data link states and events are defined. 1597 11.3.1. 1598 Data Link States 1600 Any data link can be in one of the states described below. Every 1601 state corresponds to a certain condition of the data link. 1603 Down: The data link has not been put in the resource pool 1604 (i.e., the link is not 'in service') 1606 Test: The data link is being tested. An LMP Test message is 1607 periodically sent through the link. 1609 PasvTest: The data link is being checked for incoming test 1610 messages. 1612 Up/Free: The link has been successfully tested and is now put 1613 in the pool of resources (in-service). The link has 1614 not yet been allocated to data traffic. 1616 Up/Alloc: The link is up and has been allocated for data 1617 traffic. 1619 11.3.2. 1620 Data Link Events 1622 Data link events are generated by the packet processing routines and 1623 by the FSMs of the associated control channel and the TE link. 1625 Every event has its number and a symbolic name. Description of 1626 possible data link events is given below: 1628 1 :evCCUp: First active control channel goes up. 1630 2 :evCCDown: LMP neighbor connectivity is lost. This indicates 1631 the last LMP control channel has failed between 1632 neighboring nodes. 1634 3 :evStartTst: This is an external event that triggers the sending 1635 of Test messages over the data link. 1637 4 :evStartPsv: This is an external event that triggers the 1638 listening for Test messages over the data link. 1640 5 :evTestOK: Link verification was successful and the link can 1641 be used for path establishment. 1642 (a) This event indicates the Link Verification 1643 procedure (see Section 5) was successful 1644 for this data link and a TestStatusSuccess 1645 message was received over the control 1646 channel. 1647 (b) This event indicates the link is ready for 1648 path establishment, but the Link 1649 Verification procedure was not used. For 1650 in-band signaling of the control channel, 1651 the control channel establishment may be 1652 sufficient to verify the link. 1654 6 :evTestRcv: Test message was received over the data port and a 1655 TestStatusSuccess message is transmitted over the 1656 control channel. 1658 7 :evTestFail: Link verification returned negative results. This 1659 could be because (a) a TestStatusFailure message 1660 was received, or (b) the Verification procedure has 1661 ended without receiving a TestStatusSuccess or 1662 TestStatusFailure message for the data link. 1664 8 :evPsvTestFail:Link verification returned negative results. This 1665 indicates that a Test message was not detected and 1666 either (a) the VerifyDeadInterval has expired or 1667 (b) the Verification procedure has ended and the 1668 VerifyDeadInterval has not yet expired. 1670 9 :evLnkAlloc: The data link has been allocated. 1672 10:evLnkDealloc: The data link has been de-allocated. 1674 11:evTestRet: A retransmission timer has expired and the Test 1675 message is resent. 1677 12:evSummaryFail: The LinkSummary did not match for this data port. 1679 13:evLocalizeFail: A Failure has been localized to this data link. 1681 14:evdcDown: The data channel is no longer available. 1683 11.3.3. 1684 Active Data Link FSM Description 1686 Figure 5 illustrates operation of the LMP active data link FSM in a 1687 form of FSM state transition diagram. 1689 +------+ 1690 | |<-------+ 1691 +--------->| Down | | 1692 | +----| |<-----+ | 1693 | | +------+ | | 1694 | |5b 3| ^ | | 1695 | | | |7 | | 1696 | | v | | | 1697 | | +------+ | | 1698 | | | |<-+ | | 1699 | | | Test | |11 | | 1700 | | | |--+ | | 1701 | | +------+ | | 1702 | | 5a| 3^ | | 1703 | | | | | | 1704 | | v | | | 1705 |12 | +---------+ | | 1706 | +-->| |14 | | 1707 | | Up/Free |----+ | 1708 +---------| | | 1709 +---------+ | 1710 9| ^ | 1711 | | | 1712 v |10 | 1713 +---------+ | 1714 | |13 | 1715 |Up/Alloc |------+ 1716 | | 1717 +---------+ 1719 Figure 5: Active LMP Data Link FSM 1721 11.3.4. 1722 Passive Data Link FSM Description 1724 Figure 6 illustrates operation of the LMP passive data link FSM in a 1725 form of FSM state transition diagram. 1727 +------+ 1728 | |<------+ 1729 +---------->| Down | | 1730 | +-----| |<----+ | 1731 | | +------+ | | 1732 | |5b 4| ^ | | 1733 | | | |8 | | 1734 | | v | | | 1735 | | +----------+ | | 1736 | | | PasvTest | | | 1737 | | +----------+ | | 1738 | | 6| 4^ | | 1739 | | | | | | 1740 | | v | | | 1741 |12 | +---------+ | | 1742 | +--->| Up/Free |14 | | 1743 | | |---+ | 1744 +----------| | | 1745 +---------+ | 1746 9| ^ | 1747 | | | 1748 v |10 | 1749 +---------+ | 1750 | |13 | 1751 |Up/Alloc |-----+ 1752 | | 1753 +---------+ 1755 Figure 6: Passive LMP Data Link FSM 1757 12. LMP Message Formats 1759 All LMP messages (except, in some cases, the Test messages which, 1760 are limited by the transport mechanism for in-band messaging) are 1761 run over UDP with an LMP port number to be assigned by IANA. 1763 12.1. Common Header 1765 In addition to the UDP header and standard IP header, all LMP 1766 messages (except, in some cases, the Test messages which may be 1767 limited by the transport mechanism for in-band messaging) have the 1768 following common header: 1770 0 1 2 3 1771 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 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 | Vers | (Reserved) | Flags | Msg Type | 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | LMP Length | (Reserved) | 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 The Reserved field should be sent as zero and ignored on receipt. 1779 All values are defined in network byte order (i.e., big-endian byte 1780 order). 1782 Vers: 4 bits 1784 Protocol version number. This is version 1. 1786 Flags: 8 bits 1788 The following bit-values are defined. All other bits are 1789 reserved and should be sent as zero and ignored on receipt. 1791 0x01: ControlChannelDown 1793 0x02: LMP Restart 1795 This bit is set to indicate that a nodal failure has 1796 occured and the LMP control state has been lost. This 1797 flag may be reset to 0 when a Hello message is received 1798 with RcvSeqNum equal to the local TxSeqNum. 1800 Msg Type: 8 bits 1802 The following values are defined. All other values are reserved 1804 1 = Config 1806 2 = ConfigAck 1808 3 = ConfigNack 1810 4 = Hello 1812 5 = BeginVerify 1814 6 = BeginVerifyAck 1816 7 = BeginVerifyNack 1818 8 = EndVerify 1820 9 = EndVerifyAck 1822 10 = Test 1824 11 = TestStatusSuccess 1826 12 = TestStatusFailure 1827 13 = TestStatusAck 1829 14 = LinkSummary 1831 15 = LinkSummaryAck 1833 16 = LinkSummaryNack 1835 17 = ChannelStatus 1837 18 = ChannelStatusAck 1839 19 = ChannelStatusRequest 1841 20 = ChannelStatusResponse 1843 All of the messages are sent over the control channel EXCEPT 1844 the Test message, which is sent over the data link that is 1845 being tested. 1847 LMP Length: 16 bits 1849 The total length of this LMP message in bytes, including the 1850 common header and any variable-length objects that follow. 1852 12.2. LMP Object Format 1854 LMP messages are built using objects. Each object is identified by 1855 its Object Class and Class-type. Each object has a name, which is 1856 always capitalized in this document. LMP objects can be either 1857 negotiable or non-negotiable (identified by the N bit in the object 1858 header). Negotiable objects can be used to let the devices agree on 1859 certain values. Non-negotiable objects are used for announcement of 1860 specific values that do not need or do not allow negotiation. 1862 All values are defined in network byte order (i.e., big-endian byte 1863 order). 1865 The format of the LMP object is as follows: 1867 0 1 2 3 1868 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 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 |N| C-Type | Class | Length | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | | 1873 // (object contents) // 1874 | | 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 N: 1 bit 1878 The N flag indicates if the object is negotiable (N=1) or non- 1879 negotiable (N=0). 1881 C-Type: 7 bits 1883 Class-type, unique within an Object Class. Values are defined 1884 in Section 13. 1886 Class: 8 bits 1888 The Class indicates the object type. Each object has a name, 1889 which is always capitalized in this document. 1891 Length: 16 bits 1893 The Length field indicates the length of the object in bytes, 1894 including the N, C-Type, Class, and Length fields. 1896 12.3. Parameter Negotiation Messages 1898 12.3.1. 1899 Config Message (Msg Type = 1) 1901 The Config message is used in the control channel negotiation phase 1902 of LMP. The contents of the Config message are built using LMP 1903 objects. The format of the Config message is as follows: 1905 ::= 1906 1908 The above transmission order SHOULD be followed. 1910 The MESSAGE_ID object is within the scope of the LOCAL_CCID object. 1912 The Config message MUST be periodically transmitted until (1) it 1913 receives a ConfigAck or ConfigNack message, (2) a retry limit has 1914 been reached and no ConfigAck or ConfigNack message has been 1915 received, or (3) it receives a Config message from the remote node 1916 and has lost the contention (e.g., the Node_Id of the remote node is 1917 higher than the Node_Id of the local node). Both the retransmission 1918 interval and the retry limit are local configuration parameters. 1920 12.3.2. 1921 ConfigAck Message (Msg Type = 2) 1923 The ConfigAck message is used to acknowledge receipt of the Config 1924 message and indicate agreement on all parameters. 1926 ::= 1927 1928 1930 The above transmission order SHOULD be followed. 1932 The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID 1933 objects MUST be obtained from the Config message being acknowledged. 1935 12.3.3. 1936 ConfigNack Message (Msg Type = 3) 1938 The ConfigNack message is used to acknowledge receipt of the Config 1939 message and indicate disagreement on non-negotiable parameters or 1940 propose other values for negotiable parameters. Parameters where 1941 agreement was reached MUST NOT be included in the ConfigNack 1942 Message. The format of the ConfigNack message is as follows: 1944 ::= 1945 1946 1948 The above transmission order SHOULD be followed. 1950 The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID 1951 objects MUST be obtained from the Config message being negatively 1952 acknowledged. 1954 It is possible that multiple parameters may be invalid in the Config 1955 message. 1957 If a negotiable CONFIG object is included in the ConfigNack message, 1958 it MUST include acceptable values for the parameters. 1960 If the ConfigNack message includes CONFIG objects for non-negotiable 1961 parameters, they MUST be copied from the CONFIG objects received in 1962 the Config message. 1964 If the ConfigNack message is received and only includes CONFIG 1965 objects that are negotiable, then a new Config message SHOULD be 1966 sent. The values in the CONFIG object of the new Config message 1967 SHOULD take into account the acceptable values included in the 1968 ConfigNack message. 1970 If a node receives a Config message and recognizes the CONFIG object 1971 but does not recognize the C-Type, a ConfigNack message including 1972 the unknown CONFIG object MUST be sent. 1974 12.4. Hello Message (Msg Type = 4) 1976 The format of the Hello message is as follows: 1978 ::= 1980 The above transmission order SHOULD be followed. 1982 The Hello message MUST be periodically transmitted at least once 1983 every HelloInterval msec. If no Hello message is received within the 1984 HelloDeadInterval, the control channel is assumed to have failed. 1986 12.5. Link Verification Messages 1988 12.5.1. 1989 BeginVerify Message (Msg Type = 5) 1991 The BeginVerify message is sent over the control channel and is used 1992 to initiate the link verification process. The format is as follows: 1994 ::= 1995 [] 1996 1998 The above transmission order SHOULD be followed. 2000 To limit the scope of Link Verification to a particular TE Link, the 2001 Link_Id field of the LOCAL_LINK_ID object MUST be non-zero. If this 2002 field is zero, the data links can span multiple TE links and/or they 2003 may comprise a TE link that is yet to be configured. In the special 2004 case where the local Link_Id field is zero, the "Verify all Links" 2005 flag of the BEGIN_VERIFY object is used to distinguish between data 2006 links that span multiple TE links and those that have not yet been 2007 assigned to a TE link (see Section 5). 2009 The REMOTE_LINK_ID object may be included if the local/remote 2010 Link_Id mapping is known. 2012 The Link_Id field of the REMOTE_LINK_ID object MUST be non-zero if 2013 included. 2015 The BeginVerify message MUST be periodically transmitted until (1) 2016 the node receives either a BeginVerifyAck or BeginVerifyNack message 2017 to accept or reject the verify process or (2) a retry limit has been 2018 reached and no BeginVerifyAck or BeginVerifyNack message has been 2019 received. Both the retransmission interval and the retry limit are 2020 local configuration parameters. 2022 12.5.2. 2023 BeginVerifyAck Message (Msg Type = 6) 2025 When a BeginVerify message is received and Test messages are ready 2026 to be processed, a BeginVerifyAck message MUST be transmitted. 2028 ::= [] 2029 2030 2032 The above transmission order SHOULD be followed. 2034 The LOCAL_LINK_ID object may be included if the local/remote Link_Id 2035 mapping is known or learned through the BeginVerify message. 2037 The Link_Id field of the LOCAL_LINK_ID MUST be non-zero if included. 2039 The contents of the MESSAGE_ID_ACK object MUST be obtained from the 2040 BeginVerify message being acknowledged. 2042 The VERIFY_ID object contains a node-unique value that is assigned 2043 by the generator of the BeginVerifyAck message. This value is used 2044 to uniquely identify the Verification process from multiple LMP 2045 neighbors and/or parallel Test procedures between the same LMP 2046 neighbors. 2048 12.5.3. 2049 BeginVerifyNack Message (Msg Type = 7) 2051 If a BeginVerify message is received and a node is unwilling or 2052 unable to begin the Verification procedure, a BeginVerifyNack 2053 message MUST be transmitted. 2055 ::= [] 2056 2058 The above transmission order SHOULD be followed. 2060 The contents of the MESSAGE_ID_ACK object MUST be obtained from the 2061 BeginVerify message being negatively acknowledged. 2063 If the Verification process is not supported, the ERROR_CODE MUST 2064 indicate "Link Verification Procedure not supported". 2066 If Verification is supported, but the node is unable to begin the 2067 procedure, the ERROR_CODE MUST indicate "Unwilling to verify". If a 2068 BeginVerifyNack message is received with such an ERROR_CODE, the 2069 node that originated the BeginVerify SHOULD schedule a BeginVerify 2070 retransmission after Rf seconds, where Rf is a locally defined 2071 parameter. 2073 If the Verification Transport mechanism is not supported, the 2074 ERROR_CODE MUST indicate, "Unsupported verification transport 2075 mechanism". 2077 If remote configuration of the Link_Id is not supported and the 2078 content of the REMOTE_LINK_ID object (included in the BeginVerify 2079 message) does not match any configured values, the ERROR_CODE MUST 2080 indicate "Link_Id configuration error". 2082 If a node receives a BeginVerify message and recognizes the 2083 BEGIN_VERIFY object but does not recognize the C-Type, the 2084 ERROR_CODE MUST indicate, "Unknown object C-Type". 2086 12.5.4. 2087 EndVerify Message (Msg Type = 8) 2089 The EndVerify message is sent over the control channel and is used 2090 to terminate the link verification process. The EndVerify message 2091 may be sent at any time the initiating node desires to end the 2092 Verify procedure. The format is as follows: 2094 ::= 2096 The above transmission order SHOULD be followed. 2098 The EndVerify message will be periodically transmitted until (1) an 2099 EndVerifyAck message has been received or (2) a retry limit has been 2100 reached and no EndVerifyAck message has been received. Both the 2101 retransmission interval and the retry limit are local configuration 2102 parameters. 2104 12.5.5. 2105 EndVerifyAck Message (Msg Type =9) 2107 The EndVerifyAck message is sent over the control channel and is 2108 used to acknowledge the termination of the link verification 2109 process. The format is as follows: 2111 ::= 2112 2114 The above transmission order SHOULD be followed. 2116 The contents of the MESSAGE_ID_ACK object MUST be obtained from the 2117 EndVerify message being acknowledged. 2119 12.5.6. 2120 Test Message (Msg Type = 10) 2122 The Test message is transmitted over the data link and is used to 2123 verify its physical connectivity. Unless explicitly stated, these 2124 messages MUST be transmitted over UDP like all other LMP messages. 2125 The format of the Test messages is as follows: 2127 ::= 2129 The above transmission order SHOULD be followed. 2131 Note that this message is sent over a data link and NOT over the 2132 control channel. The transport mechanism for the Test message is 2133 negotiated using Verify Transport Mechanism field of the 2134 BEGIN_VERIFY object and the Verify Transport Response field of the 2135 BEGIN_VERIFY_ACK object (see Sections 13.8 and 13.9). 2137 The local (transmitting) node sends a given Test message 2138 periodically (at least once every VerifyInterval ms) on the 2139 corresponding data link until (1) it receives a correlating 2140 TestStatusSuccess or TestStatusFailure message on the control 2141 channel from the remote (receiving) node or (2) all active control 2142 channels between the two nodes have failed. The remote node will 2143 send a given TestStatus message periodically over the control 2144 channel until it receives either a correlating TestStatusAck message 2145 or an EndVerify message is received over the control channel. 2147 12.5.7. 2148 TestStatusSuccess Message (Msg Type = 11) 2150 The TestStatusSuccess message is transmitted over the control 2151 channel and is used to transmit the mapping between the local 2152 Interface_Id and the Interface_Id that was received in the Test 2153 message. 2155 ::= 2156 2157 2159 The above transmission order SHOULD be followed. 2161 The contents of the REMOTE_INTERFACE_ID object MUST be obtained from 2162 the corresponding Test message being positively acknowledged. 2164 12.5.8. 2165 TestStatusFailure Message (Msg Type = 12) 2167 The TestStatusFailure message is transmitted over the control 2168 channel and is used to indicate that the Test message was not 2169 received. 2171 ::= 2172 2174 The above transmission order SHOULD be followed. 2176 12.5.9. 2177 TestStatusAck Message (Msg Type = 13) 2179 The TestStatusAck message is used to acknowledge receipt of the 2180 TestStatusSuccess or TestStatusFailure messages. 2182 ::= 2183 2185 The above transmission order SHOULD be followed. 2187 The contents of the MESSAGE_ID_ACK object MUST be obtained from the 2188 TestStatusSuccess or TestStatusFailure message being acknowledged. 2190 12.6. Link Summary Messages 2192 12.6.1. 2193 LinkSummary Message (Msg Type = 14) 2195 The LinkSummary message is used to synchronize the Interface_Ids and 2196 correlate the properties of the TE link. The format of the 2197 LinkSummary message is as follows: 2199 ::= 2200 [...] 2202 The above transmission order SHOULD be followed. 2204 The LinkSummary message can be exchanged at any time a link is not 2205 in the Verification process. The LinkSummary message MUST be 2206 periodically transmitted until (1) the node receives a 2207 LinkSummaryAck or LinkSummaryNack message or (2) a retry limit has 2208 been reached and no LinkSummaryAck or LinkSummaryNack message has 2209 been received. Both the retransmission interval and the retry limit 2210 are local configuration parameters. 2212 12.6.2. 2213 LinkSummaryAck Message (Msg Type = 15) 2215 The LinkSummaryAck message is used to indicate agreement on the 2216 Interface_Id synchronization and acceptance/agreement on all the 2217 link parameters. It is on the reception of this message that the 2218 local node makes the Link_Id associations. 2220 ::= 2222 The above transmission order SHOULD be followed. 2224 12.6.3. 2225 LinkSummaryNack Message (Msg Type = 16) 2227 The LinkSummaryNack message is used to indicate disagreement on non- 2228 negotiated parameters or propose other values for negotiable 2229 parameters. Parameters where agreement was reached MUST NOT be 2230 included in the LinkSummaryNack message. 2232 ::= 2233 [...] 2235 The above transmission order SHOULD be followed. 2237 The DATA_LINK objects MUST include acceptable values for all 2238 negotiable parameters. If the LinkSummaryNack includes DATA_LINK 2239 objects for non-negotiable parameters, they MUST be copied from the 2240 DATA_LINK objects received in the LinkSummary message. 2242 If the LinkSummaryNack message is received and only includes 2243 negotiable parameters, then a new LinkSummary message SHOULD be 2244 sent. The values received in the new LinkSummary message SHOULD take 2245 into account the acceptable parameters included in the 2246 LinkSummaryNack message. 2248 If the LinkSummary message is received with unacceptable non- 2249 negotiable parameters, the ERROR_CODE MUST indicate "Unacceptable 2250 non-netotiable LINK_SUMMARY parameters." 2251 If the LinkSummary message is received with unacceptable negotiable 2252 parameters, the ERROR_CODE MUST indicate "Renegotiate LINK_SUMMARY 2253 parameters." 2255 If the LinkSummary message is received with an invalid TE_LINK 2256 object, the ERROR_CODE MUST indicate "Invalid TE_LINK object." 2258 If the LinkSummary message is received with an invalid DATA_LINK 2259 object, the ERROR_CODE MUST indicate "Invalid DATA_LINK object." 2261 If the LinkSummary message is received with a TE_LINK object but the 2262 C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown TE_LINK 2263 object C-Type." 2265 If the LinkSummary message is received with a DATA_LINK object but 2266 the C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown 2267 DATA_LINK object C-Type." 2269 12.7. Fault Management Messages 2271 12.7.1. 2272 ChannelStatus Message (Msg Type = 17) 2274 The ChannelStatus message is sent over the control channel and is 2275 used to notify an LMP neighbor of the status of a data link. A node 2276 that receives a ChannelStatus message MUST respond with a 2277 ChannelStatusAck message. The format is as follows: 2279 ::= 2280 2282 The above transmission order SHOULD be followed. 2284 If the CHANNEL_STATUS object does not include any Interface_Ids, 2285 then this indicates the entire TE Link has failed. 2287 12.7.2. 2288 ChannelStatusAck Message (Msg Type = 18) 2290 The ChannelStatusAck message is used to acknowledge receipt of the 2291 ChannelStatus Message. The format is as follows: 2293 ::= 2295 The above transmission order SHOULD be followed. 2297 The contents of the MESSAGE_ID_ACK object MUST be obtained from the 2298 ChannelStatus message being acknowledged. 2300 12.7.3. 2301 ChannelStatusRequest Message (Msg Type = 19) 2303 The ChannelStatusRequest message is sent over the control channel 2304 and is used to request the status of one or more data link(s). A 2305 node that receives a ChannelStatusRequest message MUST respond with 2306 a ChannelStatusResponse message. The format is as follows: 2308 ::= 2309 2310 [] 2312 The above transmission order SHOULD be followed. 2314 If the CHANNEL_STATUS_REQUEST object is not included, then the 2315 ChannelStatusRequest is being used to request the status of ALL of 2316 the data link(s) of the TE Link. 2318 12.7.4. 2319 ChannelStatusResponse Message (Msg Type = 20) 2321 The ChannelStatusResponse message is used to acknowledge receipt of 2322 the ChannelStatusRequest Message and notify the LMP neighbor of the 2323 status of the data channel(s). The format is as follows: 2325 ::= 2326 2328 The above transmission order SHOULD be followed. 2330 The contents of the MESSAGE_ID_ACK objects MUST be obtained from the 2331 ChannelStatusRequest message being acknowledged. 2333 13. LMP Object Definitions 2335 13.1. CCID (Control Channel ID) Class 2337 Class = 1 2339 o C-Type = 1, LOCAL_CCID 2341 0 1 2 3 2342 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 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | CC_Id | 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 CC_Id: 32 bits 2349 This MUST be node-wide unique and non-zero. The CC_Id 2350 identifies the control channel of the sender associated with 2351 the message. 2353 This object is non-negotiable. 2355 o C-Type = 2, REMOTE_CCID 2357 0 1 2 3 2358 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 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 | CC_Id | 2361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 CC_Id: 32 bits 2365 This identifies the remote node's CC_Id and MUST be non-zero. 2367 This object is non-negotiable. 2369 13.2. NODE_ID Class 2371 Class = 2 2373 o C-Type = 1, LOCAL_NODE_ID 2375 0 1 2 3 2376 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 2377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2378 | Node_Id (4 bytes) | 2379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 Node_Id: 2383 This identities the node that originated the LMP packet. 2385 This object is non-negotiable. 2387 o C-Type = 2, REMOTE_NODE_ID 2389 0 1 2 3 2390 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 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | Node_Id (4 bytes) | 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 Node_Id: 2397 This identities the remote node. 2399 This object is non-negotiable. 2401 13.3. LINK_ID Class 2403 Class = 3 2405 o C-Type = 1, IPv4 LOCAL_LINK_ID 2407 o C-Type = 2, IPv4 REMOTE_LINK_ID 2409 0 1 2 3 2410 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 2411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2412 | Link_Id (4 bytes) | 2413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2415 o C-Type = 3, IPv6 LOCAL_LINK_ID 2417 o C-Type = 4, IPv6 REMOTE_LINK_ID 2419 0 1 2 3 2420 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 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 | | 2423 + + 2424 | | 2425 + Link_Id (16 bytes) + 2426 | | 2427 + + 2428 | | 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 o C-Type = 5, Unnumbered LOCAL_LINK_ID 2433 o C-Type = 6, Unnumbered REMOTE_LINK_ID 2435 0 1 2 3 2436 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 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | Link_Id (4 bytes) | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 Link_Id: 2443 For LOCAL_LINK_ID, this identifies the sender's Link associated 2444 with the message. This value MUST be non-zero. 2446 For REMOTE_LINK_ID, this identifies the remote node's Link_Id 2447 and MUST be non-zero. 2449 This object is non-negotiable. 2451 13.4. INTERFACE_ID Class 2453 Class = 4 2455 o C-Type = 1, IPv4 LOCAL_INTERFACE_ID 2457 o C-Type = 2, IPv4 REMOTE_INTERFACE_ID 2459 0 1 2 3 2460 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 2462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2463 | Interface_Id (4 bytes) | 2464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2466 o C-Type = 3, IPv6 LOCAL_INTERFACE_ID 2468 o C-Type = 4, IPv6 REMOTE_INTERFACE_ID 2470 0 1 2 3 2471 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 2472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 | | 2474 + + 2475 | | 2476 + Interface_Id (16 bytes) + 2477 | | 2478 + + 2479 | | 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 o C-Type = 5, Unnumbered LOCAL_INTERFACE_ID 2484 o C-Type = 6, Unnumbered REMOTE_INTERFACE_ID 2486 0 1 2 3 2487 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 2488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2489 | Interface_Id (4 bytes) | 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 Interface_Id: 2494 For the LOCAL_INTERFACE_ID, this identifies the data link. 2495 This value MUST be node-wide unique and non-zero. 2497 For the REMOTE_INTERFACE_ID, this identifies the remote node's 2498 data link. The Interface_Id MUST be non-zero. 2500 This object is non-negotiable. 2502 13.5. MESSAGE_ID Class 2504 Class = 5 2506 o C-Type=1, MessageId 2508 0 1 2 3 2509 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 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 | Message_Id | 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2513 Message_Id: 2515 The Message_Id field is used to identify a message. This value 2516 is incremented and only decreases when the value wraps. This is 2517 used for message acknowledgment. 2519 This object is non-negotiable. 2521 o C-Type = 2, MessageIdAck 2523 0 1 2 3 2524 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 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 | Message_Id | 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2529 Message_Id: 2531 The Message_Id field is used to identify the message being 2532 acknowledged. This value is copied from the MESSAGE_ID object 2533 of the message being acknowledged. 2535 This object is non-negotiable. 2537 13.6. CONFIG Class 2539 Class = 6. 2541 o C-Type = 1, HelloConfig 2543 0 1 2 3 2544 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 2545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2546 | HelloInterval | HelloDeadInterval | 2547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 HelloInterval: 16 bits. 2551 Indicates how frequently the Hello packets will be sent and is 2552 measured in milliseconds (ms). 2554 HelloDeadInterval: 16 bits. 2556 If no Hello packets are received within the HelloDeadInterval, 2557 the control channel is assumed to have failed. The 2558 HelloDeadInterval is measured in milliseconds (ms). The 2559 HelloDeadInterval MUST be greater than the HelloInterval, and 2560 SHOULD be at least 3 times the value of HelloInterval. 2562 If the fast keep-alive mechanism of LMP is not used, the 2563 HelloInterval and HelloDeadInterval MUST be set to zero. 2565 13.7. HELLO Class 2567 Class = 7 2569 o C-Type = 1, Hello 2571 0 1 2 3 2572 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 2573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2574 | TxSeqNum | 2575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2576 | RcvSeqNum | 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2579 TxSeqNum: 32 bits 2581 This is the current sequence number for this Hello message. 2582 This sequence number will be incremented when the sequence 2583 number is reflected in the RcvSeqNum of a Hello packet that is 2584 received over the control channel. 2586 TxSeqNum=0 is not allowed. 2587 TxSeqNum=1 is used to indicate that this is the first Hello 2588 message sent over the control channel. 2590 RcvSeqNum: 32 bits 2592 This is the sequence number of the last Hello message received 2593 over the control channel. RcvSeqNum=0 is used to indicate that 2594 a Hello message has not yet been received. 2596 This object is non-negotiable. 2598 13.8. BEGIN_VERIFY Class 2600 Class = 8 2602 o C-Type = 1 2604 0 1 2 3 2605 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 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2607 | Flags | VerifyInterval | 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2609 | Number of Data Links | 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 | EncType | (Reserved) | Verify Transport Mechanism | 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2613 | TransmissionRate | 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 | Wavelength | 2616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2617 The Reserved field should be sent as zero and ignored on receipt. 2619 Flags: 16 bits 2621 The following flags are defined: 2623 0x0001 Verify all Links 2625 If this bit is set, the verification process checks all 2626 unallocated links; else it only verifies new ports or 2627 component links that are to be added to this TE link. 2629 0x0002 Data Link Type 2631 If set, the data links to be verified are ports, 2632 otherwise they are component links 2634 VerifyInterval: 16 bits 2636 This is the interval between successive Test messages and is 2637 measured in milliseconds (ms). 2639 Number of Data Links: 32 bits 2641 This is the number of data links that will be verified. 2643 EncType: 8 bits 2645 This is the encoding type of the data link. The defined EncType 2646 values are consistent with the LSP Encoding Type values of 2647 [RFC3471]. 2649 Verify Transport Mechanism: 16 bits 2651 This defines the transport mechanism for the Test Messages. 2652 The scope of this bit mask is restricted to each encoding type. 2653 The local node will set the bits corresponding to the various 2654 mechanisms it can support for transmitting LMP test messages. 2655 The receiver chooses the appropriate mechanism in the 2656 BeginVerifyAck message. 2658 The following flag is defined across all Encoding Types. All 2659 other flags are dependent on the Encoding Type. 2661 0x8000 Payload:Test Message transmitted in the payload 2663 Capable of transmitting Test messages in the payload. 2664 The Test message is sent as an IP packet as defined 2665 above. 2667 TransmissionRate: 32 bits 2668 This is the transmission rate of the data link over which the 2669 Test messages will be transmitted. This is expressed in bytes 2670 per second and represented in IEEE floating-point format. 2672 Wavelength: 32 bits 2674 When a data link is assigned to a port or component link that 2675 is capable of transmitting multiple wavelengths (e.g., a fiber 2676 or waveband-capable port), it is essential to know which 2677 wavelength the test messages will be transmitted over. This 2678 value corresponds to the wavelength at which the Test messages 2679 will be transmitted over and has local significance. If there 2680 is no ambiguity as to the wavelength over which the message 2681 will be sent, then this value SHOULD be set to 0. 2683 13.9. BEGIN_VERIFY_ACK Class 2685 Class = 9 2687 o C-Type = 1 2689 0 1 2 3 2690 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 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 | VerifyDeadInterval | Verify_Transport_Response | 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 VerifyDeadInterval: 16 bits 2697 If a Test message is not detected within the 2698 VerifyDeadInterval, then a node will send the TestStatusFailure 2699 message for that data link. 2701 Verify_Transport_Response: 16 bits 2703 The recipient of the BeginVerify message (and the future 2704 recipient of the TEST messages) chooses the transport mechanism 2705 from the various types that are offered by the transmitter of 2706 the Test messages. One and only one bit MUST be set in the 2707 verification transport response. 2709 This object is non-negotiable. 2711 13.10. VERIFY_ID Class 2713 Class = 10 2715 o C-Type = 1 2717 0 1 2 3 2718 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 2720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2721 | Verify_Id | 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 Verify_Id: 32 bits 2726 This is used to differentiate Test messages from different TE 2727 links and/or LMP peers. This is a node-unique value that is 2728 assigned by the recipient of the BeginVerify message. 2730 This object is non-negotiable. 2732 13.11. TE_LINK Class 2734 Class = 11 2736 o C-Type = 1, IPv4 TE_LINK 2738 0 1 2 3 2739 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 2740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2741 | Flags | (Reserved) | 2742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2743 | Local_Link_Id (4 bytes) | 2744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2745 | Remote_Link_Id (4 bytes) | 2746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2748 o C-Type = 2, IPv6 TE_LINK 2750 0 1 2 3 2751 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 2752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2753 | Flags | (Reserved) | 2754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2755 | | 2756 + + 2757 | | 2758 + Local_Link_Id (16 bytes) + 2759 | | 2760 + + 2761 | | 2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 | | 2764 + + 2765 | | 2766 + Remote_Link_Id (16 bytes) + 2767 | | 2768 + + 2769 | | 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 o C-Type = 3, Unnumbered TE_LINK 2773 0 1 2 3 2774 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 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2776 | Flags | (Reserved) | 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 | Local_Link_Id (4 bytes) | 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2780 | Remote_Link_Id (4 bytes) | 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 The Reserved field should be sent as zero and ignored on receipt. 2785 Flags: 8 bits 2787 The following flags are defined. All other bit-values are 2788 reserved and should be sent as zero and ignored on receipt. 2790 0x01 Fault Management Supported. 2792 0x02 Link Verification Supported. 2794 Local_Link_Id: 2796 This identifies the node's local Link_Id and MUST be non-zero. 2798 Remote_Link_Id: 2800 This identifies the remote node's Link_Id and MUST be non-zero. 2802 13.12. DATA_LINK Class 2804 Class = 12 2806 o C-Type = 1, IPv4 DATA_LINK 2808 0 1 2 3 2809 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 2810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2811 | Flags | (Reserved) | 2812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2813 | Local_Interface_Id (4 bytes) | 2814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2815 | Remote_Interface_Id (4 bytes) | 2816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2817 | | 2818 // (Subobjects) // 2819 | | 2820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2822 o C-Type = 2, IPv6 DATA_LINK 2823 0 1 2 3 2824 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 2825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2826 | Flags | (Reserved) | 2827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2828 | | 2829 + + 2830 | | 2831 + Local_Interface_Id (16 bytes) + 2832 | | 2833 + + 2834 | | 2835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2836 | | 2837 + + 2838 | | 2839 + Remote_Interface_Id (16 bytes) + 2840 | | 2841 + + 2842 | | 2843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2844 | | 2845 // (Subobjects) // 2846 | | 2847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2849 o C-Type = 3, Unnumbered DATA_LINK 2851 0 1 2 3 2852 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 2853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2854 | Flags | (Reserved) | 2855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2856 | Local_Interface_Id (4 bytes) | 2857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2858 | Remote_Interface_Id (4 bytes) | 2859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2860 | | 2861 // (Subobjects) // 2862 | | 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2865 The Reserved field should be sent as zero and ignored on receipt. 2867 Flags: 8 bits 2869 The following flags are defined. All other bit-values are 2870 reserved and should be sent as zero and ignored on receipt. 2872 0x01 Interface Type: If set, the data link is a port, 2873 otherwise it is a component link. 2875 0x02 Allocated Link: If set, the data link is currently 2876 allocated for user traffic. If a single 2877 Interface_Id is used for both the 2878 transmit and receive data links, then 2879 this bit only applies to the transmit 2880 interface. 2882 0x04 Failed Link: If set, the data link is failed and not 2883 suitable for user traffic. 2885 Local_Interface_Id: 2887 This is the local identifier of the data link. This MUST be 2888 node-wide unique and non-zero. 2890 Remote_Interface_Id: 2892 This is the remote identifier of the data link. This MUST be 2893 non-zero. 2895 Subobjects 2897 The contents of the DATA_LINK object consist of a series of 2898 variable-length data items called subobjects. The subobjects 2899 are defined in Section 13.12.1 below. 2901 A DATA_LINK object may contain more than one subobject. More than 2902 one subobject of the same Type may appear if multiple capabilities 2903 are supported over the data link. 2905 13.12.1. Data Link Subobjects 2907 The contents of the DATA_LINK object include a series of variable- 2908 length data items called subobjects. Each subobject has the form: 2910 0 1 2911 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+ 2913 | Type | Length | (Subobject contents) | 2914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 2916 Type: 8 bits 2918 The Type indicates the type of contents of the subobject. 2919 Currently defined values are: 2921 Type = 1, Interface Switching Type 2923 Type = 2, Wavelength 2925 Length: 8 bits 2926 The Length contains the total length of the subobject in bytes, 2927 including the Type and Length fields. The Length MUST be at 2928 least 4, and MUST be a multiple of 4. 2930 13.12.1.1. Subobject Type 1: Interface Switching Type 2932 0 1 2 3 2933 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 2934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2935 | Type | Length | Switching Type| EncType | 2936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2937 | Minimum Reservable Bandwidth | 2938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2939 | Maximum Reservable Bandwidth | 2940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2942 Switching Type: 8 bits 2944 This is used to identify the local Interface Switching Type of 2945 the TE link as defined in [RFC3471]. 2947 EncType: 8 bits 2949 This is the encoding type of the data link. The defined EncType 2950 values are consistent with the LSP Encoding Type values of 2951 [RFC3471]. 2953 Minimum Reservable Bandwidth: 32 bits 2955 This is measured in bytes per second and represented in IEEE 2956 floating point format. 2958 Maximum Reservable Bandwidth: 32 bits 2960 This is measured in bytes per second and represented in IEEE 2961 floating point format. 2963 If the interface only supports a fixed rate, the minimum and maximum 2964 bandwidth fields are set to the same value. 2966 13.12.1.2. Subobject Type 2: Wavelength 2968 0 1 2 3 2969 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 2970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2971 | Type | Length | (Reserved) | 2972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2973 | Wavelength | 2974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2976 The Reserved field should be sent as zero and ignored on receipt. 2978 Wavelength: 32 bits 2980 This value indicates the wavelength carried over the port. 2981 Values used in this field only have significance between two 2982 neighbors. 2984 13.13. CHANNEL_STATUS Class 2986 Class = 13 2988 o C-Type = 1, IPv4 INTERFACE_ID 2990 0 1 2 3 2991 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 2992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2993 | Interface_Id (4 bytes) | 2994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2995 |A|D| Channel Status | 2996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2997 | : | 2998 // : // 2999 | : | 3000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3001 | Interface_Id (4 bytes) | 3002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3003 |A|D| Channel Status | 3004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3006 o C-Type = 2, IPv6 INTERFACE_ID 3008 0 1 2 3 3009 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 3010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3011 | | 3012 + + 3013 | | 3014 + Interface_Id (16 bytes) + 3015 | | 3016 + + 3017 | | 3018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3019 |A|D| Channel Status | 3020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3021 | : | 3022 // : // 3023 | : | 3024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3025 | | 3026 + + 3027 | | 3028 + Interface_Id (16 bytes) + 3029 | | 3030 + + 3031 | | 3032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3033 |A|D| Channel Status | 3034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3036 o C-Type = 3, Unnumbered INTERFACE_ID 3038 0 1 2 3 3039 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 3040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3041 | Interface_Id (4 bytes) | 3042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3043 |A|D| Channel Status | 3044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3045 | : | 3046 // : // 3047 | : | 3048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3049 | Interface_Id (4 bytes) | 3050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3051 |A|D| Channel_Status | 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3054 Active bit: 1 bit 3056 This indicates that the Channel is allocated to user traffic 3057 and the data link should be actively monitored. 3059 Direction bit: 1 bit 3061 This indicates the direction (transmit/receive) of the data 3062 channel referred to in the CHANNEL_STATUS object. If set, this 3063 indicates the data channel is in the transmit direction. 3065 Channel_Status: 30 bits 3067 This indicates the status condition of a data channel. The 3068 following values are defined. All other values are reserved. 3070 1 Signal Okay (OK): Channel is operational 3071 2 Signal Degrade (SD): A soft failure caused by a BER 3072 exceeding a preselected threshold. The specific BER 3073 used to define the threshold is configured. 3074 3 Signal Fail (SF): A hard signal failure including (but not 3075 limited to) loss of signal (LOS), loss of frame 3076 (LOF), or Line AIS. 3078 This object contains one or more Interface_Ids followed by a 3079 Channel_Status field. 3081 To indicate the status of the entire TE Link, there MUST only be one 3082 Interface_Id and it MUST be zero. 3084 This object is non-negotiable. 3086 13.14. CHANNEL_STATUS_REQUEST Class 3088 Class = 14 3090 o C-Type = 1, IPv4 INTERFACE_ID 3092 0 1 2 3 3093 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 3094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3095 | Interface_Id (4 bytes) | 3096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3097 | : | 3098 // : // 3099 | : | 3100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3101 | Interface_Id (4 bytes) | 3102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3104 This object contains one or more Interface_Ids. 3106 The Length of this object is 4 + 4N in bytes, where N is the number 3107 of Interface_Ids. 3109 o C-Type = 2, IPv6 INTERFACE_ID 3111 0 1 2 3 3112 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 3113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3114 | | 3115 + + 3116 | | 3117 + Interface_Id (16 bytes) + 3118 | | 3119 + + 3120 | | 3121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3122 | : | 3123 // : // 3124 | : | 3125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3126 | | 3127 + + 3128 | | 3129 + Interface_Id (16 bytes) + 3130 | | 3131 + + 3132 | | 3133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3135 This object contains one or more Interface_Ids. 3137 The Length of this object is 4 + 16N in bytes, where N is the number 3138 of Interface_Ids. 3140 o C-Type = 3, Unnumbered INTERFACE_ID 3142 0 1 2 3 3143 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 3144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3145 | Interface_Id (4 bytes) | 3146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3147 | : | 3148 // : // 3149 | : | 3150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3151 | Interface_Id (4 bytes) | 3152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3154 This object contains one or more Interface_Ids. 3156 The Length of this object is 4 + 4N in bytes, where N is the number 3157 of Interface_Ids. 3159 This object is non-negotiable. 3161 13.15. ERROR_CODE Class 3163 Class = 20 3165 o C-Type = 1, BEGIN_VERIFY_ERROR 3167 0 1 2 3 3168 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 3169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3170 | ERROR CODE | 3171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3173 The following bit-values are defined in network byte order 3174 (i.e., big-endian byte order): 3176 0x01 = Link Verification Procedure not supported. 3177 0x02 = Unwilling to verify. 3178 0x04 = Unsupported verification transport mechanism. 3179 0x08 = Link_Id configuration error. 3180 0x10 = Unknown object C-Type. 3182 All other bit-values are reserved and should be sent as zero 3183 and ignored on receipt. 3185 Multiple bits may be set to indicate multiple errors. 3187 This object is non-negotiable. 3189 If a BeginVerifyNack message is received with Error Code 2, the node 3190 that originated the BeginVerify SHOULD schedule a BeginVerify 3191 retransmission after Rf seconds, where Rf is a locally defined 3192 parameter. 3194 o C-Type = 2, LINK_SUMMARY_ERROR 3196 0 1 2 3 3197 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 3198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3199 | ERROR CODE | 3200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3202 The following bit-values are defined in network byte order 3203 (i.e., big-endian byte order): 3205 0x01 =Unacceptable non-negotiable LINK_SUMMARY parameters. 3206 0x02 =Renegotiate LINK_SUMMARY parameters. 3207 0x04 =Invalid TE_LINK Object. 3208 0x08 =Invalid DATA_LINK Object. 3209 0x10 =Unknown TE_LINK object C-Type. 3210 0x20 =Unknown DATA_LINK object C-Type. 3212 All other bit-values are reserved and should be sent as zero 3213 and ignored on receipt. 3215 Multiple bits may be set to indicate multiple errors. 3217 This object is non-negotiable. 3219 14. Intellectual Property Considerations 3221 The IETF takes no position regarding the validity or scope of any 3222 intellectual property or other rights that might be claimed to 3223 pertain to the implementation or use of the technology described in 3224 this document or the extent to which any license under such rights 3225 might or might not be available; neither does it represent that it 3226 has made any effort to identify any such rights. Information on the 3227 IETF's procedures with respect to rights in standards-track and 3228 standards-related documentation can be found in BCP-11. Copies of 3229 claims of rights made available for publication and any assurances 3230 of licenses to be made available, or the result of an attempt made 3231 to obtain a general license or permission for the use of such 3232 proprietary rights by implementers or users of this specification 3233 can be obtained from the IETF Secretariat. 3235 The IETF invites any interested party to bring to its attention any 3236 copyrights, patents or patent applications, or other proprietary 3237 rights which may cover technology that may be required to practice 3238 this standard. Please address the information to the IETF Executive 3239 Director. 3241 15. References 3243 15.1. Normative References 3245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3246 Requirement Levels", BCP 14, RFC 2119, March 1997. 3248 [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 3249 MPLS Traffic Engineering," (work in progress). 3251 [GMPLS-RTG] Kompella, K., Rekhter, Y. et al, "Routing Extensions in 3252 Support of Generalized MPLS," (work in progress). 3254 [RFC2961] Berger, L., Gan, D., et al, "RSVP Refresh Overhead 3255 Reduction Extensions," RFC 2961, April 2001. 3257 [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header," RFC 3258 2402, November 1998. 3260 [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security 3261 Payload (ESP)," RFC 2406, November 1998. 3263 [RFC2407] Piper, D., "The Internet IP Security Domain of 3264 Interpretation for ISAKMP," RFC 2407, November 1998 3266 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 3267 (IKE)," RFC 2409, November 1998. 3269 [RFC3471] Ashwood-Smith, P., Banerjee, A., et al, "Generalized 3270 MPLS - Signaling Functional Description," RFC 3473, 3271 January 2003. 3273 15.2. Informative References 3275 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 3276 Extensions to OSPF," (work in progress). 3278 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 3279 Engineering," (work in progress). 3281 [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the 3282 Internet Protocol," RFC 2401, November 1998 3284 [RFC2434] Narten, T. and Alvestrand, H., "Guidelines for Writing 3285 an IANA Considerations Section in RFCs," RFC 2434, 3286 October 1998. 3288 [RFC3209] Awduche, D. O., Berger, L, et al, "Extensions to RSVP 3289 for LSP Tunnels," Internet Draft, RFC 3209, December 3290 2001. 3292 16. Security Considerations 3294 There are number of attacks that an LMP protocol session can 3295 potentially experience. Some examples include: 3297 o an adversary may spoof control packets; 3299 o an adversary may modify the control packets in transit; 3301 o an adversary may replay control packets; 3303 o an adversary may study a number of control packets and try to 3304 break the key using cryptographic tools. If the 3305 hash/encryption algorithm used has known weaknesses than it 3306 becomes easy for the adversary to discover the key using 3307 simple tools. 3309 This section specifies an IPsec-based security mechanism for LMP. 3311 16.1. Security Requirements 3313 The following requirements are applied to the mechanism described in 3314 this section. 3316 o LMP security MUST be able to provide authentication, 3317 integrity, and replay protection. 3319 o For LMP traffic, confidentiality is not needed. Only 3320 authentication is needed to ensure the control packets 3321 (packets sent along the LMP Control Channel) are originating 3322 from the right place and have not been modified in transit. 3323 LMP Test packets exchanged through the data links do not need 3324 to be protected. 3326 o For LMP traffic, protecting the identity of LMP end-points is 3327 not commonly required. 3329 o Security mechanism should provide for well defined key 3330 management schemes. The key management schemes should be well 3331 analyzed to be cryptographically secure. The key management 3332 schemes should be scalable. In addition, the key management 3333 system should be automatic. 3335 o The algorithms used for authentication MUST be 3336 cryptographically sound. Also the security protocol MUST 3337 allow for negotiating and using different authentication 3338 algorithms. 3340 16.2. Security Mechanisms 3342 IPsec is a protocol suite that is used to secure communication at 3343 the network layer between two peers. This protocol is comprised of 3344 IP Security architecture document [RFC2401], IKE [RFC2409], IPsec AH 3345 [RFC2402], and IPsec ESP [RFC2406]. IKE is the key management 3346 protocol for IP networks while AH and ESP are used to protect IP 3347 traffic. IKE is defined specific to IP domain of interpretation. 3349 Considering the requirements described in Section 16.1, it is 3350 recommended that where security is needed for LMP, implementations 3351 use IPsec as described below: 3353 1. Implementations of LMP over IPsec protocol SHOULD support manual 3354 keying mode. 3356 Manual keying mode provides an easy way to set up and diagnose 3357 IPsec functionality. 3359 However, note that manual keying mode can not effectively support 3360 features such as replay protection and automatic re-keying. An 3361 implementer using manual keys must be aware of these limits. 3363 It is recommended that an implementer use manual keying only for 3364 diagnostic purpose and use dynamic keying protocol to make use of 3365 features such as replay protection and automatic re-keying. 3367 2. IPsec ESP with trailer authentication in tunnel mode MUST be 3368 supported. 3370 3. Implementations MUST support authenticated key exchange 3371 protocols. IKE [RFC2409] MUST be used as the key exchange 3372 protocol if keys are dynamically negotiated between peers. 3374 4. Implementation MUST use the IPsec DOI [RFC2407]. 3376 5. For IKE protocol, the identities of the SAs negotiated in Quick 3377 Mode represent the traffic that the peers agree to protect and 3378 are comprised of address space, protocol, and port information. 3380 For LMP over IPsec, it is recommended that the identity payload 3381 for Quick mode contain the following information: 3383 The identities MUST be of type IP addresses and the value of the 3384 identities SHOULD be the IP addresses of the communicating peers. 3386 The protocol field MUST be UDP. The port field SHOULD be set to 3387 zero to indicate port fields should be ignored. This implies all 3388 UDP traffic between the peers must be sent through the IPsec 3389 tunnel. If an implementation supports port based selectors it can 3390 opt for a finer grained selector by specifying the port field to 3391 LMP port. If, however, the peer does not use port based 3392 selectors, the implementation MUST fall back to using port 3393 selector value of 0. 3395 6. Aggressive mode of IKE negotiation MUST be supported. 3397 When IPsec is configured to be used with a peer, all LMP messages 3398 are expected to be sent over the IPsec tunnel (crypto channel). 3399 Similarly a LMP receiver configured to use Ipsec with a peer, should 3400 reject any LMP traffic not coming through the crypto channel. 3402 The crypto channel can be pre-setup with the LMP neighbor or the 3403 first LMP message message sent to the peer could trigger the 3404 creation of the IPsec tunnel. 3406 A set of control channels can share the same crypto channel. When 3407 LMP Hellos are used to monitor the status of the control channel, it 3408 is important to keep in mind that the keep-alive failure in a 3409 control channel may also be due to a failure in the crypto channel. 3410 The following method is recommended to ensure an LMP communication 3411 path between two peers is working properly. 3413 o If LMP Hellos detect a failure on a control channel, switch to 3414 an alternate control channel and/or try to establish a new 3415 control channel. 3417 o Ensure the health of the control channels using LMP Hellos. If 3418 all control channels indicate a failure and it is not possible 3419 to bring up a new control channel, tear down all existing 3420 control channels. Also tear down the crypto channel (both the 3421 IKE SA and IPsec SAs). 3423 o Reestablish the crypto channel. Failure to establish a crypto 3424 channel indicates a fatal failure for LMP communication. 3426 o Bring up the control channel. Failure to bring up the control 3427 channel indicates a fatal failure for LMP communication. 3429 When LMP peers are dynamically discovered (particularly the 3430 initiator), the following points should be noted: 3432 When using pre-shared key authentication in identity protection 3433 mode (main mode), the pre-shared key is required to compute the 3434 value of SKEYID (used for deriving keys to encrypt messages 3435 during key exchange). In main mode of IKE, the pre-shared key to 3436 be used has to be identified before receiving the peer�s identity 3437 payload. The pre-shared key is required for calculating SKEYID. 3438 The only information available about the peer at this point is 3439 its IP address from which the negotiation came from. Keying off 3440 the IP address of a peer to get the pre-shared key is not 3441 possible since the addresses are dynamic and not known 3442 beforehand. 3444 Aggressive mode key exchange can be used since identification 3445 payloads are sent in the first message. 3447 Note, however, that aggressive mode is prone to passive denial of 3448 service attacks. Using a shared secret (group shared secret) 3449 among a number of peers is strongly discourages as this opens up 3450 the solution to man-in-the-middle attacks. 3452 Digital signature based authentication is not prone to such 3453 problems. It is RECOMMENDED to use digital signature based 3454 authentication mechanism where possible. 3456 If pre-shared key based authentication is required, then 3457 aggressive mode SHOULD be used. IKE pre-shared authentication key 3458 values SHOULD be protected in a manner similar to the user's 3459 account password. 3461 17. IANA Considerations 3463 LMP requires that a UDP port number be assigned. 3465 In the following, guidelines are given for IANA assignment for each 3466 LMP name space. Ranges are specified �for Private Use�, �to be 3467 assigned by Expert Review�, and �to be assigned by Standards Action� 3468 (as defined in [RFC2434]. 3470 Assignments made from LMP number spaces set aside for Private Use 3471 (i.e., for proprietary extensions) need not be documented. 3472 Independent RSVP implementations using the same Private Ues code 3473 points will in general not interoperate, so care should be exercised 3474 in using these code points in a multi-vendor network. 3476 Assignments made from LMP number spaces to be assigned by Expert 3477 Review are to be reviewed by an Expert designated by the IESG. The 3478 intent in this document is that code points from these ranges are 3479 used for Experimental extensions; as such,assignments MUST be 3480 accompanied by Experimental RFCs. If deployment suggests that these 3481 extensions are useful, then they should be described in Standards 3482 Track RFCs, and new code points from the Standards Action ranges 3483 MUST be assigned. 3485 Assignments from LMP number spaces to be assigned by Standards 3486 Action MUST be documented by a Standards Track RFC, typically 3487 submitted to an IETF Working Group, but in any case following the 3488 usual IETF procedures for Proposed Standards. 3490 The Reserved bits of the LMP Common Header should be allocated by 3491 Standards Action, pursuant to the policies outlined in [RFC2434]. 3493 LMP defines the following name spaces that require management: 3495 - LMP Message Type. 3497 - LMP Object Class. 3498 - LMP Object Class type (C-Type). These are unique within the 3499 Object Class. 3500 - LMP Sub-object Class type (Type). These are unique within the 3501 Object Class. 3503 The LMP Message Type name space should be allocated as follows: 3504 pursuant to the policies outlined in [RFC2434], the numbers in the 3505 range 0-127 are allocated by Standards Action, 128-240 are allocated 3506 through an Expert Review, and 241-255 are reserved for Private Use. 3508 The LMP Object Class name space should be allocated as follows: 3509 pursuant to the policies outlined in [RFC2434], the numbers in the 3510 range of 0-127 are allocated by Standards Action, 128-247 are 3511 allocated through an Expert Review, and 248-255 are reserved for 3512 Private Use. 3514 The policy for allocating values out of the LMP Object Class name 3515 space is part of the definition of the specific Class instance. 3516 When a Class is defined, its definition must also include a 3517 description of the policy under which the Object Class names are 3518 allocated. 3520 The policy for allocating values out of the LMP Sub-object Class 3521 name space is part of the definition of the specific Class instance. 3522 When a Class is defined, its definition must also include a 3523 description of the policy under which sub-objects are allocated. 3525 The following name spaces need to be assigned initially: 3527 [Note to RFC Editor: Please drop all text enclosed in parentheses in 3528 this section once the IANA assignments are made. The values are 3529 included for reference only and should be considered unassigned.] 3531 ------------------------------------------------------------------ 3532 LMP Message Type name space 3534 o Config message (suggested Message type = 1) 3536 o ConfigAck message (suggested Message type = 2) 3538 o ConfigNack message (suggested Message type = 3) 3540 o Hello message (suggested Message type = 4) 3542 o BeginVerify message (suggested Message type = 5) 3544 o BeginVerifyAck message (suggested Message type = 6) 3546 o BeginVerifyNack message (suggested Message type = 7) 3548 o EndVerify message (suggested Message type = 8) 3549 o EndVerifyAck message (suggested Message type = 9) 3551 o Test message (suggested Message type = 10) 3553 o TestStatusSuccess message (suggested Message type = 11) 3555 o TestStatusFailure message (suggested Message type = 12) 3557 o TestStatusAck message (suggested Message type = 13) 3559 o LinkSummary message (suggested Message type = 14) 3561 o LinkSummaryAck message (suggested Message type = 15) 3563 o LinkSummaryNack message (suggested Message type = 16) 3565 o ChannelStatus message (suggested Message type = 17) 3567 o ChannelStatusAck message (suggested Message type = 18) 3569 o ChannelStatusRequest message (suggested Message type = 19) 3571 o ChannelStatusResponse message (suggested Message type = 20) 3573 ------------------------------------------------------------------ 3574 LMP Object Class name space and Class type (C-Type) 3576 o CCID Class name (suggested = 1) 3578 The CCID Object Class type name space should be allocated as 3579 follows: pursuant to the policies outlined in [RFC2434], the numbers 3580 in the range 0-111 are allocated by Standards Action, 112-119 are 3581 allocated through an Expert Review, and 120-127 are reserved for 3582 Private Use. 3584 - LOCAL_CCID (suggested C-Type = 1) 3585 - REMOTE_CCID (suggested C-Type = 2) 3587 o NODE_ID Class name (suggested = 2) 3589 The NODE ID Object Class type name space should be allocated as 3590 follows: pursuant to the policies outlined in [RFC2434], the numbers 3591 in the range 0-111 are allocated by Standards Action, 112-119 are 3592 allocated through an Expert Review, and 120-127 are reserved for 3593 Private Use. 3595 - LOCAL_NODE_ID (suggested C-Type = 1) 3596 - REMOTE_NODE_ID (suggested C-Type = 2) 3598 o LINK_ID Class name (suggested = 3) 3599 The LINK_ID Object Class type name space should be allocated as 3600 follows: pursuant to the policies outlined in [RFC2434], the numbers 3601 in the range 0-111 are allocated by Standards Action, 112-119 are 3602 allocated through an Expert Review, and 120-127 are reserved for 3603 Private Use. 3605 - IPv4 LOCAL_LINK_ID (suggested C-Type = 1) 3606 - IPv4 REMOTE_LINK_ID (suggested C-Type = 2) 3607 - IPv6 LOCAL_LINK_ID (suggested C-Type = 3) 3608 - IPv6 REMOTE_LINK_ID (suggested C-Type = 4) 3609 - Unnumbered LOCAL_LINK_ID (suggested C-Type = 5) 3610 - Unnumbered REMOTE_LINK_ID (suggested C-Type = 6) 3612 o INTERFACE_ID Class name (suggested = 4) 3614 The INTERFACE_ID Object Class type name space should be allocated as 3615 follows: pursuant to the policies outlined in [RFC2434], the numbers 3616 in the range 0-111 are allocated by Standards Action, 112-119 are 3617 allocated through an Expert Review, and 120-127 are reserved for 3618 Private Use. 3620 - IPv4 LOCAL_INTERFACE_ID (suggested C-Type = 1) 3621 - IPv4 REMOTE_INTERFACE_ID (suggested C-Type = 2) 3622 - IPv6 LOCAL_INTERFACE_ID (suggested C-Type = 3) 3623 - IPv6 REMOTE_INTERFACE_ID (suggested C-Type = 4) 3624 - Unnumbered LOCAL_INTERFACE_ID (suggested C-Type = 5) 3625 - Unnumbered REMOTE_INTERFACE_ID (suggested C-Type = 6) 3627 o MESSAGE_ID Class name (suggested = 5) 3629 The MESSAGE_ID Object Class type name space should be allocated as 3630 follows: pursuant to the policies outlined in [RFC2434], the numbers 3631 in the range 0-111 are allocated by Standards Action, 112-119 are 3632 allocated through an Expert Review, and 120-127 are reserved for 3633 Private Use. 3635 - MESSAGE_ID (suggested C-Type = 1) 3636 - MESSAGE_ID_ACK (suggested C-Type = 2) 3638 o CONFIG Class name (suggested = 6) 3640 The CONFIG Object Class type name space should be allocated as 3641 follows: pursuant to the policies outlined in [RFC2434], the numbers 3642 in the range 0-111 are allocated by Standards Action, 112-119 are 3643 allocated through an Expert Review, and 120-127 are reserved for 3644 Private Use. 3646 - HELLO_CONFIG (suggested C-Type = 1) 3648 o HELLO Class name (suggested = 7) 3649 The HELLO Object Class type name space should be allocated as 3650 follows: pursuant to the policies outlined in [RFC2434], the numbers 3651 in the range 0-111 are allocated by Standards Action, 112-119 are 3652 allocated through an Expert Review, and 120-127 are reserved for 3653 Private Use. 3655 - HELLO (suggested C-Type = 1) 3657 o BEGIN_VERIFY Class name (suggested = 8) 3659 The BEGIN_VERIFY Object Class type name space should be allocated as 3660 follows: pursuant to the policies outlined in [RFC2434], the numbers 3661 in the range 0-111 are allocated by Standards Action, 112-119 are 3662 allocated through an Expert Review, and 120-127 are reserved for 3663 Private Use. 3665 - Type 1 (suggested C-Type = 1) 3667 o BEGIN_VERIFY_ACK Class name (suggested = 9) 3669 The BEGIN_VERIFY_ACK Object Class type name space should be 3670 allocated as follows: pursuant to the policies outlined in 3671 [RFC2434], the numbers in the range 0-111 are allocated by Standards 3672 Action, 112-119 are allocated through an Expert Review, and 120-127 3673 are reserved for Private Use. 3675 - Type 1 (suggested C-Type = 1) 3677 o VERIFY_ID Class name (suggested = 10) 3679 The VERIFY_ID Object Class type name space should be allocated as 3680 follows: pursuant to the policies outlined in [RFC2434], the numbers 3681 in the range 0-111 are allocated by Standards Action, 112-119 are 3682 allocated through an Expert Review, and 120-127 are reserved for 3683 Private Use. 3685 - Type 1 (suggested C-Type = 1) 3687 o TE_LINK Class name (suggested = 11) 3689 The TE_LINK Object Class type name space should be allocated as 3690 follows: pursuant to the policies outlined in [RFC2434], the numbers 3691 in the range 0-111 are allocated by Standards Action, 112-119 are 3692 allocated through an Expert Review, and 120-127 are reserved for 3693 Private Use. 3695 - IPv4 TE_LINK (suggested C-Type = 1) 3696 - IPv6 TE_LINK (suggested C-Type = 2) 3697 - Unnumbered TE_LINK (suggested C-Type = 3) 3699 o DATA_LINK Class name (suggested = 12) 3700 The DATA_LINK Object Class type name space should be allocated as 3701 follows: pursuant to the policies outlined in [RFC2434], the numbers 3702 in the range 0-111 are allocated by Standards Action, 112-119 are 3703 allocated through an Expert Review, and 120-127 are reserved for 3704 Private Use. 3706 - IPv4 DATA_LINK (suggested C-Type = 1) 3707 - IPv6 DATA_LINK (suggested C-Type = 2) 3708 - Unnumbered DATA_LINK (suggested C-Type = 3) 3710 The DATA_LINK Sub-object Class name space should be allocated as 3711 follows: pursuant to the policies outlined in [RFC2434], the numbers 3712 in the range of 0-127 are allocated by Standards Action, 128-247 are 3713 allocated through an Expert Review, and 248-255 are reserved for 3714 Private Use. 3716 - Interface Switching Type (suggested sub-object Type = 1) 3717 - Wavelength (suggested sub-object Type = 2) 3719 o CHANNEL_STATUS Class name (suggested = 13) 3721 The CHANNEL_STATUS Object Class type name space should be allocated 3722 as follows: pursuant to the policies outlined in [RFC2434], the 3723 numbers in the range 0-111 are allocated by Standards Action, 112- 3724 119 are allocated through an Expert Review, and 120-127 are reserved 3725 for Private Use. 3727 - IPv4 INTERFACE_ID (suggested C-Type = 1) 3728 - IPv6 INTERFACE_ID (suggested C-Type = 2) 3729 - Unnumbered INTERFACE_ID (suggested C-Type = 3) 3731 o CHANNEL_STATUS_REQUESTClass name (suggested = 14) 3733 The CHANNEL_STATUS_REQUEST Object Class type name space should be 3734 allocated as follows: pursuant to the policies outlined in 3735 [RFC2434], the numbers in the range 0-111 are allocated by Standards 3736 Action, 112-119 are allocated through an Expert Review, and 120-127 3737 are reserved for Private Use. 3739 - IPv4 INTERFACE_ID (suggested C-Type = 1) 3740 - IPv6 INTERFACE_ID (suggested C-Type = 2) 3741 - Unnumbered INTERFACE_ID (suggested C-Type = 3) 3743 o ERROR_CODE Class name (suggested = 20) 3745 The ERROR_CODE Object Class type name space should be allocated as 3746 follows: pursuant to the policies outlined in [RFC2434], the numbers 3747 in the range 0-111 are allocated by Standards Action, 112-119 are 3748 allocated through an Expert Review, and 120-127 are reserved for 3749 Private Use. 3751 - BEGIN_VERIFY_ERROR (suggested C-Type = 1) 3752 - LINK_SUMMARY_ERROR (suggested C-Type = 2) 3754 18. Acknowledgements 3756 The authors would like to thank Andre Fredette for his many 3757 contributions to this document. We would also like to thank Ayan 3758 Banerjee, George Swallow, Andre Fredette, Adrian Farrel, Dimitri 3759 Papadimitriou, Vinay Ravuri, and David Drysdale for their insightful 3760 comments and suggestions. We would also like to thank John Yu, 3761 Suresh Katukam, and Greg Bernstein for their helpful suggestions for 3762 the in-band control channel applicability. 3764 19. Contributors 3766 Jonathan P. Lang Krishna Mitra 3767 Rincon Networks Independent Consultant 3768 829 De La Vina, Suite 220 email: kmitra@earthlink.net 3769 Santa Barbara, CA 93101 3770 Email: jplang@ieee.org 3772 John Drake Kireeti Kompella 3773 Calient Networks Juniper Networks, Inc. 3774 5853 Rue Ferrari 1194 North Mathilda Avenue 3775 San Jose, CA 95138 Sunnyvale, CA 94089 3776 email: jdrake@calient.net email: kireeti@juniper.net 3778 Yakov Rekhter Lou Berger 3779 Juniper Networks, Inc. Movaz Networks 3780 1194 North Mathilda Avenue email: lberger@movaz.com 3781 Sunnyvale, CA 94089 3782 email: yakov@juniper.net 3784 Debanjan Saha Debashis Basak 3785 IBM Watson Research Center Accelight Networks 3786 email: dsaha@us.ibm.com 70 Abele Road, Suite 1201 3787 Bridgeville, PA 15017-3470 3788 email: dbasak@accelight.com 3790 Hal Sandick Alex Zinin 3791 Shepard M.S. Alcatel 3792 2401 Dakota Street email: alex.zinin@alcatel.com 3793 Durham, NC 27705 3794 email: sandick@nc.rr.com 3796 Bala Rajagopalan Sankar Ramamoorthi 3797 Tellium Optical Systems Juniper Networks, Inc. 3798 2 Crescent Place 1194 North Mathilda Avenue 3799 Oceanport, NJ 07757-0901 Sunnyvale, CA 94089 3800 email: braja@tellium.com email: sankarr@juniper.net 3802 20. Contact Address 3803 Jonathan P. Lang 3804 Rincon Networks 3805 829 De La Vina, Suite 220 3806 Goleta, CA 93101 3807 Email: jplang@ieee.org 3809 21. Full Copyright Statement 3811 Copyright (C) The Internet Society (2003). All Rights Reserved. 3813 This document and translations of it may be copied and furnished to 3814 others, and derivative works that comment on or otherwise explain it 3815 or assist in its implementation may be prepared, copied, published 3816 and distributed, in whole or in part, without restriction of any 3817 kind, provided that the above copyright notice and this paragraph 3818 are included on all such copies and derivative works. However, this 3819 document itself may not be modified in any way, such as by removing 3820 the copyright notice or references to the Internet Society or other 3821 Internet organizations, except as needed for the purpose of 3822 developing Internet standards in which case the procedures for 3823 copyrights defined in the Internet Standards process must be 3824 followed, or as required to translate it into languages other than 3825 English. 3827 The limited permissions granted above are perpetual and will not be 3828 revoked by the Internet Society or its successors or assigns. 3830 This document and the information contained herein is provided on an 3831 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3832 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3833 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3834 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3835 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.