idnits 2.17.1 draft-rbradfor-ccamp-lmp-lol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 7 instances 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 12 longer pages, the longest (page 8) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 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 284: '... The LV-src MAY implement such an al...' RFC 2119 keyword, line 312: '...ansmission order SHOULD be followed, b...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 78 has weird spacing: '...impacts and p...' == Line 131 has weird spacing: '...creased optic...' -- 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) == Missing Reference: 'MPLSArch' is mentioned on line 138, but not defined == Unused Reference: 'RFC2026' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'LMP-DWDM' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'LSP-HIER' is defined on line 576, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-06 -- Possible downref: Normative reference to a draft: ref. 'LMP-DWDM' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-02 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group Richard Bradford 2 Internet Draft Dimitri Papadimitriou 3 Expires: April 2003 Dan Tappan 5 Link Management Protocol Extensions for Link discovery Using Loss of 6 Light 8 draft-rbradfor-ccamp-lmp-lol-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document proposes an enhanced mechanism for Link Management 35 Protocol�s Link Verification procedure that is independent of the 36 data encoding type. It can be used for any point-to-point link, 37 including both Optical Links and SONET/SDH Links. The general 38 proposal is to use the transmission of light by the sender and 39 recognition of the presence or absence of light by the receiver 40 to identify port mapping. The proposal includes minor extensions 41 to the existing messages to implement this extension to the link 42 verification procedure. 44 1. Introduction 46 Optical networks are being developed to include optical cross- 47 connects, routers and DWDMs that are configured with control 48 channels and data links. LMP was created to provide, among other 49 features, link discovery and link verification between these 50 devices. Currently, LMP requires the ability to terminate data in 51 these links in order to perform this link discovery. Many of these 52 devices, such as DWDMs, do not currently have these capabilities and 53 the addition of these capabilities could be expensive or even 54 technically unfeasible. This memo defines extensions to the LMP 55 Link Verification Procedure to allow neighbors to determine their 56 interface mappings using the presence or absence of received light 57 on those interfaces, a capability that is simpler, does not require 58 optical/electrical conversion, and is within the existing functional 59 requirements of many of these devices. A common name for the signal 60 indicating presence and absence of light is Loss-of-Light, (LOL), so 61 that name is used throughout this document. The proposed mechanism 62 provides a more scalable solution than the existing link 63 verification mechanisms. 65 Current Limitations 67 [LMP] Link Verification requires optical devices to provide link 68 termination of each port and provides a wide variety of transport 69 mechanisms for possible termination. The LMP link termination 70 requirement prevents adoption on devices which do not already 71 electrically terminate links and presents difficult engineering 72 challenges for incorporation in many other devices. Another 73 limitation is the scalability of the current link verification 74 procedure. These are discussed in detail below. 76 1.1.1 Link Termination Issues 77 This section raises issues of possible additional complexity, 78 performance impacts, reliability impacts and potentially 79 prohibitive cost issues which could limit the applicability of LMP 80 for certain devices. Many of the issues are implementation specific 81 and not all issues affect all types of optical devices. 83 First, X-transparent devices have no reason, other than 84 supporting LMP link verification, to terminate the X-aspect of the 85 data link. Support for such termination can greatly increase the 86 complexity, cost, and power consumption of some devices and the 87 additional components could affect such important aspects of a 88 device as MTBF. For example, an optically transparent DWDM does not 89 need the ability to decode the light signal, except to support LMP 90 Link Verification. 92 Second, the addition of link termination can increase the signal 93 loss through certain devices even when the link is not terminated, 94 due to the additional switching requirement. An example of this is a 95 DWDM, which normally does not need to switch the incoming light to 96 an internal termination module. While this is very implementation 97 dependent, the ability to losslessly add this capability could 98 present a roadblock to support for link verification. 100 Third, a transparent OXC would need to add one or more 101 termination modules and could lose the switching capacity required 102 for those termination modules (e.g. a 16x16 port fabric might need 103 to have at least one of those ports connected to the link 104 termination module, preventing its connection to an external 105 interface). 107 Fourth, is the problem of supporting the "right" set of 108 termination capabilities. For example, an electrically transparent 109 switch may be able to support connections carrying SONET or Gigabit 110 Ethernet. In addition, that switch may be able to switch 111 wavelengths, which are carrying anything from OC48 through OC768 and 112 beyond. It would be costly and difficult to provide termination 113 capabilities for even a small subset of these transport mechanisms. 115 1.1.2 Link Verification Scalability 117 In addition to the above, many of the mechanisms for LMP LV 118 calls for the link verification initiator to send in-band messages 119 from each port. If the link-verification target switch is incapable 120 of simultaneously terminating all its ports, it must then cycle 121 through termination of its ports to find the interface connected to 122 each source. This does not scale well for large switches. If a group 123 of 512 port OXCs is connected together, then each target switch will 124 need to cycle through an average of 256 ports before finding its 125 mate. This requires an average of 131,072 (256x512) combinations to 126 try, a large number, especially if the combinations must be tested 127 serially (i.e. one termination at a time). 129 The solution proposed in this document limits the excessive link 130 termination costs, both in terms of added hardware and the 131 potentially increased optical loss to support that hardware. It 132 also provides a mechanism that scales much better for large numbers 133 of interconnects. 135 2. Terminology 137 This document uses terminology from the MPLS architecture 138 document [MPLSArch] and the LMP Draft [LMP]. 140 Pattern: Given a well-known ordering of ports, the ports may be 141 represented as a bit sequence with a zero bit representing 142 no light and a one representing a port transmitting light. 143 The resultant bit sequence represents the 'pattern' of 144 enabled interfaces. 146 3. Proposed Solution Overview 148 The solution must address the issue of link termination 149 compatibility as well as the scalability limitation of the existing 150 LMP link verification procedure. 152 The ability to switch light on for the transmit side of an 153 interface and the ability to detect the presence of light on the 154 receive side of an interface is already present in many optical 155 devices, regardless of the optical encoding mechanisms used. A 156 link verification mechanism based on LOL puts a minimal 157 requirement on an interface and provides universal compatibility. 159 For scalability, the enhanced procedure allows testing of all 160 ports in parallel and without terminating the line. This avoids 161 the limitation of testing ports serially, which requires 162 terminating one source port at a time, then the destination will 163 need to terminate a line, wait some interval which is greater 164 than the inter-message arrival time, and move to the next. This 165 requires the source to send on the order of n-squared messages. 166 The method described in this document reduces this to a number on 167 the order of ln(n) for large numbers of interconnects. Note that 168 the scalability problem is only an issue for devices which cannot 169 terminate multiple ports simultaneously. 171 Here is an overview of the procedure. For brevity, the 172 initiator of link verification will be referred to as LV-src and 173 the destination node accepting the link verification request will 174 be referred to as LV-dst. The LV-Src may set some of its ports to 175 transmit light and others to not transmit light. 177 LV-Src sets the interfaces it is verifying to emit light in a 178 particular pattern and then sends that pattern to LV-Dst over the 179 control channel. LV-Dst looks for light on all its available 180 interfaces and reports back over the control channel. Initially 181 every one of LV-dst�s interfaces can be "possibly-connected" to 182 all of LV-src�s interfaces, since no possibilities have yet been 183 eliminated. However, each time LV-Src changes the combination 184 light on its interfaces, some of LV-dst's interfaces will not see 185 the corresponding change, and connectivity between those two 186 ports will be eliminated as a possibility. 188 Using this mechanism, the port connectivity can be 189 established through a series of interface/light-emission 190 patterns. For an eight port example, the pattern 0xF0, 0x0F, 191 0xCC, and 0xAA, would be more than sufficient to provide the 192 mapping of eight ports to eight ports. These 4 messages will 193 actually each require an acknowledgement, totaling 8 messages. To 194 verify eight-port connectivity using the existing LMP Link 195 verification procedure requires the source to terminate each 196 source port in turn. For each source port, the destination must 197 terminate each potential destination until a test message is 198 received. On average, half the ports will need to be tested 199 before discovering the right one. This requires a minimum of 8*4= 200 32 test messages, on average, and probably many more, perhaps 64, 201 since port termination and waiting for a packet will typically 202 require waiting for more than a single packet transmission 203 interval. For eight ports, the number of test messages is reduced 204 from between 32 and 63 messages, to just 8. For 64 ports, this 205 method reduces the number of test messages from (64*63)/2=2016 206 (or twice that), to 6+2=8 (or 16 including acknowledgments. 208 Once LV-Src has completed its entire pattern, LV-Dst will 209 report which interfaces, if any, map to its local interfaces. 211 The pattern of lights emissions must cause each interface to 212 change and must uniquely differentiate between all the ports. The 213 algorithm used in the above sequences is as follows. For N ports. 214 Pattern 1 = first N/2 ports on, second N/2 ports off. Pattern 2 = 215 First N/2 ports off second N/2 on. Patterns 3-maximium, (where M= 216 pattern #) = Alternate on and off in groups of N/(2**(M-1)). Note 217 that this is an example and the behavior is entirely 218 an implementation matter for the LV-Src. 220 4. Link Verification Extensions. 222 The following extensions are needed to support this method of 223 Link Verification: 225 4.1 LOL support for multiple neighbors 227 A weakness in the LOL mechanism occurs when multiple neighbors 228 simultaneously use the mechanism to verify their ports. This section 229 describes the weakness and an enhanced algorithm that can overcome 230 this weakness. Note that any given node may only be performing LOL 231 link verification with one neighbor at a time. The weakness is 232 uncovered when a node has several neighbors as shown in Figure 1. 234 +--------+ +--------+ 235 | Node A |--A1------B1-| Node B | 236 | |--A2------B2-| | 237 | |--A3------B3-| | 238 | |-A4 B4-| | 239 +--------+ \ / +--------+ 240 \ / 241 \ / 242 \ / 243 \ / 244 X 245 / \ 246 / \ 247 / \ 248 / \ 249 +--------+ / \ +--------+ 250 | |-C4 D4-| | 251 | Node C |-C3-------D3-| Node D | 252 | |-C2-------D2-| | 253 | |-C1-------D1-| | 254 +--------+ +--------+ 255 |Figure 1, Simultaneous use of LOL 257 In the above example, the weakness occurs when Node A initiates LOL 258 Link Verification at the same time as Node C initiates LOL Link 259 Verification to Node D. Let�s focus on what Node D sees. It gets a 260 message from Node C saying the light pattern is 0x0F (this is also 261 what Node A sends Node C). It appears that D4 matches the light 262 pattern sent by node C for port C4. In fact, it Node A and C march 263 through the same algorithm, it is possible the Node D will see all 264 the correct patterns on port D4 to suggest that it is connected to 265 Node C port C4. This is incorrect. As unlikely as this type of 266 synchronization is, it is possible, especially when a large number 267 of nodes restart simultaneously, as happens following a power 268 outage. 269 There are several ways to address this weakness. 270 First, each source node could randomly choose the sequence of 271 patterns it sends as it executes the LOL procedure. This makes it 272 very unlikely that two pairs of nodes would synchronize in this way. 273 Second, each source node could create a series of random patterns 274 and send those following the basic LOL link verification. For 275 example, Node A would randomly choose to send 0x23, 0x97 and then 276 0x1F while Node B would randomly choose to send 0x49, 0x17, and 277 0x77. This quickly reduces the likelihood of accidental overlap to a 278 vanishingly small probability. 279 Finally, if even the remote possibility of a random number 280 overlap is desired, then the source node could send its node ID as a 281 light pattern. For a typical 32-bit node ID, this would add an 282 additional 32 pairs of message exchanges, but would eliminate 283 accidental overlap. 284 The LV-src MAY implement such an algorithm. 285 Note that the sequence and choice of bit patterns by the LV-src 286 does not affect require any changes to the LOL procedure. The LOL 287 procedure allows the LV-src to send a long or short sequence of LOL 288 patterns. 290 5. LMP LOL Message Definitions 292 5.1. Test Message (Msg Type = 10) 294 The LOL Test message is transmitted over the control channel and 295 not the data link and is used to verify its physical connectivity. 296 This is transmitted in the standard LMP UDP/IP packet with payload 297 format as follows: 299 ::= 300 301 5.2. TestStatusSuccess Message (Msg Type = 11) 303 The TestStatusSuccess message is transmitted over the control 304 channel and is used to transmit the mapping between the local 305 Interface Id and the Interface Id that was received in the Test 306 Message once the exchange of Test and TestStatusSuccess messages 307 is complete. 309 ::= 310 312 The above transmission order SHOULD be followed, but the location 313 of the VERIFY_ID in the message is unimportant. 315 6. LMP Object Definitions 317 6.1. BEGIN_VERIFY Class modifications. 319 Verify Transport Mechanism: 16 bits 321 This defines the transport mechanism for the Test Messages. 322 The scope of this bit mask is restricted to each link 323 encoding type. The local node will set the bits 324 corresponding to the various mechanisms it can support for 325 transmitting LMP test 327 0x4000 LOL: Loss Of Light and out-of-band Test messages 329 Capable of supporting link verification through the 330 Presence and Loss of Light. In this case, the Test 331 Messages are exchanged over the same IP control 332 channel as standard LMP control messages. The Test 333 Messages identify the Data Link(s) where Light is 334 being emitted. TestStatusSuccess messages identify 335 the Data Link(s) where Light has been detected. 337 6.2. LOL_TEST_STATUS Class 339 Class = 21 341 o IPv4, C-Type = 1 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Interface Id (4 bytes) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | LOL Status | Reserved | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | : | 351 // : // 352 | : | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Interface Id (4 bytes) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | LOL Status | Reserved | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 o IPv6, C-Type = 2 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | | 365 + + 366 | | 367 + Interface Id (16 bytes) + 368 | | 369 + + 370 | | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | LOL Status | Reserved | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | : | 375 // : // 376 | : | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | | 379 + + 380 | | 381 + Interface Id (16 bytes) + 382 | | 383 + + 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | LOL Status | Reserved | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 o Unnumbered, C-Type = 3 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Interface Id (4 bytes) | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | LOL Status | Reserved | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | : | 399 // : // 400 | : | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Interface Id (4 bytes) | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | LOL Status | Reserved | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 LOL_Status: 8 bits 409 This indicates the status condition of a data channel. The 410 following values are defined. All other values are reserved. 412 1 Signal Okay (OK): Interface Sent or Detected Light 413 2 Signal Inconsistent: The Interface did sometimes detected 414 light, sometimes did not 415 This Object contains one or more Interface Ids followed by an 416 LOL_Status field. 418 7. LOL Link Verification Walkthrough 420 Here is a walkthrough of the procedure. 422 LV-src sends a BeginVerify message indicating LOL as the 423 transport mechanism. LV-dst responds with a BeginVerifyAck 424 message, selecting LOL as the transport mechanism. 426 LV-src sets its interfaces to emit light in pattern 1. For 427 example, where 8 ports are being verified, and where a one 428 represents "transmit light", the pattern of light emissions could 429 be represented by the eight bit number 0xF0. LV-src then creates 430 a test message, which includes the light emission status and 431 local-interface-id for every interface being tested. 433 LV-dst, on receipt of a test message, records the status of light 434 for every port and if at least one port has light it replies with 435 a TestStatusSuccess message, containing the local Interface_ID 436 for each port that has light. Otherwise, it sends a 437 TestStatusFailure message indicating that no light was seen on 438 any ports. 440 On receipt of a TestStatusSuccess message, the LV-src sends a 441 TestStatusAck message and changes the light emission to the next 442 pattern and continues the process. 444 When the LV-src has completed its test patterns and received the 445 TestStatusSucccess messages for those Test Messages, it will send 446 an EndVerify message to end the process. 448 Using this mechanism, the port connectivity can be established 449 through a series of interface light-emission patterns. For an 450 eight port example, the pattern 0xF0, 0x0F, 0xCC, and 0xAA, would 451 be sufficient to provide the mapping of eight ports to eight 452 ports using only four patterns. For a switch with 64 ports the 453 bitmap would have to be enlarged to eight bytes, and could use 454 the patterns 0xFFFFFFFF00000000, 0x00000000FFFFFFFF, 455 0xFFFF0000FFFF0000, 0xFF00FF00FF00FF00, 0xF0F0F0F0F0F0F0F0, 456 0xCCCCCCCCCCCCCCCC, 0xAAAAAAAAAAAAAAAA - performing the mapping 457 using only seven patterns. 459 In order to quickly eliminate ports that cannot possibly be 460 involved in the exchange, the LV-Src first activates light on 461 half the ports and then activates light on the other half of the 462 ports (patterns 0xF0 and 0X0F). This quickly eliminates ports 463 which remain lit, remain dark, and any which cannot possible be 464 connected because the light patterns did not match. This will 465 help reduce the size of the test messages. 467 Here is a walkthrough of the case where we will focus on LV-src 468 interface 1 (LV-src.1) is connected to LV-dst interface 4, 469 LVdst.4): 471 1. At the start of LV-LOL, LV-dst.4�s connectivity is unknown. 472 LV-src has eight interfaces, so it assumes that LV-dst 473 could have interfaces connected to any of its interfaces. 474 LV-src sets interfaces 1-4 off, and interfaces 5-8 on 475 sending pattern 0xF0 in the Test Message. 477 2. On receipt of the first test message, LV-dst notes that it 478 sees no light on LV-dst.4., LV-dst eliminates interfaces 5- 479 8. LV-dst sends a TestStatusSuccess indicating that it sees 480 no light on LV-dst.4. 482 3. Next LV-src sends light in a pattern 0x0F, which means LV- 483 src.1 will be lit. The Test Message contains pattern 0x0F. 485 4. LV-dst sees light on LV-dst.4. This leaves LV-dst with 486 remote interfaces 1,2,3,4 as possible matches, since they 487 were transmitting light. LV-dst sends a TestStatusSuccess 488 indicating light on LV-dst.4. 490 5. Next LV-src sends light in the pattern 0xCC and sends the 491 pattern in a Test Message. 493 6. LV-dst sees no light on LV-dst.4, leaving possible remote 494 interfaces 1,2. LV-dst sends a TestStatusSuccess indicating 495 no light on LV-dst.4. 497 7. LV-src sends light in the pattern 0xAA and includes the 498 pattern in a Test Message. 500 8. LV-dst sees no light on LV-dst.4, leaving only one possible 501 remote interface, LV-src.1. LV-dst sends TestStatusSuccess 502 indicating light on LV-dst.4. Next LV-src sends an empty 503 Test Message indicating it�s done. LV-dst sends a 504 TestStatusSuccess indicating that local LV-dst.4 is 505 connected to remote LV-src.1, along with any other ports 506 whose mapping it was able to determine in parallel. 508 The LOL Test Message includes a Message-ID. Since each Test 509 Message must be acked and either the Test Message or 510 TestStatusSuccess message could be lost or delayed, each Test 511 Message will include a Message ID that must be returned in the 512 TestStatusSuccess Message. This will allow the LV-Src to 513 correlate the TestStatusSuccess Message with the state of light 514 emissions. Before receiving the TestStatusSuccess, the LV-Src 515 must not alter the state of light emissions on the interfaces, 516 i.e. it must keep the interface emitting or not emitting light 517 until the LV-Dst has responded. If the TestStatusSuccess message 518 is not received within a specified time, the Test Message should 519 be retransmitted, incrementing the MessageID. TestStatusSuccess 520 Messages with stale MessageIDs must be discarded. 522 For this walkthrough, LV-src has eight ports. LV-dst has 4 ports. 523 LV-dst ports 1,2, and 3 are not connected to LV-src, so they will 524 not see light change. Let�s assume that LV-dst ports 1 and 2 525 always see light during the test and port 3 never sees light. 526 Here is what the procedure would show: 528 LV-Src LV-Dst 530 BeginVerify(LOL)----------------> 532 <------------------------BeginVerifyAck(LOL) 534 Test(Pattern = 0xF0)----------------> 536 <------------------------ 537 TestStatusSuccess(LVdst.1=on,2=on,3=off,4=Off) 539 Test(Pattern = 0x0F)----------------> 541 <------------------------TestStatusSuccess(LVdst4=On) 543 (Note - - LVdst.1,2, and 3 were eliminated from consideration 544 because they did not change status) 546 Test(Pattern = 0xCC)----------------> 548 <------------------------TestStatusSuccess(LVdst.4=Off) 550 Test(Pattern = 0xAA)----------------> 552 <------------------------TestStatusSuccess(LVdst.4=Off) 554 Test(Done)----------------> 556 <------------------------TestStatusAck(LVdst.4==LVsrc.1) 558 EndVerify----------------> 560 <------------------------EndVerifyAck 561 8. Acknowledgments 563 We wish to thank xxx for their comments on this draft. 565 9. References 567 9.1. Normative References 568 [RFC2026] Bradner, S., "The Internet Standards Process - 569 Revision 3," BCP 9, RFC 2026, October 1996. 570 [LMP] Lang, J., et al, "Link Management Protocol (LMP)", 571 draft-ietf-ccamp-lmp-06.txt, September, 2002 572 [LMP-DWDM] Fredette, A., Lang, J. P., editors, Link Management 573 Protocol (LMP) for WDM Transmission Systems, 574 Internet Draft, draft-fredette-lmp-wdm-03.txt, 575 (work in progress), November 2001. 576 [LSP-HIER] Kompella, K. and Rekhter, Y., LSP Hierarchy with 577 MPLS TE, Internet Draft, draft-ietf-mpls-lsp- 578 hierarchy-02.txt, (work in progress), February 579 2001. 581 9.2. Informative References 583 10. Applicability 585 The LOL-LV procedure provides an alternate mechanism that has 586 tradeoffs relative to the existing LMP LV procedure and it is up 587 to the implementation to decide when to use each. While LOL will 588 often more quickly determine that two interfaces are connected, 589 it provides no determination that the interfaces are compatible. 590 In this regard, it is able to provide a determination of improper 591 interface connectivity that is not possible with the standard 592 algorithm. For example, if a Gigabit Ethernet Interface on one 593 node is connected to an OC-48 interface on another node, then the 594 standard LV procedure will never attempt to verify the 595 connectivity of the two ports, since their transport mechanisms 596 are incompatible. The LOL procedure can be used to discover this 597 connectivity. It is beyond the scope of this document to specify 598 how such connectivity should be brought to the users attention. 600 11. Authors' Addresses 602 Richard Bradford 603 Cisco Systems, Inc. 604 300 Apollo Drive 605 Chelmsford, MA 01824 606 Phone: +1-978-497-3079 607 Email: rbradfor@cisco.com 608 Dimitri Papadimitriou 609 Alcatel 610 Francis Wellesplein 1 611 B-2018 Antwerpen, Belgium 612 Email: dimitri.Papadimitriou@alcatel.be 614 Dan Tappan 615 Cisco Systems, Inc. 616 300 Apollo Drive 617 Chelmsford, MA 01824 618 Phone: +1-978-497-8136 619 Email: tappan@cisco.com 621 12. Full Copyright Statement 623 Copyright (C) The Internet Society (2002). All Rights Reserved. 625 This document and translations of it may be copied and furnished 626 to others, and derivative works that comment on or otherwise 627 explain it or assist in its implementation may be prepared, 628 copied, published and distributed, in whole or in part, without 629 restriction of any kind, provided that the above copyright notice 630 and this paragraph are included on all such copies and derivative 631 works. However, this document itself may not be modified in any 632 way, such as by removing the copyright notice or references to 633 the Internet Society or other Internet organizations, except as 634 needed for the purpose of developing Internet standards in which 635 case the procedures for copyrights defined in the Internet 636 Standards process must be followed, or as required to translate 637 it into languages other than English. 639 The limited permissions granted above are perpetual and will not 640 be revoked by the Internet Society or its successors or assigns. 641 This document and the information contained herein is provided on 642 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 643 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 644 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 645 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 646 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 647 PURPOSE. 649 13. Intellectual Property Considerations 651 Cisco Systems may seek patent or other intellectual property 652 protection for some of all of the technologies disclosed in this 653 document. If any standards arising from this document are or 654 become protected by one or more patents assigned to Cisco 655 Systems, Cisco intends to disclose those patents and license them 656 on reasonable and non-discriminatory terms. 658 Bradford et al [Page 13 of 13]