CCAMP Working Group J. Lang
Internet Draft J. Drake
Expiration Date: June 2003 Calient Networks
D. Papadimitriou
Alcatel
December 2002
Control Channel Bootstrap for Link Management Protocol
draft-lang-ccamp-lmp-bootstrap-02.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 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.
Lang et al [Page 1]
Internet Draft draft-lang-ccamp-lmp-bootstrap-02.txt December 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-02.txt December 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 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 Port_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.
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-02.txt December 2002
<Bootstrap Message> ::= <Common Header> <LOCAL_INTERFACE_ID>
<LOCAL_NODE_ID> [<LOCAL_CONTROL_ADDRESS>...]
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.
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
Lang et al [Page 4]
Internet Draft draft-lang-ccamp-lmp-bootstrap-02.txt December 2002
should be ignored. The received Interface_Ids should still be
recorded and mapped to the local Interface_Id.
Lang et al [Page 5]
Internet Draft draft-lang-ccamp-lmp-bootstrap-02.txt December 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) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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
Lang et al [Page 6]
Internet Draft draft-lang-ccamp-lmp-bootstrap-02.txt December 2002
bits (msb) of each byte are usable. Due to the byte
limitation, the LMP Header is not included. The format is
as follows:
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 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 bit is used to determine the address type of
the Control Address. For IPv4, this value is 0. For
unnumbered, this value is 1. If the Control Address is
numbered (IPv4), then it is included after the Node_Id.
Otherwise, the Node_Id is sufficient to identify the Control
Address and no additional Control Address is included.
The next usable 32 bits MUST be the Interface_Id.
The next usable 32 bits MUST be the Node_Id.
If the Control Address is numbered, the next usable 32 bits
MUST be the Control Address. Otherwise, the 32 bits are
should be sent as zero and ignored on receipt.
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.
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].
The Bootstrap message is sent as a normal LMP packet as
defined in [LMP].
Lang et al [Page 7]
Internet Draft draft-lang-ccamp-lmp-bootstrap-02.txt December 2002
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.
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
(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
Lang et al [Page 8]
Internet Draft draft-lang-ccamp-lmp-bootstrap-02.txt December 2002
[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
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1
B-2018 Antwerpen, Belgium
Email: dimitri.Papadimitriou@alcatel.be
Lang et al [Page 9]