idnits 2.17.1 draft-lang-mpls-lmp-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 19) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 192: '... link MUST have an associated contro...' RFC 2119 keyword, line 222: '... control channel SHOULD be tried. Of ...' RFC 2119 keyword, line 223: '... channels SHOULD be pre-configured, ...' RFC 2119 keyword, line 298: '...se. Negotiation MUST only be done whe...' RFC 2119 keyword, line 314: '... MUST be greater than the HelloInter...' (25 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 HelloConfigAck message, it may begin sending Hello messages. Once it has both sent and received a Hello message, the link is UP. If, however, a node receives a HelloConfigNack message instead of a HelloConfigAck message, the node MUST not begin sending Hello messages. However, if the HelloInterval and HelloDeadInterval included in the received HelloConfigNack message are locally acceptable, the node SHOULD send a new HelloConfig message with these values to the adjacent node. == 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: To ensure that both nodes switch to the backup control channel successfully, both the local and remote nodes MUST transmit messages over both the primary and backup control channels until the switchover is successful. Messages on the primary control channel MUST have the ControlChannelSwitchover flag set to 1 and MUST not increment the TxSeqNum (even upon the receipt of a Hello message with the current TxSeqNum reflected in the RcvSeqNum field). Messages on the backup control channel MUST set the ControlChannelSwitchover flag to 0 and MUST increment the TxSeqNum by 1 to distinguish messages on the two channels. If the TxSeqNum of the Hello messages on the backup control channel are reflected in the RcvSeqNum of Hello messages being received, then the TxSeqNum MUST be incremented (as per normal operation); this indicates that the backup control channel is operational in the transmit direction and the local node may now stop transmitting Hello messages over the primary control channel. Once a Hello message is received over the backup control channel indicating that the remote node is receiving confirmation of Hello message receipt (this is indicated by an incrementing TxSeqNum), then the local node may stop listening on the primary control channel. When both nodes are only transmitting/receiving Hello packets over the backup control channel, the switchover is successful. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-kompella-mpls-bundle-01 -- Possible downref: Normative reference to a draft: ref. 'KRB00' -- No information found for draft-generalized-signaling - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ABD00' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-07 == Outdated reference: A later version (-03) exists of draft-awduche-mpls-te-optical-00 -- Possible downref: Normative reference to a draft: ref. 'ARD99' == Outdated reference: A later version (-04) exists of draft-ceuppens-mpls-optical-00 -- Possible downref: Normative reference to a draft: ref. 'CBD00' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-04 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-03 == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'SmL99' -- No information found for draft-kompella-ospf-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'KRB00a' -- No information found for draft-kompella-isis-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'KRB00b' Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jonathan P. Lang (Calient Networks) 3 Internet Draft Krishna Mitra (Calient Networks) 4 Expiration Date: January 2001 John Drake (Calient Networks) 5 Kireeti Kompella (Juniper Networks) 6 Yakov Rekhter (Cisco Systems) 7 Lou Berger (LabN Consulting, LLC) 8 Debanjan Saha (Tellium) 9 Debashis Basak (Marconi) 10 Hal Sandick (Nortel Networks) 12 Link Management Protocol (LMP) 14 draft-lang-mpls-lmp-02.txt 16 1. Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026 [Bra96]. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet- Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 2. Abstract 39 Future networks will consist of photonic switches, optical 40 crossconnects, and routers that may be configured with bundled links 41 consisting of a number of user component links and an associated 42 control channel. This draft specifies a link management protocol 43 (LMP) that runs between neighboring nodes and will be used for both 44 link provisioning and fault isolation. A unique feature of LMP is 45 that it is able to isolate faults in both opaque and transparent 46 networks, independent of the encoding scheme used for the component 47 links. LMP will be used to maintain control channel connectivity, 48 verify component link connectivity, and isolate link, fiber, or 49 channel failures within the optical network. 51 3. Introduction 53 Future networks will consist of photonic switches (PXCs), optical 54 crossconnects (OXCs), routers, switches, DWDM systems, and add-drop 55 multiplexors (ADMs) that use the MPLS control plane to dynamically 56 provision resources and to provide network survivability using 57 protection and restoration techniques. A pair of nodes (e.g., two 58 PXCs) may be connected by thousands of fibers, and each fiber may be 59 used to transmit multiple wavelengths if DWDM is used. Furthermore, 60 multiple fibers and/or multiple wavelengths may be combined into a 61 single bundled link, where we define such a link as a logical 62 relationship associating a bi-directional control channel with zero 63 or more unidirectional component links (see also [KRB00]). 65 For the purposes of this document, the granularity of a component 66 link is a wavelength, a waveband, or a fiber depending on the ports 67 that are exposed to the adjacent nodes. For example, if a cross- 68 connect is connected to a DWDM device, then the ports of the cross- 69 connect (and hence the component links) correspond to wavelengths. 70 If, however, the cross-connect multiplexes the wavelengths 71 internally before connecting them to another node, then the ports of 72 the cross-connect (and hence the component links) correspond to a 73 fiber. In general, a bundled link between two nodes will be 74 identified by a local and remote 32-bit interface (possibly a 75 virtual interface) address, and the control channel will be 76 identified by a local and remote 32-bit control channel Id (CCId). 77 Similarly, each node will identify each component link with a local 78 LinkId. LMP gives the association between the endpoints of the 79 bundled link, control channel, and component links. 81 Within the framework of the Generalized Label [ABD00], the LinkId is 82 required whenever there is ambiguity as to where the labels are to 83 be allocated. In the following, we describe how the LinkId is used 84 for the various multiplexing capabilities of a node. For the PSC 85 case, the Generalized Label includes a LinkId (corresponding to a 86 fiber) and the normal MPLS label. For the TDM case, the Generalized 87 Label includes a LinkId (corresponding to a fiber) and the Mannie 88 encoded label. For the LSC case there are two options for the 89 Generalized Label depending on if the wavelengths are exposed to the 90 adjacent nodes or not; it could include the LinkId (corresponding to 91 a fiber) and a wavelength label (corresponding to a wavelength 92 within the fiber), or it could include just the LinkId 93 (corresponding to a wavelength), where a label is present but 94 ignored. Finally, for the FSC case, the Generalized Label includes 95 only a linkId (corresponding to a fiber) and a label is present but 96 ignored. 98 A unique feature of a link as defined above is that the control 99 channel and the associated component links are not required to be 100 transmitted along the same physical medium. For example, the 101 control channel could be transmitted along a separate wavelength or 102 fiber, or on an Ethernet link between the two neighbors. A 103 consequence of allowing the control channel of a link to be 104 physically diverse from the associated component links is that the 105 health of a control channel on a link does not necessarily correlate 106 to the health of the component links, and vice-versa. Therefore, 107 new mechanisms must be developed to manage links, both in terms of 108 link provisioning and fault isolation. 110 This draft specifies a link management protocol (LMP) that runs 111 between neighboring nodes and will be used for both link 112 provisioning and fault isolation. All of the LMP messages 113 transmitted over the control channel are IP encoded, so that the 114 link level encoding becomes an implementation agreement and is not 115 part of LMP specifications. The LMP messages that are transmitted 116 over a component link will be a new protocol type. For example, if 117 it is over Ethernet, it will be a new Ethertype, and if it is over 118 SONET/SDH, the HDLC framing defined for PPP over SONET will be used 119 with the MPLSCP defined in Section 4 of [RNT99]. 121 In this draft, we will follow the naming convention of [ARD99] and 122 use OXC to refer to all categories of optical crossconnects, 123 irrespective of the internal switching fabric. We distinguish 124 between crossconnects that require opto-electronic conversion, 125 called digital crossconnects (DXCs), and those that are all-optical, 126 called photonic switches or photonic crossconnects (PXCs) - referred 127 to as pure crossconnects in [ARD99], because the transparent nature 128 of PXCs introduces new restrictions for monitoring and managing the 129 data channels (see [CBD00] for proposed extensions to MPLS for 130 performance monitoring in photonic networks). LMP, however, can be 131 used for any type of node, enhancing the functionality of 132 traditional DXCs, DWDMs, and routers, while enabling PXCs to 133 intelligently interoperate in heterogeneous optical networks. 135 Due to the transparent nature of PXCs, traditional methods can no 136 longer be used to monitor and manage links and LMP has been designed 137 to address these issues in optical networks. In addition, since LMP 138 does not dictate the actual transport mechanism, it can be 139 implemented in a heterogeneous network. A requirement for LMP is 140 that each link has an associated bi-directional control channel and 141 that a free (unallocated) component link must be opaque (i.e., able 142 to be terminated); however, once a component link is allocated, it 143 may become transparent. Note that there is no requirement that all 144 of the component links must be terminated simultaneously, but at a 145 minimum, they must be able to be terminated one at a time. There is 146 no requirement that the control channel and component links share 147 the same medium; however, the control channel must terminate on the 148 same two nodes that the component links span. 150 LMP is a protocol that runs between adjacent nodes and is designed 151 to provide four basic functions for the node pair: control channel 152 management, link connectivity verification, link property 153 correlation, and fault isolation. Control channel management is 154 used to establish and maintain link connectivity between neighboring 155 nodes. This is done using lightweight Hello messages that act as a 156 fast keep-alive mechanism between the nodes. Link connectivity 157 verification is used to verify the physical connectivity of the 158 component links as well as exchange the LinkIds that are used in the 159 Generalized Label [ABD00] for MPLS. Link property correlation 160 consists of LinkSummary messages that exchange the local/remote CCId 161 mappings that were learned when establishing control channel 162 connectivity; the local/remote LinkId mappings that were discovered 163 as a result of the link connectivity verification process; the 164 protection control channels for maintaining link connectivity; and 165 the protection component links that are used for M:N protection as 166 part of the fault isolation procedure. The fault isolation mechanism 167 can localize failures in both opaque and transparent networks, 168 independent of the encoding scheme used for the component links, and 169 as a result, both local span and end-to-end path 170 protection/restoration procedures can be initiated. 172 The organization of the remainder of this document is as follows. 173 In Section 4, we discuss the role of the control channel and the 174 messages used to establish and maintain link connectivity. The link 175 verification procedure is discussed in Section 5. In Section 6, we 176 show how LMP will be used to isolate link and channel failures 177 within the optical network. 179 4. Control channel management 181 To establish a bundled link between two nodes, a bi-directional 182 primary control channel must first be configured. The control 183 channel can be used to exchange MPLS control-plane information such 184 as link provisioning and fault isolation information (implemented 185 using a messaging protocol such as LMP, proposed in this draft), 186 path management and label distribution information (implemented 187 using a signaling protocol such as RSVP-TE [ABG99]or CR-LDP 188 [Jam99]), and topology and state distribution information 189 (implemented using traffic engineering extended protocols such as 190 OSPF [KaY99]and IS-IS [SmL99]). Each bundled link is identified by 191 a 32-bit IP interface (possibly virtual interface) and each bundled 192 link MUST have an associated control channel; however, we do not 193 specify the exact implementation of the control channel. Rather, we 194 assign a 32-bit integer control channel identifier (CCId) to each 195 direction of the control channel and we define the control channel 196 messages to be IP encoded. This allows the control channel 197 implementation to encompass both in-band and out-of-band mechanisms, 198 including the case where the control channel is transmitted 199 separately from the associated component link(s), either on a 200 separate wavelength or on a separate fiber. Furthermore, since the 201 messages are IP encoded, the link level encoding is not part of LMP. 203 The control channel of a link can be either explicitly configured or 204 automatically selected, however, for the purpose of this document we 205 will assume the control channel is explicitly configured. Note that 206 for in-band signaling, a control channel could be allocated to a 207 component link; however, this is not true when the control channel 208 is transmitted separately from the component links. In addition to 209 a primary control channel, an ordered list of backup control 210 channels can also be specified. Depending on the control channel 211 implementation, the list of backup control channels may include 212 component links, provided control channels have preemptive priority 213 over the user data traffic. 215 For LMP, it is essential that a control channel is always available 216 for a link, and in the event of a control channel failure, an 217 alternate (or backup) control channel must be made available to 218 reestablish communication with the neighboring node. Since control 219 channels are electrically terminated at each node, the failure of a 220 control channel can be detected by lower layers (e.g., SONET/SDH). 221 If the primary control channel cannot be established, then a backup 222 control channel SHOULD be tried. Of course, alternate control 223 channels SHOULD be pre-configured, however, coordinating the 224 switchover of the control channel to an alternate channel is still 225 an important issue. Specifically, if the control channel fails but 226 the node is still operational (i.e., the component links are still 227 passing user data), then both the local and remote nodes should 228 switch to an alternate control channel. If the bi-directional 229 control channel is implemented using two separate unidirectional 230 channels, and only one direction of the control channel has failed, 231 both the local and remote nodes need to understand that the channel 232 has failed so that they can coordinate a switchover. 234 4.1. LMP Link States 236 A link can be in any of five well-defined states: Initialize (INIT), 237 Configure (CONFIG), UP, Degraded (DEG), and DOWN. Many of these 238 states have multiple sub-states that are described later in this 239 document. 241 +----+ +------+ +----+ +---+ +----+ 242 | | (1) | | (2) | | (3) | | (4) | | 243 | INIT | ----> | CONFIG | ----> | UP | ----> | DEG | ---> | DOWN | 244 | | | | | | | | | | 245 +----+ +------+ +----+ +---+ +----+ 246 ^ | | | 247 | (5) | (5) | (5) | 248 -------------------------------------------- 250 4.1.1 Link States 252 INIT: Communication not established, Hello configuration not 253 initiated, and component links not in use. 255 CONFIG: Hello configuration parameters are negotiated and the 256 control channel is brought up, but link properties are not 257 yet agreed upon. 259 UP: Link Up. Control channel is UP and Hello messages are being 260 exchanged. 262 DEG: Control channel and backup control channel(s) are not 263 available, but component links are still in use. 265 DOWN: Link Down. Communication not established, Hello 266 configuration not initiated, and component links not in use. 268 4.1.2 State transition events 270 (1) The parameter negotiation phase is initiated. 272 (2) The control channel is UP and Hello messages are being 273 exchanged. 275 (3) The control channel and backup control channel(s) are not 276 available, and the component links are still in use. 278 (4) The control channel and backup control channel(s) are not 279 available, and the component links are failed or not in use. 280 This includes the case where a control channel is brought down 281 administratively. 283 (5) The parameter negotiation phase is initiated. 285 4.2. Hello protocol 287 Once a control channel is configured between two neighboring nodes, 288 a Hello protocol will be used to establish and maintain connectivity 289 between the nodes and to detect link and channel failures. The 290 Hello protocol of LMP is intended to be a lightweight keep-alive 291 mechanism that will react to control channel failures rapidly so 292 that IGP Hellos are not lost and the associated link-state 293 adjacencies are not removed unnecessarily. Furthermore, the RSVP 294 Hello of [ABG99] is not needed since the LMP Hellos will detect link 295 layer failures. 297 The Hello protocol consists of two phases: a negotiation phase and 298 a keep-alive phase. Negotiation MUST only be done when the link is 299 in the CONFIG state, and is used to exchange the CCIds and agree 300 upon the parameters used in the keep-alive phase. The keep-alive 301 phase consists of a fast lightweight Hello message exchange. 303 4.2.1. Parameter Negotiation 305 Before initiating the Hello protocol of the keep-alive phase, the 306 local and remote CCId must be exchanged and the HelloInterval and 307 HelloDeadInterval parameters must be agreed upon. The HelloInterval 308 indicates how frequently LMP Hello messages will be sent, and is 309 measured in milliseconds (ms). For example, if the value were 5, 310 then the transmitting node would send the Hello message at least 311 every 5ms. The HelloDeadInterval indicates how long a device should 312 wait to receive a Hello message before declaring a control channel 313 dead, and is measured in milliseconds (ms). The HelloDeadInterval 314 MUST be greater than the HelloInterval, and SHOULD be at least 3 315 times the value of HelloInterval. 317 The parameter negotiation consists of three messages: a HelloConfig 318 message, a HelloConfigAck message, and a HelloConfigNack message. 319 The HelloConfigAck and HelloConfigNack messages are used to 320 acknowledge receipt of the HelloConfig message. The HelloConfigNack 321 message is also used to suggest alternate values for the 322 HelloInterval and HelloDeadInterval parameters. To initiate the 323 negotiation process, a node sends a HelloConfig message containing 324 the CCId for the control channel, the IP address of the bundled 325 link, and the proposed HelloInterval and HelloDeadInterval. The 326 node also starts a single-shot timer that is used for 327 retransmissions in the event of message loss. 329 When a HelloConfig message is received at a node, a HelloConfigAck 330 message SHOULD be transmitted if the received HelloInterval and 331 HelloDeadInterval values are acceptable. Otherwise, the node MUST 332 reject the parameters by sending a HelloConfigNack message. The 333 HelloConfigNack message MUST include acceptable values for the 334 HelloInterval and HelloDeadInterval. 336 When a node has either sent or received a HelloConfigAck message, it 337 may begin sending Hello messages. Once it has both sent and 338 received a Hello message, the link is UP. If, however, a node 339 receives a HelloConfigNack message instead of a HelloConfigAck 340 message, the node MUST not begin sending Hello messages. However, if 341 the HelloInterval and HelloDeadInterval included in the received 342 HelloConfigNack message are locally acceptable, the node SHOULD send 343 a new HelloConfig message with these values to the adjacent node. 345 4.1.2. Fast keep-alive 347 Once the parameters have been agreed upon and a node has sent and 348 received a HelloConfigAck message, it may begin sending Hello 349 messages. Each Hello message will contain two sequence numbers: the 350 first sequence number (TxSeqNum) is the sequence number for this 351 Hello message and the second sequence number (RcvSeqNum) is the 352 sequence number of the last Hello message received from the adjacent 353 node. Each node increments its sequence number when it sees its 354 current sequence number reflected in Hellos received from its peer. 355 The sequence numbers will be 32-bit lollipop sequence numbers that 356 start at 1 and wrap around back to 2; 0 is used in the RcvSeqNum to 357 indicate that a Hello has not yet been seen and 1 is used to 358 indicate a node boot/reboot. 360 Having sequence numbers in the Hello messages allows each node to 361 verify that its peer is receiving its Hello messages. This provides 362 a two-fold service. First, the remote node will detect that a node 363 has rebooted if TxSeqNum=1. If this occurs, the remote node will 364 indicate its knowledge of the reboot by setting RcvSeqNum=1 in the 365 Hello messages that it sends and SHOULD wait to receive a Hello 366 message with TxSeqNum=2 before transmitting any messages other than 367 Hello messages. Second, by including the RcvSeqNum in Hello 368 packets, the local node will know which Hello packets the remote 369 node has received. This is important because it helps coordinate 370 control-channel switchover in case of a control channel failure. 372 4.1.3. Control channel switchover 374 As mentioned above, LMP requires that a control channel always be 375 available for a link, and multiple mechanisms are used within LMP to 376 ensure that the switchover of a control channel is both smooth and 377 proper. Control channels may need to be switched as a result of a 378 control channel failure or for administration purposes (e.g., 379 routine fiber maintenance, reverting back to a primary control 380 channel, etc.), and peer connectivity must be maintained to ensure 381 that unnecessary rerouting of user traffic is avoided and false 382 failures are not reported. 384 To ensure that a smooth transition occurs when switching to a backup 385 control channel, a ControlChannelSwitchover flag is available in the 386 Common Header of LMP packets. The receipt of a Hello message with 387 ControlChannelSwitchover = 1 indicates that the remote node is 388 switching to the backup control channel, and the local node MUST 389 begin listening to the backup control channel in addition to the 390 primary control channel. 392 To ensure that both nodes switch to the backup control channel 393 successfully, both the local and remote nodes MUST transmit messages 394 over both the primary and backup control channels until the 395 switchover is successful. Messages on the primary control channel 396 MUST have the ControlChannelSwitchover flag set to 1 and MUST not 397 increment the TxSeqNum (even upon the receipt of a Hello message 398 with the current TxSeqNum reflected in the RcvSeqNum field). 399 Messages on the backup control channel MUST set the 400 ControlChannelSwitchover flag to 0 and MUST increment the TxSeqNum 401 by 1 to distinguish messages on the two channels. If the TxSeqNum 402 of the Hello messages on the backup control channel are reflected in 403 the RcvSeqNum of Hello messages being received, then the TxSeqNum 404 MUST be incremented (as per normal operation); this indicates that 405 the backup control channel is operational in the transmit direction 406 and the local node may now stop transmitting Hello messages over the 407 primary control channel. Once a Hello message is received over the 408 backup control channel indicating that the remote node is receiving 409 confirmation of Hello message receipt (this is indicated by an 410 incrementing TxSeqNum), then the local node may stop listening on 411 the primary control channel. When both nodes are only 412 transmitting/receiving Hello packets over the backup control 413 channel, the switchover is successful. 415 4.1.4. Taking a link down administratively 417 As mentioned above, a link is DOWN when the control channel and 418 backup control channel(s) are not available and none of the 419 component links are in use. A link may be DOWN, for example, when a 420 link is reconfigured for administrative purposes. A link SHOULD 421 only be administratively taken down if the component links are not 422 in use. To ensure that bringing a link DOWN is done gracefully for 423 administration purposes, a LinkDown flag is available in the Common 424 Header of LMP packets. 426 When a node receives LMP packets with LinkDown = 1, it must first 427 verify that it is able to bring the link down on its end. Once the 428 verification is done, it must set the LinkDown flag to 1 on all of 429 the LMP packets that it sends. When the node that initiated the 430 LinkDown procedure receives LMP packets with LinkDown = 1, it may 431 then bring the link DOWN. 433 4.1.5. Degraded (DEG) state 435 A consequence of allowing the control channels and component links 436 to be transmitted along a separate medium is that the link may be in 437 a state where a control channel and backup control channel(s) are 438 not available, but the component links are still in use. For many 439 applications, it is unacceptable to drop traffic that is in use 440 simply because the control channel is no longer available; however, 441 the traffic that is using the component links may no longer be 442 guaranteed the same level of service. Hence the link is in a 443 Degraded (DEG) state. 445 When a link is in the DEG state, the routing protocol should be 446 notified so that new connections are not accepted and resources are 447 no longer advertised for the link. To bring a link back UP out of a 448 degraded state, a node may begin transmitting HelloConfig messages 449 over the primary control channel. 451 5. Verifying link connectivity 453 In this section, we describe the mechanism used to verify the 454 physical connectivity of the component links. This will be done 455 initially when a link is established, and subsequently, on a 456 periodic basis for all free component links of a bundled link. A 457 unique characteristic of all-optical PXCs is that the data being 458 transmitted over a component link is not terminated at the PXC, but 459 instead passes through transparently. This characteristic of PXCs 460 poses a challenge for validating the connectivity of the component 461 links since shining unmodulated light through a component link may 462 not result in received light at the next PXC. This is because there 463 may be terminating (or opaque) elements, such as DWDM equipment, in 464 between the PXCs. Therefore, to ensure that proper verification of 465 component link connectivity, we require that until the component 466 links are allocated, they must be opaque. There is no requirement 467 that all component links be terminated simultaneously, but at a 468 minimum, the component links must be able to be terminated one at a 469 time. Furthermore, we assume that the nodal architecture is 470 designed so that messages can be sent and received over any 471 component link. Note that this requirement is trivial for DXCs (and 472 OEO nodes in general) since each component link is received 473 electronically before being forwarded to the next DXC, but that in 474 PXCs this is an additional requirement. 476 To interconnect two nodes, a link must be added between them, and at 477 a minimum, the link must contain a control channel spanning the two 478 nodes. Optionally, the attributes of a link may include the 479 protection mechanism for the control channel (possibly including an 480 ordered list of backup control channels), a list of component links, 481 and the protection mechanism for each component link. 483 As part of the link verification protocol, the primary control 484 channel is first verified, and connectivity maintained, using the 485 Hello protocol discussed in Section 4. Once the control channel has 486 been established between the two nodes, component link connectivity 487 is verified by exchanging Ping-type Test messages over each of the 488 component links specified in the bundled link. It should be noted 489 that all LMP messages except for the Test message are exchanged over 490 the control channel and that Hello messages continue to be exchanged 491 over the control channel during the component link verification 492 process. The Test message is sent over the component link that is 493 being verified. Component links are tested in the transmit 494 direction as they are uni-directional, and as such, it may be 495 possible for both nodes to exchange the Test messages 496 simultaneously. 498 To initiate the link verification process, the local node first 499 sends a BeginVerify message over the control channel to indicate 500 that the node will begin sending Test messages across the component 501 links of a particular bundled link. The BeginVerify message 502 contains the number of component links that are to be verified; the 503 interval (called VerifyInterval) at which the Test messages will be 504 sent; the encoding scheme and data rate for Test messages; and, in 505 the case where the component links correspond to fibers, the 506 wavelength over which the Test messages will be transmitted. When a 507 node generates a BeginVerify message, it waits either to receive a 508 BeginVerifyAck or BeginVerifyNack message from the adjacent node to 509 accept or reject the verify process. 511 If the remote node receives a BeginVerify message and it is ready to 512 process Test messages, it MUST send a BeginVerifyAck message back to 513 the local node. When the local node receives a BeginVerifyAck 514 message from the remote node, it will begin testing the component 515 links by transmitting periodic Test messages over each component 516 link. The Test message will include the local LinkId for the 517 associated component link. The remote node will return a 518 TestStatusSuccess or TestStatusFail message in response for each 519 component link and will expect a TestStatusAck message from the 520 local node to confirm receipt of these messages. 522 The local (transmitting) node will send a given Test message 523 periodically (at least every VerifyInterval ms) on the corresponding 524 component link until it receives a correlating TestStatusSuccess or 525 TestStatusFailure message on the control channel from the remote 526 (receiving) node. The remote node will send a given TestStatus 527 message periodically over the control channel until it receives 528 either a correlating TestStatusAck message or an EndVerify message 529 on the control channel. It is also permissible for the sender to 530 terminate Test messages over a component link without receiving a 531 TestStatusSuccess or TestStatusFailure message. Message correlation 532 is done using the local node's LinkId and message identifiers. 534 When the Test message is detected at a node, the received LinkId is 535 recorded and mapped to the local LinkId for that channel. The 536 receipt of a TestStatusSuccess message indicates that the Test 537 message was detected and the physical connectivity of the component 538 link has been verified. The TestStatusSuccess message includes both 539 the local LinkId and remote node�s LinkId. When the 540 TestStatusSuccess message is received, the local node SHOULD mark 541 the component link as UP, send a TestStatusAck message to the remote 542 node, and begin testing the next component link. If, however, the 543 Test message is not detected at the remote node within an 544 observation period (specified by the VerifyDeadInterval), the remote 545 node will send a TestStatusFailure message over the control channel 546 indicating that the verification of the physical connectivity of the 547 component link has failed. When the local node receives a 548 TestStatusFailure message, it will mark the component link as 549 FAILED, send a TestStatusAck message to the remote node, and begin 550 testing the next component link. When all the component links on 551 the list have been tested, the local node will send an EndVerify 552 message to indicate that testing has been completed on this link. 553 Upon the receipt of an EndVerify message, an EndVerifyAck message 554 MUST be sent. 556 Both the local and remote nodes will maintain the complete list of 557 LinkId mappings for correlation purposes. 559 5.1. Example of link verification 561 Figure 1 shows an example of the link verification scenario that is 562 executed when a link between PXC A and PXC B is added. In this 563 example, the bundled link will consist of a bi-directional control 564 channel (indicated by a "c") and three free component links (each 565 transmitted along a separate fiber). The verification process is as 566 follows: PXC A sends a BeginVerify message over the control channel 567 to PXC B indicating it will begin verifying the component links. 568 PXC B receives the BeginVerify message and returns the 569 BeginVerifyAck message over the control channel to PXC A. When PXC 570 A receives the BeginVerifyAck message, it begins transmitting 571 periodic Test messages over the first component link (LinkId=1). 572 When PXC B receives the Test messages, it maps the received LinkId 573 to its own local LinkId = 10 and transmits a TestStatusSuccess 574 message over the control channel back to PXC A. The 575 TestStatusSuccess message will include both the local and received 576 LinkIds for the component link. PXC A will send a TestStatusAck 577 message over the control channel back to PXC B indicating it 578 received the TestStatusSuccess message. The process is repeated 579 until all of the component links are verified. At this point, PXC A 580 will send an EndVerify message over the control channel to PXC B to 581 indicate that testing is complete and PXC B will respond by sending 582 an EndVerifyAck message over the control channel back to PXC A. 584 +---------------------+ +---------------------+ 585 + + + + 586 + PXC A +<-------- c --------->+ PCX B + 587 + + + + 588 + + + + 589 + 1 +--------------------->+ 10 + 590 + + + + 591 + + + + 592 + 2 + /---->+ 11 + 593 + + /----/ + + 594 + + /---/ + + 595 + 3 +----/ + 12 + 596 + + + + 597 + + + + 598 + 4 +--------------------->+ 14 + 599 + + + + 600 +---------------------+ +---------------------+ 602 Figure 1: Example of link connectivity between PXC A and PXC B. 604 6. LinkSummary message 606 As part of LMP, a LinkSummary message must be transmitted in order 607 to add component links to a bundled link, change LinkIds, or change 608 a link's protection mechanism. In addition, the LinkSummary message 609 can be exchanged at any time a link is UP and not in the 610 Verification process. The LinkSummary message contains the primary 611 and backup CCIds, the IP address for the link (binding the CCIds to 612 the link IP addresses), and the local and remote LinkIds for each 613 component link and their associated priorities. In addition, each 614 component link may have one or more associated protection component 615 links defined for local (span) protection (e.g., M:N, 1+1). If the 616 LinkSummary message is received from a remote node and the LinkId 617 mappings match those that are stored locally, then the two nodes 618 have agreement on the Verify process. Furthermore, any protection 619 definitions that are included in the LinkSummary message must be 620 accepted or rejected by the local node. To signal agreement on the 621 LinkId mappings and protection definitions, a LinkSummaryAck message 622 is transmitted. Otherwise, a LinkSummaryNack message will be 623 transmitted, indicating which channels are not correct and/or which 624 protection definitions are not accepted. If a LinkSummaryNack 625 message indicates that the LinkId mappings are not correct, the link 626 verification process should be repeated for all mismatched free 627 component links; if an allocated component link has a mapping 628 mismatch, it should be flagged and verified when it becomes free. 629 If, however, a LinkSummaryNack message indicates that a component 630 link's protection mechanism is not accepted, then that component 631 link's protection mechanism cannot be changed; in other words, both 632 local and remote nodes must agree on the protection mechanism for 633 each component link. 635 7. Fault localization 637 In this section, we describe a mechanism in LMP that is used to 638 rapidly isolate link failures. As before, we assume each link has a 639 bi-directional control channel that is always available for inter- 640 node communication and that the control channel spans a single hop 641 between two neighboring nodes. The case where a control channel is 642 no longer available between two nodes is beyond the scope of this 643 draft. The mechanism used to rapidly isolate link failures is 644 designed to work for unidirectional LSPs, and can be easily extended 645 to work for bi-directional LSPs; however, for the purposes of this 646 document, we only discuss the operation when the LSPs are 647 unidirectional. 649 Recall that a bundled link connecting two nodes consists of a 650 control channel and a number of component links. If one or more 651 component links fail between two nodes, a mechanism must be used to 652 rapidly locate the failure so that appropriate 653 protection/restoration mechanisms can be initiated. An important 654 implication of using PXCs is that traditional methods that are used 655 to monitor the health of allocated component links in OEO nodes 656 (e.g., DXCs) may no longer be appropriate, since PXCs are 657 transparent to the bit-rate, format, and wavelength. Instead, fault 658 detection is delegated to the physical layer (i.e., loss of light or 659 optical monitoring of the data) instead of layer 2 or layer 3. 661 7.1. Fault detection 663 As mentioned earlier, fault detection must be handled at the layer 664 closest to the failure; for optical networks, this is the physical 665 (optical) layer. One measure of fault detection at the physical 666 layer is simply detecting loss of light (LOL). Other techniques for 667 monitoring optical signals are still being developed and will not be 668 further considered in this document. However, it should be clear 669 that the mechanism used to locate the failure is independent of the 670 mechanism used to detect the failure, but simply relies on the fact 671 that a failure is detected. 673 7.2. Fault localization mechanism 675 If component links fail between two PXCs, the power monitoring 676 system in all of the downstream nodes will detect LOL and indicate a 677 failure. To correlate multiple failures between a pair of nodes, a 678 monitoring window can be used in each node to determine if a single 679 component link has failed or if multiple component links have 680 failed. 682 As part of the fault localization, a downstream node that detects 683 component link failures will send a ChannelFail message to its 684 upstream neighbor (bundling together the notification of all of the 685 failed component links) and the ports associated with the failed 686 component links will be put into the standby state. An upstream 687 node that receives the ChannelFail message will correlate the 688 failure to see if there is a failure on the corresponding input and 689 output ports for the LSP(s). If there is also a failure on the 690 input port(s) of the upstream node, the node will return a 691 ChannelFailAck message to the downstream node (bundling together the 692 notification of all the component links), indicating that it too has 693 detected a failure. If, however, the fault is CLEAR in the upstream 694 node (e.g., there is no LOL on the corresponding input channels), 695 then the upstream node will have localized the failure and will 696 return a ChannelFailNack message to the downstream node. Once the 697 failure has been localized, the signaling protocols can be used to 698 initiate span or path protection/restoration procedures. 700 7.3. Examples of fault localization 702 In Fig. 2, a sample network is shown where four PXCs are connected 703 in a linear array configuration. The control channels are bi- 704 directional and are labeled with a "c". All LSPs are uni- 705 directional going left to right. 707 In the first example [see Fig. 2(A)], there is a failure on a single 708 component link between PXC2 and PXC3. Both PXC3 and PXC4 will 709 detect the failure and each node will send a ChannelFail message to 710 the corresponding upstream node (PXC3 will send a message to PXC2 711 and PXC4 will send a message to PXC3). When PXC3 receives the 712 ChannelFail message from PXC4, it will correlate the failure and 713 return a ChannelFailAck message back to PXC4. Upon receipt of the 714 ChannelFailAck message, PXC4 will move the associated ports into a 715 standby state. When PXC2 receives the ChannelFail message from PXC3, 716 it will correlate the failure, verify that it is CLEAR, localize the 717 failure to the component link between PXC2 and PXC3, and send a 718 ChannelFailNack message back to PXC3. 720 In the second example [see Fig. 2(B)], there is a failure on three 721 component links between PXC3 and PXC4. In this example, PXC4 has 722 correlated the failures and will send a bundled ChannelFail message 723 for the three failures to PXC3. PXC3 will correlate the failures, 724 localize them to the channels between PXC3 and PXC4, and return a 725 bundled ChannelFailNack message back to PXC4. 727 In the last example [see Fig. 2(C)], there is a failure on the 728 tributary link of the ingress node (PXC1) to the network. Each 729 downstream node will detect the failure on the corresponding input 730 ports and send a ChannelFail message to the upstream neighboring 731 node. When PXC2 receives the message from PXC3, it will correlate 732 the ChannelFail message and return a ChannelFailAck message to PXC3 733 (PXC3 and PXC4 will also act accordingly). Since PXC1 is the 734 ingress node to the optical network, it will correlate the failure 735 and localize the failure to the component link between itself and 736 the network element outside the optical network. 738 +-------+ +-------+ +-------+ +-------+ 739 + PXC 1 + + PXC 2 + + PXC 3 + + PXC 4 + 740 + +-- c ---+ +-- c ---+ +-- c ---+ + 741 ----+---\ + + + + + + + 742 + \--+--------+-------+---\ + + + /--+---> 743 ----+---\ + + + \---+-------+---##---+---/ + 744 + \--+--------+-------+--------+-------+---##---+-------+---> 745 ----+-------+--------+-------+--------+-------+---##---+-------+---> 746 ----+-------+--------+---\ + + + (B) + + 747 + + + \--+---##---+--\ + + + 748 + + + + (A) + \ + + + 749 -##-+--\ + + + + \--+--------+-------+---> 750 (C) + \ + + /--+--------+---\ + + + 751 + \--+--------+---/ + + \--+--------+-------+---> 752 + + + + + + + + 753 +-------+ +-------+ +-------+ +-------+ 755 Figure 2: We show three types of component link failures 756 (indicated by ## in the figure): (A) a single 757 component link fails between two PXCs, (B) three 758 component links fail between two PXCs, and (C) a 759 single component link fails on the tributary input of 760 PXC 1. The control channel connecting two PXCs is 761 indicated with a "c". 763 9. Finite State Machine 765 9.1. Bringing a link UP 767 | 0 | 1 | 2 | 768 -----------------------------|-----|-----|-----| 769 External event starts process| 1a | - | - | 770 | | | | 771 Receive HelloConfig with | 2b,d| 2b,d| 2b,d| 772 agreable parameters | | | | 773 | | | | 774 Receive HelloConfig with | 0c | 1c | 0c | 775 unacceptable parameters | | | | 776 | | | | 777 Receive HelloConfigAck | - | 2d | 2d | 778 | | | | 779 Receive HelloConfigNack | - | 0 | 2b,d| 780 | | | | 781 Receive Hello | - | 1a | 3 | 783 States 784 0 INIT 785 1 CONFIG - Wait for HelloConfig response 786 2 CONFIG - Wait for Hello message 787 3 UP 789 Actions 790 a send HelloConfig 791 b send HelloConfigAck 792 c send HelloConfigNack 793 d send Hello 795 8. LMP Message Formats 797 8.1. Common Header 799 In addition to the standard IP header, all LMP control-channel 800 messages have the following common header: 802 0 1 2 3 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Vers | Flags | Msg Type | (Reserved) | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Control Channel Id | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 Vers: 4 bits 812 Protocol version number. This is version 1. 814 Flags: 8 bits 816 1 = LinkDown 818 2 = ControlChannelSwitchover 820 The remaining flag bits are not yet defined. 822 Msg Type: 8 bits 824 1 = HelloConfig 826 2 = HelloConfigAck 828 3 = HelloConfigNack 830 4 = Hello 832 5 = BeginVerify 834 6 = BeginVerifyAck 836 7 = BeginVerifyNack 838 8 = EndVerify 840 9 = EndVerifyAck 842 10 = Test 843 11 = TestStatusSuccess 845 12 = TestStatusFailure 847 13 = TestStatusAck 849 14 = LinkSummary 851 15 = LinkSummaryAck 853 16 = LinkSummaryNack 855 17 = ChannelFail 857 18 = ChannelFailAck 859 19 = ChannelFailNack 861 All of the messages are sent over the control channel EXCEPT 862 the Test message (Msg Type = 10) which is sent over the 863 component link that is being tested. 865 Control Channel Id: 32 bits 867 The Control Channel Id (CCId) identifies the control channel of 868 the sender associated with the message. For the Test message, 869 which is sent over a component link, this is the control 870 channel associated with the Verify procedure. 872 8.2 Parameter Negotiation 874 8.2.1 HelloConfig Message (MsgType = 1) 876 The HelloConfig message is used to negotiate parameters for the 877 Hello phase of LMP. The format of the HelloConfig message is as 878 follows: 880 ::= 882 The HelloConfig Object has the following format: 884 0 1 2 3 885 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 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Interface IP Address | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | HelloInterval | HelloDeadInterval | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 Interface IP Address: 32 bits. 893 This is the address of the interface (or possibly virtual 894 interface) for the bundled link. If the bundled link is 895 unnumbered, the address is the Router ID of the node. 897 HelloInterval: 16 bits. 899 Indicates how frequently the Hello packets will be sent and is 900 measured in milliseconds (ms). 902 HelloDeadInterval: 16 bits. 904 If no Hello packets are received within the HelloDeadInterval, 905 the control channel is assumed to have failed and is measured 906 in milliseconds (ms). 908 8.2.2 HelloConfigAck Message (MsgType = 2) 910 ::= 912 The HelloConfigAck Object has the following format: 914 0 1 2 3 915 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 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | HelloInterval | HelloDeadInterval | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 HelloInterval: 16 bits. 922 Indicates how frequently the Hello packets will be sent and is 923 measured in milliseconds (ms). 925 HelloDeadInterval: 16 bits. 927 If no Hello packets are received within the HelloDeadInterval, 928 the control channel is assumed to be dead and is measured in 929 milliseconds (ms). 931 The values of the HelloInterval and HelloDeadInterval are copied 932 from the HelloConfig message that is being acknowledged. 934 8.2.3 HelloConfigNack Message (MsgType = 3) 936 ::= 938 The HelloConfigNack Object has the following format: 940 0 1 2 3 941 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 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | HelloInterval | HelloDeadInterval | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 HelloInterval: 16 bits. 947 Indicates how frequently the Hello packets will be sent and is 948 measured in milliseconds (ms). 950 HelloDeadInterval: 16 bits. 952 If no Hello packets are received within the HelloDeadInterval, 953 the control channel is assumed to be dead and is measured in 954 milliseconds (ms). 956 The values of the HelloInterval and HelloDeadInterval MUST be equal 957 to the locally accepted values. 959 8.3 Hello Message (MsgType = 4) 961 The format of the Hello message is as follows: 963 ::= . 965 The Hello object format is shown below: 967 0 1 2 3 968 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 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | TxSeqNum | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | RcvSeqNum | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 TxSeqNum: 32 bits 977 This is the current sequence number for this Hello message. 978 This sequence number will be incremented when either (a) the 979 sequence number is reflected in the RcvSeqNum of a Hello packet 980 that is received over the control channel, or (b) the Hello 981 packet is transmitted over a backup control channel. 983 TxSeqNum=0 is not allowed. 985 TxSeqNum=1 is reserved to indicate that a node has booted or 986 rebooted. 988 RcvSeqNum: 32 bits 990 This is the sequence number of the last Hello message received 991 over the control channel. 993 RcvSeqNum=0 is reserved to indicate that a Hello message has 994 not yet been received. 996 8.4 Link Verification 998 8.4.1 BeginVerify Message (MsgType = 5) 1000 The BeginVerify message is sent over the control channel and is used 1001 to initiate the link verification process. The format is as 1002 follows: 1004 ::= 1006 The BeginVerify object has the following format: 1008 0 1 2 3 1009 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 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | MessageId | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | NumComponentLinks | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | VerifyInterval | EncType | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | BitRate | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Wavelength | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 MessageId: 32 bits 1024 When combined with the CCId and MsgType, the MessageId field 1025 uniquely identifies a message. This value is incremented and 1026 only decreases when the value wraps. This is used for message 1027 acknowledgment in the BeginVerifyAck and BeginVerifyNack 1028 messages. 1030 NumComponentLinks: 32 bits 1032 This is the number of component links that will be verified. 1034 VerifyInterval: 16 bits 1036 This is the interval between successive Test messages. 1038 EncType: 16 bits 1040 This is required for the purpose of testing where the component 1041 links are not required to be the same encoding type as the 1042 control channel. The EncType values are consistent with the 1043 Link Encoding Type values of [KRB00a] and [KRB00b]and are taken 1044 from the following list: 1046 1 Standard SONET 1047 2 Arbitrary SONET 1048 3 Standard SDH 1049 4 Arbitrary SDH 1050 5 Clear (not used) 1051 6 GigE 1052 7 10GigE 1054 BitRate: 32 bits 1056 This is the bit rate at which the Test messages will be 1057 transmitted and is expressed in bytes. 1059 Wavelength: 32 bits 1061 When a component link is assigned to a fiber, it is essential 1062 to know which wavelength the test messages will be transmitted 1063 over. This value corresponds to the wavelength at which the 1064 Test messages will be transmitted over and is measured in 1065 nanometers (nm). If each component link corresponds to a 1066 separate wavelength, than this value SHOULD be set to 0. 1068 8.1.3.3 BeginVerifyAck Message (MsgType = 6) 1070 When a BeginVerify message is received and Test messages are ready 1071 to be processed, a BeginVerifyAck message MUST be transmitted. 1073 ::= 1075 The BeginVerifyAck object has the following format: 1077 0 1 2 3 1078 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 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | MessageId | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | VerifyDeadInterval | (Reserved) | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 MessageId: 32 bits 1087 This is copied from the BeginVerify message being acknowledged. 1089 VerifyDeadInterval: 16 bits 1091 If a Test message is not detected within the 1092 VerifyDeadInterval, then a node will send the TestStatusFailure 1093 message for that component link. 1095 8.1.3.4 BeginVerifyNack Message (MsgType = 7) 1097 If a BeginVerify message is received and a node is unwilling or 1098 unable to begin the Verification procedure, a BeginVerifyNack 1099 message MUST be transmitted. 1101 ::= 1102 The BeginVerifyNack object has the following format: 1104 0 1 2 3 1105 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 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | MessageId | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 MessageId: 32 bits 1112 This is copied from the BeginVerify message being negatively 1113 acknowledged. 1115 8.1.3.2 EndVerify Message (MsgType = 8) 1117 The EndVerify message is sent over the control channel and is used 1118 to terminate the link verification process. The format is as 1119 follows: 1121 ::= 1123 The EndVerify object has the following format: 1125 0 1 2 3 1126 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 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | MessageId | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 MessageId: 32 bits 1133 When combined with the CCId and MsgType, the MessageId field 1134 uniquely identifies a message. This value is incremented and 1135 only decreases when the value wraps. This is used for message 1136 acknowledgement in the EndVerifyAck message. 1138 8.1.3.2 EndVerifyAck Message (MsgType =9) 1140 The EndVerifyAck message is sent over the control channel and is 1141 used to acknowledge the termination of the link verification 1142 process. The format is as follows: 1144 ::= 1146 The EndVerifyNack object has the following format: 1148 0 1 2 3 1149 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 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | MessageId | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 MessageId: 32 bits 1155 This is copied from the EndVerify message being acknowledged. 1157 8.1.3.5 Test Message (MsgType = 10) 1159 The Test message is transmitted over the component link and is used 1160 to verify the component link connectivity. The format is as 1161 follows: 1163 ::= 1165 The Test object has the following format: 1167 0 1 2 3 1168 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 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | LinkId | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 LinkId: 32 bits 1175 The LinkId identifies the component link over which this 1176 message is sent. A valid LinkId MUST be nonzero. 1178 Note that this message is sent over a component link and NOT over 1179 the control channel. 1181 8.1.3.6 TestStatusSuccess Message (MsgType = 11) 1183 The TestStatusSuccess message is transmitted over the control 1184 channel and is used to transmit the mapping between the local LinkId 1185 and the LinkId that was received in the Test message. 1187 ::= 1189 The TestStatusSuccess object has the following format: 1191 0 1 2 3 1192 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 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | MessageId | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Received LinkId | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Local LinkId | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 MessageId: 32 bits 1203 When combined with the CCId and MsgType, the MessageId field 1204 uniquely identifies a message. This value is incremented and only 1205 decreases when the value wraps. This is used for message 1206 acknowledgement in the TestStatusAck message. 1208 Received LinkId: 32 bits 1210 This is the value of the LinkId that was received in the Test 1211 message. A valid LinkId MUST be nonzero, therefore, a value of 1212 0 in the Received LinkId indicates that the Test message was 1213 not detected. 1215 Local LinkId: 32 bits 1217 This is the local value of the LinkId. A valid LinkId MUST be 1218 nonzero. 1220 8.1.3.6 TestStatusFailure Message (MsgType = 12) 1222 The TestStatusFailure message is transmitted over the control 1223 channel and is used to indicate that the Test message was not 1224 received. 1226 ::= 1228 The TestStatusFailure object has the following format: 1230 0 1 2 3 1231 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 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | MessageId | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 MessageId: 32 bits 1238 When combined with the CCId and MsgType, the MessageId field 1239 uniquely identifies a message. This value is incremented and 1240 only decreases when the value wraps. This is used for message 1241 acknowledgement in the TestStatusAck message. 1243 8.1.3.7 TestStatusAck Message (MsgType = 13) 1245 The TestStatusAck message is used to acknowledge receipt of the 1246 TestStatusSuccess or TestStatusFailure messages. 1248 ::= 1250 The TestStatusAck object has the following format: 1252 0 1 2 3 1253 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 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | MessageId | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 MessageId: 32 bits 1259 This is copied from the TestStatusSuccess or TestStatusFailure 1260 message being acknowledged. 1262 8.5 Link Summary Messages 1264 8.5.1 LinkSummary Message (MsgType = 14) 1266 The LinkSummary message is used to synchronize the LinkIds and 1267 correlate the properties of the link. The format of the LinkSummary 1268 message is as follows: 1270 ::= 1272 The LinkSummary Object has the following format: 1274 0 1 2 3 1275 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 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | MessageId | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Interface IP Address | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | NumWorking | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | NumProtection | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | | 1286 // (working channel subobjects) // 1287 | | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | | 1290 // (protection channel subobjects) // 1291 | | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 MessageId: 32 bits 1296 When combined with the CCId and MsgType, the MessageId field 1297 uniquely identifies a message. This value is incremented and 1298 only decreases when the value wraps. This is used for message 1299 acknowledgement in the LinkSummaryAck and LinkSummaryNack 1300 messages. 1302 Interface IP Address: 32 bits 1304 This is the local IP address of the interface (or possibly 1305 virtual interface) for the bundled link. If the bundled link 1306 is unnumbered, the address is the Router ID of the node. 1308 NumWorking: 32 bits 1310 This value is the number of working channels in the link. This 1311 also indicates how many working channel subobjects are in the 1312 LinkSummary message. 1314 NumProtection: 32 bits 1316 This value is the number of protection channels in the link. 1317 This also indicates how many protection channel subobjects are 1318 in the LinkSummary message. 1320 The LinkSummary message contains a list of working channel 1321 subobjects and protection channel subobjects. The list of working 1322 channels MUST include the control channel. 1324 The Working Channel Subobject has the following format: 1326 0 1 2 3 1327 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 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | Local Id | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Received Id | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Priority | (Reserved) | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 Local Id: 32 bits 1338 This is the local value of the LinkId (for component link) or 1339 CCId (for control channel). 1341 Received Id: 32 bits 1343 This is the value of the corresponding Id. If this is a 1344 component link, then this is the value that was received in the 1345 Test message. If this is the primary control channel, then 1346 this is the value that is received in all of the Verify 1347 messages. 1349 Priority: 8 bits 1351 This is the channel priority and is in the range of 0 to 7. 1352 The value 0 is the highest priority. The control channel MUST 1353 have a priority of 0. 1355 The Protection Channel Subobject has the following format: 1357 0 1 2 3 1358 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 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | Local Id | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 | Received Id | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | Priority | Type | (Reserved) | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | NumWorking | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | | 1369 // (WorkingProtect Subobjects) // 1370 | | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 Local Id: 32 bits 1375 This is the local value of the LinkId. This could be a 1376 protection component link and/or a protection control channel. 1377 In addition, a protection control channel could also be a 1378 working component link (so it could appear in both the working 1379 channel subobject as well as the protection channel subobject). 1381 Received Id: 32 bits 1383 This is the value of the corresponding LinkId that was received 1384 in the Test message. 1386 Priority: 8 bits. 1388 The priority of the resources, in the range of 0 to 7. The 1389 value 0 is the highest priority. 1391 Type: 4 bits. 1393 This is the protection type. 1395 1 = 1+1 protection 1397 2 = M:N protection 1399 NumWorking: 32 bits 1401 This is the number of working channels that this channel is 1402 protecting. This defines the number of WorkingProtect 1403 subjects. 1405 The WorkingProtect Subobject has the following format: 1407 0 1 2 3 1408 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 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | Local Channel Id | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 Local Channel Id: 32 bits 1414 This is the local channel Id of the working channel that is 1415 being protected. This channel could be a control channel or a 1416 component link. 1418 8.5.2 LinkSummaryAck Message (MsgType = 15) 1420 The LinkSummaryAck message is used to indicate agreement on the 1421 LinkId synchronization and acceptance/agreement on all the link 1422 parameters. 1424 ::= 1426 The LinkSummaryAck object has the following format: 1428 0 1 2 3 1429 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 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | MessageId | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 MessageId: 32 bits 1436 This is copied from the LinkSummary message being acknowledged. 1438 8.5.3 LinkSummaryNack Message (MsgType = 16) 1440 The LinkSummaryNack message is used to indicate disagreement on 1441 LinkId synchronization and/or the link parameters. 1443 ::= 1445 The LinkSummaryNack object has the following format: 1447 0 1 2 3 1448 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 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | MessageId | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | NumWorking | 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | NumProtection | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | | 1457 // (working channel subobjects) // 1458 | | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | | 1461 // (protection channel subobjects) // 1462 | | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 MessageId: 32 bits 1466 This is copied from the LinkSummary message being negatively 1467 acknowledged. 1469 NumWorking: 32 bits 1471 This value is the number of working channels in the LinkSummary 1472 message that are being negatively acknowledged. This also 1473 indicates how many working channel subobjects are in the 1474 LinkSummaryNack message. 1476 NumProtection: 32 bits 1478 This value is the number of protection channels in the 1479 LinkSummary message that are being negatively acknowledged. 1480 This also indicates how many protection channel subobjects are 1481 in the LinkSummaryNack message. 1483 The Working Channel and Protection Channel Subobjects are copied 1484 from the LinkSummary message being negatively acknowledged. These 1485 represent the Subobjects that were not accepted. 1487 As an optimization, the entire LinkSummary message can be rejected 1488 by setting NumWorking = NumProtection = 0. If this is done, the 1489 working and protection channel subobjects are not required in the 1490 LinkSummaryNack message. 1492 8.6 Failure Messages 1494 8.6.1 ChannelFail Message (MsgType = 17) 1496 The ChannelFail message is sent over the control channel and is used 1497 to query a neighboring node when a link or channel failure is 1498 detected. The format is as follows: 1500 ::= 1502 The format of the ChannelFail object is as follows: 1504 0 1 2 3 1505 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 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | MessageId | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | NumFailedChannels | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | | 1512 // (FailedChannel subobjects) // 1513 | | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 MessageId: 32 bits 1518 When combined with the CCId and MsgType, the MessageId field 1519 uniquely identifies a message. This value is incremented and 1520 only decreases when the value wraps. This is used for message 1521 acknowledgement in the ChannelFailAck and ChannelFailNack 1522 messages. 1524 NumFailedChannels: 32 bits 1526 This value indicates how many channels have failed. This also 1527 defines the number of FailedChannel subobjects. 1529 The FailedChannel Subobjects is a list of the failed channels and 1530 has the following format: 1532 0 1 2 3 1533 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 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | Local LinkId | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 Local LinkId: 32 bits 1540 This is the local LinkId of the component link that has failed. 1542 8.6.2 ChannelFailAck Message (MsgType = 18) 1544 The ChannelFailAck message is used to indicate that all of the 1545 failed channels reported in the ChannelFail message also have 1546 failures on the corresponding input channels. The format is as 1547 follows: 1549 ::= 1551 The ChannelFailureAck object has the following format: 1553 0 1 2 3 1554 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 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | MessageId | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 MessageId: 32 bits 1561 This is copied from the ChannelFail message being acknowledged. 1563 8.6.3 ChannelFailNack Message (MsgType = 19) 1565 The ChannelFailNack message is used to indicate that the failed 1566 component link(s) reported in the ChannelFail message are CLEAR in 1567 the upstream node, and hence, the failure has been isolated between 1568 the two nodes. 1570 ::= 1572 The ChannelFailNack object has the following format: 1574 0 1 2 3 1575 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 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 | MessageId | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 | NumChannelClear | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 | | 1582 // (ChannelClear subobject) // 1583 | | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 MessageId: 32 bits 1588 This is copied from the ChannelFail message being negatively 1589 acknowledged. 1591 NumChannelFail: 32 bits 1593 This value is the number of failed component links reported in 1594 the ChannelFail message that also have failures on the 1595 corresponding inputs. 1597 NumChannelClear: 32 bits 1599 This is the number of failed component links reported in the 1600 ChannelFail message that are CLEAR in the upstream node. This 1601 also indicates how many ChannelClear subobjects are in the 1602 ChannelFailNack message. 1604 The ChannelClear subobject is used to indicate which failed 1605 component links have been isolated and has the following format: 1607 0 1 2 3 1608 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 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 | Local LinkId | 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 Local LinkId: 32 bits 1615 This is the local LinkId of the component link where the 1616 failure has been isolated. 1618 9. Security Considerations 1620 Security considerations are for future study, however, LMP is a 1621 point-to-point protocol so security is largely derived from the 1622 physical security of the optical network. 1624 10. References 1626 [Bra96] Bradner, S., "The Internet Standards Process -- Revision 3," 1627 BCP 9, RFC 2026, October 1996. 1629 [KRB00] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 1630 MPLS Traffic Engineering," Internet Draft, draft-kompella- 1631 mpls-bundle-01.txt, July 2000. 1633 [ABD00] Ashwood-Smith, P., Berger, L., et al, "Generalized MPLS - 1634 Signaling Functional Description," Internet Draft, draft- 1635 generalized-signaling-00.txt, July 2000. 1637 [RNT99] Rosen, E. C., Rekhter, Y., et al, "MPLS Label Stack 1638 Encoding," Internet Draft, draft-ietf-mpls-label-encaps- 1639 07.txt, September 1999. 1641 [ARD99] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., "Multi- 1642 Protocol Lambda Switching: Combining MPLS Traffic 1643 Engineering Control with Optical Crossconnects," Internet 1644 Draft, draft-awduche-mpls-te-optical-00.txt, October 1999. 1646 [CBD00] Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski, J., 1647 Edwards, W. L., "Performance Monitoring in Photonic 1648 Networks," Internet Draft, draft-ceuppens-mpls-optical- 1649 00.txt, March 2000. 1651 [ABG99] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Swallow, G., 1652 Srinivasan, V., "Extensions to RSVP for LSP Tunnels," 1653 Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-04.txt, 1654 September 1999. 1656 [Jam99] Jamoussi, B., et al, "Constraint-Based LSP Setup using LDP," 1657 Internet Draft, draft-ietf-mpls-cr-ldp-03.txt, September 1658 1999. 1660 [KaY99] Katz, D., Yeung, D., "Traffic Engineering Extensions to 1661 OSPF," Internet Draft, draft-katz-yeung-ospf-traffic-01.txt, 1662 1999. 1664 [SmL99] Smit, H. and Li, T., "IS-IS extensions for Traffic 1665 Engineering," Internet Draft, 1999. 1667 [KRB00a] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF 1668 Extensions in Support of Generalized MPLS," Internet Draft, 1669 draft-kompella-ospf-extensions-00.txt, July 2000. 1671 [KRB00b] Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS 1672 Extensions in Support of Generalized MPLS," Internet Draft, 1673 draft-kompella-isis-extensions-00.txt, July 2000. 1675 9. Acknowledgments 1677 The authors would like to thank Adrian Farrel, Vishal Sharma, and 1678 Stephen Shew for their comments on the draft. 1680 10. Author's Addresses 1682 Jonathan P. Lang Krishna Mitra 1683 Calient Networks Calient Networks 1684 25 Castilian Drive 5853 Rue Ferrari 1685 Goleta, CA 93117 San Jose, CA 95138 1686 Email: jplang@calient.net email: krishna@calient.net 1688 John Drake Kireeti Kompella 1689 Calient Networks Juniper Networks, Inc. 1690 5853 Rue Ferrari 385 Ravendale Drive 1691 San Jose, CA 95138 Mountain View, CA 94043 1692 email: jdrake@calient.net email: kireeti@juniper.net 1694 Yakov Rekhter Debanjan Saha 1695 Cisco Systems Tellium Optical Systems 1696 170 W. Tasman Dr. 2 Crescent Place 1697 San Jose, CA 95134 Oceanport, NJ 07757-0901 1698 email: yakov@cisco.com email: dsaha@tellium.com 1700 Lou Berger Debashis Basak 1701 LabN Consulting, LLC Marconi 1702 email: lberger@labn.net 1000 Fore Drive 1703 Warrendale, PA 15086-7502 1704 email: dbasak@fore.com 1706 Hal Sandick 1707 Nortel Networks 1708 email: hsandick@nortelnetworks.com