CCAMP Working Group Jonathan P. Lang Internet Draft John Drake Expiration Date: December 2002 Dimitri Papadimitriou June 2002 Control Channel Bootstrap for LMP draft-lang-ccamp-lmp-bootstrap-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. 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. 2. Abstract The Link Management Protocol (LMP) requires that at least one bi- directional control channel is established between the nodes. 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 control channels and exchange interface mappings using a new LMP message that is transmitted in-band over the data links. Lang et al [Page 1] Internet Draft draft-lang-ccamp-lmp-bootstrap-00.txt June 2002 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. Lang et al [Page 2] Internet Draft draft-lang-ccamp-lmp-bootstrap-00.txt June 2002 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 between the nodes. 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 and the IP address(es) of the neighborÆs control channel endpoints. Once these are learned, normal LMP procedures (i.e., Config message exchange) can be used to bring up one or more LMP control channels. Note that these procedures can be initiated by either node 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 Test 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, we provide a simple mechanism to do both (i.e., dynamically bootstrap out-of-band control channels as well as exchange the local port Ids). 5. LMP Bootstrap message 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: ::= [...] 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 Lang et al [Page 3] Internet Draft draft-lang-ccamp-lmp-bootstrap-00.txt June 2002 ADDRESS objects with the same Control Address, only one control channel SHOULD be established; the duplicate objects SHOULD be ignored. 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. 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 Control Address is numbered, then the LMP Config message should be sent to that address. If a Control Address is unnumbered, then the LMP Config message should be sent to the Node Id. 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 they 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 Lang et al [Page 4] Internet Draft draft-lang-ccamp-lmp-bootstrap-00.txt June 2002 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) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o C-Type = 3, Unnumbered 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 LMP Bootstrap message The Bootstrap message is transmitted using J0 overhead bytes with string length of 16 bytes (with CRC-7). See table 4 of ITU G.707 [G707] for the 16-byte J0 definition. The definition of CRC-7 is found in Annex B of ITU G.707. Note that due to the byte limitation, the Bootstrap message is NOT sent as an IP packet and as such, no L2 encapsulation is used. In addition, only IPv4 or unnumbered interfaces may be used for the Interface Id or Control Address. Furthermore, only one Control Address can be included. A special Bootstrap message format is defined as follows: The Bootstrap message is a 15-byte message, where the 7 most significant bits (MSb) of each byte are usable. Due to the byte limitation, the LMP Header is not included. The first usable bit is used to identify the type of Interface Id: if set, the Interface Id is numbered (IPv4); if clear, the Interface Id is unnumbered. The next usable 32 bits MUST be the Interface Id. The next usable 32 bits MUST Lang et al [Page 5] Internet Draft draft-lang-ccamp-lmp-bootstrap-00.txt June 2002 be the Node Id. The next usable bit is used to identify the type of Control Address: if set, the Interface Id is numbered (IPv4); if clear, the Control Address is unnumbered. The next usable 32 bits MUST be the Control Address. The remaining bits are Reserved. J0-64: 64 byte J0 Bootstrap Message The Bootstrap message is transmitted using J0 overhead bytes with string length of 64 bytes (see GR-253-CORE [GR253]). Note that this is only appropriate for SONET encoding and not SDH encoding. The Bootstrap message is sent as an IP packet as defined above. Byte limitations may restrict the address combinations and/or the number of Control Addresses that are included. DCCS: Bootstrap Message over the Section DCC The Bootstrap message is transmitted using the DCC Section Overhead bytes with bit-oriented HDLC framing format. The Bootstrap message is sent as an IP packet as defined above. DCCL: Bootstrap Message over the Line DCC The Bootstrap message is transmitted using the DCC Line Overhead bytes with bit-oriented HDLC framing format. The Bootstrap message is sent as an IP packet as defined above. 6. 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 enpoints 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. 7. Security Considerations Security considerations are for future study. Lang et al [Page 6] Internet Draft draft-lang-ccamp-lmp-bootstrap-00.txt June 2002 8. References 8.1 Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. [LMP] Lang, J. P., ed., "The Link Management Protocol (LMP)," Internet Draft, draft-ietf-ccamp-lmp-03.txt, (work in progress), March 2002. [G707] ITU-T G.707, ôNetwork node interface for the synchronous digital hierarchy (SDH),ö March 1996. [GR253] GR-253-CORE, ôSynchronous Optical Network (SONET) Transport Systems: Common Generic Criteria,ö Telcordia Technologies, Issue 3, September 2000. 8.1 Informative References [RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs," RFC 2547, March 1999. 9. 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.089.0 in the Optical Internetworking Forum (OIF). 10. Author's Addresses Jonathan P. Lang Calient Networks 25 Castilian Drive Goleta, CA 93117 Email: jplang@calient.net John Drake Calient Networks 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 Lang et al [Page 7]