CCAMP Working Group J.P. Lang (Rincon) Internet Draft J. Drake (Calient) Expiration Date: August 2003 D. Papadimitriou (Alcatel) February 2003 Control Channel Bootstrap for Link Management Protocol draft-lang-ccamp-lmp-bootstrap-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Link Management Protocol (LMP) requires that a bi-directional control channel is established to form an LMP adjacency. The control channel may be transmitted either in-band with the data links or out-of-band over a separate wavelength, fiber, or IP network. This draft specifies a simple procedure to dynamically bootstrap LMP control channels and exchange interface mappings using a new LMP message that is transmitted in-band over the data links. This memo also details how this mechanism is used in implementing Layer Adjacency Discovery as described in [G.7714.1]. J.P.Lang et al. Internet Draft - Expires August 2003 1 draft-lang-ccamp-lmp-bootstrap-03.txt February 2003 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. The reader is assumed to be familiar with the terminology in [LMP], [LMP-SONET-SDH], [G.707], and [T1.105]. The following abbreviations are used in this document: DCC: Data communications channel. LOH: Line Overhead. LOVC: Lower order virtual container HOVC: Higher order virtual container MS: Multiplex section. MSOH: Multiplex section overhead. POH: Path overhead. RS: Regenerator section. RSOH: Regenerator section overhead. SDH: Synchronous digital hierarchy. SOH: Section overhead. SONET: Synchronous Optical Network. STM(-N): Synchronous Transport Module (-N) (SDH). STS(-N): Synchronous Transport Signal-Level N (SONET). TCP: Termination Connection Point. TCP-ID: Termination Connection Point Identifier VC-n: Virtual Container-n (SDH). VTn: Virtual Tributary-n (SONET). 3. Summary for Sub-IP Area 3.1. Summary This document specifies LMP extensions to dynamically bootstrap out- of-band control channels and exchange interface mappings using an in-band message transmitted over the data links. 3.2 Where does it fit in the Picture of the Sub-IP Work This work fits squarely in the CCAMP box. 3.3 Why is it Targeted at this WG This draft is targeted at the CCAMP WG because this draft specifies an extension to the Link Management Protocol (LMP). 3.4 Justification The WG should consider this document as it specifies the extensions to the link management protocol in support auto-discovery of control channel endpoint addresses for out-of-band signaling. This falls in the category of multiple physical path and tunnel technologies. J.P.Lang et al. Internet Draft - Expires August 2003 2 draft-lang-ccamp-lmp-bootstrap-03.txt February 2003 4. Introduction The Link Management Protocol (LMP) [LMP] is run between a pair of nodes and is used to manage traffic engineering (TE) links. This includes discovering the local/remote interface mappings and exchanging the TE link properties. LMP requires that a bi- directional control channel is established to form an LMP adjacency. This control channel may be in-band with the data links or out-of- band, possibly over a separate wavelength, fiber, or IP network. Control channel bootstrapping is the procedure of automatically discovering the neighboring node (i.e., learning the address of the node) and the IP address(es) of the neighborÆs control channel endpoints. Once these are learned, normal LMP procedures (i.e., Config message exchange as described in [LMP]) can be used to bring up one or more LMP control channels and establish the LMP adjacency. Either node can initiate these procedures if both nodes know the addresses of the control channel endpoints. Automatic discovery of the local/remote interface mappings can be done by sending in-band messages that contain the local interface identifiers. For example, this functionality is provided in LMP using the Link Verification procedure. To support interfaces with multiple termination capabilities (i.e., encoding type, transport mechanism, bandwidth, wavelength, etc.), a negotiation phase is used to agree upon the parameters of the Test procedure. This is done in LMP by first establishing a control channel, and then discovering the data port connectivity according to the negotiated parameters. When the control channel is in-band, the existing LMP Config message exchange can be used to bootstrap the control channel as well as exchange the local interface mappings. Currently there is no LMP mechanism to bootstrap out-of-band control channels and discover the interface mappings before establishing a control channel. In this draft, a simple mechanism is provided to do both (i.e., dynamically bootstrap out-of-band control channels as well as exchange the local Interface_Ids). This mechanism does not raise any backward compatibility issues with respect to [LMP]. Once the control channel is established and the Interface_Ids are learned, the LMP Link Property Correlation procedure (Section 4 of [LMP]) can be used to (a) check that both ends of a TE link have a consistent view of mapping data links into TE links, and (b) exchange link identifiers for the TE links. This draft (see Section 6) also describes LMP message extensions in delivering Layer Adjacency Discovery as specified in [G.7714.1] which delivers similar capability. 5. LMP Bootstrap message J.P.Lang et al. Internet Draft - Expires August 2003 3 draft-lang-ccamp-lmp-bootstrap-03.txt February 2003 In this section, we define a new LMP bootstrap message (Msg Type = TBA by IANA). This message is transmitted in-band over a data link and identifies the Node_Id of the sender, the Interface_Id of the data link, and one or more IP addresses of the control channel endpoints. The format of the Bootstrap message is as follows: ::= [...] If the Bootstrap Message does not include a LOCAL_CONTROL_ADDRESS, then the LOCAL_NODE_ID MUST be a routable address (i.e., the address MUST be reachable via normal IP routing) and SHOULD be used to establish the LMP control channel. Multiple LOCAL_CONTROL_ADDRESS objects may be included in a single Bootstrap message. In this case each Control Address MUST be unique. If a Bootstrap Message is received with multiple LOCAL_CONTROL ADDRESS objects with the same Control Address, only one control channel SHOULD be established; the duplicate objects SHOULD be ignored. The selection of the local control address is a local matter. The LMP Common Header, LOCAL_INTERFACE_ID object, and LOCAL_NODE_ID object are defined in [LMP]. The LOCAL_CONTROL_ADDRESS object is defined in Section 5.2. This message SHOULD be sent to the Multicast address (224.0.0.1). 5.1 Procedures The process of bootstrapping the control channel(s) requires periodic transmission of the LMP Bootstrap message over the data link(s) until (1) A Config message is received for each (distinct) address specified in the LOCAL_CONTROL_ADDRESS object or (2) a timeout expires and no Config message has been received for all of the addresses specified in the LOCAL_CONTROL_ADDRESS objects of the Bootstrap message. The default value for the retransmission interval is 500ms. The default value for the timeout is 5 minutes. Note that some restrictions on applicability of the procedure are dictated by the encoding type of the data link(s). In particular, for SONET/SDH encoding type, the applicability may be limited to the data link(s) that have not yet been put "in-service". When the Bootstrap message is received, the received Interface_Id is recorded and mapped to the local Interface_Id for that data link. The received Node_Id is recorded to identify the neighbor associated with the data link. The Control Address(es) SHOULD be used for establishing the out-of-band LMP control channel(s). If a LOCAL_CONTROL_ADDRESS is included in the Bootstrap message, then the LMP Config message SHOULD be sent to that address. If a LOCAL_CONTROL_ADDRESS is not included in the Bootstrap message, then the LMP Config message SHOULD be sent to the Node_Id. J.P.Lang et al. Internet Draft - Expires August 2003 4 draft-lang-ccamp-lmp-bootstrap-03.txt February 2003 It is possible that Bootstrap messages are received over several data links. If the Control Addresses are the same, or if they correspond to a control channel that is already established or in the process of being established, then duplicate Control Addresses should be ignored. The received Interface_Ids should still be recorded and mapped to the local Interface_Id. 5.2 CONTROL_ADDRESS Class Class = TBA by IANA o C-Type = 1, IPv4 LOCAL_CONTROL_ADDRESS 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o C-Type = 2, IPv6 LOCAL_CONTROL ADDRESS 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Control Address (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control Address: This identifies the address to be used for establishing an LMP control channel. 5.3 LMP Bootstrap transport In this section, we define the transport mechanism for the LMP Bootstrap message when the data link encoding is SONET/SDH. Based on the termination capabilities of the nodes and the links connecting the nodes, the following different transport mechanisms are defined: J0-16: 16 byte J0 Bootstrap message The Bootstrap message is transmitted using J0 overhead bytes with string length of 16 bytes (with CRC-7). See table 9-1 of ITU G.707 [G.707] for the 16-byte J0 definition. The definition of CRC-7 is found in Annex B of ITU G.707. J.P.Lang et al. Internet Draft - Expires August 2003 5 draft-lang-ccamp-lmp-bootstrap-03.txt February 2003 Note that due to the byte limitation, the Bootstrap message is NOT sent as a normal LMP packet and as such, no layer 2 encapsulation is used. A special Bootstrap message format is defined as follows (using 80 bits as suggested in [G.7714.1]): The first usable 4 bits are reserved. These bits MUST be sent as zero and ignored on receipt. The next usable 2 bits are used to identify the message type. For the Bootstrap message, this value is 1. The next usable 1 bit is used to determine the address type of the Interface_Id. For IPv4, this value is 0. For unnumbered, this value is 1. The next usable 1 bit is used to determine the address type of the Control Address. For IPv4, this value is 0. Note that for unnumbered interfaces, the Node_Id can correspond to the Control_Address. The next usable 32 bits MUST be the Interface_Id. The next usable 32 bits MUST be the Control Address. The remaining 8 bits are reserved and should be sent as zero and ignored on receipt. Note that this Bootstrap Message format is only valid when the Interface_Id is either IPv4 or unnumbered. Furthermore, only one single IPv4 Control Address can be included. DCCS: Bootstrap Message over the Section/RS DCC The Bootstrap message is transmitted using the DCC Section/RS Overhead bytes with bit-oriented HDLC framing format [RFC1662]. The Bootstrap message is by default sent as a normal LMP packet as defined in [LMP]. This message MAY be sent using the format defined above for J0-16. DCCL: Bootstrap Message over the Line/MS DCC The Bootstrap message is transmitted using the DCC Line/MS Overhead bytes with bit-oriented HDLC framing format [RFC1662]. The Bootstrap message is by default sent as a normal LMP packet as defined in [LMP]. This message MAY be sent using the format defined above for J0-16. J1-16: 16 byte J1 Bootstrap Message The Bootstrap message is transmitted using the SDH HOVC J1 Path Trace byte (frame length of 16 bytes with CRC-7), see J.P.Lang et al. Internet Draft - Expires August 2003 6 draft-lang-ccamp-lmp-bootstrap-03.txt February 2003 [G.707]. Note that due to the byte limitation, the Bootstrap message is NOT sent as a normal LMP packet and as such, no layer 2 encapsulation is used. The Bootstrap message format defined above for J0-16 is used. Note that this Bootstrap Message format is only valid when the Interface_Id is either IPv4 or unnumbered. Furthermore, only one Control Address can be included. J2-16: 16 byte J2 Bootstrap Message The Bootstrap message is transmitted using the SONET/SDH VT SPE/LOVC J2 Path Trace byte (frame length of 16 bytes with CRC-7), see [T1.105] and [G.707]. Note that due to the byte limitation, the Bootstrap message is NOT sent as a normal LMP packet and as such, no layer 2 encapsulation is used. The Bootstrap message format defined above for J0-16 is used. Note that this Bootstrap Message format is only valid when the Interface_Id is either IPv4 or unnumbered. Furthermore, only one Control Address can be included. 6. Layer Adjacency Discovery This section details the LMP implementation of the Layer Adjacency Discovery as described by the ITU-T G.7714.1 recommendation. 6.1 Scope For this purpose, we consider here the "DA DCN-ID (In-band) Discovery Message" format of the In-band Discovery message (as defined in Sections 8.1.2 and 8.1.3 of [G.7714.1]) as printable Bootstrap message. The bi-directional LMP control channel between the involved parties must be established and available before exchanging the "Discovery Response Message" (as defined in Section 11 of [G.7714.1]). The bi-directional LMP control channel establishment and maintenance mechanisms as well as the corresponding Config and Hello message exchanges are detailed in [LMP]. In addition, it is assumed that a given Termination Connection Point Identifier (TCP-ID) represents both transmitter and receiver i.e. the identifier of the TCP where the (received) TCP-ID is received corresponds to the sent TCP-ID. In this context, when using 16 byte J0, the local/remote TCP-ID is equivalent to an Interface Index, and referenced as an unnumbered LOCAL/REMOTE INTERFACE_ID, respectively. When using 16 Byte J1/J2, the local/remote TCP-ID is semantically equivalent to an SDH timeslot (at both end-points) that can be referenced as an unnumbered LOCAL/REMOTE INTERFACE_ID, respectively. J.P.Lang et al. Internet Draft - Expires August 2003 7 draft-lang-ccamp-lmp-bootstrap-03.txt February 2003 The Local/Remote Discovery Agent (DA) DCN-ID corresponds to the IPv4 LOCAL/REMOTE_CONTROL_ADDRESS of the local/remote LMP Node_Id or simply Node_Id, respectively (see also [LMP]). 6.2 Procedure Upon reception of the Bootstrap message referred in G.7714.1 to as the In-band Discovery message, an out-of-band Extended_TraceMonitor message (see also [LMP-SONET-SDH]) referred in G.7714.1 to as the Discovery Response message is sent back to the sender. This, after establishment of the bi-directional LMP control channel (see [LMP]) using the IPv4 LOCAL_CONTROL_ADDRESS information included in the received Bootstrap message. Note that if upon reception a control channel has already been established between the two nodes this information is simply ignored and only the interface identifier information is considered. Here also, once the control channel is established and the Interface_Ids are learned, the LMP Link Property Correlation procedure (Section 4 of [LMP]) can be used to (a) check that both ends of a TE link have a consistent view of mapping data links into TE links, and (b) exchange link identifiers for the TE links. 6.3 Messages 6.3.1 Extended_TraceMonitor Message The newly defined Extended_TraceMonitor message (MsgType = TBA by IANA) includes the following information elements (i.e. objects): The format of this message is as follows: ::= The above transmission order SHOULD be followed. The local object is defined in [LMP-SONET-SDH]. The REMOTE_TRACE object (Class = TBA by IANA, C-Type = 2) is defined similarly and contains as the TRACE object, a Trace Type, a Trace Length and a Trace Message field: - The Trace Type (16 bits): indicates the type of the trace byte (i.e. J0, J1 or J2) used by the local/remote Bootstrap message. - The Trace Length (16 Bits): indicates the length in bytes of the Trace Message. - The Trace message contains among other the unnumbered LOCAL/ REMOTE_INTERFACE_ID and the local/remote Control Address information. J.P.Lang et al. Internet Draft - Expires August 2003 8 draft-lang-ccamp-lmp-bootstrap-03.txt February 2003 6.3.2 Extended_TraceMonitorAck Message Upon reception of the Extended_TraceMonitor message, an Extended_ TraceMonitorAck message (MsgType = TBA) is sent back to acknowledge its reception and indicate that the TRACE *and* the REMOTE_TRACE Objects in the Extended_Trace Monitor message have been received and processed correctly i.e. no (discovery) Trace mismatch. The format of this message is as follows: ::= The MESSAGE_ID_ACK object is defined in [LMP]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the Extended_Trace Monitor message being acknowledged. 6.3.3 Extended_TraceMonitorNack Message The Extended_TraceMonitorNack message is used to acknowledge receipt of the Extended_TraceMonitor message (MsgType = TBA) and indicate that the TRACE or REMOTE_TRACE object in the Extended_TraceMonitor message was not processed correctly i.e. (discovery) Trace mismatch. The format of this message is as follows: ::= The MESSAGE_ID_ACK and ERROR_CODE objects are defined in [LMP]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the Extended_TraceMonitor message being acknowledged. If the TRACE object was not equal to the value received in the In- band Discovery Message, the ERROR_CODE MUST indicate, "Invalid Trace Message". If the REMOTE TRACE object was not equal to the value sent in the In-band Discovery Message, the ERROR_CODE MUST indicate, "Invalid Remote Trace Message". 7. Discussion The LMP bootstrap procedure is based on the assumption that the data link encoding type, transport mechanism, transmission rate, and transmission wavelength are either (a) known, (b) agreed upon in advance, or (c) able to be dynamically detected at the time the procedure is run. Furthermore, the addresses of the control channel endpoints are assumed to be reachable via normal IP routing. If the control channel is provided through a VPN, either IP-based VPN (e.g., [RFC2547], IP tunneling (GRE or IP in IP), etc.), or a sub-IP based VPN (e.g., MPLS, FR, ATM, etc.), further configuration may be needed. J.P.Lang et al. Internet Draft - Expires August 2003 9 draft-lang-ccamp-lmp-bootstrap-03.txt February 2003 8. Security Considerations Security considerations are left for future study. 9. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. IANA Considerations LMP defines the following name spaces that require management: - LMP Message Type. - LMP Object Class. - LMP Object Class type (C-Type) unique within the Object Class. - LMP Sub-object Class type (Type) unique within the Object Class. This memo introduces two new Message Types: LMP Message Type name space o Bootstrap message (Message type = TBA) o Extended_TraceMonitor message (Message type = TBA) o Extended_TraceMonitorAck message (Message type = TBA) o Extended_TraceMonitorNack message (Message type = TBA) This memo introduces two new Object Classes: CONTROL_ADDRESS Class name (Class = TBA) - IPv4 CONTROL ADDRESS (suggested C-Type = 1) - IPv6 CONTROL ADDRESS (suggested C-Type = 2) REMOTE_TRACE Class name (Class = TBA) - Type-1 (suggested C-Type = 1) J.P.Lang et al. Internet Draft - Expires August 2003 10 draft-lang-ccamp-lmp-bootstrap-03.txt February 2003 11. References 11.1 Normative References [G.707] ITU-T G.707, "Network node interface for the synchronous digital hierarchy (SDH)," March 1996. [G.7714.1] ITU-T Recommendation G.7714.1, "Layer Adjacency Discovery for ASON Networks," January 2003. [LMP] J.P. Lang (Editor), "The Link Management Protocol (LMP)," Internet Draft, Work in progress, draft-ietf- ccamp-lmp-07.txt, October 2002. [LMP-SONET-SDH] J.P. Lang and D. Papadimitriou, "SONET/SDH Encoding for Link Management Protocol (LMP) Test messages", Internet Draft, Work in Progress, draft- ietf-ccamp-lmp-test-sonet-sdh-01.txt, February 2003. [RFC1662] W. Simpson (Editor), "PPP in HDLC-like Framing", IETF RFC 1662, STD 51, July 1994. [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3," BCP 9, IETF RFC 2026, October 1996. [T1.105] T1.105, "Revised Draft T105 SONET Base Standard," January 2001. 11.2 Informative References [RFC2547] E. Rosen and Y. Rekhter, "BGP/MPLS VPNs," IETF RFC 2547, March 1999. 12. Acknowledgments The authors would like to thank George Swallow for originally suggesting this idea. The authors would also like to thank Yakov Rekhter for his comments and suggestions on the draft. This draft is based on earlier work on control channel bootstrapping originally submitted as contribution oif2000.289.0 in the Optical Internetworking Forum (OIF). Thanks also to Razdan Rajender (G.7714.1 Editor) for its revision effort. 13. Author's Addresses Jonathan P. Lang (Rincon Networks) 110, El Paso Goleta, CA 93101 Email: jplang@ieee.org J.P.Lang et al. Internet Draft - Expires August 2003 11 draft-lang-ccamp-lmp-bootstrap-03.txt February 2003 John Drake (Calient) 5853 Rue Ferrari San Jose, CA 95138 Email: jdrake@calient.net Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1 B-2018 Antwerpen, Belgium Email: dimitri.Papadimitriou@alcatel.be J.P.Lang et al. Internet Draft - Expires August 2003 12 draft-lang-ccamp-lmp-bootstrap-03.txt February 2003 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. J.P.Lang et al. Internet Draft - Expires August 2003 13