idnits 2.17.1 draft-lang-ccamp-lmp-bootstrap-03.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: ---------------------------------------------------------------------------- ** 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? == 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 12 longer pages, the longest (page 13) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([G.7714.1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7735 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 16 == Unused Reference: 'RFC2026' is defined on line 557, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.707' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.7714.1' == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-07 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-lmp-test-sonet-sdh-01 -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group J.P. Lang (Rincon) 3 Internet Draft J. Drake (Calient) 4 Expiration Date: August 2003 D. Papadimitriou (Alcatel) 6 February 2003 8 Control Channel Bootstrap for Link Management Protocol 10 draft-lang-ccamp-lmp-bootstrap-03.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 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 The Link Management Protocol (LMP) requires that a bi-directional 35 control channel is established to form an LMP adjacency. The control 36 channel may be transmitted either in-band with the data links or 37 out-of-band over a separate wavelength, fiber, or IP network. This 38 draft specifies a simple procedure to dynamically bootstrap LMP 39 control channels and exchange interface mappings using a new LMP 40 message that is transmitted in-band over the data links. 42 This memo also details how this mechanism is used in implementing 43 Layer Adjacency Discovery as described in [G.7714.1]. 45 J.P.Lang et al. Internet Draft - Expires August 2003 1 46 Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 50 this document are to be interpreted as described in RFC-2119. 52 The reader is assumed to be familiar with the terminology in [LMP], 53 [LMP-SONET-SDH], [G.707], and [T1.105]. The following abbreviations 54 are used in this document: 56 DCC: Data communications channel. 57 LOH: Line Overhead. 58 LOVC: Lower order virtual container 59 HOVC: Higher order virtual container 60 MS: Multiplex section. 61 MSOH: Multiplex section overhead. 62 POH: Path overhead. 63 RS: Regenerator section. 64 RSOH: Regenerator section overhead. 65 SDH: Synchronous digital hierarchy. 66 SOH: Section overhead. 67 SONET: Synchronous Optical Network. 68 STM(-N): Synchronous Transport Module (-N) (SDH). 69 STS(-N): Synchronous Transport Signal-Level N (SONET). 70 TCP: Termination Connection Point. 71 TCP-ID: Termination Connection Point Identifier 72 VC-n: Virtual Container-n (SDH). 73 VTn: Virtual Tributary-n (SONET). 75 3. Summary for Sub-IP Area 77 3.1. Summary 79 This document specifies LMP extensions to dynamically bootstrap out- 80 of-band control channels and exchange interface mappings using an 81 in-band message transmitted over the data links. 83 3.2 Where does it fit in the Picture of the Sub-IP Work 85 This work fits squarely in the CCAMP box. 87 3.3 Why is it Targeted at this WG 89 This draft is targeted at the CCAMP WG because this draft specifies 90 an extension to the Link Management Protocol (LMP). 92 3.4 Justification 94 The WG should consider this document as it specifies the extensions 95 to the link management protocol in support auto-discovery of control 96 channel endpoint addresses for out-of-band signaling. This falls in 97 the category of multiple physical path and tunnel technologies. 99 J.P.Lang et al. Internet Draft - Expires August 2003 2 100 4. Introduction 102 The Link Management Protocol (LMP) [LMP] is run between a pair of 103 nodes and is used to manage traffic engineering (TE) links. This 104 includes discovering the local/remote interface mappings and 105 exchanging the TE link properties. LMP requires that a bi- 106 directional control channel is established to form an LMP adjacency. 107 This control channel may be in-band with the data links or out-of- 108 band, possibly over a separate wavelength, fiber, or IP network. 110 Control channel bootstrapping is the procedure of automatically 111 discovering the neighboring node (i.e., learning the address of the 112 node) and the IP address(es) of the neighbor�s control channel 113 endpoints. Once these are learned, normal LMP procedures (i.e., 114 Config message exchange as described in [LMP]) can be used to bring 115 up one or more LMP control channels and establish the LMP adjacency. 116 Either node can initiate these procedures if both nodes know the 117 addresses of the control channel endpoints. 119 Automatic discovery of the local/remote interface mappings can be 120 done by sending in-band messages that contain the local interface 121 identifiers. For example, this functionality is provided in LMP 122 using the Link Verification procedure. To support interfaces with 123 multiple termination capabilities (i.e., encoding type, transport 124 mechanism, bandwidth, wavelength, etc.), a negotiation phase is used 125 to agree upon the parameters of the Test procedure. This is done in 126 LMP by first establishing a control channel, and then discovering 127 the data port connectivity according to the negotiated parameters. 129 When the control channel is in-band, the existing LMP Config message 130 exchange can be used to bootstrap the control channel as well as 131 exchange the local interface mappings. 133 Currently there is no LMP mechanism to bootstrap out-of-band control 134 channels and discover the interface mappings before establishing a 135 control channel. In this draft, a simple mechanism is provided to do 136 both (i.e., dynamically bootstrap out-of-band control channels as 137 well as exchange the local Interface_Ids). This mechanism does not 138 raise any backward compatibility issues with respect to [LMP]. 140 Once the control channel is established and the Interface_Ids are 141 learned, the LMP Link Property Correlation procedure (Section 4 of 142 [LMP]) can be used to (a) check that both ends of a TE link have a 143 consistent view of mapping data links into TE links, and (b) 144 exchange link identifiers for the TE links. 146 This draft (see Section 6) also describes LMP message extensions in 147 delivering Layer Adjacency Discovery as specified in [G.7714.1] 148 which delivers similar capability. 150 5. LMP Bootstrap message 152 J.P.Lang et al. Internet Draft - Expires August 2003 3 153 In this section, we define a new LMP bootstrap message (Msg Type = 154 TBA by IANA). This message is transmitted in-band over a data link 155 and identifies the Node_Id of the sender, the Interface_Id of the 156 data link, and one or more IP addresses of the control channel 157 endpoints. The format of the Bootstrap message is as follows: 159 ::= 160 [...] 162 If the Bootstrap Message does not include a LOCAL_CONTROL_ADDRESS, 163 then the LOCAL_NODE_ID MUST be a routable address (i.e., the address 164 MUST be reachable via normal IP routing) and SHOULD be used to 165 establish the LMP control channel. 167 Multiple LOCAL_CONTROL_ADDRESS objects may be included in a single 168 Bootstrap message. In this case each Control Address MUST be unique. 169 If a Bootstrap Message is received with multiple LOCAL_CONTROL 170 ADDRESS objects with the same Control Address, only one control 171 channel SHOULD be established; the duplicate objects SHOULD be 172 ignored. The selection of the local control address is a local 173 matter. 175 The LMP Common Header, LOCAL_INTERFACE_ID object, and LOCAL_NODE_ID 176 object are defined in [LMP]. The LOCAL_CONTROL_ADDRESS object is 177 defined in Section 5.2. 179 This message SHOULD be sent to the Multicast address (224.0.0.1). 181 5.1 Procedures 183 The process of bootstrapping the control channel(s) requires 184 periodic transmission of the LMP Bootstrap message over the data 185 link(s) until (1) A Config message is received for each (distinct) 186 address specified in the LOCAL_CONTROL_ADDRESS object or (2) a 187 timeout expires and no Config message has been received for all of 188 the addresses specified in the LOCAL_CONTROL_ADDRESS objects of the 189 Bootstrap message. The default value for the retransmission interval 190 is 500ms. The default value for the timeout is 5 minutes. 192 Note that some restrictions on applicability of the procedure are 193 dictated by the encoding type of the data link(s). In particular, 194 for SONET/SDH encoding type, the applicability may be limited to the 195 data link(s) that have not yet been put "in-service". 197 When the Bootstrap message is received, the received Interface_Id is 198 recorded and mapped to the local Interface_Id for that data link. 199 The received Node_Id is recorded to identify the neighbor associated 200 with the data link. The Control Address(es) SHOULD be used for 201 establishing the out-of-band LMP control channel(s). If a 202 LOCAL_CONTROL_ADDRESS is included in the Bootstrap message, then the 203 LMP Config message SHOULD be sent to that address. If a 204 LOCAL_CONTROL_ADDRESS is not included in the Bootstrap message, then 205 the LMP Config message SHOULD be sent to the Node_Id. 207 J.P.Lang et al. Internet Draft - Expires August 2003 4 208 It is possible that Bootstrap messages are received over several 209 data links. If the Control Addresses are the same, or if they 210 correspond to a control channel that is already established or in 211 the process of being established, then duplicate Control Addresses 212 should be ignored. The received Interface_Ids should still be 213 recorded and mapped to the local Interface_Id. 215 5.2 CONTROL_ADDRESS Class 217 Class = TBA by IANA 219 o C-Type = 1, IPv4 LOCAL_CONTROL_ADDRESS 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Control Address (4 bytes) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 o C-Type = 2, IPv6 LOCAL_CONTROL ADDRESS 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | 233 + + 234 | | 235 + Control Address (16 bytes) + 236 | | 237 + + 238 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Control Address: 243 This identifies the address to be used for establishing an LMP 244 control channel. 246 5.3 LMP Bootstrap transport 248 In this section, we define the transport mechanism for the LMP 249 Bootstrap message when the data link encoding is SONET/SDH. Based on 250 the termination capabilities of the nodes and the links connecting 251 the nodes, the following different transport mechanisms are defined: 253 J0-16: 16 byte J0 Bootstrap message 255 The Bootstrap message is transmitted using J0 overhead bytes 256 with string length of 16 bytes (with CRC-7). See table 9-1 of 257 ITU G.707 [G.707] for the 16-byte J0 definition. The definition 258 of CRC-7 is found in Annex B of ITU G.707. 260 J.P.Lang et al. Internet Draft - Expires August 2003 5 261 Note that due to the byte limitation, the Bootstrap message 262 is NOT sent as a normal LMP packet and as such, no layer 2 263 encapsulation is used. A special Bootstrap message format is 264 defined as follows (using 80 bits as suggested in [G.7714.1]): 266 The first usable 4 bits are reserved. These bits MUST be sent 267 as zero and ignored on receipt. 269 The next usable 2 bits are used to identify the message type. 270 For the Bootstrap message, this value is 1. 272 The next usable 1 bit is used to determine the address type of 273 the Interface_Id. For IPv4, this value is 0. For unnumbered, 274 this value is 1. 276 The next usable 1 bit is used to determine the address type of 277 the Control Address. For IPv4, this value is 0. Note that for 278 unnumbered interfaces, the Node_Id can correspond to the 279 Control_Address. 281 The next usable 32 bits MUST be the Interface_Id. 283 The next usable 32 bits MUST be the Control Address. 285 The remaining 8 bits are reserved and should be sent as zero 286 and ignored on receipt. 288 Note that this Bootstrap Message format is only valid when the 289 Interface_Id is either IPv4 or unnumbered. Furthermore, only 290 one single IPv4 Control Address can be included. 292 DCCS: Bootstrap Message over the Section/RS DCC 294 The Bootstrap message is transmitted using the DCC Section/RS 295 Overhead bytes with bit-oriented HDLC framing format [RFC1662]. 297 The Bootstrap message is by default sent as a normal LMP packet 298 as defined in [LMP]. This message MAY be sent using the format 299 defined above for J0-16. 301 DCCL: Bootstrap Message over the Line/MS DCC 303 The Bootstrap message is transmitted using the DCC Line/MS 304 Overhead bytes with bit-oriented HDLC framing format [RFC1662]. 306 The Bootstrap message is by default sent as a normal LMP packet 307 as defined in [LMP]. This message MAY be sent using the format 308 defined above for J0-16. 310 J1-16: 16 byte J1 Bootstrap Message 312 The Bootstrap message is transmitted using the SDH HOVC J1 313 Path Trace byte (frame length of 16 bytes with CRC-7), see 315 J.P.Lang et al. Internet Draft - Expires August 2003 6 317 [G.707]. 319 Note that due to the byte limitation, the Bootstrap message is 320 NOT sent as a normal LMP packet and as such, no layer 2 321 encapsulation is used. The Bootstrap message format defined 322 above for J0-16 is used. 324 Note that this Bootstrap Message format is only valid when the 325 Interface_Id is either IPv4 or unnumbered. Furthermore, only 326 one Control Address can be included. 328 J2-16: 16 byte J2 Bootstrap Message 330 The Bootstrap message is transmitted using the SONET/SDH VT 331 SPE/LOVC J2 Path Trace byte (frame length of 16 bytes with 332 CRC-7), see [T1.105] and [G.707]. 334 Note that due to the byte limitation, the Bootstrap message 335 is NOT sent as a normal LMP packet and as such, no layer 2 336 encapsulation is used. The Bootstrap message format defined 337 above for J0-16 is used. 339 Note that this Bootstrap Message format is only valid when 340 the Interface_Id is either IPv4 or unnumbered. Furthermore, 341 only one Control Address can be included. 343 6. Layer Adjacency Discovery 345 This section details the LMP implementation of the Layer Adjacency 346 Discovery as described by the ITU-T G.7714.1 recommendation. 348 6.1 Scope 350 For this purpose, we consider here the "DA DCN-ID (In-band) 351 Discovery Message" format of the In-band Discovery message (as 352 defined in Sections 8.1.2 and 8.1.3 of [G.7714.1]) as printable 353 Bootstrap message. The bi-directional LMP control channel between 354 the involved parties must be established and available before 355 exchanging the "Discovery Response Message" (as defined in Section 356 11 of [G.7714.1]). The bi-directional LMP control channel 357 establishment and maintenance mechanisms as well as the 358 corresponding Config and Hello message exchanges are detailed in 359 [LMP]. In addition, it is assumed that a given Termination 360 Connection Point Identifier (TCP-ID) represents both transmitter and 361 receiver i.e. the identifier of the TCP where the (received) TCP-ID 362 is received corresponds to the sent TCP-ID. 364 In this context, when using 16 byte J0, the local/remote TCP-ID is 365 equivalent to an Interface Index, and referenced as an unnumbered 366 LOCAL/REMOTE INTERFACE_ID, respectively. When using 16 Byte J1/J2, 367 the local/remote TCP-ID is semantically equivalent to an SDH 368 timeslot (at both end-points) that can be referenced as an 369 unnumbered LOCAL/REMOTE INTERFACE_ID, respectively. 371 J.P.Lang et al. Internet Draft - Expires August 2003 7 372 The Local/Remote Discovery Agent (DA) DCN-ID corresponds to the IPv4 373 LOCAL/REMOTE_CONTROL_ADDRESS of the local/remote LMP Node_Id or 374 simply Node_Id, respectively (see also [LMP]). 376 6.2 Procedure 378 Upon reception of the Bootstrap message referred in G.7714.1 to as 379 the In-band Discovery message, an out-of-band Extended_TraceMonitor 380 message (see also [LMP-SONET-SDH]) referred in G.7714.1 to as the 381 Discovery Response message is sent back to the sender. This, after 382 establishment of the bi-directional LMP control channel (see [LMP]) 383 using the IPv4 LOCAL_CONTROL_ADDRESS information included in the 384 received Bootstrap message. 386 Note that if upon reception a control channel has already been 387 established between the two nodes this information is simply ignored 388 and only the interface identifier information is considered. 390 Here also, once the control channel is established and the 391 Interface_Ids are learned, the LMP Link Property Correlation 392 procedure (Section 4 of [LMP]) can be used to (a) check that both 393 ends of a TE link have a consistent view of mapping data links into 394 TE links, and (b) exchange link identifiers for the TE links. 396 6.3 Messages 398 6.3.1 Extended_TraceMonitor Message 400 The newly defined Extended_TraceMonitor message (MsgType = TBA by 401 IANA) includes the following information elements (i.e. objects): 403 The format of this message is as follows: 405 ::= 406 407 409 The above transmission order SHOULD be followed. The local 410 object is defined in [LMP-SONET-SDH]. The REMOTE_TRACE object (Class 411 = TBA by IANA, C-Type = 2) is defined similarly and contains as the 412 TRACE object, a Trace Type, a Trace Length and a Trace Message 413 field: 415 - The Trace Type (16 bits): indicates the type of the trace byte 416 (i.e. J0, J1 or J2) used by the local/remote Bootstrap message. 418 - The Trace Length (16 Bits): indicates the length in bytes of the 419 Trace Message. 421 - The Trace message contains among other the unnumbered LOCAL/ 422 REMOTE_INTERFACE_ID and the local/remote Control Address 423 information. 425 J.P.Lang et al. Internet Draft - Expires August 2003 8 426 6.3.2 Extended_TraceMonitorAck Message 428 Upon reception of the Extended_TraceMonitor message, an Extended_ 429 TraceMonitorAck message (MsgType = TBA) is sent back to acknowledge 430 its reception and indicate that the TRACE *and* the REMOTE_TRACE 431 Objects in the Extended_Trace Monitor message have been received and 432 processed correctly i.e. no (discovery) Trace mismatch. 434 The format of this message is as follows: 436 ::= 438 The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the 439 MESSAGE_ID_ACK object MUST be obtained from the Extended_Trace 440 Monitor message being acknowledged. 442 6.3.3 Extended_TraceMonitorNack Message 444 The Extended_TraceMonitorNack message is used to acknowledge receipt 445 of the Extended_TraceMonitor message (MsgType = TBA) and indicate 446 that the TRACE or REMOTE_TRACE object in the Extended_TraceMonitor 447 message was not processed correctly i.e. (discovery) Trace mismatch. 449 The format of this message is as follows: 451 ::= 452 454 The MESSAGE_ID_ACK and ERROR_CODE objects are defined in [LMP]. The 455 contents of the MESSAGE_ID_ACK object MUST be obtained from the 456 Extended_TraceMonitor message being acknowledged. 458 If the TRACE object was not equal to the value received in the In- 459 band Discovery Message, the ERROR_CODE MUST indicate, "Invalid Trace 460 Message". 462 If the REMOTE TRACE object was not equal to the value sent in the 463 In-band Discovery Message, the ERROR_CODE MUST indicate, "Invalid 464 Remote Trace Message". 466 7. Discussion 468 The LMP bootstrap procedure is based on the assumption that the data 469 link encoding type, transport mechanism, transmission rate, and 470 transmission wavelength are either (a) known, (b) agreed upon in 471 advance, or (c) able to be dynamically detected at the time the 472 procedure is run. Furthermore, the addresses of the control channel 473 endpoints are assumed to be reachable via normal IP routing. If the 474 control channel is provided through a VPN, either IP-based VPN 475 (e.g., [RFC2547], IP tunneling (GRE or IP in IP), etc.), or a sub-IP 476 based VPN (e.g., MPLS, FR, ATM, etc.), further configuration may be 477 needed. 479 J.P.Lang et al. Internet Draft - Expires August 2003 9 480 8. Security Considerations 482 Security considerations are left for future study. 484 9. Intellectual Property Considerations 486 The IETF takes no position regarding the validity or scope of any 487 intellectual property or other rights that might be claimed to 488 pertain to the implementation or use of the technology described in 489 this document or the extent to which any license under such rights 490 might or might not be available; neither does it represent that it 491 has made any effort to identify any such rights. Information on the 492 IETF's procedures with respect to rights in standards-track and 493 standards-related documentation can be found in BCP-11. Copies of 494 claims of rights made available for publication and any assurances 495 of licenses to be made available, or the result of an attempt made 496 to obtain a general license or permission for the use of such 497 proprietary rights by implementers or users of this specification 498 can be obtained from the IETF Secretariat. 500 The IETF invites any interested party to bring to its attention any 501 copyrights, patents or patent applications, or other proprietary 502 rights which may cover technology that may be required to practice 503 this standard. Please address the information to the IETF Executive 504 Director. 506 10. IANA Considerations 508 LMP defines the following name spaces that require management: 510 - LMP Message Type. 511 - LMP Object Class. 512 - LMP Object Class type (C-Type) unique within the Object Class. 513 - LMP Sub-object Class type (Type) unique within the Object Class. 515 This memo introduces two new Message Types: 517 LMP Message Type name space 519 o Bootstrap message (Message type = TBA) 521 o Extended_TraceMonitor message (Message type = TBA) 522 o Extended_TraceMonitorAck message (Message type = TBA) 523 o Extended_TraceMonitorNack message (Message type = TBA) 525 This memo introduces two new Object Classes: 527 CONTROL_ADDRESS Class name (Class = TBA) 528 - IPv4 CONTROL ADDRESS (suggested C-Type = 1) 529 - IPv6 CONTROL ADDRESS (suggested C-Type = 2) 531 REMOTE_TRACE Class name (Class = TBA) 532 - Type-1 (suggested C-Type = 1) 534 J.P.Lang et al. Internet Draft - Expires August 2003 10 535 11. References 537 11.1 Normative References 539 [G.707] ITU-T G.707, "Network node interface for the 540 synchronous digital hierarchy (SDH)," March 1996. 542 [G.7714.1] ITU-T Recommendation G.7714.1, "Layer Adjacency 543 Discovery for ASON Networks," January 2003. 545 [LMP] J.P. Lang (Editor), "The Link Management Protocol 546 (LMP)," Internet Draft, Work in progress, draft-ietf- 547 ccamp-lmp-07.txt, October 2002. 549 [LMP-SONET-SDH] J.P. Lang and D. Papadimitriou, "SONET/SDH 550 Encoding for Link Management Protocol (LMP) Test 551 messages", Internet Draft, Work in Progress, draft- 552 ietf-ccamp-lmp-test-sonet-sdh-01.txt, February 2003. 554 [RFC1662] W. Simpson (Editor), "PPP in HDLC-like Framing", IETF 555 RFC 1662, STD 51, July 1994. 557 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 558 3," BCP 9, IETF RFC 2026, October 1996. 560 [T1.105] T1.105, "Revised Draft T105 SONET Base Standard," 561 January 2001. 563 11.2 Informative References 565 [RFC2547] E. Rosen and Y. Rekhter, "BGP/MPLS VPNs," IETF RFC 566 2547, March 1999. 568 12. Acknowledgments 570 The authors would like to thank George Swallow for originally 571 suggesting this idea. The authors would also like to thank Yakov 572 Rekhter for his comments and suggestions on the draft. This draft is 573 based on earlier work on control channel bootstrapping originally 574 submitted as contribution oif2000.289.0 in the Optical 575 Internetworking Forum (OIF). 577 Thanks also to Razdan Rajender (G.7714.1 Editor) for its revision 578 effort. 580 13. Author's Addresses 582 Jonathan P. Lang (Rincon Networks) 583 110, El Paso 584 Goleta, CA 93101 585 Email: jplang@ieee.org 587 J.P.Lang et al. Internet Draft - Expires August 2003 11 588 John Drake (Calient) 589 5853 Rue Ferrari 590 San Jose, CA 95138 591 Email: jdrake@calient.net 593 Dimitri Papadimitriou (Alcatel) 594 Francis Wellesplein 1 595 B-2018 Antwerpen, Belgium 596 Email: dimitri.Papadimitriou@alcatel.be 598 J.P.Lang et al. Internet Draft - Expires August 2003 12 599 Full Copyright Statement 601 "Copyright (C) The Internet Society (date). All Rights Reserved. 602 This document and translations of it may be copied and furnished to 603 others, and derivative works that comment on or otherwise explain it 604 or assist in its implmentation may be prepared, copied, published 605 and distributed, in whole or in part, without restriction of any 606 kind, provided that the above copyright notice and this paragraph 607 are included on all such copies and derivative works. However, this 608 document itself may not be modified in any way, such as by removing 609 the copyright notice or references to the Internet Society or other 610 Internet organizations, except as needed for the purpose of 611 developing Internet standards in which case the procedures for 612 copyrights defined in the Internet Standards process must be 613 followed, or as required to translate it into languages other than 614 English. 616 The limited permissions granted above are perpetual and will not be 617 revoked by the Internet Society or its successors or assigns. 619 This document and the information contained herein is provided on an 620 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 621 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 622 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 623 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 624 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 626 J.P.Lang et al. Internet Draft - Expires August 2003 13