CCAMP Working Group J. Lang Internet Draft J. Drake Expiration Date: March 2003 Calient Networks D. Papadimitriou Alcatel September 2002 Control Channel Bootstrap for Link Management Protocol draft-lang-ccamp-lmp-bootstrap-01.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-01.txt September 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-01.txt September 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 (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. 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, a simple mechanism is provided to do both (i.e., dynamically bootstrap out-of-band control channels as well as exchange the local port Ids). 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. 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: Lang et al [Page 3] Internet Draft draft-lang-ccamp-lmp-bootstrap-01.txt September 2002 ::= [...] 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 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. Lang et al [Page 4] Internet Draft draft-lang-ccamp-lmp-bootstrap-01.txt September 2002 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) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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 [G707] for the 16-byte J0 definition. The definition of CRC-7 is found in Annex B of ITU G.707. Lang et al [Page 5] Internet Draft draft-lang-ccamp-lmp-bootstrap-01.txt September 2002 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: The Bootstrap message (i.e., the string inserted into the frame) 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 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 Test message, this value is 0. The next usable 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 32 bits MUST 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 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 Control Address can be included. J0-64: 64 byte J0 Bootstrap Message The Bootstrap message is transmitted using J0 overhead bytes with frame length of 64 bytes (see [T1105]). Note that this is only appropriate for SONET encoding and not SDH encoding. The Bootstrap message is sent as a normal LMP packet as defined in [LMP]. Byte limitations may restrict the address combinations and/or the number of Control Addresses that are 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 sent as a normal LMP packet as defined in [LMP]. 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]. Lang et al [Page 6] Internet Draft draft-lang-ccamp-lmp-bootstrap-01.txt September 2002 The Bootstrap message is sent as a normal LMP packet as defined in [LMP]. 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 [G707]. 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. J1-64: 64 byte J1 Bootstrap Message The Bootstrap messages is transmitted using J1 overhead bytes with frame length of 64 bytes (see [T1105]). Note that this is only appropriate for SONET encoding and not SDH encoding. The Bootstrap message is sent as a normal LMP packet as defined in [LMP]. 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 [T1105] and [G707]. 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. 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 Lang et al [Page 7] Internet Draft draft-lang-ccamp-lmp-bootstrap-01.txt September 2002 (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. 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, (work in progress). [G707] ITU-T G.707, ôNetwork node interface for the synchronous digital hierarchy (SDH),ö March 1996. [T1105] T1.105, "Revised Draft T105 SONET Base Standard," January 2001. [RFC1662] W. Simpson, Ed., "PPP in HDLC-like Framing", IETF RFC 1662, STD 51, July 1994. 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.289.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 Lang et al [Page 8] Internet Draft draft-lang-ccamp-lmp-bootstrap-01.txt September 2002 Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen, Belgium Email: dimitri.Papadimitriou@alcatel.be Lang et al [Page 9]