idnits 2.17.1 draft-ietf-mpls-lmp-00.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 2 longer pages, 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 190: '... link MUST have an associated contro...' RFC 2119 keyword, line 220: '... control channel SHOULD be tried. Of ...' RFC 2119 keyword, line 221: '... channels SHOULD be pre-configured, ...' RFC 2119 keyword, line 295: '...se. Negotiation MUST only be done whe...' RFC 2119 keyword, line 311: '... MUST be greater than the HelloInter...' (26 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-02 -- 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-02 -- 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-06 == 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-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (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: 8 errors (**), 0 flaws (~~), 12 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jonathan P. Lang (Calient Networks) 2 Internet Draft Krishna Mitra (Calient Networks) 3 Expiration Date: January 2001 John Drake (Calient Networks) 4 Kireeti Kompella (Juniper Networks) 5 Yakov Rekhter (Cisco Systems) 6 Lou Berger (LabN Consulting, LLC) 7 Debanjan Saha (Tellium) 8 Debashis Basak (Marconi) 9 Hal Sandick (Nortel Networks) 11 Link Management Protocol (LMP) 13 draft-ietf-mpls-lmp-00.txt 15 1. Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [Bra96]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet- Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 2. Abstract 38 Future networks will consist of photonic switches, optical 39 crossconnects, and routers that may be configured with bundled links 40 consisting of a number of user component links and an associated 41 control channel. This draft specifies a link management protocol 42 (LMP) that runs between neighboring nodes and will be used for both 43 link provisioning and fault isolation. A unique feature of LMP is 44 that it is able to isolate faults in both opaque and transparent 45 networks, independent of the encoding scheme used for the component 46 links. LMP will be used to maintain control channel connectivity, 47 verify component link connectivity, and isolate link, fiber, or 48 channel failures within the network. 50 3. Introduction 52 Future networks will consist of photonic switches (PXCs), optical 53 crossconnects (OXCs), routers, switches, DWDM systems, and add-drop 54 multiplexors (ADMs) that use the MPLS control plane to dynamically 55 provision resources and to provide network survivability using 56 protection and restoration techniques. A pair of nodes (e.g., two 57 PXCs) may be connected by thousands of fibers, and each fiber may be 58 used to transmit multiple wavelengths if DWDM is used. Furthermore, 59 multiple fibers and/or multiple wavelengths may be combined into a 60 single bundled link, where we define such a link as a logical 61 relationship associating a bi-directional control channel with zero 62 or more unidirectional component links (see also [KRB00]). 64 For the purposes of this document, the granularity of a component 65 link is a wavelength, a waveband, or a fiber depending on the ports 66 that are exposed to the adjacent nodes. For example, if a cross- 67 connect is connected to a DWDM device, then the ports of the cross- 68 connect (and hence the component links) correspond to wavelengths. 69 If, however, the cross-connect multiplexes the wavelengths 70 internally before connecting them to another node, then the ports of 71 the cross-connect (and hence the component links) correspond to a 72 fiber. In general, a bundled link between two nodes will be 73 identified by a local and remote 32-bit interface (possibly a 74 virtual interface) address, and the control channel will be 75 identified by a local and remote 32-bit control channel Id (CCId). 76 Similarly, each node will identify each component link with a local 77 LinkId. LMP gives the association between the endpoints of the 78 bundled link, control channel, and component links. 80 Within the framework of the Generalized Label [ABD00], the LinkId is 81 required whenever there is ambiguity as to where the labels are to 82 be allocated. In the following, we describe how the LinkId is used 83 for the various multiplexing capabilities of a node. For the PSC 84 case, the Generalized Label includes a LinkId (corresponding to a 85 fiber) and the normal MPLS label. For the TDM case, the Generalized 86 Label includes a LinkId (corresponding to a fiber) and the Mannie 87 encoded label. For the LSC case there are two options for the 88 Generalized Label depending on if the wavelengths are exposed to the 89 adjacent nodes or not; it could include the LinkId (corresponding to 90 a fiber) and a wavelength label (corresponding to a wavelength 91 within the fiber), or it could include just the LinkId 92 (corresponding to a wavelength), where a label is present but 93 ignored. Finally, for the FSC case, the Generalized Label includes 94 only a linkId (corresponding to a fiber) and a label is present but 95 ignored. 97 A unique feature of a link as defined above is that the control 98 channel and the associated component links are not required to be 99 transmitted along the same physical medium. For example, the 100 control channel could be transmitted along a separate wavelength or 101 fiber, or on an Ethernet link between the two neighbors. A 102 consequence of allowing the control channel of a link to be 103 physically diverse from the associated component links is that the 104 health of a control channel on a link does not necessarily correlate 105 to the health of the component links, and vice-versa. Therefore, 106 new mechanisms must be developed to manage links, both in terms of 107 link provisioning and fault isolation. 109 This draft specifies a link management protocol (LMP) that runs 110 between neighboring nodes and will be used for both link 111 provisioning and fault isolation. All of the LMP messages 112 transmitted over the control channel are IP encoded, so that the 113 link level encoding becomes an implementation agreement and is not 114 part of LMP specifications. The LMP messages that are transmitted 115 over a component link will be a new protocol type. For example, if 116 it is over Ethernet, it will be a new Ethertype, and if it is over 117 SONET/SDH, the HDLC framing defined for PPP over SONET will be used 118 with the MPLSCP defined in Section 4 of [RNT99]. 120 In this draft, we will follow the naming convention of [ARD99] and 121 use OXC to refer to all categories of optical crossconnects, 122 irrespective of the internal switching fabric. We distinguish 123 between crossconnects that require opto-electronic conversion, 124 called digital crossconnects (DXCs), and those that are all-optical, 125 called photonic switches or photonic crossconnects (PXCs) - referred 126 to as pure crossconnects in [ARD99], because the transparent nature 127 of PXCs introduces new restrictions for monitoring and managing the 128 data channels (see [CBD00] for proposed extensions to MPLS for 129 performance monitoring in photonic networks). LMP, however, can be 130 used for any type of node, enhancing the functionality of 131 traditional DXCs, DWDMs, and routers, while enabling PXCs to 132 intelligently interoperate in heterogeneous optical networks. 134 Due to the transparent nature of PXCs, traditional methods can no 135 longer be used to monitor and manage links and LMP has been designed 136 to address these issues in optical networks. In addition, since LMP 137 does not dictate the actual transport mechanism, it can be 138 implemented in a heterogeneous network. A requirement for LMP is 139 that each link has an associated bi-directional control channel and 140 that a free (unallocated) component link must be opaque (i.e., able 141 to be terminated); however, once a component link is allocated, it 142 may become transparent. Note that there is no requirement that all 143 of the component links must be terminated simultaneously, but at a 144 minimum, they must be able to be terminated one at a time. There is 145 no requirement that the control channel and component links share 146 the same medium; however, the control channel must terminate on the 147 same two nodes that the component links span. 149 LMP is a protocol that runs between adjacent nodes and is designed 150 to provide four basic functions for the node pair: control channel 151 management, link connectivity verification, link property 152 correlation, and fault isolation. Control channel management is 153 used to establish and maintain link connectivity between neighboring 154 nodes. This is done using lightweight Hello messages that act as a 155 fast keep-alive mechanism between the nodes. Link connectivity 156 verification is used to verify the physical connectivity of the 157 component links as well as exchange the LinkIds that are used in the 158 Generalized Label [ABD00] for MPLS. Link property correlation 159 consists of LinkSummary messages that exchange the local/remote CCId 160 mappings that were learned when establishing control channel 161 connectivity; the local/remote LinkId mappings that were discovered 162 as a result of the link connectivity verification process; the 163 protection control channels for maintaining link connectivity; and 164 the protection component links that are used for span protection. 165 The fault isolation mechanism can localize failures in both opaque 166 and transparent networks, independent of the encoding scheme used 167 for the component links, and as a result, both local span and end- 168 to-end path protection/restoration procedures can be initiated. 170 The organization of the remainder of this document is as follows. 171 In Section 4, we discuss the role of the control channel and the 172 messages used to establish and maintain link connectivity. The link 173 verification procedure is discussed in Section 5. In Section 6, we 174 show how LMP will be used to isolate link and channel failures 175 within the optical network. 177 4. Control channel management 179 To establish a bundled link between two nodes, a bi-directional 180 primary control channel must first be configured. The control 181 channel can be used to exchange MPLS control-plane information such 182 as link provisioning and fault isolation information (implemented 183 using a messaging protocol such as LMP, proposed in this draft), 184 path management and label distribution information (implemented 185 using a signaling protocol such as RSVP-TE [ABG99]or CR-LDP 186 [Jam99]), and topology and state distribution information 187 (implemented using traffic engineering extended protocols such as 188 OSPF [KaY99]and IS-IS [SmL99]). Each bundled link is identified by 189 a 32-bit IP interface (possibly virtual interface) and each bundled 190 link MUST have an associated control channel; however, we do not 191 specify the exact implementation of the control channel. Rather, we 192 assign a 32-bit integer control channel identifier (CCId) to each 193 direction of the control channel and we define the control channel 194 messages to be IP encoded. This allows the control channel 195 implementation to encompass both in-band and out-of-band mechanisms, 196 including the case where the control channel is transmitted 197 separately from the associated component link(s), either on a 198 separate wavelength or on a separate fiber. Furthermore, since the 199 messages are IP encoded, the link level encoding is not part of LMP. 201 The control channel of a link can be either explicitly configured or 202 automatically selected, however, for the purpose of this document we 203 will assume the control channel is explicitly configured. Note that 204 for in-band signaling, a control channel could be allocated to a 205 component link; however, this is not true when the control channel 206 is transmitted separately from the component links. In addition to 207 a primary control channel, an ordered list of backup control 208 channels can also be specified. Depending on the control channel 209 implementation, the list of backup control channels may include 210 component links, provided control channels have preemptive priority 211 over the user data traffic. 213 For LMP, it is essential that a control channel is always available 214 for a link, and in the event of a control channel failure, an 215 alternate (or backup) control channel must be made available to 216 reestablish communication with the neighboring node. Since control 217 channels are electrically terminated at each node, the failure of a 218 control channel can be detected by lower layers (e.g., SONET/SDH). 219 If the primary control channel cannot be established, then a backup 220 control channel SHOULD be tried. Of course, alternate control 221 channels SHOULD be pre-configured, however, coordinating the 222 switchover of the control channel to an alternate channel is still 223 an important issue. Specifically, if the control channel fails but 224 the node is still operational (i.e., the component links are still 225 passing user data), then both the local and remote nodes should 226 switch to an alternate control channel. If the bi-directional 227 control channel is implemented using two separate unidirectional 228 channels, and only one direction of the control channel has failed, 229 both the local and remote nodes need to understand that the channel 230 has failed so that they can coordinate a switchover. 232 4.1. LMP Link States 234 A link can be in any of four well-defined states: DOWN, Configure 235 (CONFIG), UP, and Degraded (DEG). These states apply to the link as 236 a whole, including both control channel and component links. Many 237 of these states have multiple sub-states that are described later in 238 this document. 240 +----+ +------+ +----+ +---+ 241 | | (1) | | (2) | | (3) | | 242 | DOWN | ----> | CONFIG | ----> | UP | ----> | DEG | 243 | | | | | | | | 244 +----+ +------+ +----+ +---+ 245 ^ ^ | | | 246 | | (5) | (5) | | 247 | (4) ------------------------------ | 248 ----------------------------------------------- 250 4.1.1 Link States 252 DOWN: Link Down. Communication not established, Hello 253 configuration not 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 4.1.2 State transition events 267 (1) The parameter negotiation phase is initiated. 269 (2) The control channel is UP and Hello messages are being 270 exchanged. 272 (3) The control channel and backup control channel(s) are not 273 available, and the component links are still in use. 275 (4) The control channel and backup control channel(s) are not 276 available, and the component links are failed or not in use. 277 This includes the case where a control channel is brought down 278 administratively. 280 (5) The parameter negotiation phase is initiated. 282 4.2. Hello protocol 284 Once a control channel is configured between two neighboring nodes, 285 a Hello protocol will be used to establish and maintain connectivity 286 between the nodes and to detect link and channel failures. The 287 Hello protocol of LMP is intended to be a lightweight keep-alive 288 mechanism that will react to control channel failures rapidly so 289 that IGP Hellos are not lost and the associated link-state 290 adjacencies are not removed unnecessarily. Furthermore, the RSVP 291 Hello of [ABG99] is not needed since the LMP Hellos will detect link 292 layer failures. 294 The Hello protocol consists of two phases: a negotiation phase and 295 a keep-alive phase. Negotiation MUST only be done when the link is 296 in the CONFIG state, and is used to exchange the CCIds and agree 297 upon the parameters used in the keep-alive phase. The keep-alive 298 phase consists of a fast lightweight Hello message exchange. 300 4.2.1. Parameter Negotiation 302 Before initiating the Hello protocol of the keep-alive phase, the 303 local and remote CCId must be exchanged and the HelloInterval and 304 HelloDeadInterval parameters must be agreed upon. The HelloInterval 305 indicates how frequently LMP Hello messages will be sent, and is 306 measured in milliseconds (ms). For example, if the value were 5, 307 then the transmitting node would send the Hello message at least 308 every 5ms. The HelloDeadInterval indicates how long a device should 309 wait to receive a Hello message before declaring a control channel 310 dead, and is measured in milliseconds (ms). The HelloDeadInterval 311 MUST be greater than the HelloInterval, and SHOULD be at least 3 312 times the value of HelloInterval. 314 The parameter negotiation consists of three messages: a HelloConfig 315 message, a HelloConfigAck message, and a HelloConfigNack message. 316 The HelloConfigAck and HelloConfigNack messages are used to 317 acknowledge receipt of the HelloConfig message. The HelloConfigNack 318 message is also used to suggest alternate values for the 319 HelloInterval and HelloDeadInterval parameters. To initiate the 320 negotiation process, a node sends a HelloConfig message containing 321 the CCId for the control channel, the IP address of the bundled 322 link, and the proposed HelloInterval and HelloDeadInterval. The 323 node also starts a single-shot timer that is used for 324 retransmissions in the event of message loss. 326 When a HelloConfig message is received at a node, a HelloConfigAck 327 message SHOULD be transmitted if the received HelloInterval and 328 HelloDeadInterval values are acceptable. Otherwise, the node MUST 329 reject the parameters by sending a HelloConfigNack message. The 330 HelloConfigNack message MUST include acceptable values for the 331 HelloInterval and HelloDeadInterval. 333 When a node has either sent or received a HelloConfigAck message, it 334 may begin sending Hello messages. Once it has both sent and 335 received a Hello message, the link is UP. If, however, a node 336 receives a HelloConfigNack message instead of a HelloConfigAck 337 message, the node MUST not begin sending Hello messages. However, if 338 the HelloInterval and HelloDeadInterval included in the received 339 HelloConfigNack message are locally acceptable, the node SHOULD send 340 a new HelloConfig message with these values to the adjacent node. 342 4.2.2. Fast keep-alive 344 Once the parameters have been agreed upon and a node has sent and 345 received a HelloConfigAck message, it may begin sending Hello 346 messages. Each Hello message will contain two sequence numbers: the 347 first sequence number (TxSeqNum) is the sequence number for this 348 Hello message and the second sequence number (RcvSeqNum) is the 349 sequence number of the last Hello message received from the adjacent 350 node. Each node increments its sequence number when it sees its 351 current sequence number reflected in Hellos received from its peer. 352 The sequence numbers will be 32-bit lollipop sequence numbers that 353 start at 1 and wrap around back to 2; 0 is used in the RcvSeqNum to 354 indicate that a Hello has not yet been seen and 1 is used to 355 indicate a node boot/reboot. 357 Under normal operation, the difference between the RecSeqNum and 358 local SendSeqNum will be at most 1. There are only two cases where 359 this difference can be more than 1: when a node reboots and when 360 switching over to a backup control channel. 362 Having sequence numbers in the Hello messages allows each node to 363 verify that its peer is receiving its Hello messages. This provides 364 a two-fold service. First, the remote node will detect that a node 365 has rebooted if TxSeqNum=1. If this occurs, the remote node will 366 indicate its knowledge of the reboot by setting RcvSeqNum=1 in the 367 Hello messages that it sends and SHOULD wait to receive a Hello 368 message with TxSeqNum=2 before transmitting any messages other than 369 Hello messages. Second, by including the RcvSeqNum in Hello 370 packets, the local node will know which Hello packets the remote 371 node has received. This is important because it helps coordinate 372 control-channel switchover in case of a control channel failure. 374 4.2.3. Control channel switchover 376 As mentioned above, LMP requires that a control channel always be 377 available for a link, and multiple mechanisms are used within LMP to 378 ensure that the switchover of a control channel is both smooth and 379 proper. Control channels may need to be switched as a result of a 380 control channel failure or for administration purposes (e.g., 381 routine fiber maintenance, reverting back to a primary control 382 channel, etc.), and peer connectivity must be maintained to ensure 383 that unnecessary rerouting of user traffic is avoided and false 384 failures are not reported. 386 To ensure that a smooth transition occurs when switching to a backup 387 control channel, a ControlChannelSwitchover flag is available in the 388 Common Header of LMP packets. The receipt of a Hello message with 389 ControlChannelSwitchover = 1 indicates that the remote node is 390 switching to the backup control channel, and the local node MUST 391 begin listening to the backup control channel in addition to the 392 primary control channel. 394 To ensure that both nodes switch to the backup control channel 395 successfully, both the local and remote nodes MUST transmit messages 396 over both the primary and backup control channels until the 397 switchover is successful. Messages on the primary control channel 398 MUST have the ControlChannelSwitchover flag set to 1 and MUST not 399 increment the TxSeqNum (even upon the receipt of a Hello message 400 with the current TxSeqNum reflected in the RcvSeqNum field). 401 Messages on the backup control channel MUST set the 402 ControlChannelSwitchover flag to 0 and MUST increment the TxSeqNum 403 by 1 to distinguish messages on the two channels. If the TxSeqNum 404 of the Hello messages on the backup control channel are reflected in 405 the RcvSeqNum of Hello messages being received, then the TxSeqNum 406 MUST be incremented (as per normal operation); this indicates that 407 the backup control channel is operational in the transmit direction 408 and the local node may now stop transmitting Hello messages over the 409 primary control channel. Once a Hello message is received over the 410 backup control channel indicating that the remote node is receiving 411 confirmation of Hello message receipt (this is indicated by an 412 incrementing TxSeqNum), then the local node may stop listening on 413 the primary control channel. When both nodes are only 414 transmitting/receiving Hello packets over the backup control 415 channel, the switchover is successful. 417 4.2.4. Taking a link down administratively 419 As mentioned above, a link is DOWN when the control channel and 420 backup control channel(s) are not available and none of the 421 component links are in use. A link may be DOWN, for example, when a 422 link is reconfigured for administrative purposes. A link SHOULD 423 only be administratively taken down if the component links are not 424 in use. To ensure that bringing a link DOWN is done gracefully for 425 administration purposes, a LinkDown flag is available in the Common 426 Header of LMP packets. 428 When a node receives LMP packets with LinkDown = 1, it must first 429 verify that it is able to bring the link down on its end. Once the 430 verification is done, it must set the LinkDown flag to 1 on all of 431 the LMP packets that it sends. When the node that initiated the 432 LinkDown procedure receives LMP packets with LinkDown = 1, it may 433 then bring the link DOWN. 435 4.2.5. Degraded (DEG) state 437 A consequence of allowing the control channels and component links 438 to be transmitted along a separate medium is that the link may be in 439 a state where a control channel and backup control channel(s) are 440 not available, but the component links are still in use. For many 441 applications, it is unacceptable to drop traffic that is in use 442 simply because the control channel is no longer available; however, 443 the traffic that is using the component links may no longer be 444 guaranteed the same level of service. Hence the link is in a 445 Degraded (DEG) state. 447 When a link is in the DEG state, the routing protocol should be 448 notified so that new connections are not accepted and resources are 449 no longer advertised for the link. To bring a link back UP out of a 450 degraded state, a node may begin transmitting HelloConfig messages 451 over the primary control channel. 453 5. Verifying link connectivity 455 In this section, we describe the mechanism used to verify the 456 physical connectivity of the component links. This will be done 457 initially when a link is established, and subsequently, on a 458 periodic basis for all free component links of a bundled link. A 459 unique characteristic of all-optical PXCs is that the data being 460 transmitted over a component link is not terminated at the PXC, but 461 instead passes through transparently. This characteristic of PXCs 462 poses a challenge for validating the connectivity of the component 463 links since shining unmodulated light through a component link may 464 not result in received light at the next PXC. This is because there 465 may be terminating (or opaque) elements, such as DWDM equipment, in 466 between the PXCs. Therefore, to ensure proper verification of 467 component link connectivity, we require that until the component 468 links are allocated, they must be opaque. There is no requirement 469 that all component links be terminated simultaneously, but at a 470 minimum, the component links must be able to be terminated one at a 471 time. Furthermore, we assume that the nodal architecture is 472 designed so that messages can be sent and received over any 473 component link. Note that this requirement is trivial for DXCs (and 474 OEO nodes in general) since each component link is received 475 electronically before being forwarded to the next DXC, but that in 476 PXCs this is an additional requirement. 478 To interconnect two nodes, a link must be added between them, and at 479 a minimum, the link must contain a control channel spanning the two 480 nodes. Optionally, the attributes of a link may include the 481 protection mechanism for the control channel (possibly including an 482 ordered list of backup control channels), a list of component links, 483 and the protection mechanism for each component link. 485 As part of the link verification protocol, the primary control 486 channel is first verified, and connectivity maintained, using the 487 Hello protocol discussed in Section 4. Once the control channel has 488 been established between the two nodes, component link connectivity 489 is verified by exchanging Ping-type Test messages over each of the 490 component links specified in the bundled link. It should be noted 491 that all LMP messages except for the Test message are exchanged over 492 the control channel and that Hello messages continue to be exchanged 493 over the control channel during the component link verification 494 process. The Test message is sent over the component link that is 495 being verified. Component links are tested in the transmit 496 direction as they are uni-directional, and as such, it may be 497 possible for both nodes to exchange the Test messages 498 simultaneously. 500 To initiate the link verification process, the local node first 501 sends a BeginVerify message over the control channel to indicate 502 that the node will begin sending Test messages across the component 503 links of a particular bundled link. The BeginVerify message 504 contains the number of component links that are to be verified; the 505 interval (called VerifyInterval) at which the Test messages will be 506 sent; the encoding scheme and data rate for Test messages; and, in 507 the case where the component links correspond to fibers, the 508 wavelength over which the Test messages will be transmitted. When a 509 node generates a BeginVerify message, it waits either to receive a 510 BeginVerifyAck or BeginVerifyNack message from the adjacent node to 511 accept or reject the verify process. 513 If the remote node receives a BeginVerify message and it is ready to 514 process Test messages, it MUST send a BeginVerifyAck message back to 515 the local node. When the local node receives a BeginVerifyAck 516 message from the remote node, it will begin testing the component 517 links by transmitting periodic Test messages over each component 518 link. The Test message will include the local LinkId for the 519 associated component link. The remote node will return a 520 TestStatusSuccess or TestStatusFail message in response for each 521 component link and will expect a TestStatusAck message from the 522 local node to confirm receipt of these messages. 524 The local (transmitting) node will send a given Test message 525 periodically (at least every VerifyInterval ms) on the corresponding 526 component link until it receives a correlating TestStatusSuccess or 527 TestStatusFailure message on the control channel from the remote 528 (receiving) node. The remote node will send a given TestStatus 529 message periodically over the control channel until it receives 530 either a correlating TestStatusAck message or an EndVerify message 531 on the control channel. It is also permissible for the sender to 532 terminate Test messages over a component link without receiving a 533 TestStatusSuccess or TestStatusFailure message. Message correlation 534 is done using the local node's LinkId and message identifiers. 536 When the Test message is detected at a node, the received LinkId is 537 recorded and mapped to the local LinkId for that channel. The 538 receipt of a TestStatusSuccess message indicates that the Test 539 message was detected and the physical connectivity of the component 540 link has been verified. The TestStatusSuccess message includes both 541 the local LinkId and remote node�s LinkId. When the 542 TestStatusSuccess message is received, the local node SHOULD mark 543 the component link as UP, send a TestStatusAck message to the remote 544 node, and begin testing the next component link. If, however, the 545 Test message is not detected at the remote node within an 546 observation period (specified by the VerifyDeadInterval), the remote 547 node will send a TestStatusFailure message over the control channel 548 indicating that the verification of the physical connectivity of the 549 component link has failed. When the local node receives a 550 TestStatusFailure message, it will mark the component link as 551 FAILED, send a TestStatusAck message to the remote node, and begin 552 testing the next component link. When all the component links on 553 the list have been tested, the local node will send an EndVerify 554 message to indicate that testing has been completed on this link. 555 Upon the receipt of an EndVerify message, an EndVerifyAck message 556 MUST be sent. 558 Both the local and remote nodes will maintain the complete list of 559 LinkId mappings for correlation purposes. 561 5.1. Example of link verification 563 Figure 1 shows an example of the link verification scenario that is 564 executed when a link between PXC A and PXC B is added. In this 565 example, the bundled link will consist of a bi-directional control 566 channel (indicated by a "c") and three free component links (each 567 transmitted along a separate fiber). The verification process is as 568 follows: PXC A sends a BeginVerify message over the control channel 569 to PXC B indicating it will begin verifying the component links. 570 PXC B receives the BeginVerify message and returns the 571 BeginVerifyAck message over the control channel to PXC A. When PXC 572 A receives the BeginVerifyAck message, it begins transmitting 573 periodic Test messages over the first component link (LinkId=1). 574 When PXC B receives the Test messages, it maps the received LinkId 575 to its own local LinkId = 10 and transmits a TestStatusSuccess 576 message over the control channel back to PXC A. The 577 TestStatusSuccess message will include both the local and received 578 LinkIds for the component link. PXC A will send a TestStatusAck 579 message over the control channel back to PXC B indicating it 580 received the TestStatusSuccess message. The process is repeated 581 until all of the component links are verified. At this point, PXC A 582 will send an EndVerify message over the control channel to PXC B to 583 indicate that testing is complete and PXC B will respond by sending 584 an EndVerifyAck message over the control channel back to PXC A. 586 +---------------------+ +---------------------+ 587 + + + + 588 + PXC A +<-------- c --------->+ PCX B + 589 + + + + 590 + + + + 591 + 1 +--------------------->+ 10 + 592 + + + + 593 + + + + 594 + 2 + /---->+ 11 + 595 + + /----/ + + 596 + + /---/ + + 597 + 3 +----/ + 12 + 598 + + + + 599 + + + + 600 + 4 +--------------------->+ 14 + 601 + + + + 602 +---------------------+ +---------------------+ 604 Figure 1: Example of link connectivity between PXC A and PXC B. 606 6. LinkSummary message 608 As part of LMP, a LinkSummary message must be transmitted in order 609 to add component links to a bundled link, change LinkIds, or change 610 a link's protection mechanism. In addition, the LinkSummary message 611 can be exchanged at any time a link is UP and not in the 612 Verification process. The LinkSummary message contains the primary 613 and backup CCIds, the IP address for the link (binding the CCIds to 614 the link IP addresses), and the local and remote LinkIds for each 615 component link and their associated priorities. In addition, each 616 component link may have one or more associated protection component 617 links defined for local (span) protection (e.g., M:N, 1+1). If the 618 LinkSummary message is received from a remote node and the LinkId 619 mappings match those that are stored locally, then the two nodes 620 have agreement on the Verify process. Furthermore, any protection 621 definitions that are included in the LinkSummary message must be 622 accepted or rejected by the local node. To signal agreement on the 623 LinkId mappings and protection definitions, a LinkSummaryAck message 624 is transmitted. Otherwise, a LinkSummaryNack message will be 625 transmitted, indicating which channels are not correct and/or which 626 protection definitions are not accepted. If a LinkSummaryNack 627 message indicates that the LinkId mappings are not correct, the link 628 verification process should be repeated for all mismatched free 629 component links; if an allocated component link has a mapping 630 mismatch, it should be flagged and verified when it becomes free. 631 If, however, a LinkSummaryNack message indicates that a component 632 link's protection mechanism is not accepted, then that component 633 link's protection mechanism cannot be changed; in other words, both 634 local and remote nodes must agree on the protection mechanism for 635 each component link. 637 7. Fault localization 639 In this section, we describe a mechanism in LMP that is used to 640 rapidly isolate link failures. As before, we assume each link has a 641 bi-directional control channel that is always available for inter- 642 node communication and that the control channel spans a single hop 643 between two neighboring nodes. The case where a control channel is 644 no longer available between two nodes is beyond the scope of this 645 draft. The mechanism used to rapidly isolate link failures is 646 designed to work for unidirectional LSPs, and can be easily extended 647 to work for bi-directional LSPs; however, for the purposes of this 648 document, we only discuss the operation when the LSPs are 649 unidirectional. 651 Recall that a bundled link connecting two nodes consists of a 652 control channel and a number of component links. If one or more 653 component links fail between two nodes, a mechanism must be used to 654 rapidly locate the failure so that appropriate 655 protection/restoration mechanisms can be initiated. An important 656 implication of using PXCs is that traditional methods that are used 657 to monitor the health of allocated component links in OEO nodes 658 (e.g., DXCs) may no longer be appropriate, since PXCs are 659 transparent to the bit-rate, format, and wavelength. Instead, fault 660 detection is delegated to the physical layer (i.e., loss of light or 661 optical monitoring of the data) instead of layer 2 or layer 3. 663 7.1. Fault detection 665 As mentioned earlier, fault detection must be handled at the layer 666 closest to the failure; for optical networks, this is the physical 667 (optical) layer. One measure of fault detection at the physical 668 layer is simply detecting loss of light (LOL). Other techniques for 669 monitoring optical signals are still being developed and will not be 670 further considered in this document. However, it should be clear 671 that the mechanism used to locate the failure is independent of the 672 mechanism used to detect the failure, but simply relies on the fact 673 that a failure is detected. 675 7.2. Fault localization mechanism 677 If component links fail between two PXCs, the power monitoring 678 system in all of the downstream nodes will detect LOL and indicate a 679 failure. To correlate multiple failures between a pair of nodes, a 680 monitoring window can be used in each node to determine if a single 681 component link has failed or if multiple component links have 682 failed. 684 As part of the fault localization, a downstream node that detects 685 component link failures will send a ChannelFail message to its 686 upstream neighbor (bundling together the notification of all of the 687 failed component links) and the ports associated with the failed 688 component links will be put into the standby state. An upstream 689 node that receives the ChannelFail message will correlate the 690 failure to see if there is a failure on the corresponding input and 691 output ports for the LSP(s). If there is also a failure on the 692 input port(s) of the upstream node, the node will return a 693 ChannelFailAck message to the downstream node (bundling together the 694 notification of all the component links), indicating that it too has 695 detected a failure. If, however, the fault is CLEAR in the upstream 696 node (e.g., there is no LOL on the corresponding input channels), 697 then the upstream node will have localized the failure and will 698 return a ChannelFailNack message to the downstream node. Once the 699 failure has been localized, the signaling protocols can be used to 700 initiate span or path protection/restoration procedures. 702 7.3. Examples of fault localization 704 In Fig. 2, a sample network is shown where four PXCs are connected 705 in a linear array configuration. The control channels are bi- 706 directional and are labeled with a "c". All LSPs are uni- 707 directional going left to right. 709 In the first example [see Fig. 2(A)], there is a failure on a single 710 component link between PXC2 and PXC3. Both PXC3 and PXC4 will 711 detect the failure and each node will send a ChannelFail message to 712 the corresponding upstream node (PXC3 will send a message to PXC2 713 and PXC4 will send a message to PXC3). When PXC3 receives the 714 ChannelFail message from PXC4, it will correlate the failure and 715 return a ChannelFailAck message back to PXC4. Upon receipt of the 716 ChannelFailAck message, PXC4 will move the associated ports into a 717 standby state. When PXC2 receives the ChannelFail message from PXC3, 718 it will correlate the failure, verify that it is CLEAR, localize the 719 failure to the component link between PXC2 and PXC3, and send a 720 ChannelFailNack message back to PXC3. 722 In the second example [see Fig. 2(B)], there is a failure on three 723 component links between PXC3 and PXC4. In this example, PXC4 has 724 correlated the failures and will send a bundled ChannelFail message 725 for the three failures to PXC3. PXC3 will correlate the failures, 726 localize them to the channels between PXC3 and PXC4, and return a 727 bundled ChannelFailNack message back to PXC4. 729 In the last example [see Fig. 2(C)], there is a failure on the 730 tributary link of the ingress node (PXC1) to the network. Each 731 downstream node will detect the failure on the corresponding input 732 ports and send a ChannelFail message to the upstream neighboring 733 node. When PXC2 receives the message from PXC3, it will correlate 734 the ChannelFail message and return a ChannelFailAck message to PXC3 735 (PXC3 and PXC4 will also act accordingly). Since PXC1 is the 736 ingress node to the optical network, it will correlate the failure 737 and localize the failure to the component link between itself and 738 the network element outside the optical network. 740 +-------+ +-------+ +-------+ +-------+ 741 + PXC 1 + + PXC 2 + + PXC 3 + + PXC 4 + 742 + +-- c ---+ +-- c ---+ +-- c ---+ + 743 ----+---\ + + + + + + + 744 + \--+--------+-------+---\ + + + /--+---> 745 ----+---\ + + + \---+-------+---##---+---/ + 746 + \--+--------+-------+--------+-------+---##---+-------+---> 747 ----+-------+--------+-------+--------+-------+---##---+-------+---> 748 ----+-------+--------+---\ + + + (B) + + 749 + + + \--+---##---+--\ + + + 750 + + + + (A) + \ + + + 751 -##-+--\ + + + + \--+--------+-------+---> 752 (C) + \ + + /--+--------+---\ + + + 753 + \--+--------+---/ + + \--+--------+-------+---> 754 + + + + + + + + 755 +-------+ +-------+ +-------+ +-------+ 757 Figure 2: We show three types of component link failures 758 (indicated by ## in the figure): (A) a single 759 component link fails between two PXCs, (B) three 760 component links fail between two PXCs, and (C) a 761 single component link fails on the tributary input of 762 PXC 1. The control channel connecting two PXCs is 763 indicated with a "c". 765 8. Finite State Machine 767 8.1. Bringing a link UP 769 | 0 | 1 | 2 | 770 -----------------------------|-----|-----|-----| 771 External event starts process| 1a | - | - | 772 | | | | 773 Receive HelloConfig with | 2b,d| 2b,d| 2b,d| 774 agreable parameters | | | | 775 | | | | 776 Receive HelloConfig with | 0c | 1c | 0c | 777 unacceptable parameters | | | | 778 | | | | 779 Receive HelloConfigAck | - | 2d | 2d | 780 | | | | 781 Receive HelloConfigNack | - | 0 | 2b,d| 782 | | | | 783 Receive Hello | - | 1a | 3 | 785 States 786 0 DOWN 787 1 CONFIG - Wait for HelloConfig response 788 2 CONFIG - Wait for Hello message 789 3 UP 791 Actions 792 a send HelloConfig 793 b send HelloConfigAck 794 c send HelloConfigNack 795 d send Hello 797 9. LMP Message Formats 799 9.1. Common Header 801 In addition to the standard IP header, all LMP control-channel 802 messages have the following common header: 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Vers | Flags | Msg Type | (Reserved) | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Control Channel Id | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 Vers: 4 bits 814 Protocol version number. This is version 1. 816 Flags: 8 bits 818 1 = LinkDown 820 2 = ControlChannelSwitchover 822 The remaining flag bits are not yet defined. 824 Msg Type: 8 bits 826 1 = HelloConfig 828 2 = HelloConfigAck 830 3 = HelloConfigNack 832 4 = Hello 834 5 = BeginVerify 836 6 = BeginVerifyAck 838 7 = BeginVerifyNack 840 8 = EndVerify 842 9 = EndVerifyAck 844 10 = Test 845 11 = TestStatusSuccess 847 12 = TestStatusFailure 849 13 = TestStatusAck 851 14 = LinkSummary 853 15 = LinkSummaryAck 855 16 = LinkSummaryNack 857 17 = ChannelFail 859 18 = ChannelFailAck 861 19 = ChannelFailNack 863 All of the messages are sent over the control channel EXCEPT 864 the Test message (Msg Type = 10) which is sent over the 865 component link that is being tested. 867 Control Channel Id: 32 bits 869 The Control Channel Id (CCId) identifies the control channel of 870 the sender associated with the message. For the Test message, 871 which is sent over a component link, this is the control 872 channel associated with the Verify procedure. 874 9.2 Parameter Negotiation 876 9.2.1 HelloConfig Message (MsgType = 1) 878 The HelloConfig message is used to negotiate parameters for the 879 Hello phase of LMP. The format of the HelloConfig message is as 880 follows: 882 ::= 884 The HelloConfig Object has the following format: 886 0 1 2 3 887 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 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Interface IP Address | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | HelloInterval | HelloDeadInterval | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 Interface IP Address: 32 bits. 895 This is the address of the interface (or possibly virtual 896 interface) for the bundled link. If the bundled link is 897 unnumbered, the address is the Router ID of the node. 899 HelloInterval: 16 bits. 901 Indicates how frequently the Hello packets will be sent and is 902 measured in milliseconds (ms). 904 HelloDeadInterval: 16 bits. 906 If no Hello packets are received within the HelloDeadInterval, 907 the control channel is assumed to have failed and is measured 908 in milliseconds (ms). 910 9.2.2 HelloConfigAck Message (MsgType = 2) 912 ::= 914 The HelloConfigAck Object has the following format: 916 0 1 2 3 917 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 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | HelloInterval | HelloDeadInterval | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 HelloInterval: 16 bits. 924 Indicates how frequently the Hello packets will be sent and is 925 measured in milliseconds (ms). 927 HelloDeadInterval: 16 bits. 929 If no Hello packets are received within the HelloDeadInterval, 930 the control channel is assumed to be dead and is measured in 931 milliseconds (ms). 933 The values of the HelloInterval and HelloDeadInterval are copied 934 from the HelloConfig message that is being acknowledged. 936 9.2.3 HelloConfigNack Message (MsgType = 3) 938 ::= 940 The HelloConfigNack Object has the following format: 942 0 1 2 3 943 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 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | HelloInterval | HelloDeadInterval | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 HelloInterval: 16 bits. 949 Indicates how frequently the Hello packets will be sent and is 950 measured in milliseconds (ms). 952 HelloDeadInterval: 16 bits. 954 If no Hello packets are received within the HelloDeadInterval, 955 the control channel is assumed to be dead and is measured in 956 milliseconds (ms). 958 The values of the HelloInterval and HelloDeadInterval MUST be equal 959 to the locally accepted values. 961 9.3 Hello Message (MsgType = 4) 963 The format of the Hello message is as follows: 965 ::= . 967 The Hello object format is shown below: 969 0 1 2 3 970 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 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | TxSeqNum | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | RcvSeqNum | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 TxSeqNum: 32 bits 979 This is the current sequence number for this Hello message. 980 This sequence number will be incremented when either (a) the 981 sequence number is reflected in the RcvSeqNum of a Hello packet 982 that is received over the control channel, or (b) the Hello 983 packet is transmitted over a backup control channel. 985 TxSeqNum=0 is not allowed. 987 TxSeqNum=1 is reserved to indicate that a node has booted or 988 rebooted. 990 RcvSeqNum: 32 bits 992 This is the sequence number of the last Hello message received 993 over the control channel. 995 RcvSeqNum=0 is reserved to indicate that a Hello message has 996 not yet been received. 998 9.4 Link Verification 1000 9.4.1 BeginVerify Message (MsgType = 5) 1002 The BeginVerify message is sent over the control channel and is used 1003 to initiate the link verification process. The format is as 1004 follows: 1006 ::= 1008 The BeginVerify object has the following format: 1010 0 1 2 3 1011 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 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | MessageId | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | NumComponentLinks | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | VerifyInterval | EncType | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | BitRate | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Wavelength | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 MessageId: 32 bits 1026 When combined with the CCId and MsgType, the MessageId field 1027 uniquely identifies a message. This value is incremented and 1028 only decreases when the value wraps. This is used for message 1029 acknowledgment in the BeginVerifyAck and BeginVerifyNack 1030 messages. 1032 NumComponentLinks: 32 bits 1034 This is the number of component links that will be verified. 1036 VerifyInterval: 16 bits 1038 This is the interval between successive Test messages. 1040 EncType: 16 bits 1042 This is required for the purpose of testing where the component 1043 links are not required to be the same encoding type as the 1044 control channel. The EncType values are consistent with the 1045 Link Encoding Type values of [KRB00a] and [KRB00b]and are taken 1046 from the following list: 1048 1 Standard SONET 1049 2 Arbitrary SONET 1050 3 Standard SDH 1051 4 Arbitrary SDH 1052 5 Clear (not used) 1053 6 GigE 1054 7 10GigE 1056 BitRate: 32 bits 1058 This is the bit rate at which the Test messages will be 1059 transmitted and is expressed in bytes. 1061 Wavelength: 32 bits 1063 When a component link is assigned to a fiber, it is essential 1064 to know which wavelength the test messages will be transmitted 1065 over. This value corresponds to the wavelength at which the 1066 Test messages will be transmitted over and is measured in 1067 nanometers (nm). If each component link corresponds to a 1068 separate wavelength, than this value SHOULD be set to 0. 1070 9.4.2 BeginVerifyAck Message (MsgType = 6) 1072 When a BeginVerify message is received and Test messages are ready 1073 to be processed, a BeginVerifyAck message MUST be transmitted. 1075 ::= 1077 The BeginVerifyAck object has the following format: 1079 0 1 2 3 1080 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 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | MessageId | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | VerifyDeadInterval | (Reserved) | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 MessageId: 32 bits 1089 This is copied from the BeginVerify message being acknowledged. 1091 VerifyDeadInterval: 16 bits 1093 If a Test message is not detected within the 1094 VerifyDeadInterval, then a node will send the TestStatusFailure 1095 message for that component link. 1097 9.4.3 BeginVerifyNack Message (MsgType = 7) 1099 If a BeginVerify message is received and a node is unwilling or 1100 unable to begin the Verification procedure, a BeginVerifyNack 1101 message MUST be transmitted. 1103 ::= 1104 The BeginVerifyNack object has the following format: 1106 0 1 2 3 1107 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 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | MessageId | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 MessageId: 32 bits 1114 This is copied from the BeginVerify message being negatively 1115 acknowledged. 1117 9.4.4 EndVerify Message (MsgType = 8) 1119 The EndVerify message is sent over the control channel and is used 1120 to terminate the link verification process. The format is as 1121 follows: 1123 ::= 1125 The EndVerify object has the following format: 1127 0 1 2 3 1128 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 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | MessageId | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 MessageId: 32 bits 1135 When combined with the CCId and MsgType, the MessageId field 1136 uniquely identifies a message. This value is incremented and 1137 only decreases when the value wraps. This is used for message 1138 acknowledgement in the EndVerifyAck message. 1140 9.4.5 EndVerifyAck Message (MsgType =9) 1142 The EndVerifyAck message is sent over the control channel and is 1143 used to acknowledge the termination of the link verification 1144 process. The format is as follows: 1146 ::= 1147 The EndVerifyNack object has the following format: 1149 0 1 2 3 1150 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 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | MessageId | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 MessageId: 32 bits 1157 This is copied from the EndVerify message being acknowledged. 1159 9.4.6 Test Message (MsgType = 10) 1161 The Test message is transmitted over the component link and is used 1162 to verify the component link connectivity. The format is as 1163 follows: 1165 ::= 1167 The Test object has the following format: 1169 0 1 2 3 1170 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 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | LinkId | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 LinkId: 32 bits 1177 The LinkId identifies the component link over which this 1178 message is sent. A valid LinkId MUST be nonzero. 1180 Note that this message is sent over a component link and NOT over 1181 the control channel. 1183 9.4.7 TestStatusSuccess Message (MsgType = 11) 1185 The TestStatusSuccess message is transmitted over the control 1186 channel and is used to transmit the mapping between the local LinkId 1187 and the LinkId that was received in the Test message. 1189 ::= 1190 The TestStatusSuccess object has the following format: 1192 0 1 2 3 1193 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 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | MessageId | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | Received LinkId | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | Local LinkId | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 MessageId: 32 bits 1204 When combined with the CCId and MsgType, the MessageId field 1205 uniquely identifies a message. This value is incremented and only 1206 decreases when the value wraps. This is used for message 1207 acknowledgement in the TestStatusAck message. 1209 Received LinkId: 32 bits 1211 This is the value of the LinkId that was received in the Test 1212 message. A valid LinkId MUST be nonzero, therefore, a value of 1213 0 in the Received LinkId indicates that the Test message was 1214 not detected. 1216 Local LinkId: 32 bits 1218 This is the local value of the LinkId. A valid LinkId MUST be 1219 nonzero. 1221 9.4.8 TestStatusFailure Message (MsgType = 12) 1223 The TestStatusFailure message is transmitted over the control 1224 channel and is used to indicate that the Test message was not 1225 received. 1227 ::= 1229 The TestStatusFailure object has the following format: 1231 0 1 2 3 1232 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 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | MessageId | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 MessageId: 32 bits 1239 When combined with the CCId and MsgType, the MessageId field 1240 uniquely identifies a message. This value is incremented and 1241 only decreases when the value wraps. This is used for message 1242 acknowledgement in the TestStatusAck message. 1244 9.4.9 TestStatusAck Message (MsgType = 13) 1246 The TestStatusAck message is used to acknowledge receipt of the 1247 TestStatusSuccess or TestStatusFailure messages. 1249 ::= 1251 The TestStatusAck object has the following format: 1253 0 1 2 3 1254 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 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | MessageId | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 MessageId: 32 bits 1261 This is copied from the TestStatusSuccess or TestStatusFailure 1262 message being acknowledged. 1264 9.5 Link Summary Messages 1266 9.5.1 LinkSummary Message (MsgType = 14) 1268 The LinkSummary message is used to synchronize the LinkIds and 1269 correlate the properties of the link. The format of the LinkSummary 1270 message is as follows: 1272 ::= 1274 The LinkSummary Object has the following format: 1276 0 1 2 3 1277 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 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | MessageId | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Interface IP Address | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | NumWorking | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | NumProtection | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | | 1288 // (working channel subobjects) // 1289 | | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | | 1292 // (protection channel subobjects) // 1293 | | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 MessageId: 32 bits 1297 When combined with the CCId and MsgType, the MessageId field 1298 uniquely identifies a message. This value is incremented and 1299 only decreases when the value wraps. This is used for message 1300 acknowledgement in the LinkSummaryAck and LinkSummaryNack 1301 messages. 1303 Interface IP Address: 32 bits 1305 This is the local IP address of the interface (or possibly 1306 virtual interface) for the bundled link. If the bundled link 1307 is unnumbered, the address is the Router ID of the node. 1309 NumWorking: 32 bits 1311 This value is the number of working channels in the link. This 1312 also indicates how many working channel subobjects are in the 1313 LinkSummary message. 1315 NumProtection: 32 bits 1317 This value is the number of protection channels in the link. 1318 This also indicates how many protection channel subobjects are 1319 in the LinkSummary message. 1321 The LinkSummary message contains a list of working channel 1322 subobjects and protection channel subobjects. The list of working 1323 channels MUST include the control channel. Any backup control 1324 channels that are defined MUST be included in the list of protection 1325 channel subobjects. Note that a backup control channel can also be 1326 a working component link (provided it has preemptive priority over 1327 the working component link), so it is possible to appear in both the 1328 working channel subobject as well as the protection channel 1329 subobject. 1331 The Working Channel Subobject has the following format: 1333 0 1 2 3 1334 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 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Local Id | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | Received Id | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Priority | (Reserved) | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 Local Id: 32 bits 1345 This is the local value of the LinkId (for component link) or 1346 CCId (for control channel). 1348 Received Id: 32 bits 1349 This is the value of the corresponding Id. If this is a 1350 component link, then this is the value that was received in the 1351 Test message. If this is the primary control channel, then 1352 this is the value that is received in all of the Verify 1353 messages. 1355 Priority: 8 bits 1357 This is the channel priority and is in the range of 0 to 7. 1358 The value 0 is the highest priority. The control channel MUST 1359 have a priority of 0. 1361 The Protection Channel Subobject has the following format: 1363 0 1 2 3 1364 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 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | Local Id | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | Received Id | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Priority | Type | (Reserved) | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | NumWorking | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | | 1375 // (WorkingProtect Subobjects) // 1376 | | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 Local Id: 32 bits 1381 This is the local value of the LinkId. This could be a 1382 protection component link and/or a protection control channel. 1383 In addition, a protection control channel could also be a 1384 working component link (so it could appear in both the working 1385 channel subobject as well as the protection channel subobject). 1387 Received Id: 32 bits 1389 This is the value of the corresponding LinkId that was received 1390 in the Test message. 1392 Priority: 8 bits. 1394 The priority of the resources, in the range of 0 to 7. The 1395 value 0 is the highest priority. 1397 Type: 4 bits. 1399 This is the protection type. 1401 1 = 1+1 protection 1403 2 = M:N protection 1405 NumWorking: 32 bits 1407 This is the number of working channels that this channel is 1408 protecting. This defines the number of WorkingProtect 1409 subjects. 1411 The WorkingProtect Subobject has the following format: 1413 0 1 2 3 1414 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 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | Local Channel Id | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 Local Channel Id: 32 bits 1421 This is the local channel Id of the working channel that is 1422 being protected. This channel could be a control channel or a 1423 component link. 1425 9.5.2 LinkSummaryAck Message (MsgType = 15) 1427 The LinkSummaryAck message is used to indicate agreement on the 1428 LinkId synchronization and acceptance/agreement on all the link 1429 parameters. 1431 ::= 1433 The LinkSummaryAck object has the following format: 1435 0 1 2 3 1436 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 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | MessageId | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 MessageId: 32 bits 1443 This is copied from the LinkSummary message being acknowledged. 1445 9.5.3 LinkSummaryNack Message (MsgType = 16) 1447 The LinkSummaryNack message is used to indicate disagreement on 1448 LinkId synchronization and/or the link parameters. 1450 ::= 1451 The LinkSummaryNack object has the following format: 1453 0 1 2 3 1454 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | MessageId | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | NumWorking | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | NumProtection | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | | 1463 // (working channel subobjects) // 1464 | | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | | 1467 // (protection channel subobjects) // 1468 | | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 MessageId: 32 bits 1473 This is copied from the LinkSummary message being negatively 1474 acknowledged. 1476 NumWorking: 32 bits 1478 This value is the number of working channels in the LinkSummary 1479 message that are being negatively acknowledged. This also 1480 indicates how many working channel subobjects are in the 1481 LinkSummaryNack message. 1483 NumProtection: 32 bits 1485 This value is the number of protection channels in the 1486 LinkSummary message that are being negatively acknowledged. 1487 This also indicates how many protection channel subobjects are 1488 in the LinkSummaryNack message. 1490 The Working Channel and Protection Channel Subobjects are copied 1491 from the LinkSummary message being negatively acknowledged. These 1492 represent the Subobjects that were not accepted. 1494 As an optimization, the entire LinkSummary message can be rejected 1495 by setting NumWorking = NumProtection = 0. If this is done, the 1496 working and protection channel subobjects are not required in the 1497 LinkSummaryNack message. 1499 9.6 Failure Messages 1501 9.6.1 ChannelFail Message (MsgType = 17) 1503 The ChannelFail message is sent over the control channel and is used 1504 to query a neighboring node when a link or channel failure is 1505 detected. The format is as follows: 1507 ::= 1509 The format of the ChannelFail object is as follows: 1511 0 1 2 3 1512 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 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 | MessageId | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | NumFailedChannels | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | | 1519 // (FailedChannel subobjects) // 1520 | | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 MessageId: 32 bits 1525 When combined with the CCId and MsgType, the MessageId field 1526 uniquely identifies a message. This value is incremented and 1527 only decreases when the value wraps. This is used for message 1528 acknowledgement in the ChannelFailAck and ChannelFailNack 1529 messages. 1531 NumFailedChannels: 32 bits 1533 This value indicates how many channels have failed. This also 1534 defines the number of FailedChannel subobjects. 1536 The FailedChannel Subobjects is a list of the failed channels and 1537 has the following format: 1539 0 1 2 3 1540 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 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 | Local LinkId | 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 Local LinkId: 32 bits 1547 This is the local LinkId of the component link that has failed. 1549 9.6.2 ChannelFailAck Message (MsgType = 18) 1551 The ChannelFailAck message is used to indicate that all of the 1552 failed channels reported in the ChannelFail message also have 1553 failures on the corresponding input channels. The format is as 1554 follows: 1556 ::= 1558 The ChannelFailureAck object has the following format: 1560 0 1 2 3 1561 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 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | MessageId | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 MessageId: 32 bits 1568 This is copied from the ChannelFail message being acknowledged. 1570 9.6.3 ChannelFailNack Message (MsgType = 19) 1572 The ChannelFailNack message is used to indicate that the failed 1573 component link(s) reported in the ChannelFail message are CLEAR in 1574 the upstream node, and hence, the failure has been isolated between 1575 the two nodes. 1577 ::= 1579 The ChannelFailNack object has the following format: 1581 0 1 2 3 1582 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 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | MessageId | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | NumChannelClear | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | | 1589 // (ChannelClear subobject) // 1590 | | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 MessageId: 32 bits 1595 This is copied from the ChannelFail message being negatively 1596 acknowledged. 1598 NumChannelFail: 32 bits 1600 This value is the number of failed component links reported in 1601 the ChannelFail message that also have failures on the 1602 corresponding inputs. 1604 NumChannelClear: 32 bits 1606 This is the number of failed component links reported in the 1607 ChannelFail message that are CLEAR in the upstream node. This 1608 also indicates how many ChannelClear subobjects are in the 1609 ChannelFailNack message. 1611 The ChannelClear subobject is used to indicate which failed 1612 component links have been isolated and has the following format: 1614 0 1 2 3 1615 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 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 | Local LinkId | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 Local LinkId: 32 bits 1622 This is the local LinkId of the component link where the 1623 failure has been isolated. 1624 10. Security Considerations 1626 Security considerations are for future study, however, LMP is a 1627 point-to-point protocol so security is largely derived from the 1628 physical security of the optical network. 1630 11. References 1632 [Bra96] Bradner, S., "The Internet Standards Process -- Revision 3," 1633 BCP 9, RFC 2026, October 1996. 1635 [KRB00] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 1636 MPLS Traffic Engineering," Internet Draft, draft-kompella- 1637 mpls-bundle-02.txt, (work in progress), July 2000. 1639 [ABD00] Ashwood-Smith, P., Berger, L., et al, "Generalized MPLS - 1640 Signaling Functional Description," Internet Draft, draft- 1641 generalized-signaling-00.txt, (work in progress), July 2000. 1643 [RNT99] Rosen, E. C., Rekhter, Y., et al, "MPLS Label Stack 1644 Encoding," Internet Draft, draft-ietf-mpls-label-encaps- 1645 07.txt, (work in progress), September 1999. 1647 [ARD99] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., "Multi- 1648 Protocol Lambda Switching: Combining MPLS Traffic 1649 Engineering Control with Optical Crossconnects," Internet 1650 Draft, draft-awduche-mpls-te-optical-02.txt, (work in 1651 progress), July 2000. 1653 [CBD00] Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski, J., 1654 Edwards, W. L., "Performance Monitoring in Photonic 1655 Networks," Internet Draft, draft-ceuppens-mpls-optical- 1656 00.txt, (work in progress), March 2000. 1658 [ABG99] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Swallow, G., 1659 Srinivasan, V., "Extensions to RSVP for LSP Tunnels," 1660 Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-06.txt, 1661 (work in progress), July 2000. 1663 [Jam99] Jamoussi, B., et al, "Constraint-Based LSP Setup using LDP," 1664 Internet Draft, draft-ietf-mpls-cr-ldp-03.txt, (work in 1665 progress), September 1999. 1667 [KaY99] Katz, D., Yeung, D., "Traffic Engineering Extensions to 1668 OSPF," Internet Draft, draft-katz-yeung-ospf-traffic-02.txt, 1669 (work in progress), August 2000. 1671 [SmL99] Smit, H. and Li, T., "IS-IS extensions for Traffic 1672 Engineering," Internet Draft,draft-ietf-isis-traffic.txt, 1673 (work in progress), September 2000. 1675 [KRB00a] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF 1676 Extensions in Support of Generalized MPLS," Internet Draft, 1677 draft-kompella-ospf-extensions-00.txt, (work in progress), 1678 July 2000. 1680 [KRB00b] Kompella, K., Rekhter, Y., Banerjee, A., et al, "IS-IS 1681 Extensions in Support of Generalized MPLS," Internet Draft, 1682 draft-kompella-isis-extensions-00.txt, (work in progress), 1683 July 2000. 1685 12. Acknowledgments 1687 The authors would like to thank Adrian Farrel for his comments on 1688 the draft. 1690 13. Author's Addresses 1692 Jonathan P. Lang Krishna Mitra 1693 Calient Networks Calient Networks 1694 25 Castilian Drive 5853 Rue Ferrari 1695 Goleta, CA 93117 San Jose, CA 95138 1696 Email: jplang@calient.net email: krishna@calient.net 1698 John Drake Kireeti Kompella 1699 Calient Networks Juniper Networks, Inc. 1700 5853 Rue Ferrari 385 Ravendale Drive 1701 San Jose, CA 95138 Mountain View, CA 94043 1702 email: jdrake@calient.net email: kireeti@juniper.net 1704 Yakov Rekhter Lou Berger 1705 Cisco Systems LabN Consulting, LLC 1706 170 W. Tasman Dr. email: lberger@labn.net 1707 San Jose, CA 95134 1708 email: yakov@cisco.com 1709 Debanjan Saha Debashis Basak 1710 Tellium Optical Systems Marconi 1711 2 Crescent Place 1000 Fore Drive 1712 Oceanport, NJ 07757-0901 Warrendale, PA 15086-7502 1713 email: dsaha@tellium.com email: dbasak@fore.com 1715 Hal Sandick 1716 Nortel Networks 1717 email: hsandick@nortelnetworks.com