idnits 2.17.1 draft-ietf-ccamp-lmp-04.txt: -(2249): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2663): 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 11 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 179: '... LMP capable devices SHOULD allow sub-...' RFC 2119 keyword, line 183: '... OXC SHOULD be able to configure eac...' RFC 2119 keyword, line 216: '...meters, however, MUST be individually ...' RFC 2119 keyword, line 218: '...P Hello messages MUST be exchanged ove...' RFC 2119 keyword, line 219: '...her LMP messages MAY be transmitted ov...' (161 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When a node has either sent or received a ConfigAck message, it may begin sending Hello messages. Once it has 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.) 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 12.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 (June 2002) is 7979 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) == Missing Reference: 'IANA' is mentioned on line 1169, but not defined -- Possible downref: Normative reference to a draft: ref. 'BUNDLE' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'G707' -- Possible downref: Non-RFC (?) normative reference: ref. 'GR253' -- Possible downref: Normative reference to a draft: ref. 'LMP-SEC' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-04 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-02 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jonathan P. Lang, Editor 2 Internet Draft 3 Expiration Date: December 2002 5 June 2002 7 Link Management Protocol (LMP) 9 draft-ietf-ccamp-lmp-04.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 [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 reference 24 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 Optical networks are being developed to include photonic switches, 35 optical crossconnects, and routers that are configured with control 36 channels and data links. Furthermore, multiple data links may be 37 combined to form a single traffic engineering (TE) link for routing 38 purposes. This draft specifies a link management protocol (LMP) that 39 runs between neighboring nodes and is used to manage TE links. 40 Specifically, LMP will be used to maintain control channel 41 connectivity, verify the physical connectivity of the data-bearing 42 channels, correlate the link property information, suppress 43 downstream alarms, and localize link failures for 44 protection/restoration purposes in both opaque and transparent 45 networks. 47 Table of Contents 48 1 Introduction ................................................ 4 49 2 LMP Overview ................................................ 5 50 3 Control Channel Management ................................... 7 51 3.1 Parameter Negotiation ................................... 8 52 3.2 Hello Protocol ........................................... 9 53 3.2.1 Hello Parameter Negotiation ....................... 9 54 3.2.2 Fast Keep-alive .................................. 10 55 3.2.3 Control Channel Down ............................. 11 56 3.2.4 Degraded (DEG) State ............................. 11 57 4 Link Property Correlation ................................... 11 58 5 Verifying Link Connectivity ................................. 13 59 5.1 Example of Link Connectivity Verification ............... 16 60 6 Fault Management ............................................ 17 61 6.1 Fault Detection ......................................... 17 62 6.2 Fault Localization Procedure ............................ 18 63 6.3 Examples of Fault Localization .......................... 18 64 6.4 Channel Activation Indication ........................... 19 65 6.5 Channel Deactivation Indication ......................... 20 66 7 Message_Id Usage ............................................ 20 67 8 Graceful Restart ............................................ 21 68 9 Addressing .................................................. 22 69 10 Exponential Back-off Procedures ............................. 23 70 10.1 Operation.................................................. 23 71 10.2 Retransmission Algorithm .................................. 23 72 11 IANA Considerations ......................................... 24 73 12 LMP Finite State Machines ................................... 24 74 12.1 Control Channel FSM .................................... 24 75 12.1.1 Control Channel States .......................... 24 76 12.1.2 Control Channel Events .......................... 25 77 12.1.3 Control Channel FSM Description ................. 28 78 12.2 TE Link FSM ............................................ 29 79 12.2.1 TE link States .................................. 29 80 12.2.2 TE link Events .................................. 29 81 12.2.3 TE link FSM Description ......................... 30 82 12.3 Data Link FSM .......................................... 30 83 12.3.1 Data Link States ................................ 31 84 12.3.2 Data Link Events ................................ 31 85 12.3.3 Active Data Link FSM Description ................ 33 86 12.3.4 Passive Data Link FSM Description ............... 34 87 13 LMP Message Formats ......................................... 35 88 13.1 Common Header .......................................... 35 89 13.2 LMP Object Format ...................................... 36 90 13.3 Parameter Negotiation .................................. 37 91 13.4 Hello .................................................. 39 92 13.5 Link Verification ...................................... 39 93 13.6 Link Summary ........................................... 43 94 13.7 Fault Management ....................................... 44 95 14 LMP Object Definitions ...................................... 45 96 15 Security Conderations ....................................... 63 97 16 Intellectual Property Considerations ........................ 63 98 17 References .................................................. 63 99 18 Acknowledgments ............................................. 64 100 19 Contributors ................................................ 65 101 20 Contact Address ............................................. 65 102 Changes from previous version: 104 o Editorial changes. 105 o Changed LMP from running directly over IP to running over UDP. 106 o Added Section describing exponential back-off procedures. 107 o Added suggested values for timers. 108 o Merged the LOCAL/REMOTE Id classes into single class. 109 o Merged the MESSAGE_ID/MESSAGE_ID_ACK classes into single class. 110 o Removed the MD5 security option. 112 1. Introduction 114 Optical networks are being developed with photonic switches (PXCs), 115 optical crossconnects (OXCs), routers, switches, DWDM systems, and 116 add-drop multiplexors (ADMs) that use a common control plane [e.g., 117 Generalized MPLS (GMPLS)] to dynamically allocate resources and to 118 provide network survivability using protection and restoration 119 techniques. A pair of nodes (e.g., two PXCs) may be connected by 120 thousands of fibers, and each fiber may be used to transmit multiple 121 wavelengths if DWDM is used. Furthermore, multiple fibers and/or 122 multiple wavelengths may be combined into a single traffic- 123 engineering (TE) link for routing purposes. To enable communication 124 between nodes for routing, signaling, and link management, control 125 channels must be established between the node pair; however, the 126 interface over which the control messages are sent/received may not 127 be the same interface over which the data flows. This draft 128 specifies a link management protocol (LMP) that runs between 129 neighboring nodes and is used to manage TE links. 131 In this draft, OXC is used to refer to all categories of optical 132 crossconnects irrespective of the internal switching fabric. 133 Furthermore, a distinction is made between crossconnects that 134 require opto-electronic conversion, called digital crossconnects 135 (DXCs), and those that are all-optical, called photonic switches or 136 photonic crossconnects (PXCs) � often referred to as pure 137 crossconnects [LAMBDA] because their transparent nature introduces 138 new restrictions for monitoring and managing the data links. LMP can 139 be used for any type of node, enhancing the functionality of 140 traditional DXCs and routers, while enabling PXCs and DWDMs to 141 intelligently interoperate in heterogeneous optical networks. 143 In GMPLS, the control channels between two adjacent nodes are no 144 longer required to use the same physical medium as the data-bearing 145 links between those nodes. For example, a control channel could use 146 a separate wavelength or fiber, an Ethernet link, an IP tunnel 147 through a separate management network, or a multi-hop IP network. A 148 consequence of allowing the control channel(s) between two nodes to 149 be physically diverse from the associated data links is that the 150 health of a control channel does not necessarily correlate to the 151 health of the data links, and vice-versa. Therefore, a clean 152 separation between the fate of the control channel and data-bearing 153 links must be made. New mechanisms must be developed to manage the 154 data-bearing links, both in terms of link provisioning and fault 155 management. 157 For the purposes of this document, a data-bearing link may be either 158 a "port" or a "component link" depending on its multiplexing 159 capability; component links are multiplex capable, whereas ports are 160 not multiplex capable. This distinction is important since the 161 management of such links (including, for example, resource 162 allocation, label assignment, and their physical verification) is 163 different based on their multiplexing capability. For example, a 164 SONET crossconnect with OC-192 interfaces may be able to demultiplex 165 the OC-192 stream into four OC-48 streams. If multiple interfaces 166 are grouped together into a single TE link using link bundling 167 [BUNDLE], then the link resources must be identified using three 168 levels: TE link Id, component interface Id, and timeslot label. 169 Resource allocation happens at the lowest level (timeslots), but 170 physical connectivity happens at the component link level. As 171 another example, consider the case where a PXC transparently 172 switches OC-192 lightpaths. If multiple interfaces are once again 173 grouped together into a single TE link, then link bundling [BUNDLE] 174 is not required and only two levels of identification are required: 175 TE link Id and port Id. In this case, both resource allocation and 176 physical connectivity happen at the lowest level (i.e. port level). 178 To ensure interworking between data links with different 179 multiplexing capabilities, LMP capable devices SHOULD allow sub- 180 channels of a component link to be locally configured as (logical) 181 data links. For example, if a Router with 4 OC-48 interfaces is 182 connected through a 4:1 MUX to an OXC with OC-192c interfaces, the 183 OXC SHOULD be able to configure each OC-48 sub-channel as a data 184 link. 186 LMP is designed to support aggregation of one or more data-bearing 187 links into a TE link (either ports into TE links, or component links 188 into TE links). The purpose of forming a TE link is to group/map the 189 information about certain physical resources (and their properties) 190 into the information that is used by Constrained SPF for the purpose 191 of path computation, and by GMPLS signaling. 193 2. LMP Overview 195 The two core procedures of LMP are control channel management and 196 link property correlation. Control channel management is used to 197 establish and maintain control channels between adjacent nodes. This 198 is done using a Config message exchange and a fast keep-alive 199 mechanism between the nodes. The latter is required if lower-level 200 mechanisms are not available to detect control channel failures. 201 Link property correlation is used to synchronize the TE link 202 properties and verify the TE link configuration. 204 LMP requires that a pair of nodes have at least one active bi- 205 directional control channel between them. Each direction of the 206 control channel is identified by a control channel id (CCId), and 207 the two directions are coupled together using the LMP Config message 208 exchange. All LMP messages are IP encoded [except in some cases, the 209 Test Message which may be limited by the transport mechanism for in- 210 band messaging]. The link level encoding of the control channel is 211 outside the scope of this document. 213 An "LMP adjacency" is formed between two nodes when at least one bi- 214 directional control channel is established between them. Multiple 215 control channels may be active simultaneously for each adjacency; 216 control channel parameters, however, MUST be individually negotiated 217 for each control channel. If the LMP fast keep-alive is used over a 218 control channel, LMP Hello messages MUST be exchanged over the 219 control channel. Other LMP messages MAY be transmitted over any of 220 the active control channels between a pair of adjacent nodes. One or 221 more active control channels may be grouped into a logical control 222 channel for signaling, routing, and link property correlation 223 purposes. 225 The link property correlation function of LMP is designed to 226 aggregate multiple data links (ports or component links) into a TE 227 link and to synchronize the properties of the TE link. As part of 228 the link property correlation function, a LinkSummary message 229 exchange is defined. The LinkSummary message includes the local and 230 remote TE Link Ids, a list of all data links that comprise the TE 231 link, and various link properties. A LinkSummaryAck or 232 LinkSummaryNack message MUST be sent in response to the receipt of a 233 LinkSummary message indicating agreement or disagreement on the link 234 properties. 236 LMP messages are transmitted reliably using Message Ids and 237 retransmissions. Message Ids are carried in MESSAGE_ID objects. No 238 more than one MESSAGE_ID object may be included in an LMP message. 239 For control channel specific messages, the Message Id is within the 240 scope of the control channel over which the message is sent. For TE 241 link specific messages, the Message Id is within the scope of the 242 LMP adjacency. The value of the Message Id is monotonically 243 increasing and only decreases when the value wraps. 245 In this draft, two additional LMP procedures are defined: link 246 connectivity verification and fault management. These procedures are 247 particularly useful when the control channels are physically diverse 248 from the data-bearing links. Link connectivity verification is used 249 for data plane discovery, Interface Id exchange (Interface Ids are 250 used in GMPLS signaling, either as Port labels or Component 251 Interface Ids, depending on the configuration), and physical 252 connectivity verification. This is done by sending Test messages in- 253 band over the data-bearing links and TestStatus messages back over 254 the control channel. Note that the Test message is the only LMP 255 message that must be transmitted over the data-bearing link. The 256 ChannelStatus message exchange is used between adjacent nodes for 257 both the suppression of downstream alarms and the localization of 258 faults for protection and restoration. 260 For LMP link connectivity verification using a PXC, the Test message 261 is generated and terminated by opaque test units that may be shared 262 among multiple ports. Opaque test units are needed since the PXC 263 ports are transparent. The LMP link connectivity verification 264 procedure is coordinated using a BeginVerify message exchange over a 265 control channel. To support various degrees of transparency (e.g., 266 examining overhead bytes, terminating the payload, etc.), and hence, 267 different mechanisms to transport the Test messages, a Verify 268 Transport Mechanism is included in the BeginVerify and 269 BeginVerifyAck messages. Note that there is no requirement that all 270 data-bearing links must be terminated simultaneously, but at a 271 minimum, it must be possible to terminate them one at a time. There 272 is also no requirement that the control channel and TE link use the 273 same physical medium; however, the control channel MUST terminate on 274 the same two nodes that the TE link spans. Since the BeginVerify 275 message exchange coordinates the Test procedure, it also naturally 276 coordinates the transition of the data links between opaque and 277 transparent mode. 279 The LMP fault management procedure is based on a ChannelStatus 280 exchange using the following messages: ChannelStatus, 281 ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse. 282 The ChannelStatus message is sent unsolicitated and is used to 283 notify an LMP neighbor about the status of one or more data channels 284 of a TE link. The ChannelStatusAck message is used to acknowledge 285 receipt of the ChannelStatus message. The ChannelStatusRequest 286 message is used to query an LMP neighbor for the status of one or 287 more data channels of a TE Link. The ChannelStatusResponse message 288 is used to acknowledge receipt of the ChannelStatusRequest message 289 and indicate the states of the queried data links. 291 3. Control Channel Management 293 To initiate an LMP adjacency between two nodes, one or more bi- 294 directional control channels MUST be activated. The control channels 295 can be used to exchange control-plane information such as link 296 provisioning and fault management information (implemented using a 297 messaging protocol such as LMP, proposed in this draft), path 298 management and label distribution information (implemented using a 299 signaling protocol such as RSVP-TE [RFC3209] or CR-LDP [RFC3219]), 300 and network topology and state distribution information (implemented 301 using traffic engineering extensions of protocols such as OSPF 302 [OSPF-TE] and IS-IS [ISIS-TE]). 304 For the purposes of LMP, the exact implementation of the control 305 channel is not specified; it could be, for example, a separate 306 wavelength or fiber, an Ethernet link, an IP tunnel through a 307 separate management network, or the overhead bytes of a data-bearing 308 link. Rather, a node-wide unique 32-bit non-zero integer control 309 channel identifier (CCId) is assigned at each end of the control 310 channel. This identifier comes from the same space as the unnumbered 311 interface Id. Furthermore, LMP packets are run over UDP with an LMP 312 port number. Thus, the link level encoding of the control channel is 313 not part of the LMP specification. 315 To establish a control channel, the destination IP address on the 316 far end of the control channel must be known. This knowledge may be 317 manually configured or automatically discovered. Note that for in- 318 band signaling, a control channel could be explicitly configured on 319 a particular data-bearing link. In this case, the Config message 320 exchange can be used to dynamically learn the IP address on the far 321 end of the control channel. This is done by sending the Config 322 message to the Multicast address (224.0.0.1). The ConfigAck and 323 ConfigNack messages MUST be sent to the source IP address found in 324 the IP header of the received Config message. 326 Control channels exist independently of TE links and multiple 327 control channels may be active simultaneously between a pair of 328 nodes. Individual control channels can be realized in different 329 ways; one might be implemented in-fiber while another one may be 330 implemented out-of-fiber. As such, control channel parameters MUST 331 be negotiated over each individual control channel, and LMP Hello 332 packets MUST be exchanged over each control channel to maintain LMP 333 connectivity if other mechanisms are not available. Since control 334 channels are electrically terminated at each node, it may be 335 possible to detect control channel failures using lower layers 336 (e.g., SONET/SDH). 338 There are four LMP messages that are used to manage individual 339 control channels. They are the Config, ConfigAck, ConfigNack, and 340 Hello messages. These messages MUST be transmitted on the channel to 341 which they refer. All other LMP messages may be transmitted over any 342 of the active control channels between a pair of LMP adjacent nodes. 344 In order to maintain an LMP adjacency, it is necessary to have at 345 least one active control channel between a pair of adjacent nodes 346 (recall that multiple control channels can be active simultaneously 347 between a pair of nodes). In the event of a control channel failure, 348 alternate active control channels can be used and it may be possible 349 to activate additional control channels as described below. 351 3.1. Parameter Negotiation 353 Control channel activation begins with a parameter negotiation 354 exchange using Config, ConfigAck, and ConfigNack messages. The 355 contents of these messages are built using LMP objects, which can be 356 either negotiable or non-negotiable (identified by the N bit in the 357 object header). Negotiable objects can be used to let LMP peers 358 agree on certain values. Non-negotiable objects are used for the 359 announcement of specific values that do not need, or do not allow, 360 negotiation. 362 To activate a control channel, a Config message MUST be transmitted 363 to the remote node, and in response, a ConfigAck message MUST be 364 received at the local node. The Config message contains the Local 365 Control Channel ID (CC_ID), the sender�s Node ID, a MessageId for 366 reliable messaging, and a CONFIG object. It is possible that both 367 the local and remote nodes initiate the configuration procedure at 368 the same time. To avoid ambiguities, the node with the higher Node 369 Id wins the contention; the node with the lower Node Id MUST stop 370 transmitting the Config message and respond to the Config message it 371 received. 373 The ConfigAck message is used to acknowledge receipt of the Config 374 message and express agreement on ALL of the configured parameters 375 (both negotiable and non-negotiable). 377 The ConfigNack message is used to acknowledge receipt of the Config 378 message, indicate which (if any) non-negotiable CONFIG objects are 379 unacceptable, and propose alternate values for the negotiable 380 parameters. 382 If a node receives a ConfigNack message with acceptable alternate 383 values for negotiable parameters, the node SHOULD transmit a Config 384 message using these values for those parameters. 386 If a node receives a ConfigNack message with unacceptable alternate 387 values, the node MAY continue to retransmit Config messages. Note 388 that the problem may be solved by an operator changing parameters. 390 In the case where multiple control channels use the same physical 391 interface, the parameter negotiation exchange is performed for each 392 control channel. The various LMP parameter negotiation messages are 393 associated with their corresponding control channels by their node- 394 wide unique identifiers (CCIds). 396 3.2. Hello Protocol 398 Once a control channel is activated between two adjacent nodes, the 399 LMP Hello protocol can be used to maintain control channel 400 connectivity between the nodes and to detect control channel 401 failures. The LMP Hello protocol is intended to be a lightweight 402 keep-alive mechanism that will react to control channel failures 403 rapidly so that IGP Hellos are not lost and the associated link- 404 state adjacencies are not removed unnecessarily. 406 3.2.1. Hello Parameter Negotiation 408 Before sending Hello messages, the HelloInterval and 409 HelloDeadInterval parameters MUST be agreed upon by the local and 410 remote nodes. These parameters are exchanged in the Config message. 411 The HelloInterval indicates how frequently LMP Hello messages will 412 be sent, and is measured in milliseconds (ms). For example, if the 413 value were 150, then the transmitting node would send the Hello 414 message at least every 150ms. The HelloDeadInterval indicates how 415 long a device should wait to receive a Hello message before 416 declaring a control channel dead, and is measured in milliseconds 417 (ms). The HelloDeadInterval MUST be greater than the HelloInterval, 418 and SHOULD be at least 3 times the value of HelloInterval. 420 Suggested default values for the HelloInterval is 5 ms and for the 421 HelloDeadInterval is 18 ms. 423 If the fast keep-alive mechanism of LMP is not used, the 424 HelloInterval and HelloDeadInterval parameters MUST be set to zero. 426 When a node has either sent or received a ConfigAck message, it may 427 begin sending Hello messages. Once it has sent a Hello message and 428 received a valid Hello message (i.e., with expected sequence 429 numbers; see Section 3.2.2), the control channel moves to the UP 430 state. (It is also possible to move to the UP state without sending 431 Hellos if other methods are used to indicate bi-directional control- 432 channel connectivity.) If, however, a node receives a ConfigNack 433 message instead of a ConfigAck message, the node MUST not send Hello 434 messages and the control channel SHOULD NOT move to the UP state. 435 See Section 12.1 for the complete control channel FSM. 437 3.2.2. Fast Keep-alive 439 Each Hello message contains two sequence numbers: the first sequence 440 number (TxSeqNum) is the sequence number for the Hello message being 441 sent and the second sequence number (RcvSeqNum) is the sequence 442 number of the last Hello message received from the adjacent node 443 over this control channel. Each node increments its sequence number 444 when it sees its current sequence number reflected in Hellos 445 received from its peer. The sequence numbers start at 1 and wrap 446 around back to 2; 0 is used in the RcvSeqNum to indicate that a 447 Hello has not yet been seen. 449 Under normal operation, the difference between the RcvSeqNum in a 450 Hello message that is received and the local TxSeqNum that is 451 generated will be at most 1. This difference can be more than one 452 only when a control channel restarts or when the values wrap. 454 Note that the 32-bit sequence numbers MAY wrap. The following 455 expression may be used to test if a newly received TxSeqNum value is 456 less than a previously received value: 458 If ((int) old_id � (int) new_id > 0) { 459 New value is less than old value; 460 } 462 Having sequence numbers in the Hello messages allows each node to 463 verify that its peer is receiving its Hello messages. By including 464 the RcvSeqNum in Hello packets, the local node will know which Hello 465 packets the remote node has received. 467 The following example illustrates how the sequence numbers operate. 468 Note that only the operation at one node is shown, and alternative 469 scenarios are possible: 471 1) After completing the configuration stage, Node A sends Hello 472 messages to Node B with {TxSeqNum=1;RcvSeqNum=0}. 473 2) When Node A receives a Hello from Node B with 474 {TxSeqNum=1;RcvSeqNum=1}, it sends Hellos to Node B with 475 {TxSeqNum=2;RcvSeqNum=1}. 476 3) When Node A receives a Hello from Node B with 477 {TxSeqNum=2;RcvSeqNum=2}, it sends Hellos to Node B with 478 {TxSeqNum=3;RcvSeqNum=2}. 480 3.2.3. Control Channel Down 482 To allow bringing a control channel DOWN gracefully for 483 administration purposes, a ControlChannelDown flag is available in 484 the Common Header of LMP packets. When data links are still in use 485 between a pair of nodes, a control channel SHOULD only be taken down 486 administratively when there are other active control channels that 487 can be used to manage the data links. 489 When bringing a control channel DOWN administratively, a node MUST 490 set the ControlChannelDown flag in all LMP messages sent over the 491 control channel. The node that initiated the control channel DOWN 492 procedure may stop sending Hello messages after HelloDeadInterval 493 seconds have passed, or if it receives an LMP message over the same 494 control channel with the ControlChannelDown flag set. 496 When a node receives an LMP packet with the ControlChannelDown flag 497 set, it SHOULD send a Hello message with the ControlChannelDown flag 498 set and move the control channel to the Down state. 500 3.2.4. Degraded State 502 A consequence of allowing the control channels to be physically 503 diverse from the associated data links is that there may not be any 504 active control channels available while the data links are still in 505 use. For many applications, it is unacceptable to tear down a link 506 that is carrying user traffic simply because the control channel is 507 no longer available; however, the traffic that is using the data 508 links may no longer be guaranteed the same level of service. Hence 509 the TE link is in a Degraded state. 511 When a TE link is in the Degraded state, routing and signaling 512 SHOULD be notified so that new connections are not accepted and the 513 TE link is advertised with no unreserved resources. 515 4. Link Property Correlation 516 As part of LMP, a link property correlation exchange is defined for 517 TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack 518 messages. The contents of these messages are built using LMP 519 objects, which can be either negotiable or non-negotiable 520 (identified by the N flag in the object header). Negotiable objects 521 can be used to let both sides agree on certain link parameters. Non- 522 negotiable objects are used for announcement of specific values that 523 do not need, or do not allow, negotiation. 525 Each TE link has an identifier (Link_Id) that is assigned at each 526 end of the link. These identifiers MUST be the same type (i.e, IPv4, 527 IPv6, unnumbered) at both ends. If a LinkSummary message is received 528 with different local and remote TE link types, then a 529 LinkSummaryNack message MUST be sent with Error Code "Bad TE Link 530 Object". Similarly, each data link is assigned an identifier 531 (Interface_Id) at each end. These identifiers MUST also be the same 532 type at both ends. If a LinkSummary message is received with 533 different local and remote Interface Id types then a LinkSummaryNack 534 message MUST be sent with Error Code "Bad Data Link Object". 536 Link property correlation SHOULD be done before the link is brought 537 up and MAY be done at any time a link is UP and not in the 538 Verification process. 540 The LinkSummary message is used to verify for consistency the TE and 541 data bearing link information on both sides. Link Summary messages 542 are also used to aggregate multiple data links (either ports or 543 component links) into a TE link; exchange, correlate (to determine 544 inconsistencies), or change TE link parameters; and exchange, 545 correlate (to determine inconsistencies), or change Interface Ids 546 (used either Port Ids or Component Interface Ids). 548 The LinkSummary message includes a TE_LINK object followed by one or 549 more DATA_LINK objects. The TE_LINK object identifies the TE link's 550 local and remote Link Id and indicates support for fault management 551 and link verification procedures for that TE link. The DATA_LINK 552 objects are used to characterize the data links that comprise the TE 553 link. These objects include the local and remote Interface Ids, and 554 may include one or more sub-objects further describing the 555 properties of the data links. 557 If the LinkSummary message is received from a remote node and the 558 Interface Id mappings match those that are stored locally, then the 559 two nodes have agreement on the Verification procedure (see Section 560 5) and data link configuration. If the verification procedure is not 561 used, the LinkSummary message can be used to verify agreement on 562 manual configuration. 564 The LinkSummaryAck message is used to signal agreement on the 565 Interface Id mappings and link property definitions. Otherwise, a 566 LinkSummaryNack message MUST be transmitted, indicating which 567 Interface mappings are not correct and/or which link properties are 568 not accepted. If a LinkSummaryNack message indicates that the 569 Interface Id mappings are not correct and the link verification 570 procedure is enabled, the link verification process SHOULD be 571 repeated for all mismatched free data links; if an allocated data 572 link has a mapping mismatch, it SHOULD be flagged and verified when 573 it becomes free. If a LinkSummaryNack message includes negotiable 574 parameters, then acceptable values for those parameters MUST be 575 included. If a LinkSummaryNack message is received and includes 576 negotiable parameters, then the initiator of the LinkSummary message 577 SHOULD send a new LinkSummary message. The new LinkSummary message 578 SHOULD include new values for the negotiable parameters. These 579 values SHOULD take into account the acceptable values received in 580 the LinkSummaryNack message. 582 It is possible that the LinkSummary message could grow quite large 583 due to the number of DATA LINK objects. Since the LinkSummary 584 message is IP encoded, normal IP fragmentation should be used if the 585 resulting PDU exceeds the MTU. 587 5. Verifying Link Connectivity 589 In this section, an optional procedure is described that may be used 590 to verify the physical connectivity of the data-bearing links and 591 dynamically learn (i.e., discover) the TE link and Interface ID 592 associations. The procedure SHOULD be done when establishing a TE 593 link, and subsequently, on a periodic basis for all unallocated 594 (free) data links of the TE link. 596 Support for this procedure is indicated by setting the "Link 597 Verification Supported" flag in the TE_LINK object of the 598 LinkSummary message. 600 If a BeginVerify message is received and link verification is not 601 supported for the TE link, then a BeginVerifyNack message MUST be 602 transmitted with Error Code indicating "Link Verification Procedure 603 not supported for this TE Link." 605 A unique characteristic of all-optical switches is that the data- 606 bearing links are transparent when allocated to user traffic. This 607 characteristic poses a challenge for validating the connectivity of 608 the data links. For example, shining unmodulated light through a 609 link may not result in received light at the next switch because 610 there may be terminating (or opaque) elements, such as DWDM 611 equipment, between the PXCs. Therefore, to ensure proper 612 verification of data link connectivity, it is required that until 613 the links are allocated for user traffic, they must be opaque. To 614 support various degrees of opaqueness (e.g., examining overhead 615 bytes, terminating the payload, etc.), and hence different 616 mechanisms to transport the Test messages, a Verify Transport 617 Mechanism field is included in the BeginVerify and BeginVerifyAck 618 messages. 620 There is no requirement that all data links be terminated 621 simultaneously, but at a minimum, the data links MUST be able to be 622 terminated one at a time. Furthermore, for the link verification 623 procedure it is assumed that the nodal architecture is designed so 624 that messages can be sent and received over any data link. Note that 625 this requirement is trivial for DXCs (and OEO devices in general) 626 since each data link is terminated and processed electronically 627 before being forwarded to the next OEO device, but that in PXCs (and 628 transparent devices in general) this is an additional requirement. 630 To interconnect two nodes, a TE link is defined between them, and at 631 a minimum, there MUST be at least one active control channel between 632 the nodes. For link verification, a TE link MUST include at least 633 one data link. 635 Once a control channel has been established between the two nodes, 636 data link connectivity can be verified by exchanging Test messages 637 over each of the data links specified in the TE link. It should be 638 noted that all LMP messages except the Test message are exchanged 639 over the control channels and that Hello messages continue to be 640 exchanged over each control channel during the data link 641 verification process. The Test message is sent over the data link 642 that is being verified. Data links are tested in the transmit 643 direction as they are unidirectional, and therefore, it may be 644 possible for both nodes to (independently) exchange the Test 645 messages simultaneously. 647 To initiate the link verification procedure, the local node MUST 648 send a BeginVerify message over a control channel. To limit the 649 scope of Link Verification to a particular TE Link, the 650 LOCAL_LINK_ID MUST be non-zero. If this field is zero, the data 651 links can span multiple TE links and/or they may comprise a TE link 652 that is yet to be configured. For the case where the LOCAL_LINK_ID 653 field is zero, the "Verify all Links" flag of the BEGIN_VERIFY 654 object is used to distinguish between data links that span multiple 655 TE links and those that have not yet been assigned to a TE link. 656 Specifically, verification of data links that span multiple TE links 657 is indicated by setting the LOCAL_LINK_ID field to zero and setting 658 the "Verify all Links" flag. Verification of data links that have 659 not yet been assigned to a TE link is indicated by setting the 660 LOCAL_LINK_ID field to zero and clearing the "Verify all Links" 661 flag. 663 The BeginVerify message also contains the number of data links that 664 are to be verified; the interval (called VerifyInterval) at which 665 the Test messages will be sent; the encoding scheme and transport 666 mechanisms that are supported; the data rate for Test messages; and, 667 when the data links correspond to fibers, the wavelength identifier 668 over which the Test messages will be transmitted. 670 If the remote node receives a BeginVerify message and it is ready to 671 process Test messages, it MUST send a BeginVerifyAck message back to 672 the local node specifying the desired transport mechanism for the 673 TEST messages. The remote node includes a 32-bit node unique 674 VerifyId in the BeginVerifyAck message. The VerifyId is then used in 675 all corresponding verification messages to differentiate them from 676 different LMP peers and/or parallel Test procedures. When the local 677 node receives a BeginVerifyAck message from the remote node, it may 678 begin testing the data links by transmitting periodic Test messages 679 over each data link. The Test message includes the VerifyId and the 680 local Interface Id for the associated data link. The remote node 681 MUST send either a TestStatusSuccess or a TestStatusFailure message 682 in response for each data link. A TestStatusAck message MUST be sent 683 to confirm receipt of the TestStatusSuccess and TestStatusFailure 684 messages. 686 It is also permissible for the sender to terminate the Test 687 procedure anytime after sending the BeginVerify message. An 688 EndVerify message SHOULD be sent for this purpose. 690 Message correlation is done using message identifiers and the Verify 691 Id; this enables verification of data links, belonging to different 692 link bundles or LMP sessions, in parallel. 694 When the Test message is received, the received Interface Id (used 695 in GMPLS as either a Port/Wavelength label or Component Interface 696 Identifier depending on the configuration) is recorded and mapped to 697 the local Interface Id for that data link, and a TestStatusSuccess 698 message MUST be sent. The TestStatusSuccess message includes the 699 local Interface Id and the remote Interface Id (received in the Test 700 message), along with the VerifyId received in the Test message. The 701 receipt of a TestStatusSuccess message indicates that the Test 702 message was detected at the remote node and the physical 703 connectivity of the data link has been verified. When the 704 TestStatusSuccess message is received, the local node SHOULD mark 705 the data link as UP and send a TestStatusAck message to the remote 706 node. If, however, the Test message is not detected at the remote 707 node within an observation period (specified by the 708 VerifyDeadInterval), the remote node will send a TestStatusFailure 709 message over the control channel indicating that the verification of 710 the physical connectivity of the data link has failed. When the 711 local node receives a TestStatusFailure message, it SHOULD mark the 712 data link as FAILED and send a TestStatusAck message to the remote 713 node. When all the data links on the list have been tested, the 714 local node SHOULD send an EndVerify message to indicate that testing 715 is complete on this link. 717 If the local/remote data link mappings are known, then the link 718 verification procedure can be optimized by testing the data links in 719 a defined order known to both nodes. The suggested criteria for this 720 ordering is in increasing value of the Remote_Interface_ID. 722 Both the local and remote nodes SHOULD maintain the complete list of 723 Interface Id mappings for correlation purposes. 725 5.1. Example of Link Connectivity Verification 727 Figure 1 shows an example of the link verification scenario that is 728 executed when a link between Node A and Node B is added. In this 729 example, the TE link consists of three free ports (each transmitted 730 along a separate fiber) and is associated with a bi-directional 731 control channel (indicated by a "c"). The verification process is as 732 follows: 733 o A sends a BeginVerify message over the control channel to B 734 indicating it will begin verifying the ports that form the TE 735 link. The LOCAL_LINK_ID object carried in the BeginVerify 736 message carries the identifier (IP address or interface index) 737 that A assigns to the link. 738 o Upon receipt of the BeginVerify message, B creates a VerifyId 739 and binds it to the TE Link from A. This binding is used later 740 when B receives the Test messages from A, and these messages 741 carry the VerifyId. B discovers the identifier (IP address or 742 interface index) that A assigns to the TE link by examining the 743 LOCAL_LINK_ID object carried in the received BeginVerify 744 message. (If the data ports are not yet assigned to the TE 745 Link, the binding is limited to the Node Id of A.) In response 746 to the BeginVerify message, B sends to A the BeginVerifyAck 747 message. The LOCAL_LINK_ID object carried in the BeginVerifyAck 748 message is used to carry the identifier (IP address or 749 interface index) that B assigns to the TE link. The 750 REMOTE_LINK_ID object carried in the BeginVerifyAck message is 751 used to bind the TE link Ids assigned by both A and B. The 752 VerifyId is returned to A in the BeginVerifyAck message over 753 the control channel. 754 o When A receives the BeginVerifyAck message, it begins 755 transmitting periodic Test messages over the first port 756 (Interface Id=1). The Test message includes the Interface Id 757 for the port and the VerifyId that was assigned by B. 758 o When B receives the Test messages, it maps the received 759 Interface Id to its own local Interface Id = 10 and transmits a 760 TestStatusSuccess message over the control channel back to PXC 761 A. The TestStatusSuccess message includes both the local and 762 received Interface Ids for the port as well as the VerifyId. 763 The VerifyId is used to determine the local/remote TE link 764 identifiers (IP addresses or interface indices) for which the 765 data links belong. 766 o A will send a TestStatusAck message over the control channel 767 back to B indicating it received the TestStatusSuccess message. 768 o The process is repeated until all of the ports are verified. 769 o At this point, A will send an EndVerify message over the 770 control channel to B to indicate that testing is complete. 771 o B will respond by sending an EndVerifyAck message over the 772 control channel back to A. 774 Note that this procedure can be used to "discover" the 775 connectivity of the data ports. 777 +---------------------+ +---------------------+ 778 + + + + 779 + PXC A +<-------- c --------->+ PXC B + 780 + + + + 781 + + + + 782 + 1 +--------------------->+ 10 + 783 + + + + 784 + + + + 785 + 2 + /---->+ 11 + 786 + + /----/ + + 787 + + /---/ + + 788 + 3 +----/ + 12 + 789 + + + + 790 + + + + 791 + 4 +--------------------->+ 14 + 792 + + + + 793 +---------------------+ +---------------------+ 795 Figure 1: Example of link connectivity between PXC A and PXC B. 797 6. Fault Management 799 In this section, an optional LMP procedure is described that is used 800 to manage failures by rapid notification of the status of one or 801 more data channels of a TE Link. The scope of this procedure is 802 within a TE link, and as such, the use of this procedure is 803 negotiated as part of the LinkSummary exchange. The procedure can be 804 used to rapidly isolate link failures and is designed to work for 805 both unidirectional and bi-directional LSPs. 807 An important implication of using PXCs is that traditional methods 808 that are used to monitor the health of allocated data links in OEO 809 nodes (e.g., DXCs) may no longer be appropriate, since PXCs are 810 transparent to the bit-rate, format, and wavelength. Instead, fault 811 detection is delegated to the physical layer (i.e., loss of light or 812 optical monitoring of the data) instead of layer 2 or layer 3. 814 Recall that a TE link connecting two nodes may consist of a number 815 of data links. If one or more data links fail between two nodes, a 816 mechanism must be used for rapid failure notification so that 817 appropriate protection/restoration mechanisms can be initiated. If 818 the failure is subsequently cleared, then a mechanism must be used 819 to notify that the failure is clear and the channel status is OK. 821 6.1. Fault Detection 823 Fault detection should be handled at the layer closest to the 824 failure; for optical networks, this is the physical (optical) layer. 825 One measure of fault detection at the physical layer is detecting 826 loss of light (LOL). Other techniques for monitoring optical signals 827 are still being developed and will not be further considered in this 828 document. However, it should be clear that the mechanism used for 829 fault notification in LMP is independent of the mechanism used to 830 detect the failure, but simply relies on the fact that a failure is 831 detected. 833 6.2. Fault Localization Procedure 835 If data links fail between two PXCs, the power monitoring system in 836 all of the downstream nodes may detect LOL and indicate a failure. 837 To avoid multiple alarms stemming from the same failure, LMP 838 provides a failure notification through the ChannelStatus message. 839 This message may be used to indicate that a single data channel has 840 failed, multiple data channels have failed, or an entire TE link has 841 failed. Failure correlation is done locally at each node upon 842 receipt of the failure notification. 844 To localize a fault to a particular link between adjacent OXCs, a 845 downstream node (downstream in terms of data flow) that detects data 846 link failures will send a ChannelStatus message to its upstream 847 neighbor indicating that a failure has occurred (bundling together 848 the notification of all of the failed data links). An upstream node 849 that receives the ChannelStatus message MUST send a ChannelStatusAck 850 message to the downstream node indicating it has received the 851 ChannelStatus message. The upstream node should correlate the 852 failure to see if the failure is also detected locally (including 853 ingress side) for the corresponding LSP(s). If, for example, the 854 failure is clear on the input of the upstream node or internally, 855 then the upstream node will have localized the failure. Once the 856 failure is correlated, the upstream node SHOULD send a ChannelStatus 857 message to the downstream node indicating that the channel is failed 858 or is ok. If a ChannelStatus message is not received by the 859 downstream node, it SHOULD send a ChannelStatusRequest message for 860 the channel in question. Once the failure has been localized, the 861 signaling protocols may be used to initiate span or path protection 862 and restoration procedures. 864 If all of the data links of a TE link have failed, then the upstream 865 node MAY be notified of the TE link failure without specifying each 866 data link of the failed TE link. This is done by sending failure 867 notification in a ChannelStatus message identifying the TE Link 868 without including the Interface Ids in the CHANNEL_STATUS object. 870 6.3. Examples of Fault Localization 872 In Fig. 2, a sample network is shown where four nodes are connected 873 in a linear array configuration. The control channels are bi- 874 directional and are labeled with a "c". All LSPs are also bi- 875 directional. 877 In the first example [see Fig. 2(a)], there is a failure on one 878 direction of the bi-directional LSP. Node 4 will detect the failure 879 and will send a ChannelStatus message to Node 3 indicating the 880 failure (e.g., LOL) to the corresponding upstream node. When Node 3 881 receives the ChannelStatus message from Node 4, it returns a 882 ChannelStatusAck message back to Node 4 and correlates the failure 883 locally. When Node 3 correlates the failure and verifies that it is 884 CLEAR, it has localized the failure to the data link between Node 3 885 and Node 4. At that time, Node 3 should send a ChannelStatus message 886 to Node 4 indicating that the failure has been localized. 888 In the second example [see Fig. 2(b)], a single failure (e.g., fiber 889 cut) affects both directions of the bi-directional LSP. Node 2 (Node 890 3) will detect the failure of the upstream (downstream) direction 891 and send a ChannelStatus message to the upstream (in terms of data 892 flow) node indicating the failure (e.g., LOL). Simultaneously 893 (ignoring propagation delays), Node 1 (Node 4) will detect the 894 failure on the upstream (downstream) direction, and will send a 895 ChannelStatus message to the corresponding upstream (in terms of 896 data flow) node indicating the failure. Node 2 and Node 3 will have 897 localized the two directions of the failure. 899 +-------+ +-------+ +-------+ +-------+ 900 + Node1 + + Node2 + + Node3 + + Node4 + 901 + +-- c ---+ +-- c ---+ +-- c ---+ + 902 ----+---\ + + + + + + + 903 <---+---\\--+--------+-------+---\ + + + /--+---> 904 + \--+--------+-------+---\\---+-------+---##---+---//--+---- 905 + + + + \---+-------+--------+---/ + 906 + + + + + + (a) + + 907 ----+-------+--------+---\ + + + + + 908 <---+-------+--------+---\\--+---##---+--\ + + + 909 + + + \--+---##---+--\\ + + + 910 + + + + (b) + \\--+--------+-------+---> 911 + + + + + \--+--------+-------+---- 912 + + + + + + + + 913 +-------+ +-------+ +-------+ +-------+ 915 Figure 2: Two types of data link failures are shown 916 (indicated by ## in the figure): (A) a data link 917 corresponding to the downstream direction of a bi-directional 918 LSP fails, (B) two data links corresponding to both 919 directions of a bi-directional LSP fail. The control channel 920 connecting two nodes is indicated with a "c". 922 6.4. Channel Activation Indication 924 The ChannelStatus message may also be used to notify an LMP neighbor 925 that the data link should be actively monitored. This is called 926 Channel Activation Indication. This is particularly useful in 927 networks with transparent nodes where the status of data links may 928 need to be triggered using control channel messages. For example, if 929 a data link is pre-provisioned and the physical link fails after 930 verification and before inserting user traffic, a mechanism is 931 needed to indicate the data link should be active or the failure may 932 not be able to be detected. 934 The ChannelStatus message is used to indicate that a channel or 935 group of channels are now active. The ChannelStatusAck message MUST 936 be transmitted upon receipt of a ChannelStatus message. When a 937 ChannelStatus message is received, the corresponding data link(s) 938 MUST be put into the Active state. If upon putting them into the 939 Active state, a failure is detected, the ChannelStatus message 940 SHOULD be transmitted as described in Section 6.2. 942 6.5. Channel Deactivation Indication 944 The ChannelStatus message may also be used to notify an LMP neighbor 945 that the data link no longer needs to be actively monitored. This is 946 the counterpart to the Channel Active Indication. 948 When a ChannelStatus message is received with Channel Deactive 949 Indication, the corresponding data link(s) MUST be taken out of the 950 Active state. 952 7. Message_Id Usage 954 The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP 955 messages to support reliable message delivery. This section 956 describes the usage of these objects. The MESSAGE_ID and 957 MESSAGE_ID_ACK objects contain a Message_Id field. Only one 958 MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP message. 960 For control channel specific messages, the Message_Id field is 961 within the scope of the CCID. For TE link specific messages, the 962 Message_Id field is within the scope of the LMP adjacency. 964 The Message_Id field of the MESSAGE_ID object contains a generator 965 selected value. This value MUST be monotonically increasing. A value 966 is considered to be previously used when it has been sent in an LMP 967 message with the same CCID (for control channel specific messages) 968 or LMP adjacency (for TE Link specific messages). The Message_Id 969 field of the MESSAGE_ID_ACK object contains the Message_Id field of 970 the message being acknowledged. 972 Unacknowledged messages sent with the MESSAGE_ID object SHOULD be 973 retransmitted until the message is acknowledged or until a retry 974 limit is reached (see also Section 10). 976 Note that the 32-bit Message_Id value MAY wrap. The following 977 expression may be used to test if a newly received Message_Id value 978 is less than a previously received value: 980 If ((int) old_id � (int) new_id > 0) { 981 New value is less than old value; 982 } 984 Nodes processing incoming messages SHOULD check to see if a newly 985 received message is out of order and can be ignored. Out-of-order 986 messages can be identified by examining the value in the Message_Id 987 field. 989 If the message is a Config message, and the Message_Id value is less 990 than the largest Message_Id value previously received from the 991 sender for the CCID, then the message SHOULD be treated as being out 992 of order. 994 If the message is a LinkSummary message and the Message_Id value is 995 less than the largest Message_Id value previously received from the 996 sender for the TE Link, then the message SHOULD be treated as being 997 out of order. 999 If the message is a ChannelStatus message and the Message_Id value 1000 is less than the largest Message_Id value previously received from 1001 the sender for the specified TE link, then the receiver SHOULD check 1002 the Message_Id value previously received for the state of each data 1003 channel included in the ChannelStatus message. If the Message_Id 1004 value is greater than the most recently received Message_Id value 1005 associated with at least one of the data channels included in the 1006 message, the message MUST NOT be treated as out of order; otherwise 1007 the message SHOULD be treated as being out of order. However, the 1008 state of any data channel MUST NOT be updated if the Message_Id 1009 value is less than the most recently received Message_Id value 1010 associated with the data channel. 1012 All other messages MUST NOT be treated as out-of-order. 1014 8. Graceful Restart 1016 This section describes the mechanism to resynchronize the LMP state 1017 after a control plane restart. A control plane restart may occur 1018 when bringing up the first control channel after an LMP adjacency 1019 has failed, or as a result of an LMP component restart. The latter 1020 is detected by setting the "LMP Restart" bit in the Common Header of 1021 the LMP messages. When the control plane fails due to the loss of 1022 the control channel (rather than an LMP component restart), the LMP 1023 Link information should be retained. It is possible that a node may 1024 be capable of retaining the LMP Link information across an LMP 1025 component restart. However, in both cases the status of the data 1026 channels MUST be synchronized. 1028 It is assumed the Local Interface Ids remain stable across a control 1029 plane restart. 1031 After the control plane of a node restarts, the control channel(s) 1032 must be re-established using the procedures of Section 3.1. 1034 If the control plane failure was the result of an LMP component 1035 restart, then the "LMP Restart" flag MUST be set in LMP messages 1036 until a Hello message is received with the RcvSeqNum equal to the 1037 local TxSeqNum. This indicates that the control channel is UP and 1038 the LMP neighbor has detected the restart. 1040 The following assumes that the LMP component restart only occurred 1041 on one end of the TE Link. If the LMP component restart occurred on 1042 both ends of the TE Link, the normal procedures for LinkSummary 1043 should be used, as described in Section 4. 1045 Once a control channel is UP, the LMP neighbor MUST send a 1046 LinkSummary message for each TE Link across the adjacency. All the 1047 objects of the LinkSummary message MUST have the N-bit set to 0 1048 indicating that the parameters are non-negotiable. This provides the 1049 local/remote Link Id and Interace Id mappings, the associated 1050 Link/Data channel parameters, and indication of which data links are 1051 currently allocated to user traffic. When a node receives the 1052 LinkSummary message, it checks its local configuration. If the node 1053 is capable of retaining the LMP Link information across a restart, 1054 it must process the LinkSummary message as described in Section 4 1055 with the exception that the allocated/deallocated flag of the 1056 DATA_LINK object received in the LinkSummary message MUST take 1057 precedence over any local value. If, however, the node was not 1058 capable of retaining the LMP Link information across a restart, the 1059 node MUST accept the Link/Data channel parameters of the received 1060 LinkSummary message and respond with a LinkSummaryAck message. 1062 Upon completion of the LinkSummary exchange, the node that has 1063 restarted the control plane SHOULD send a ChannelStatusRequest 1064 message for that TE link. The node SHOULD also verify the 1065 connectivity of all unallocated data channels. 1067 9. Addressing 1069 All LMP messages are sent directly over IP (except, in some cases, 1070 the Test messages are limited by the transport mechanism for in-band 1071 messaging). The destination address of the IP packet MAY be either 1072 the address learned in the Configuration procedure (i.e., the Source 1073 IP address found in the IP header of the received Config message), 1074 an IP address configured on the remote node, or the node ID. The 1075 Config message is an exception as described below. 1077 The manner in which a Config message is addressed may depend on the 1078 signaling transport mechanism. When the transport mechanism is a 1079 point-to-point link, Config messages SHOULD be sent to the Multicast 1080 address (224.0.0.1). Otherwise, Config messages MUST be sent to an 1081 IP address on the neighboring node. This may be configured at both 1082 ends of the control channel or may be automatically discovered. 1084 10. Exponential Back-off Procedures 1086 This section is based on [RFC2961] and provides exponential backup 1087 procedures for message retransmission. Implementations MUST use the 1088 described procedures or their equivalent. 1090 10.1. Operation 1092 The following operation is one possible mechanism for exponential 1093 back-off retransmission of unacknowledged LMP messages. The sending 1094 node retransmits the message until an acknowledgement message is 1095 received or until a retry limit is reached. When the sending node 1096 receives the acknowledgement, retransmission of the message is 1097 stopped. The interval between message retransmission is governed by 1098 a rapid retransmission timer. The rapid retransmission timer starts 1099 at a small interval and increases exponentially until it reaches a 1100 threshold. 1102 The following time parameters are useful to characterize the 1103 procedures: 1105 Rapid retransmission interval Ri: 1107 Ri is the initial retransmission interval for unacknowledged 1108 messages. After sending the message for the first time, the 1109 sending node will schedule a retransmission after Ri 1110 milliseconds. 1112 Rapid retry limit Rl: 1114 Rl is the maximum number of times a message will be transmitted 1115 without being acknowledged. 1117 Increment value Delta: 1119 Delta governs the speed with which the sender increases the 1120 retransmission interval. The ratio of two successive 1121 retransmission intervals is (1 + Delta). 1123 Suggested default values for an initial retransmission interval (Ri) 1124 of 500ms, a power of 2 exponential back-off (Delta = 1) and a retry 1125 limit of 3. 1127 10.2. Retransmission Algorithm 1129 After a node transmits a message requiring acknowledgement, it 1130 should immediately schedule a retransmission after Ri seconds. If a 1131 corresponding acknowledgement message is received before Ri seconds, 1132 then message retransmission SHOULD be canceled. Otherwise, it will 1133 retransmit the message after (1+Delta)*Ri seconds. The 1134 retransmission will continue until either an appropriate 1135 acknowledgement message is received or the rapid retry limit, Rl, 1136 has been reached. 1138 A sending node can use the following algorithm when transmitting a 1139 message that requires acknowledgement: 1141 Prior to initial transmission, initialize Rk = Ri and Rn = 0. 1143 while (Rn++ < Rl) { 1144 transmit the message; 1145 wake up after Rk milliseconds; 1146 Rk = Rk * (1 + Delta); 1147 } 1148 /* acknowledged message or no reply from receiver and Rl 1149 reached*/ 1150 do any needed clean up; 1151 exit; 1153 Asynchronously, when a sending node receives a corresponding 1154 acknowledgment message, it will change the retry count, Rn, to Rl. 1156 Note that the transmitting node does not advertise or negotiate the 1157 use of the described exponential back-off procedures in the Config 1158 or LinkSummary messages. 1160 11. IANA Considerations 1162 LMP defines the following name spaces that require management: 1164 - Msg Type Name Space. 1165 - LMP Object Class name space. 1166 - LMP Object Class type (C-Type). These are unique within the Object 1167 Class. 1169 Following the policies outlined in [IANA], Msg Type, Object Class, 1170 and Class type are allocated through an IETF Consensus action. 1172 12. LMP Finite State Machines 1174 12.1. Control Channel FSM 1176 The control channel FSM defines the states and logics of operation 1177 of an LMP control channel. The description of FSM state transitions 1178 and associated actions is given in Section 3. 1180 12.1.1. Control Channel States 1182 A control channel can be in one of the states described below. Every 1183 state corresponds to a certain condition of the control channel and 1184 is usually associated with a specific type of LMP message that is 1185 periodically transmitted to the far end. 1187 Down: This is the initial control channel state. In this 1188 state, no attempt is being made to bring the control 1189 channel up and no LMP messages are sent. The control 1190 channel parameters should be set to the initial values. 1192 ConfigSnd: The control channel is in the parameter negotiation 1193 state. In this state the node periodically sends a 1194 Config message, and is expecting the other side to 1195 reply with either a ConfigAck or ConfigNack message. 1196 The FSM does not transition into the Active state until 1197 the remote side positively acknowledges the parameters. 1199 ConfRcv: The control channel is in the parameter negotiation 1200 state. In this state, the node is waiting for 1201 acceptable configuration parameters from the remote 1202 side. Once such parameters are received and 1203 acknowledged, the FSM can transition to the Active 1204 state. 1206 Active: In this state the node periodically sends a Hello 1207 message and is waiting to receive a valid Hello 1208 message. Once a valid Hello message is received, it can 1209 transition to the UP state. 1211 Up: The CC is in an operational state. The node receives 1212 valid Hello messages and sends Hello messages. 1214 GoingDown: A CC may go into this state because of administrative 1215 action. While a CC is in this state, the node sets the 1216 ControlChannelDown bit in all the messages it sends. 1218 12.1.2. Control Channel Events 1220 Operation of the LMP control channel is described in terms of FSM 1221 states and events. Control channel Events are generated by the 1222 underlying protocols and software modules, as well as by the packet 1223 processing routines and FSMs of associated TE links. Every event has 1224 its number and a symbolic name. Description of possible control 1225 channel events is given below. 1227 1 : evBringUp: This is an externally triggered event indicating 1228 that the control channel negotiation should begin. 1229 This event, for example, may be triggered by an 1230 operator command, by the successful completion of 1231 a control channel bootstrap procedure, or by 1232 configuration. Depending on the configuration, 1233 this will trigger either 1234 1a) the sending of a Config message, 1235 1b) a period of waiting to receive a Config 1236 message from the remote node. 1238 2 : evCCDn: This event is generated when there is indication 1239 that the control channel is no longer available. 1241 3 : evConfDone: This event indicates a ConfigAck message has been 1242 received, acknowledging the Config parameters. 1244 4 : evConfErr: This event indicates a ConfigNack message has been 1245 received, rejecting the Config parameters. 1247 5 : evNewConfOK: New Config message was received from neighbor and 1248 positively Acknowledged. 1250 6 : evNewConfErr: New Config message was received from neighbor and 1251 rejected with a ConfigNack message. 1253 7 : evContenWin: New Config message was received from neighbor at 1254 the same time a Config message was sent to the 1255 neighbor. The Local node wins the contention. As a 1256 result, the received Config message is ignored. 1258 8 : evContenLost: New Config message was received from neighbor at 1259 the same time a Config message was sent to the 1260 neighbor. The Local node loses the contention. 1261 8a) The Config message is positively 1262 Acknowledged. 1263 8b) The Config message is negatively 1264 Acknowledged. 1266 9 : evAdminDown: The administrator has requested that the control 1267 channel is brought down administratively. Hello 1268 messages (with ControlChannelDown flag set) SHOULD 1269 be sent for HelloDeadInterval seconds or until an 1270 LMP message is received over the control channel 1271 with the ControlChannelDown flag set. 1273 10: evNbrGoesDn: A packet with ControlChannelDown flag is received 1274 from the neighbor. 1276 11: evHelloRcvd: A Hello packet with expected SeqNum has been 1277 received. 1279 12: evHoldTimer: The HelloDeadInterval timer has expired indicating 1280 that no Hello packet has been received. This moves 1281 the control channel back into the Negotiation 1282 state, and depending on the local configuration, 1283 this will trigger either 1284 12a) the sending of periodic Config messages, 1285 12b) a period of waiting to receive Config 1286 messages from the remote node. 1288 13: evSeqNumErr: A Hello with unexpected SeqNum received and 1289 discarded. 1291 14: evReconfig: Control channel parameters have been reconfigured 1292 and require renegotiation. 1294 15: evConfRet: A retransmission timer has expired and a Config 1295 message is resent. 1297 16: evHelloRet: The HelloInterval timer has expired and a Hello 1298 packet is sent. 1300 17: evDownTimer: A timer has expired and no messages have been 1301 received with the ControlChannelDown flag set. 1303 12.1.3. Control Channel FSM Description 1305 Figure 3 illustrates operation of the control channel FSM 1306 in a form of FSM state transition diagram. 1308 +--------+ 1309 +----------------->| |<--------------+ 1310 | +--------->| Down |<----------+ | 1311 | |+---------| |<-------+ | | 1312 | || +--------+ | | | 1313 | || | ^ 2,9| 2| 2| 1314 | ||1b 1a| | | | | 1315 | || v |2,9 | | | 1316 | || +--------+ | | | 1317 | || +->| |<------+| | | 1318 | || 4,7,| |ConfSnd | || | | 1319 | || 14,15+--| |<----+ || | | 1320 | || +--------+ | || | | 1321 | || 3,8a| | | || | | 1322 | || +---------+ |8b 14,12a| || | | 1323 | || | v | || | | 1324 | |+-|------>+--------+ | || | | 1325 | | | +->| |-----|-|+ | | 1326 | | |6,14| |ConfRcv | | | | | 1327 | | | +--| |<--+ | | | | 1328 | | | +--------+ | | | | | 1329 | | | 5| ^ | | | | | 1330 | | +---------+ | | | | | | | 1331 | | | | | | | | | | 1332 | | v v |6,12b | | | | | 1333 | |10 +--------+ | | | | | 1334 | +----------| | | | | | | 1335 | | +--| Active |---|-+ | | | 1336 10,17| | 5,16| | |-------|---+ | 1337 +-------+ 9 | 13 +->| | | | | 1338 | Going |<--|----------+--------+ | | | 1339 | Down | | 11| ^ | | | 1340 +-------+ | | |5 | | | 1341 ^ | v | 6,12b| | | 1342 |9 |10 +--------+ | |12a,14 | 1343 | +----------| |---+ | | 1344 | | Up |-------+ | 1345 +------------------| |---------------+ 1346 +--------+ 1347 | ^ 1348 | | 1349 +---+ 1350 11,13,16 1351 Figure 3: Control Channel FSM 1353 Event evCCDn always forces the FSM to the Down State. Events 1354 evHoldTimer evReconfig always force the FSM to the Negotiation state 1355 (either ConfigSnd or ConfigRcv). 1357 12.2. TE Link FSM 1359 The TE Link FSM defines the states and logics of operation of an LMP 1360 TE Link. 1362 12.2.1. TE Link States 1364 An LMP TE link can be in one of the states described below. Every 1365 state corresponds to a certain condition of the TE link and is 1366 usually associated with a specific type of LMP message that is 1367 periodically transmitted to the far end via the associated control 1368 channel or in-band via the data links. 1370 Down: There are no data links allocated to the TE link. 1372 Init: Data links have been allocated to the TE link, but the 1373 configuration has not yet been synchronized with the LMP 1374 neighbor. 1376 Up: This is the normal operational state of the TE link. At 1377 least one primary CC is required to be operational 1378 between the nodes sharing the TE link. 1380 Degraded: In this state, all primary CCs are down, but the TE link 1381 still includes some data links that are allocated to 1382 data traffic. 1384 12.2.2. TE Link Events 1386 Operation of the LMP TE link is described in terms of FSM states and 1387 events. TE Link events are generated by the packet processing 1388 routines and by the FSMs of the associated primary control 1389 channel(s) and the data links. Every event has its number and a 1390 symbolic name. Description of possible control channel events is 1391 given below. 1393 1 : evDCUp: One or more data channels have been enabled and 1394 assigned to the TE Link. 1395 2 : evSumAck: LinkSummary message received and positively 1396 acknowledged. 1397 3 : evSumNack: LinkSummary message received and negatively 1398 acknowledged. 1399 4 : evRcvAck: LinkSummaryAck message received acknowledging 1400 the TE Link Configuration. 1401 5 : evRcvNack: LinkSummaryNack message received. 1402 6 : evSumRet: Retransmission timer has expired and LinkSummary 1403 message is resent. 1404 7 : evCCUp: First active control channel goes up. 1406 8 : evCCDown: Last active control channel goes down. 1407 9 : evDCDown: Last data channel of TE Link has been removed. 1409 12.2.3. TE Link FSM Description 1411 Figure 4 illustrates operation of the LMP TE Link FSM in a form of 1412 FSM state transition diagram. 1414 3,7,8 1415 +--+ 1416 | | 1417 | v 1418 +--------+ 1419 | | 1420 +------------>| Down |<---------+ 1421 | | | | 1422 | +--------+ | 1423 | | ^ | 1424 | 1| |9 | 1425 | v | | 1426 | +--------+ | 1427 | | |<-+ | 1428 | | Init | |3,5,6 |9 1429 | | |--+ 7,8 | 1430 9| +--------+ | 1431 | | | 1432 | 2,4| | 1433 | v | 1434 +--------+ 7 +--------+ | 1435 | |------>| |----------+ 1436 | Deg | | Up | 1437 | |<------| | 1438 +--------+ 8 +--------+ 1439 | ^ 1440 | | 1441 +--+ 1442 2,3,4,5,6 1444 Figure 4: LMP TE Link FSM 1446 In the above FSM, the sub-states that may be implemented when the 1447 link verification procedure is used have been omitted. 1449 12.3. Data Link FSM 1451 The data link FSM defines the states and logics of operation of a 1452 port or component link within an LMP TE link. Operation of a data 1453 link is described in terms of FSM states and events. Data-bearing 1454 links can either be in the active (transmitting) mode, where Test 1455 messages are transmitted from them, or the passive (receiving) mode, 1456 where Test messages are received through them. For clarity, separate 1457 FSMs are defined for the active/passive data-bearing links; however, 1458 a single set of data link states and events are defined. 1460 12.3.1. Data Link States 1462 Any data link can be in one of the states described below. Every 1463 state corresponds to a certain condition of the TE link. 1465 Down: The data link has not been put in the resource pool 1466 (i.e., the link is not �in service� 1468 Test: The data link is being tested. An LMP Test message is 1469 periodically sent through the link. 1471 PasvTest: The data link is being checked for incoming test 1472 messages. 1474 Up/Free: The link has been successfully tested and is now put 1475 in the pool of resources (in-service). The link has 1476 not yet been allocated to data traffic. 1478 Up/Allocated: The link is UP and has been allocated for data 1479 traffic. 1481 12.3.2. Data Link Events 1483 Data bearing link events are generated by the packet processing 1484 routines and by the FSMs of the associated control channel and the 1485 TE link. Every event has its number and a symbolic name. Description 1486 of possible data link events is given below: 1488 1 :evCCUp: CC has gone up. 1489 2 :evCCDown: LMP neighbor connectivity is lost. This indicates 1490 the last LMP control channel has failed between 1491 neighboring nodes. 1492 3 :evStartTst: This is an external event that triggers the sending 1493 of Test messages over the data bearing link. 1495 4 :evStartPsv: This is an external event that triggers the 1496 listening for Test messages over the data bearing 1497 link. 1499 5 :evTestOK: Link verification was successful and the link can 1500 be used for path establishment. 1501 (a) This event indicates the Link Verification 1502 procedure (see Section 5) was successful 1503 for this data link and a TestStatusSuccess 1504 message was received over the control 1505 channel. 1506 (b) This event indicates the link is ready for 1507 path establishment, but the Link 1508 Verification procedure was not used. For 1509 in-band signaling of the control channel, 1510 the control channel establishment may be 1511 sufficient to verify the link. 1512 6 :evTestRcv: Test message was received over the data port and a 1513 TestStatusSuccess message is transmitted over the 1514 control channel. 1515 7 :evTestFail: Link verification returned negative results. This 1516 could be because (a) a TestStatusFailure message 1517 was received, or (b) the Verification procedure has 1518 ended without receiving a TestStatusSuccess or 1519 TestStatusFailure message for the data link. 1520 8 :evPsvTestFail:Link verification returned negative results. This 1521 indicates that a Test message was not detected and 1522 either (a) the VerifyDeadInterval has expired or 1523 (b) the Verification procedure has ended and the 1524 VerifyDeadInterval has not yet expired. 1525 9 :evLnkAlloc: The data link has been allocated. 1526 10:evLnkDealloc: The data link has been deallocated. 1527 11:evTestRet: A retransmission timer has expired and the Test 1528 message is resent. 1529 12:evSummaryFail:The LinkSummary did not match for this data port. 1530 13:evLocalizeFail:A Failure has been localized to this data link. 1531 14:evdcDown: The data channel is no longer available. 1533 12.3.3. Active Data Link FSM Description 1535 Figure 5 illustrates operation of the LMP active data link FSM in a 1536 form of FSM state transition diagram. 1538 +------+ 1539 | |<-------+ 1540 +--------->| Down | | 1541 | +----| |<-----+ | 1542 | | +------+ | | 1543 | |5b 3| ^ | | 1544 | | | |7 | | 1545 | | v | | | 1546 | | +------+ | | 1547 | | | |<-+ | | 1548 | | | Test | |11 | | 1549 | | | |--+ | | 1550 | | +------+ | | 1551 | | 5a| 3^ | | 1552 | | | | | | 1553 | | v | | | 1554 |12 | +---------+ | | 1555 | +-->| |14 | | 1556 | | Up/Free |----+ | 1557 +---------| | | 1558 +---------+ | 1559 9| ^ | 1560 | | | 1561 v |10 | 1562 +---------+ | 1563 | |13 | 1564 |Up/Alloc |------+ 1565 | | 1566 +---------+ 1568 Figure 5: Active LMP Data Link FSM 1570 12.3.4. Passive Data Link FSM Description 1572 Figure 6 illustrates operation of the LMP passive data link FSM in a 1573 form of FSM state transition diagram. 1575 +------+ 1576 | |<------+ 1577 +---------->| Down | | 1578 | +-----| |<----+ | 1579 | | +------+ | | 1580 | |5b 4| ^ | | 1581 | | | |8 | | 1582 | | v | | | 1583 | | +----------+ | | 1584 | | | PasvTest | | | 1585 | | +----------+ | | 1586 | | 6| 4^ | | 1587 | | | | | | 1588 | | v | | | 1589 |12 | +---------+ | | 1590 | +--->| Up/Free |14 | | 1591 | | |---+ | 1592 +----------| | | 1593 +---------+ | 1594 9| ^ | 1595 | | | 1596 v |10 | 1597 +---------+ | 1598 | |13 | 1599 |Up/Alloc |-----+ 1600 | | 1601 +---------+ 1603 Figure 6: Passive LMP Data Link FSM 1605 13. LMP Message Formats 1607 All LMP messages are IP encoded (except, in some cases, the Test 1608 messages are limited by the transport mechanism for in-band 1609 messaging) and run over UDP with port number xxx - TBA (to be 1610 assigned) by IANA. 1612 13.1. Common Header 1614 In addition to the standard IP header, all LMP messages (except, in 1615 some cases, the Test messages which are limited by the transport 1616 mechanism for in-band messaging) have the following common header: 1618 0 1 2 3 1619 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 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | Vers | (Reserved) | Flags | Msg Type | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | LMP Length | Checksum | 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 Vers: 4 bits 1628 Protocol version number. This is version 1. 1630 Flags: 8 bits. The following values are defined. All other values 1631 are reserved. 1633 0x01: ControlChannelDown 1635 0x02: LMP Restart 1637 This bit is set to indicate the LMP component has 1638 restarted. This flag may be reset to 0 when a Hello 1639 message is received with RcvSeqNum equal to the local 1640 TxSeqNum. 1642 Msg Type: 8 bits. The following values are defined. All other values 1643 are reserved. 1645 1 = Config 1647 2 = ConfigAck 1649 3 = ConfigNack 1651 4 = Hello 1653 5 = BeginVerify 1655 6 = BeginVerifyAck 1656 7 = BeginVerifyNack 1658 8 = EndVerify 1660 9 = EndVerifyAck 1662 10 = Test 1664 11 = TestStatusSuccess 1666 12 = TestStatusFailure 1668 13 = TestStatusAck 1670 14 = LinkSummary 1672 15 = LinkSummaryAck 1674 16 = LinkSummaryNack 1676 17 = ChannelStatus 1678 18 = ChannelStatusAck 1680 19 = ChannelStatusRequest 1682 20 = ChannelStatusResponse 1684 All of the messages are sent over the control channel EXCEPT 1685 the Test message, which is sent over the data link that is 1686 being tested. 1688 LMP Length: 16 bits 1690 The total length of this LMP message in bytes, including the 1691 common header and any variable-length objects that follow. 1693 Checksum: 16 bits 1695 The standard IP checksum of the entire contents of the LMP 1696 message, starting with the LMP message header. This checksum is 1697 calculated as the 16-bit one's complement of the one's 1698 complement sum of all the 16-bit words in the packet. If the 1699 packet's length is not an integral number of 16-bit words, the 1700 packet is padded with a byte of zero before calculating the 1701 checksum. 1703 13.2. LMP Object Format 1705 LMP messages are built using objects. Each object is identified by 1706 its Object Class and Class-type. Each object has a name, which is 1707 always capitalized in this document. LMP objects can be either 1708 negotiable or non-negotiable (identified by the N bit in the object 1709 header). Negotiable objects can be used to let the devices agree on 1710 certain values. Non-negotiable objects are used for announcement of 1711 specific values that do not need or do not allow negotiation. 1713 The format of the LMP object is as follows: 1715 0 1 2 3 1716 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 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 |N| C-Type | Class | Length | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | | 1721 // (object contents) // 1722 | | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 N: 1 bit 1727 The N flag indicates if the object is negotiable (N=1) or non- 1728 negotiable (N=0). 1730 C-Type: 7 bits 1732 Class-type, unique within an Object Class. Values are defined 1733 in Section 14. 1735 Class: 8 bits 1737 The Class indicates the object type. Each object has a name, 1738 which is always capitalized in this document. 1740 Length: 16 bits 1742 The Length field indicates the length of the object in bytes, 1743 including the N, C-Type, Class, and Length fields. 1745 13.3. Parameter Negotiation Messages 1747 13.3.1. Config Message (Msg Type = 1) 1749 The Config message is used in the control channel negotiation phase 1750 of LMP. The contents of the Config message are built using LMP 1751 objects. The format of the Config message is as follows: 1753 ::= 1754 1756 The above transmission order SHOULD be followed. 1758 The MESSAGE_ID is within the scope of the CCID. 1760 The Config message MUST be periodically transmitted until (1) it 1761 receives a ConfigAck or ConfigNack message, (2) a timeout expires 1762 and no ConfigAck or ConfigNack message has been received, or (3) it 1763 receives a Config message from the remote node and has lost the 1764 contention (e.g., the Node Id of the remote node is higher than the 1765 Node Id of the local node). Both the retransmission interval and the 1766 timeout period are local configuration parameters. 1768 13.3.2. ConfigAck Message (Msg Type = 2) 1770 The ConfigAck message is used to acknowledge receipt of the Config 1771 message and indicate agreement on all parameters. 1773 ::= 1774 1775 1777 The above transmission order SHOULD be followed. 1779 The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID 1780 objects MUST be obtained from the Config message being acknowledged. 1782 13.3.3. ConfigNack Message (Msg Type = 3) 1784 The ConfigNack message is used to acknowledge receipt of the Config 1785 message and indicate disagreement on non-negotiable parameters or 1786 propose other values for negotiable parameters. Parameters where 1787 agreement was reached MUST NOT be included in the ConfigNack 1788 Message. The format of the ConfigNack message is as follows: 1790 ::= 1791 1792 1794 The above transmission order SHOULD be followed. 1796 The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID 1797 objects MUST be obtained from the Config message being negatively 1798 acknowledged. 1800 It is possible that multiple parameters may be invalid in the Config 1801 message. 1803 If a negotiable CONFIG object is included in the ConfigNack message, 1804 it MUST include acceptable values for the parameters. 1806 If the ConfigNack message includes CONFIG objects for non-negotiable 1807 parameters, they MUST be copied from the CONFIG objects received in 1808 the Config message. 1810 If the ConfigNack message is received and only includes CONFIG 1811 objects that are negotiable, then a new Config message SHOULD be 1812 sent. The values in the CONFIG object of the new Config message 1813 SHOULD take into account the acceptable values included in the 1814 ConfigNack message. 1816 13.4. Hello Message (Msg Type = 4) 1818 The format of the Hello message is as follows: 1820 ::= 1822 The above transmission order SHOULD be followed. 1824 The Hello message MUST be periodically transmitted at least once 1825 every HelloInterval msec. If no Hello message is received within the 1826 HelloDeadInterval, the control channel is assumed to have failed. 1828 13.5. Link Verification 1830 13.5.1. BeginVerify Message (Msg Type = 5) 1832 The BeginVerify message is sent over the control channel and is used 1833 to initiate the link verification process. The format is as follows: 1835 ::= 1836 [] 1837 1839 The above transmission order SHOULD be followed. 1841 To limit the scope of Link Verification to a particular TE Link, the 1842 LOCAL_LINK_ID MUST be non-zero. If this field is zero, the data 1843 links can span multiple TE links and/or they may comprise a TE link 1844 that is yet to be configured. In the special case where the 1845 LOCAL_LINK_ID field is zero, the "Verify all Links" flag of the 1846 BEGIN_VERIFY object is used to distinguish between data links that 1847 span multiple TE links and those that have not yet been assigned to 1848 a TE link. 1850 The REMOTE_LINK_ID may be included if the local/remote Link Id 1851 mapping is known. 1853 The REMOTE_LINK_ID MUST be non-zero if included. 1855 The BeginVerify message MUST be periodically transmitted until (1) 1856 the node receives either a BeginVerifyAck or BeginVerifyNack message 1857 to accept or reject the verify process or (2) a timeout expires and 1858 no BeginVerifyAck or BeginVerifyNack message has been received. Both 1859 the retransmission interval and the timeout period are local 1860 configuration parameters. 1862 13.5.2. BeginVerifyAck Message (Msg Type = 6) 1864 When a BeginVerify message is received and Test messages are ready 1865 to be processed, a BeginVerifyAck message MUST be transmitted. 1867 ::= [] 1868 1869 1871 The above transmission order SHOULD be followed. 1873 The LOCAL_LINK_ID may be included if the local/remote Link Id 1874 mapping is known or learned through the BeginVerify message. 1876 The LOCAL_LINK_ID MUST be non-zero if included. 1878 The contents of the MESSAGE_ID_ACK object MUST be obtained from the 1879 BeginVerify message being acknowledged. 1881 The VERIFY_ID object contains a node-unique value that is assigned 1882 by the generator of the BeginVerifyAck message. This value is used 1883 to uniquely identify the Verification process from multiple LMP 1884 neighbors and/or parallel Test procedures between the same LMP 1885 neighbors. 1887 13.5.3. BeginVerifyNack Message (Msg Type = 7) 1889 If a BeginVerify message is received and a node is unwilling or 1890 unable to begin the Verification procedure, a BeginVerifyNack 1891 message MUST be transmitted. 1893 ::= [] 1894 1896 The above transmission order SHOULD be followed. 1898 The contents of the MESSAGE_ID_ACK object MUST be obtained from the 1899 BeginVerify message being negatively acknowledged. 1901 If the Verification process is not supported, the ERROR_CODE MUST 1902 indicate "Link Verification Procedure not supported". 1904 If Verification is supported, but the node unable to begin the 1905 procedure, the ERROR_CODE MUST indicate "Unwilling to verify". If a 1906 BeginVerifyNack message is received with such an ERROR_CODE, the 1907 node that originated the BeginVerify SHOULD schedule a BeginVerify 1908 retransmission after Rf seconds, where Rf is a locally defined 1909 parameter. 1911 If the Verification Transport mechanism is not supported, the 1912 ERROR_CODE MUST indicate "Unsupported verification transport 1913 mechanism". 1915 If remote configuration of the TE Link Id is not supported and the 1916 REMOTE_LINK_ID object (included in the BeginVerify message) does not 1917 match any configured values, the ERROR_CODE MUST indicate "TE Link 1918 Id configuration error". 1920 The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 1. 1922 13.5.4. EndVerify Message (Msg Type = 8) 1924 The EndVerify message is sent over the control channel and is used 1925 to terminate the link verification process. The EndVerify message 1926 may be sent at any time the initiating node desires to end the 1927 Verify procedure. The format is as follows: 1929 ::= 1931 The above transmission order SHOULD be followed. 1933 The EndVerify message will be periodically transmitted until (1) an 1934 EndVerifyAck message has been received or (2) a timeout expires and 1935 no EndVerifyAck message has been received. Both the retransmission 1936 interval and the timeout period are local configuration parameters. 1938 13.5.5. EndVerifyAck Message (Msg Type =9) 1940 The EndVerifyAck message is sent over the control channel and is 1941 used to acknowledge the termination of the link verification 1942 process. The format is as follows: 1944 ::= 1945 1947 The above transmission order SHOULD be followed. 1949 The contents of the MESSAGE_ID_ACK object MUST be obtained from the 1950 EndVerify message being acknowledged. 1952 13.5.6. Test Message (Msg Type = 10) 1954 The Test message is transmitted over the data link and is used to 1955 verify its physical connectivity. Unless explicitly stated in the 1956 Verify Transport Mechanism description for the BEGIN_VERIFY class, 1957 this is transmitted as an IP packet with payload format as follows: 1959 ::= 1961 The above transmission order SHOULD be followed. 1963 Note that this message is sent over a data link and NOT over the 1964 control channel. The transport mechanism for the Test message is 1965 negotiated using Verify Transport Mechanism field of the 1966 BEGIN_VERIFY object and the Verify Transport Response field of the 1967 BEGIN_VERIFY_ACK object (see Sections 14.8 and 14.9). 1969 The local (transmitting) node sends a given Test message 1970 periodically (at least once every VerifyInterval ms) on the 1971 corresponding data link until (1) it receives a correlating 1972 TestStatusSuccess or TestStatusFailure message on the control 1973 channel from the remote (receiving) node or (2) all active control 1974 channels between the two nodes have failed. The remote node will 1975 send a given TestStatus message periodically over the control 1976 channel until it receives either a correlating TestStatusAck message 1977 or an EndVerify message is received over the control channel. 1979 13.5.7. TestStatusSuccess Message (Msg Type = 11) 1981 The TestStatusSuccess message is transmitted over the control 1982 channel and is used to transmit the mapping between the local 1983 Interface Id and the Interface Id that was received in the Test 1984 message. 1986 ::= 1987 1988 1990 The above transmission order SHOULD be followed. 1992 The contents of the REMOTE_INTERFACE_ID object MUST be obtained from 1993 the corresponding Test message being positively acknowledged. 1995 13.5.8. TestStatusFailure Message (Msg Type = 12) 1997 The TestStatusFailure message is transmitted over the control 1998 channel and is used to indicate that the Test message was not 1999 received. 2001 ::= 2002 2004 The above transmission order SHOULD be followed. 2006 13.5.9. TestStatusAck Message (Msg Type = 13) 2008 The TestStatusAck message is used to acknowledge receipt of the 2009 TestStatusSuccess or TestStatusFailure messages. 2011 ::= 2012 2014 The above transmission order SHOULD be followed. 2016 The contents of the MESSAGE_ID_ACK object MUST be obtained from the 2017 TestStatusSuccess or TestStatusFailure message being acknowledged. 2019 13.6. Link Summary Messages 2021 13.6.1. LinkSummary Message (Msg Type = 14) 2023 The LinkSummary message is used to synchronize the Interface Ids and 2024 correlate the properties of the TE link. The format of the 2025 LinkSummary message is as follows: 2027 ::= 2028 [...] 2030 The above transmission order SHOULD be followed. 2032 The LinkSummary message can be exchanged at any time a link is not 2033 in the Verification process. The LinkSummary message MUST be 2034 periodically transmitted until (1) the node receives a 2035 LinkSummaryAck or LinkSummaryNack message or (2) a timeout expires 2036 and no LinkSummaryAck or LinkSummaryNack message has been received. 2037 Both the retransmission interval and the timeout period are local 2038 configuration parameters. 2040 13.6.2. LinkSummaryAck Message (Msg Type = 15) 2042 The LinkSummaryAck message is used to indicate agreement on the 2043 Interface Id synchronization and acceptance/agreement on all the 2044 link parameters. It is on the reception of this message that the 2045 local node makes the TE Link Id associations. 2047 ::= 2049 The above transmission order SHOULD be followed. 2051 13.6.3. LinkSummaryNack Message (Msg Type = 16) 2053 The LinkSummaryNack message is used to indicate disagreement on non- 2054 negotiated parameters or propose other values for negotiable 2055 parameters. Parameters where agreement was reached MUST NOT be 2056 included in the LinkSummaryNack message. 2058 ::= 2059 [...] 2061 The above transmission order SHOULD be followed. 2063 The DATA_LINK objects MUST include acceptable values for all 2064 negotiable parameters. If the LinkSummaryNack includes DATA_LINK 2065 objects for non-negotiable parameters, they MUST be copied from the 2066 DATA_LINK objects received in the LinkSummary message. 2068 If the LinkSummaryNack message is received and only includes 2069 negotiable parameters, then a new LinkSummary message SHOULD be 2070 sent. The values received in the new LinkSummary message SHOULD take 2071 into account the acceptable parameters included in the 2072 LinkSummaryNack message. 2074 The LinkSummaryNack message uses LINK_SUMMARY_ERROR C-Type 2. 2076 13.7. Fault Management Messages 2078 13.7.1. ChannelStatus Message (Msg Type = 17) 2080 The ChannelStatus message is sent over the control channel and is 2081 used to notify an LMP neighbor of the status of a data link. A node 2082 that receives a ChannelStatus message MUST respond with a 2083 ChannelStatusAck message. The format is as follows: 2085 ::= 2086 2088 The above transmission order SHOULD be followed. 2090 If the CHANNEL_STATUS object does not include any Interface Ids, 2091 then this indicates the entire TE Link has failed. 2093 13.7.2. ChannelStatusAck Message (Msg Type = 18) 2095 The ChannelStatusAck message is used to acknowledge receipt of the 2096 ChannelStatus Message. The format is as follows: 2098 ::= 2100 The above transmission order SHOULD be followed. 2102 The contents of the MESSAGE_ID_ACK object MUST be obtained from the 2103 ChannelStatus message being acknowledged. 2105 13.7.3. ChannelStatusRequest Message (Msg Type = 19) 2107 The ChannelStatusRequest message is sent over the control channel 2108 and is used to request the status of one or more data link(s). A 2109 node that receives a ChannelStatusRequest message MUST respond with 2110 a ChannelStatusResponse message. The format is as follows: 2112 ::= 2113 2114 [] 2116 The above transmission order SHOULD be followed. 2118 If the CHANNEL_STATUS_REQUEST object is not included, then the 2119 ChannelStatusRequest is being used to request the status of ALL of 2120 the data link(s) of the TE Link. 2122 13.7.4. ChannelStatusResponse Message (Msg Type = 20) 2124 The ChannelStatusResponse message is used to acknowledge receipt of 2125 the ChannelStatusRequest Message and notify the LMP neighbor of the 2126 status of the data channel(s). The format is as follows: 2128 ::= 2129 2131 The above transmission order SHOULD be followed. 2133 The contents of the MESSAGE_ID_ACK objects MUST be obtained from the 2134 ChannelStatusRequest message being acknowledged. 2136 14. LMP Object Definitions 2138 14.1. CCID (Control Channel ID) Class 2140 Class = 1. 2142 o C-Type = 1, LOCAL_CCID 2144 0 1 2 3 2145 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 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | CC_Id | 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 CC_Id: 32 bits 2152 This MUST be node-wide unique and non-zero. The CC_Id 2153 identifies the control channel of the sender associated with 2154 the message. 2156 This object is non-negotiable. 2158 o C-Type = 2, REMOTE_CCID 2160 0 1 2 3 2161 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 2162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2163 | CC_Id | 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 CC_Id: 32 bits 2168 This identifies the remote node�s CC_Id and MUST be non-zero. 2170 This object is non-negotiable. 2172 14.2. NODE_ID Classes 2174 Class = 2. 2176 o C-Type = 1, LOCAL_NODE_ID Class 2178 0 1 2 3 2179 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 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 | Node_Id (4 bytes) | 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2184 Node_Id: 2186 This identities the node that originated the LMP packet. 2188 This object is non-negotiable. 2190 o C-Type = 2, REMOTE_NODE_ID Class 2192 0 1 2 3 2193 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 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 | Node_Id (4 bytes) | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 Node_Id: 2200 This identities the remote node. 2202 This object is non-negotiable. 2204 14.3. LINK _ID Class 2206 Class = 3 2208 o C-Type = 1, IPv4 LOCAL_LINK_ID 2210 o C-Type = 2, IPv4 REMOTE_LINK_ID 2212 0 1 2 3 2213 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 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 | Link_Id (4 bytes) | 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 o C-Type = 3, IPv6 LOCAL_LINK_ID 2220 o C-Type = 4, IPv6 REMOTE_LINK_ID 2221 0 1 2 3 2222 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 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 | | 2225 + + 2226 | | 2227 + Link_Id (16 bytes) + 2228 | | 2229 + + 2230 | | 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2233 o C-Type = 5, Unnumbered LOCAL_LINK_ID 2235 o C-Type = 6, Unnumbered REMOTE_LINK_ID 2237 0 1 2 3 2238 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 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 | Link_Id (4 bytes) | 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 o C-Type = 7, Reserved for OIF 2245 o C-Type = 8, Reserved for OIF 2247 Link_Id: 2249 For LOCAL_LINK_ID, this identifies the sender�s Link associated 2250 with the message. 2252 For REMOTE_LINK_ID, this identifies the remote node�s Link Id 2253 and MUST be non-zero. 2255 This object is non-negotiable. 2257 14.4. INTERFACE_ID Class 2259 Class = 4 2261 o C-Type = 1, IPv4 LOCAL_INTERFACE_ID 2263 o C-Type = 2, IPv4 REMOTE_INTERFACE_ID 2265 0 1 2 3 2266 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 2267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2268 | Interface_Id (4 bytes) | 2269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 o C-Type = 3, IPv6 LOCAL_INTERFACE_ID 2272 o C-Type = 4, IPv6 REMOTE_INTERFACE_ID 2274 0 1 2 3 2275 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 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | | 2278 + + 2279 | | 2280 + Interface_Id (16 bytes) + 2281 | | 2282 + + 2283 | | 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 o C-Type = 5, Unnumbered LOCAL_INTERFACE_ID 2288 o C-Type = 6, Unnumbered REMOTE_INTERFACE_ID 2290 0 1 2 3 2291 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 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | Interface_Id (4 bytes) | 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 Interface_Id: 2298 For the LOCAL_INTERFACE_ID, this identifies the data link 2299 (either port or component link). This value MUST be node-wide 2300 unique and non-zero. 2302 For the REMOTE_INTERFACE_ID, this identifies the remote node�s 2303 data link (either port or component link). The Interface Id 2304 MUST be non-zero. 2306 This object is non-negotiable. 2308 14.5. MESSAGE_ID Class 2310 Class = 5. 2312 o C-Type=1, MessageId 2314 0 1 2 3 2315 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 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 | Message_Id | 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 Message_Id: 2322 The Message_Id field is used to identify a message. This value 2323 is incremented and only decreases when the value wraps. This is 2324 used for message acknowledgment. 2326 This object is non-negotiable. 2328 o C-Type = 2, MessageIdAck 2330 0 1 2 3 2331 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 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 | Message_Id | 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 Message_Id: 2338 The Message_Id field is used to identify the message being 2339 acknowledged. This value is copied from the MESSAGE_ID object 2340 of the message being acknowledged. 2342 This object is non-negotiable. 2344 14.6. CONFIG Class 2346 Class = 6. 2348 o C-Type = 1, HelloConfig 2350 0 1 2 3 2351 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 2352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 | HelloInterval | HelloDeadInterval | 2354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 HelloInterval: 16 bits. 2358 Indicates how frequently the Hello packets will be sent and is 2359 measured in milliseconds (ms). 2361 HelloDeadInterval: 16 bits. 2363 If no Hello packets are received within the HelloDeadInterval, 2364 the control channel is assumed to have failed. The 2365 HelloDeadInterval is measured in milliseconds (ms). The 2366 HelloDeadInterval MUST be greater than the HelloInterval, and 2367 SHOULD be at least 3 times the value of HelloInterval. 2369 If the fast keep-alive mechanism of LMP is not used, the 2370 HelloInterval and HelloDeadInterval MUST be set to zero. 2372 14.7. HELLO Class 2373 Class = 7 2375 o C-Type = 1, Hello 2377 0 1 2 3 2378 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 2379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2380 | TxSeqNum | 2381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2382 | RcvSeqNum | 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 TxSeqNum: 32 bits 2387 This is the current sequence number for this Hello message. 2388 This sequence number will be incremented when the sequence 2389 number is reflected in the RcvSeqNum of a Hello packet that is 2390 received over the control channel. 2392 TxSeqNum=0 is not allowed. 2394 TxSeqNum=1 is reserved to indicate that the control channel has 2395 booted or restarted. 2397 RcvSeqNum: 32 bits 2399 This is the sequence number of the last Hello message received 2400 over the control channel. RcvSeqNum=0 is reserved to indicate 2401 that a Hello message has not yet been received. 2403 This object is non-negotiable. 2405 14.8. BEGIN_VERIFY Class 2407 Class = 8. 2409 o C-Type = 1 2411 0 1 2 3 2412 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 2413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2414 | Flags | VerifyInterval | 2415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 | Number of Data Links | 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2418 | EncType | (Reserved) | Verify Transport Mechanism | 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2420 | TransmissionRate | 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 | Wavelength | 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 Flags: 16 bits 2426 The following flags are defined: 2428 0x01 Verify all Links 2429 If this bit is set, the verification process checks all 2430 unallocated links; else it only verifies new ports or 2431 component links that are to be added to this TE link. 2432 0x02 Data Link Type 2433 If set, the data links to be verified are ports, 2434 otherwise they are component links 2436 VerifyInterval: 16 bits 2438 This is the interval between successive Test messages and is 2439 measured in milliseconds (ms). 2441 Number of Data Links: 32 bits 2443 This is the number of data links that will be verified. 2445 EncType: 8 bits 2447 This is the encoding type of the data link. The defined EncType 2448 values are consistent with the Link Encoding Type values of 2449 [GMPLS-SIG] 2451 Verify Transport Mechanism: 16 bits 2453 This defines the transport mechanism for the Test Messages. The 2454 scope of this bit mask is restricted to each link encoding 2455 type. The local node will set the bits corresponding to the 2456 various mechanisms it can support for transmitting LMP test 2457 messages. The receiver chooses the appropriate mechanism in the 2458 BeginVerifyAck message. 2460 For SONET/SDH Encoding Type, the following flags are defined: 2462 0x01 J0-16: 16 byte J0 Test Message 2464 Capable of transmitting Test messages using J0 overhead 2465 bytes with string length of 16 bytes (with CRC-7). See 2466 table 4 of ITU G.707 [G707] for the 16-byte J0 2467 definition. The definition of CRC-7 is found in Annex B 2468 of ITU G.707. 2470 Note that Due to the byte limitation, the Test message 2471 is NOT sent as an IP packet and as such, no L2 2472 encapsulation is used. A special Test message format is 2473 defined as follows: 2475 The Test message is a 15-byte message, where the 7 most 2476 significant bits (MSb) of each byte are usable. Due to 2477 the byte limitation, the LMP Header is not included. 2479 The first usable 32 bits MUST be the VerifyId that was 2480 received in the VERIFY_ID object of the BeginVerifyAck 2481 message. The second usable 32 bits MUST be the 2482 Interface_Id. The next usable 8 bits are used to 2483 determine the address type of the Interface_Id. For 2484 IPv4, this value is 1. For unnumbered, this value is 3. 2485 The remaining bits are Reserved. 2487 Note that this Test Message format is only valid when 2488 the Interface_Id is either IPv4 or unnumbered. 2490 0x02 J0-64: 64 byte J0 Test Message 2492 Capable of transmitting Test messages using J0 2493 overhead bytes with string length of 64 bytes (see GR- 2494 253-CORE [GR253]). Note that this is only appropriate 2495 for SONET encoding and not SDH encoding. 2497 The Test message is sent as an IP packet as defined 2498 above. 2500 0x04 DCCS: Test Message over the Section DCC 2502 Capable of transmitting Test messages using the DCC 2503 Section Overhead bytes with bit-oriented HDLC framing 2504 format. 2506 The Test message is sent as an IP packet as defined 2507 above. 2509 0x08 DCCL: Test Message over the Line DCC 2511 Capable of transmitting Test messages using the DCC 2512 Line Overhead bytes with bit-oriented HDLC framing 2513 format. 2515 The Test message is sent as an IP packet as defined 2516 above. 2518 0x10 Payload: Test Message transmitted in the payload 2520 Capable of transmitting Test messages in the payload 2521 using Packet over SONET framing using the encoding type 2522 specified in the EncType field. 2524 The Test message is sent as an IP packet as defined 2525 above. 2527 0x20 GigE: 2529 Capable of transmitting Test messages in the payload 2531 TransmissionRate: 32 bits 2533 This is the transmission rate of the data link over which the 2534 Test messages will be transmitted. This is expressed in bytes 2535 per second and represented in IEEE floating point format. 2537 Wavelength: 32 bits 2539 When a data link is assigned to a port or component link that 2540 is capable of transmitting multiple wavelengths (e.g., a fiber 2541 or waveband-capable port), it is essential to know which 2542 wavelength the test messages will be transmitted over. This 2543 value corresponds to the wavelength at which the Test messages 2544 will be transmitted over and has local significance. If there 2545 is no ambiguity as to the wavelength over which the message 2546 will be sent, then this value SHOULD be set to 0. 2548 14.9. BEGIN_VERIFY_ACK Class 2550 Class = 9. 2552 o C-Type = 1 2554 0 1 2 3 2555 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 2556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 | VerifyDeadInterval | Verify_Transport_Response | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 VerifyDeadInterval: 16 bits 2562 If a Test message is not detected within the 2563 VerifyDeadInterval, then a node will send the TestStatusFailure 2564 message for that data link. 2566 Verify_Transport_Response: 16 bits 2568 The recipient of the BeginVerify message (and the future 2569 recipient of the TEST messages) chooses the transport mechanism 2570 from the various types that are offered by the transmitter of 2571 the Test messages. One and only one bit MUST be set in the 2572 verification transport response. 2574 This object is non-negotiable. 2576 14.10. VERIFY_ID Class 2578 Class = 10. 2580 o C-Type = 1 2582 0 1 2 3 2583 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 2584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2585 | VerifyId | 2586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2588 VerifyId: 32 bits 2590 This is used to differentiate Test messages from different TE 2591 links and/or LMP peers. This is a node-unique value that is 2592 assigned by the recipient of the BeginVerify message. 2594 This object is non-negotiable. 2596 14.11. TE_LINK Class 2598 Class = 11. 2600 o C-Type = 1, IPv4 TE_LINK 2602 0 1 2 3 2603 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 2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2605 | Flags | (Reserved) | 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2607 | Local_Link_Id (4 bytes) | 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2609 | Remote_Link_Id (4 bytes) | 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 o C-Type = 2, IPv6 TE_LINK 2614 0 1 2 3 2615 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 2616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2617 | Flags | (Reserved) | 2618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 | | 2620 + + 2621 | | 2622 + Local_Link_Id (16 bytes) + 2623 | | 2624 + + 2625 | | 2626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 | | 2628 + + 2629 | | 2630 + Remote_Link_Id (16 bytes) + 2631 | | 2632 + + 2633 | | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2636 o C-Type = 3, Unnumbered TE_LINK 2638 0 1 2 3 2639 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 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 | Flags | (Reserved) | 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 | Local_Link_Id (4 bytes) | 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2645 | Remote_Link_Id (4 bytes) | 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2648 o C-Type = 4, Reserved for OIF 2650 Flags: 8 bits 2651 The following flags are defined. All other values are reserved. 2653 0x01 Fault Management Supported. 2655 0x02 Link Verification Supported. 2657 Local_Link_Id: 2659 This identifies the node�s local Link Id and MUST be non-zero. 2661 Remote_Link_Id: 2663 This identifies the remote node�s Link Id and MUST be non-zero. 2665 14.12. DATA_LINK Class 2667 Class = 12. 2669 o C-Type = 1, IPv4 DATA_LINK 2671 0 1 2 3 2672 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 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 | Flags | (Reserved) | 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676 | Local_Interface_Id (4 bytes) | 2677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 | Remote_Interface_Id (4 bytes) | 2679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2680 | | 2681 // (Subobjects) // 2682 | | 2683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 o C-Type = 2, IPv6 DATA_LINK 2687 0 1 2 3 2688 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 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2690 | Flags | (Reserved) | 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 | | 2693 + + 2694 | | 2695 + Local_Interface_Id (16 bytes) + 2696 | | 2697 + + 2698 | | 2699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 | | 2701 + + 2702 | | 2703 + Remote_Interface_Id (16 bytes) + 2704 | | 2705 + + 2706 | | 2707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2708 | | 2709 // (Subobjects) // 2710 | | 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 o C-Type = 3, Unnumbered DATA_LINK 2715 0 1 2 3 2716 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 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 | Flags | (Reserved) | 2719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 | Local_Interface_Id (4 bytes) | 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 | Remote_Interface_Id (4 bytes) | 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 | | 2725 // (Subobjects) // 2726 | | 2727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 Flags: 8 bits 2731 The following flags are defined. All other values are reserved. 2733 0x01 Interface Type: If set, the data link is a port, 2734 otherwise it is a component link. 2736 0x02 Allocated Link: If set, the data link is currently 2737 allocated for user traffic. If a single 2738 Interface_Id is used for both the 2739 transmit and receive data links, then 2740 this bit only applies to the transmit 2741 interface. 2742 0x04 Failed Link: If set, the data link is failed and not 2743 suitable for user traffic. 2745 Local_Interface_Id: 2747 This is the local identifier of the data link. This MUST be 2748 node-wide unique and non-zero. 2750 Remote_Interface_Id: 2752 This is the remote identifier of the data link. This MUST be 2753 non-zero. 2755 Subobjects 2757 The contents of the DATA_LINK object consist of a series of 2758 variable-length data items called subobjects. The subobjects 2759 are defined in section 14.12.1 below. 2761 A DATA_LINK object may contain more than one subobject. More than 2762 one subobject of the same Type may appear if multiple capabilities 2763 are supported over the data link. 2765 14.12.1. Data Link Subobjects 2767 The contents of the DATA_LINK object include a series of variable- 2768 length data items called subobjects. Each subobject has the form: 2770 0 1 2771 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//------------ -+ 2773 | Type | Length | (Subobject contents) | 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 2776 Type: 8 bits 2778 The Type indicates the type of contents of the subobject. 2779 Currently defined values are: 2781 Type = 1, Interface Switching Capability 2783 Length: 8 bits 2785 The Length contains the total length of the subobject in bytes, 2786 including the Type and Length fields. The Length MUST be at 2787 least 4, and MUST be a multiple of 4. 2789 14.12.1.1. Subobject Type 1: Interface Switching Capability 2791 0 1 2 3 2792 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 2793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2794 | Type | Length | Switching Cap | EncType | 2795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 | Minimum Reservable Bandwidth | 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 | Maximum Reservable Bandwidth | 2799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2801 Switching Capability: 8 bits 2803 This is used to identify the local Interface Switching 2804 Capability of the TE link as defined in [GMPLS-SIG]. 2806 EncType: 8 bits 2808 This is the encoding type of the data link. The defined EncType 2809 values are consistent with the Link Encoding Type values of 2810 [GMPLS-SIG]. 2812 Minimum Reservable Bandwidth: 32 bits 2814 This is measured in bytes per second and represented in IEEE 2815 floating point format. 2817 Maximum Reservable Bandwidth: 32 bits 2819 This is measured in bytes per second and represented in IEEE 2820 floating point format. 2822 If the interface only supports a fixed rate, the minimum and maximum 2823 bandwidth fields are set to the same value. 2825 14.12.1.2. Subobject Type 2: Wavelength 2827 0 1 2 3 2828 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 2829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2830 | Type | Length | (Reserved) | 2831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2832 | Wavelength | 2833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2835 Wavelength: 32 bits 2837 This value indicates the wavelength carried over the port. 2838 Values used in this field only have significance between two 2839 neighbors. 2841 14.13. CHANNEL_STATUS Class 2843 Class = 13 2845 o C-Type = 1, IPv4 INTERFACE_ID 2847 0 1 2 3 2848 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 2849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2850 | Interface Id (4 bytes) | 2851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2852 |A| Channel Status | 2853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2854 | : | 2855 // : // 2856 | : | 2857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2858 | Interface Id (4 bytes) | 2859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2860 |A| Channel Status | 2861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2863 o C-Type = 2, IPv6 INTERFACE_ID 2865 0 1 2 3 2866 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 2867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2868 | | 2869 + + 2870 | | 2871 + Interface Id (16 bytes) + 2872 | | 2873 + + 2874 | | 2875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2876 |A| Channel Status | 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 | : | 2879 // : // 2880 | : | 2881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2882 | | 2883 + + 2884 | | 2885 + Interface Id (16 bytes) + 2886 | | 2887 + + 2888 | | 2889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2890 |A| Channel Status | 2891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2892 o C-Type = 3, Unnumbered INTERFACE_ID 2894 0 1 2 3 2895 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 2896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2897 | Interface Id (4 bytes) | 2898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2899 |A| Channel Status | 2900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2901 | : | 2902 // : // 2903 | : | 2904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2905 | Interface Id (4 bytes) | 2906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2907 |A|D| Channel Status | 2908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2910 Active bit: 1 bit 2912 This indicates that the Channel is allocated to user traffic and the 2913 data link should be actively monitored. 2915 Direction bit: 1 bit 2917 This indicates the direction (transmit/receive) of the data channel 2918 referred to in the CHANNEL_STATUS object. If set, this indicates the 2919 data channel is in the transmit direction. 2921 Channel_Status: 30 bits 2923 This indicates the status condition of a data channel. The 2924 following values are defined. All other values are reserved. 2926 1 Signal Okay (OK): Channel is operational 2927 2 Signal Degrade (SD): A soft failure caused by a BER 2928 exceeding a preselected threshold. The specific BER 2929 used to define the threshold is configured. 2930 3 Signal Fail (SF): A hard signal failure including (but not 2931 limited to) loss of signal (LOS), loss of frame 2932 (LOF), or Line AIS. 2934 This object contains one or more Interface Ids followed by a 2935 Channel_Status field. 2937 To indicate the status of the entire TE Link, there MUST only be one 2938 Interface Id and it MUST be zero. 2940 This object is non-negotiable. 2942 14.14. CHANNEL_STATUS_REQUEST Class 2943 Class = 14 2945 o C-Type = 1, IPv4 INTERFACE_ID 2947 0 1 2 3 2948 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 2949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2950 | Interface Id (4 bytes) | 2951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2952 | : | 2953 // : // 2954 | : | 2955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2956 | Interface Id (4 bytes) | 2957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2959 This object contains one or more Interface Ids. 2961 The Length of this object is 4 + 4N in bytes, where N is the number 2962 of Interface Ids. 2964 o C-Type = 2, IPv4 INTERFACE_ID 2966 0 1 2 3 2967 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 2968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2969 | | 2970 + + 2971 | | 2972 + Interface Id (16 bytes) + 2973 | | 2974 + + 2975 | | 2976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2977 | : | 2978 // : // 2979 | : | 2980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2981 | | 2982 + + 2983 | | 2984 + Interface Id (16 bytes) + 2985 | | 2986 + + 2987 | | 2988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2990 This object contains one or more Interface Ids. 2992 The Length of this object is 4 + 16N in bytes, where N is the number 2993 of Interface Ids. 2995 o C-Type = 3, Unnumbered INTERFACE_ID 2997 0 1 2 3 2998 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 2999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3000 | Interface Id (4 bytes) | 3001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3002 | : | 3003 // : // 3004 | : | 3005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3006 | Interface Id (4 bytes) | 3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3009 This object contains one or more Interface Ids. 3011 The Length of this object is 4 + 4N in bytes, where N is the number 3012 of Interface Ids. 3014 This object is non-negotiable. 3016 14.15. ERROR_CODE Class 3018 Class = 20. 3020 o C-Type = 1, BEGIN_VERIFY_ERROR 3022 0 1 2 3 3023 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 3024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3025 | ERROR CODE | 3026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3028 The following bit-values are defined: 3030 0x01 = Link Verification Procedure not supported for this TE 3031 Link. 3032 0x02 = Unwilling to verify at this time 3033 0x04 = Unsupported verification transport mechanism 3034 0x08 = TE Link Id configuration error 3036 All other values are Reserved. 3038 Multiple bits may be set to indicate multiple errors. 3040 This object is non-negotiable. 3042 If a BeginVerifyNack message is received with Error Code 2, the node 3043 that originated the BeginVerify SHOULD schedule a BeginVerify 3044 retransmission after Rf seconds, where Rf is a locally defined 3045 parameter. 3047 o C-Type = 2, LINK_SUMMARY_ERROR 3049 0 1 2 3 3050 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 3051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3052 | ERROR CODE | 3053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3055 The following bit-values are defined: 3057 0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters 3058 0x02 = Renegotiate LINK_SUMMARY parameters 3059 0x04 = Bad Received Remote_Link_Id 3060 0x08 = Bad TE Link Object 3061 0x10 = Bad Data Link Object 3063 All other values are Reserved. 3065 Multiple bits may be set to indicate multiple errors. 3067 This object is non-negotiable. 3069 15. Security Considerations 3071 Security is discussed in [LMP-SEC]. 3073 16. Intellectual Property Considerations 3075 The IETF takes no position regarding the validity or scope of any 3076 intellectual property or other rights that might be claimed to 3077 pertain to the implementation or use of the technology described in 3078 this document or the extent to which any license under such rights 3079 might or might not be available; neither does it represent that it 3080 has made any effort to identify any such rights. Information on the 3081 IETF's procedures with respect to rights in standards-track and 3082 standards-related documentation can be found in BCP-11. Copies of 3083 claims of rights made available for publication and any assurances 3084 of licenses to be made available, or the result of an attempt made 3085 to obtain a general license or permission for the use of such 3086 proprietary rights by implementers or users of this specification 3087 can be obtained from the IETF Secretariat. 3089 The IETF invites any interested party to bring to its attention any 3090 copyrights, patents or patent applications, or other proprietary 3091 rights which may cover technology that may be required to practice 3092 this standard. Please address the information to the IETF Executive 3093 Director. 3095 17. References 3097 17.1. Normative References 3099 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3100 3," BCP 9, RFC 2026, October 1996. 3101 [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 3102 MPLS Traffic Engineering," Internet Draft, draft- 3103 kompella-mpls-bundle-05.txt, (work in progress), February 3104 2001. 3105 [RFC2961] Berger, L., Gan, D., et al, "RSVP Refresh Overhead 3106 Reduction Extensions," RFC 2961, April 2001. 3107 [GMPLS-SIG] Ashwood-Smith, P., Banerjee, A., et al, "Generalized 3108 MPLS - Signaling Functional Description," Internet Draft, 3109 draft-ietf-mpls-generalized-signaling-06.txt, (work in 3110 progress), October 2001. 3111 [G707] ITU-T G.707, "Network node interface for the synchronous 3112 digital hierarchy (SDH)," March 1996. 3113 [GR253] GR-253-CORE, "Synchronous Optical Network (SONET) 3114 Transport Systems: Common Generic Criteria," Telcordia 3115 Technologies, Issue 3, September 2000. 3116 [LMP-SEC] Ramamoorthi,S. and Zinin, A., "LMP Security Mechanism," 3117 Internet Draft, draft-sankar-lmp-sec-00.txt, (work in 3118 progress), Internet Draft, February 2002. 3120 17.2. Informative References 3122 [LAMBDA] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., 3123 "Multi-Protocol Lambda Switching: Combining MPLS Traffic 3124 Engineering Control with Optical Crossconnects," 3125 Internet Draft, draft-awduche-mpls-te-optical-03.txt, 3126 (work in progress), April 2001. 3127 [RFC3209] Awduche, D. O., Berger, L, et al, "Extensions to RSVP 3128 for LSP Tunnels," Internet Draft, RFC3209 December 2001. 3129 [RFC3219] Jamoussi, B., ed., "Constraint-Based LSP Setup using 3130 LDP," RFC3219, January 2002. 3131 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 3132 Extensions to OSPF," Internet Draft, draft-katz-yeung- 3133 ospf-traffic-04.txt, (work in progress), February 2001. 3134 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 3135 Engineering," Internet Draft,draft-ietf-isis-traffic- 3136 02.txt, (work in progress), September 2000. 3138 18. Acknowledgements 3140 The authors would like to thank Andre Fredette for his many 3141 contributions to this draft. We would also like to thank Ayan 3142 Banerjee, George Swallow, Andre Fredette, Adrian Farrel, Vinay 3143 Ravuri, and David Drysdale for their insightful comments and 3144 suggestions. We would also like to thank John Yu, Suresh Katukam, 3145 and Greg Bernstein for their helpful suggestions for the in-band 3146 control channel applicability. Finally, we would like to thank 3147 Dimitri Papadimitriou for his contributions to the SONET/SDH test 3148 procedures. 3150 19. Contributors 3152 Jonathan P. Lang Krishna Mitra 3153 Calient Networks Calient Networks 3154 25 Castilian Drive 5853 Rue Ferrari 3155 Goleta, CA 93117 San Jose, CA 95138 3156 Email: jplang@calient.net email: krishna@calient.net 3158 John Drake Kireeti Kompella 3159 Calient Networks Juniper Networks, Inc. 3160 5853 Rue Ferrari 385 Ravendale Drive 3161 San Jose, CA 95138 Mountain View, CA 94043 3162 email: jdrake@calient.net email: kireeti@juniper.net 3164 Yakov Rekhter Lou Berger 3165 Juniper Networks, Inc. Movaz Networks 3166 385 Ravendale Drive email: lberger@movaz.com 3167 Mountain View, CA 94043 3168 email: yakov@juniper.net 3170 Debanjan Saha Debashis Basak 3171 Tellium Optical Systems Accelight Networks 3172 2 Crescent Place 70 Abele Road, Suite 1201 3173 Oceanport, NJ 07757-0901 Bridgeville, PA 15017-3470 3174 email: dsaha@tellium.com email: dbasak@accelight.com 3176 Hal Sandick Alex Zinin 3177 Shepard M.S. Alcatel 3178 2401 Dakota Street email: zinin@psg.com 3179 Durham, NC 27705 3180 email: sandick@nc.rr.com 3182 Bala Rajagopalan 3183 Tellium Optical Systems 3184 2 Crescent Place 3185 Oceanport, NJ 07757-0901 3186 email: braja@tellium.com 3188 20. Contact Address 3190 Jonathan P. Lang 3191 Calient Networks 3192 25 Castilian Drive 3193 Goleta, CA 93117 3194 Email: jplang@calient.net