Network Working Group K. Kompella Internet-Draft Juniper Networks Expires: October 17, 2005 J. Ospina S. Kamdar Cingular Wireless J. Richmond Electric Lightwave G. Miller MCI April 15, 2005 Circuit Cross-Connect draft-kompella-ccc-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on October 17, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Circuit Cross-Connect (CCC) was the ground-breaking design and implementation of the transport of Layer 2 frames over Multi-Protocol Kompella, et al. Expires October 17, 2005 [Page 1] Internet-Draft Circuit Cross-Connect April 2005 Label Switching (MPLS), which is now seen as an important application of MPLS. Thus, documenting CCC is important from a historical point of view. Furthermore, CCC is still in production in many networks, providing yet another reason to document it. It is hoped that those interested in this area will see where it started, how far we have come, and the strengths and weaknesses of this particular approach, and thereby gain some perspective of the area. If in the process they get new insights for the future development in this area, that is a bonus. It should be emphasized that there is no intent to propose this document as a rival standard to the work being done in the PWE3 and L2VPN Working Groups. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. History and Motivation . . . . . . . . . . . . . . . . . . . . 4 3. Design and Implementation . . . . . . . . . . . . . . . . . . 6 3.1 Control Plane . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1 Actions on the PE . . . . . . . . . . . . . . . . . . 8 3.1.2 Protocol Changes . . . . . . . . . . . . . . . . . . . 9 3.1.3 Fault Reporting . . . . . . . . . . . . . . . . . . . 10 3.2 Data Plane . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1 Frame Relay . . . . . . . . . . . . . . . . . . . . . 11 3.2.2 PPP, HDLC and Ethernet . . . . . . . . . . . . . . . . 12 3.2.3 ATM AAL/5 PDUs . . . . . . . . . . . . . . . . . . . . 13 3.2.4 ATM Cells . . . . . . . . . . . . . . . . . . . . . . 14 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1 Enhancements to CCC . . . . . . . . . . . . . . . . . . . 16 4.2 Operational Issues . . . . . . . . . . . . . . . . . . . . 18 4.3 Provisioning Model . . . . . . . . . . . . . . . . . . . . 19 4.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.4.1 Configuration . . . . . . . . . . . . . . . . . . . . 20 4.4.2 Data Plane . . . . . . . . . . . . . . . . . . . . . . 21 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1 CCC in Mobile Operator Networks . . . . . . . . . . . . . 22 5.2 CCC in Carrier Networks for ATM Trunk Applications . . . . 23 5.3 CCC as a Core Convergence Technology in Carrier Networks . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1 Normative References . . . . . . . . . . . . . . . . . . . 28 8.2 Informative References . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . 30 Kompella, et al. Expires October 17, 2005 [Page 2] Internet-Draft Circuit Cross-Connect April 2005 1. Introduction An important application of MPLS is the "convergence" of Layer 2 networks, i.e., a means of transporting Layer 2 frames over an MPLS infrastructure. Circuit Cross-Connect (CCC) is the first instantiation of this technology that was deployed in production networks; as such, it is important to document the design and implementation of CCC. Being an early implementation of the idea of Layer 2 convergence over MPLS as well as an early MPLS application, CCC didn't have the benefit of many techniques that today are taken for granted, for instance, label stacking. To understand this, and other aspects of the design of CCC, it is useful to review the intended application of CCC. Section 2 covers the history and motivation of CCC. Section 3 describes the design and implementation details of CCC. Section 4 is a discussion of the strengths and weaknesses of CCC, and how more recent progress in the PWE3 and L2VPN WGs addresses some of the weaknesses. Finally, Section 5 provides several case studies of CCC deployments in production networks, and feedback on its effectiveness. Kompella, et al. Expires October 17, 2005 [Page 3] Internet-Draft Circuit Cross-Connect April 2005 2. History and Motivation CCC was first conceived in 1998 by Tony Li, brainstorming on the relationship on the "connection-orientedness" of RSVP-TE-based MPLS with more traditional connection-oriented technologies, such as ATM and Frame Relay. The impetus to translate this musing into deployable code came from a service provider who wanted to migrate from an ATM backbone to an MPLS backbone. Most of the access circuits into the backbone were Frame Relay and ATM virtual circuits carrying IP traffic intended to be terminated and forwarded as IP packets. These posed no problem for the migration. However, a small number of important ATM access circuits were provisioned across the ATM backbone ("edge-to-edge"); these had to be transported *as ATM*, not terminated and forwarded as IP. CCC was the solution Tony Li, Der-Hwa Gan and Kireeti Kompella came up with. Normally, a router on receiving ATM cells would first reassemble them into ATM AAL5 frames. The router would then take note of the incoming Virtual Circuit (VC) identifier, and then parse the Layer 2 header (usually SNAP-encoded) to determine the type of Layer 3 payload being carried. If the frame is an IP packet, then information from the IP header would be extracted so as to forward the packet. For the case of Layer 2 transport, what was proposed instead is that the re-assembled ATM frames be transported as MPLS packets, without regard to the contents of the IP header, nor indeed the type of Layer 3 header. Each ATM VC maps one-to-one to an RSVP-TE label-switched path (LSP) as follows. The ingress label-switching router (LSR) receives cells from the ATM network, assemble these into an ATM frame, modifying it as needed, and then encapsulate it within an MPLS packet. The egress LSR unpacks the ATM frame from the MPLS packet, and re-constitute the ATM frame. Then, the egress LSR segments the frame into cells, and forward these to the ATM network. In the core of the network, the MPLS packets containing ATM frames are treated as any other MPLS packets, i.e., they are simply label switched. The net result is that the backbone can be pure MPLS, which was the desired outcome. Any ATM (or Frame Relay) VCs that were provisioned edge-to-edge as a native Layer 2 connection is mapped to MPLS. The intelligence to do this rested solely with the edge LSRs (or LERs); transit LSRs had no need to parse or forward ATM cells or frames. It was visualized at the time that this technique would only be used for a small number of VCs network-wide: a few tens to a few hundreds. This has indeed been borne out in some scenarios, but as the idea caught on, it became evident that the CCC approach had scaling issues if thousands or tens of thousands of VCs had to be so transported. Kompella, et al. Expires October 17, 2005 [Page 4] Internet-Draft Circuit Cross-Connect April 2005 Nonetheless, the basic idea was immensely appealing, leading to serious effort to address the scaling and other issues. In any case, CCC as proposed satisfied the requirements of the service provider. Kompella worked on a more detailed design and then an implementation of CCC. Support for the transport of Frame Relay, PPP and HDLC was part of JunOS 3.2, released in March 1999. Subsequently, several enhancements were released, most notably, the transport of ATM AAL/5 PDUs (February 2001), individual ATM cells (May 2001) and Ethernet frames (May 2001). Another significant milestone was the notion of Translational Cross-Connect (TCC), which allowed connections between unlike media (e.g., ATM to Ethernet), released in February 2002. Kompella, et al. Expires October 17, 2005 [Page 5] Internet-Draft Circuit Cross-Connect April 2005 3. Design and Implementation We will use the termninology defined in [8] and other places; the figure below is also taken from [8], with some modifications. |<-------------- Emulated Service ---------------->| | | | | V +----+ +----+ V +-----+ AC1 | PE1|==================| PE2| AC1' +-----+ | |----------|....... CCC Tunnel 1 .......|----------| | | CE1 | | | | | | CE2 | | |----------|....... CCC Tunnel 2 .......|----------| | +-----+ ^ AC2 | |==================| | AC2' ^ +-----+ ^ | +----+ +----+ | ^ | | Provider Edge 1 Provider Edge 2 | | | | | | Customer | | Customer Edge 1 | | Edge 2 | | | | native service native service AC: Attachment Circuit CE: Customer Edge device PE: Provider Edge device Figure 1: CCC reference model There are two main aspects to the design of CCC: control plane: how a given AC is associated with LSPs at the ingress and egress LSRs, and how the ingress and egress synchronize the connection; and data plane: how a AC (for each Layer 2 type) is encapsulated inside MPLS, and what modifications (if any) are made at the ingress and egress LSRs. 3.1 Control Plane At the time that CCC was developed, only unidirectional LSPs were defined in the protocol specifications; thus this was the approach taken for CCC. (To date, this approach has been retained by all mechanisms for the transport of Layer 2 circuits over MPLS.) This Kompella, et al. Expires October 17, 2005 [Page 6] Internet-Draft Circuit Cross-Connect April 2005 meant that two RSVP-TE LSPs were needed for each CCC connection, a "transmit" LSP to accept Layer 2 packets arriving at the LSR, to be encapsulated in MPLS and sent to the remote PE; and a "receive" LSP to deliver MPLS-encapsulated Layer 2 frames, to be re-constituted and sent to the Layer 2 network. Note that from the point of view of the other end of the CCC connection, the roles of transmit and receive LSPs are reversed. The association of an AC to a transmit and receive LSP is done by explicit provisioning on the PEs, using the following configuration stanza: attachment circuit: encapsulation type: transmit LSP: receive LSP: This instructs the PE to splice the subinterface (i.e., virtual circuit) to the named transmit and receive LSPs, using one of the encapsulation methods described below. Note that the two ends of the CCC connection must be configured consistently. One could signal the encapsulation type as part of the RSVP-TE LSP setup, for example in the Properties object (Section 3.1.2.1), to automate verification of consistent encapsulations. The transmit and receive LSPs are signaled using RSVP-TE ([1]). There are two reasons for this. The first reason is that between a given pair of LSRs, any number of independent RSVP-TE LSPs can be defined and identified, whereas with LDP there can only be one LSP between a pair of LSRs, and even if there are several, there is no easy way of distinguishing them. The second is RSVP-TE offered many features that were deemed important for carrying Layer 2 traffic, such as traffic engineering ([3]), call admission control and fast reroute ([7]). As background, it might be helpful to describe a typical configuration model for RSVP-TE LSPs. The following is a simple approach: LSP to { [explicit path | cspf]; [bandwidth specification]; [protection style]; } This defines an LSP named "" on the configured LSR, say A, and requests that LSR A signal the LSP to the LSR identified by "" (e.g., by an IP address) using RSVP-TE. The path (sequence of hops Kompella, et al. Expires October 17, 2005 [Page 7] Internet-Draft Circuit Cross-Connect April 2005 the LSP traverses) can either be explicitly given or can be computed by LSR A using a form of the "Constrained Shortest Path First" algorithm. The specification of a bandwidth parameter requests that LSR A (and all LSRs along the path of the LSP) do call admission control and reserve bandwidth for the LSP. The protection style parameter, if present, requests that the LSP be protected, typically using one of the methods in [7]. This configuration illustrates some of the features of RSVP-TE LSPs (e.g., naming, traffic engineering, call admission control and protection) that make RSVP-TE LSPs appealing as vehicles for Layer 2 traffic. The choice to identify transmit and receive LSPs by name in the CCC configuration was dictated by usability. RSVP-TE LSPs are identified by name in LSP configuration, and so using this very name seemed the most user-friendly approach. However, this simple approach has a drawback: if several LSPs with the same name (say "foo") terminate at a given LSR, and on that LSR, a connection is defined with receive LSP named foo, there is no way to disambiguate among all the LSPs named foo. However, while this problem is solvable (e.g., by using RSVP sessions as identifiers), the result would not be human- readable, and this idea was discarded. In practice, using LSP names has not been an issue. In fact, as can be seen in the case studies below, using LSP names can be a benefit, allowing one to quickly and easily identify the LSPs transporting a given circuit. 3.1.1 Actions on the PE A PE on which a configuration stanza like the one above is present must perform the following four actions: 1. signal and set up the transmit LSP (say with label T); 2. check whether it is the egress for an LSP whose name matches the receive LSP name (and also to make sure such an LSP is given a real label R, not an implicit or explicit null). To do this check, one uses the name of the LSP carried in the Path message, specifically, in the Session Name field of the SESSION_ATTRIBUTE object]. 3. check that the given subinterface exists and is up; 4. if the above three steps succeed, establish the cross-connection. This involves: 1. instructing the forwarding plane to take the Layer 2 frames or cells received on the subinterface, modify them as explained in Section 3.2, push the transmit label T, and encapsulate the result as an MPLS packet; and Kompella, et al. Expires October 17, 2005 [Page 8] Internet-Draft Circuit Cross-Connect April 2005 2. instructing the forwarding plane that for packets received on the receive LSP (i.e., with label R), the label should be popped, the packet modified as in Section 3.2 and the result forwarded out the subinterface. 3.1.2 Protocol Changes When CCC was first implemented, there was only one minor change to the RSVP-TE implementation. Typically, the egress LSR of an RSVP-TE LSP sent back either an implicit or explicit null to its upstream neighbor. The change made (only to the implementation, not to the protocol specification) was that the egress of a RSVP-TE LSP that was a receive LSP of some CCC connection had to send back a "real" label so that the connection could be established in the data plane. (The reason a real label is needed (as opposed to an explicit or implicit null label) is to identify packets as belonging to the receive LSP.) In later implementations, though, a new RSVP object, the "Properties Object", was introduced. This object (among other things) allowed a PE to signal the local state of an AC to the remote end, for the purposes of Operations, Administration and Management and fault reporting. These are important to CCC because they are vital functions of the Layer 2 services that CCC was designed to emulate. 3.1.2.1 Properties Object A PE signals the Properties Object in the RSVP Path message for the CCC Transmit LSP and this is carried in every Path message, thereby refreshing the state of the AC. Any change to the AC local state triggers a Path message to be sent with the correct AC status. The Class Number for the Properties Object has not yet been assigned officially. The Class Type is 1. The Properties Object is formatted as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Count | Pad Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs ... | . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of Properties Object Kompella, et al. Expires October 17, 2005 [Page 9] Internet-Draft Circuit Cross-Connect April 2005 The TLV count is the number of Type-Length-Value (TLV) triplets present in the Properties Object. The Pad Length is between 0 and 3, and is used to pad the entire object length to a multiple of 4 (as required by [2]). The overall length of the Properties Object in the object header in octets is therefore: 4 (object header length) + 2 (TLV Count field) + 2 (Pad Length field) + 2*nTLVs (Type + Length fields for each TLV) + sum (TLV Lengths) + value of Pad Length The Length of a TLV is the length of the Value field in octets. A TLV is formatted as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Value continued, if needed) | . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Format of Properties Object TLVs The particular TLV relevant to CCC is the Circuit Status TLV. The Type of this TLV is 8, the Length is 1, and the Value is 0 for "Circuit Up", 1 for "Circuit Down" and 2 for "Status Unknown". 3.1.3 Fault Reporting CCC's successful deployment brought with it several new requirements. Primary among them was a means of debugging CCC connections. There were already commands that one could run on a PE to determine the local status of a connection. However, an administrator could not determine the status of the remote end of the connection without logging in to the other PE. More significantly, the CE devices needed to know what the overall circuit status was, either to report it or to take corrective action. Fault reporting devolved into two components: one or both of the unidirectional RSVP-TE LSP being down, and an attachment circuit at either end being down. Information about the former was available to both PEs, as this was part of the RSVP-TE protocol. Information Kompella, et al. Expires October 17, 2005 [Page 10] Internet-Draft Circuit Cross-Connect April 2005 about the attachment circuit, however, depended on the Layer 2 encapsulation. For PPP and HDLC, keepalives were sent from CE to CE. Thus, if an attachment circuit were to go down, the other CE would find out when keepalives timed out. This was acceptable if a detection time of the order of tens of seconds was tolerable; however, in some circumstances, a faster mechanism was required. For Frame Relay and ATM, keepalives (such as LMI or ILMI) were generally terminated on the PE. This meant that, unlike PPP and HDLC, the remote CE could not find out the status of the other attachment circuit. The solution was that a PE, on learning that its local attachment circuit (or the link) was down, signals this through RSVP-TE to its peer. This also solved the problem of quicker notification for PPP attachment circuits in the case where the link failed. A PE generally discovered a link failure very quickly; it could then signal this to the other PE, which in turn relays it to the remote CE, instead of the remote CE having to wait for keepalives to time out. 3.2 Data Plane In order to carry Layer 2 frames across the MPLS backbone, a format had to be defined for these frames when encapsulated in MPLS. The format was decided based on the requirements at both ends. As these requirements varied with the type of Layer 2 frame, each Layer 2 had its own format. In what follows, the processing required for each type of Layer 2 AC is detailed for ingress (i.e., before entering the transmit LSP) and egress (i.e., after leaving the receive LSP). 3.2.1 Frame Relay On ingress, Frame Relay PDUs belonging to the CCC sub-interface are identified by the DLCI they carry. The DLCI is then mapped either directly or via a cookie to the outgoing transmit LSP. The DLCI is then stripped from the Frame Relay PDU, the corresponding label pushed on the PDU, and the Layer 2 header appropriate to the outgoing MPLS interface put on the packet. Note that in so doing, some information in the DLCI (such as the FECN/BECN and DE bits) is discarded. Pictorially: Kompella, et al. Expires October 17, 2005 [Page 11] Internet-Draft Circuit Cross-Connect April 2005 +------+------------+---------------+ | DLCI | NLPID/SNAP | Layer 3 frame | +------+------------+---------------+ | \ / | -------------------------- | | | | | ------------- V | cookie -- mapping -- | | | | | V v +-----------+-------+--------------------+ | L2 header | label | Frame without DLCI | +-----------+-------+--------------------+ Figure 5: Frame Relay PDUs Encapsulated as CCC At the egress PE, an MPLS packet arrives with the label allocated by the egress PE for the receive LSP for the connection. The egress PE then maps the label into the appropriate DLCI for the egress Frame Relay subinterface and pop the L2 header and label. Then the egress DLCI is prepended to the remainder of the frame, with zeros used for the control bits, thus re-constituting an entire Frame Relay PDU. Note that the egress DLCI need not be the same as the ingress DLCI; thus the CCC connection acts exactly as a Frame Relay switch would for the DLCI, i.e., switching an ingress DLCI on the ingress port to a possibly different egress DLCI on an egress port. There is a variant of Frame Relay CCC called "Frame Relay port mode". In this mode, all Frame Relay traffic except that on DLCI 0 and DLCI 1023 (which are special DLCIs carrying control information) are mapped to a single transmit LSP. In this mode, the DLCI is not stripped on ingress, nor added at egress. The two modes have different characteristics. The 'normal' Frame Relay mode allows greater flexibility, since each DLCI can go to a different destination PE and port. Also, DLCI switching is possible. Port mode, on the other hand, requires less configuration and a single pair of LSPs. DLCI switching at egress is not possible with port mode. 3.2.2 PPP, HDLC and Ethernet For PPP, HDLC and Ethernet, a CCC connection maps all traffic on a physical port to a transmit LSP. On ingress, all framing information is removed from the received frame. For PPP and HDLC, this includes flags, the Frame Checksum and bit or byte stuffing. For PPP, the Kompella, et al. Expires October 17, 2005 [Page 12] Internet-Draft Circuit Cross-Connect April 2005 initial two octets of the Layer 2 frame (0xff, 0x03) are also removed at the ingress, and put back at the egress. For Ethernet, the framing information includes the inter-packet gap, the preamble, the Frame Checksum and possible pad octets. In all these cases (PPP, HDLC and Ethernet) the resulting Layer 2 PDU is mapped by port number to a transmit label. Pictorially: +------------------------------------------+ port | Layer 2 PDU, without framing information | num +------------------------------------------+ | \ / | ---------------------------------------- | | | | | ------- V | mapping ------------- | | | | | V v +-----------+-------+--------------------+ | L2 header | label | Layer 2 PDU | +-----------+-------+--------------------+ Figure 6: Frame Relay PDUs Encapsulated as CCC At the egress PE, an MPLS packet arriving with the label allocated by the egress PE for the receive LSP for the connection is mapped to the appropriate egress port for the connection. The L2 header and label are removed and the frame is sent out the egress port. Framing bits and bytes are added in the process of transmission. A variant of Ethernet allows one to partition an Ethernet port into subinterfaces by Virtual LAN (VLAN) identifiers. The operation is largely the same as for non-VLAN Ethernet. The only difference is that on ingress, the mapping to a transmit label is based on instead of just physical port number. 3.2.3 ATM AAL/5 PDUs On ingress, ATM cells belonging to a VC carrying AAL/5 data are first re-assembled into a Protocol Data Unit (PDU). The PDU contains only the data within the cells; there is also an external cookie that identifies the VC (or equivalently, the subinterface). When an Kompella, et al. Expires October 17, 2005 [Page 13] Internet-Draft Circuit Cross-Connect April 2005 entire PDU is available, the cookie (i.e., the subinterface) is mapped to the outgoing transmit LSP, the corresponding label pushed on the PDU, and the Layer 2 header appropriate to the outgoing MPLS interface put on the packet. Pictorially: cell cell cell cell cell cell cell cell header data header data header data header data +----+------+ +----+------+ +----+------+ +----+------+ |VC1 | | |VC1 | | ... |VC1 | | |VC1 | | +----+------+ +----+------+ +----+------+ +----+------+ | \ / \ / \ / \ / | ---- ---- ---- ---- | | | | | | | | | | | ------------- ---- ------ ----------- V | | | | cookie -- mapping -- | | | | | --- | | ----- | | | | | V v v v v +-----------+-------+------- ... -------+ | L2 header | label | ATM AAL/5 PDU | +-----------+-------+------- ... -------+ Figure 7: ATM AAL/5 PDUs Encapsulated as CCC At the egress PE, an MPLS packet arrives with the label allocated by the egress PE for the receive LSP for the connection. The egress PE then maps the label into the appropriate VC for the egress ATM subinterface, pop the L2 header and label, and segment the AAL/5 PDU into ATM cells. On each cell, it prepends an ATM cell header with the egress VC. Note that the egress VC need not be the same as the ingress VC; thus the CCC connection acts exactly as an ATM switch would for the VC, i.e., cell-switching an ingress VC on the ingress port to a possibly different egress VC on an egress port. 3.2.4 ATM Cells In ATM cell mode, a CCC connection takes one or more cells, all belonging to a single VC (or VP, for VP-based cell-mode switching), modifies the ATM header, and encapsulates the ATM cell with modified header as MPLS, and sends it out over the transmit LSP. This mode can be used for any Adaptation Layer (AAL1-5). The number of cells that are bundled together in a single MPLS packet depends on the delay and jitter that can be tolerated on the CCC connection. Typically, this is specified by an upper bound on the number of cells and the time from receiving the first cell to Kompella, et al. Expires October 17, 2005 [Page 14] Internet-Draft Circuit Cross-Connect April 2005 transmitting the MPLS packet. cell cell cell cell cell cell cell cell header data header data header data header data +----+------+ +----+------+ +----+------+ +----+------+ |VC1 | | |VC1 | | ... |VC1 | | |VC1 | | +----+------+ +----+------+ +----+------+ +----+------+ \ | / \ / \ / \ / --------- --------- --------- --------- | | | | | | | | | | | ------------- ---- ------ ----------- V | | | | cookie -- mapping -- | | | | | --- | | ----- | | | | | V v v v v +-----------+-------+------- ... --------+ | L2 header | label | cell1 | | celln | +-----------+-------+------- ... --------+ Figure 8: ATM Cells Encapsulated as CCC At the egress PE, an MPLS packet arrives with the label allocated by the egress PE for the receive LSP for the connection. This label identifies the CCC connection. The egress PE removes the label, fixes the ATM header, and sends the packet over the outgoing ATM interface. Kompella, et al. Expires October 17, 2005 [Page 15] Internet-Draft Circuit Cross-Connect April 2005 4. Discussion CCC has been very successful, both as a tool for Service Providers as well as to demonstrate that transporting Layer 2 over MPLS was a viable and useful technology. This led to several enhancements to the original implementation. At the same time, some drawbacks came to light, which necessitated a rethinking of some of the design. This section examines both aspects of CCC, the enhancements and the drawbacks, and presents some solutions to the latter. 4.1 Enhancements to CCC As is often the case, deployment meant refinement and new features. The most straightforward of these was the addition of new types of Layer 2 encapsulations: the original implementation only dealt with ATM AAL/5 PDUs, Frame Relay, PPP and HDLC. Later, cell-mode ATM, Virtual Path switching for ATM and Ethernet were added. Within cell- mode ATM, the ability to put several cells (from the same VC, or even from different VCs) into a single MPLS packet improved the transport efficiency of the encapsulation. From a management point of view, two topics were discussed: fault reporting (already described) and simplified configuration. The former was implemented. The latter was what is now called "single- sided signaling". It consisted of having yet another (optional) clause in the configuration stanza for CCC: "". The theory was that RSVP-TE signaling would carry this information to the remote end, where a connection would be established for the named subinterface without a corresponding configuration stanza. However, on reflection, this "solution" created more problems than it solved. First, making sure that the remote subinterface was correct was difficult; making a connection on the wrong subinterface was a serious matter. Second, the resultant asymmetric provisioning usually made management harder rather than easier. Third, creating connections with no configuration whatsoever violated the principle of least surprise. Finally, the provisioning model for CCC was inherently complex; it was decided to solve this problem completely rather than offer a quick fix (see Section 4.3). Furthermore, there were requests for improved QoS with CCC. In the control plane, this meant doing Call Admission Control and managing bandwidth, functions that RSVP-TE already provided. In the data plane, this required mapping information in the Layer 2 header of Layer 2 frame to the MPLS label. This took two forms: for ATM (Frame Relay), the Cell Loss Priority (Discard Eligible) field in the ATM (Frame Relay) header was mapped to one of the EXP bits in the label to indicate whether this frame should be dropped ahead of others in the case of congestion. For Ethernet, this meant mapping the 802.1p Kompella, et al. Expires October 17, 2005 [Page 16] Internet-Draft Circuit Cross-Connect April 2005 bits in a Virtual LAN tag to the EXP bits in the label. Finally, there was an important innovation, the notion of "Layer 2.5" connections, also called Translational Cross-Connect (TCC). Unlike CCC connections, which require the same Layer 2 type at each end of the connection, TCC connections can have different types of Layer 2, but can only carry IPv4 packets. In TCC, the forwarding of the packet is based entirely on the Layer 2 header (e.g., the Frame Relay DLCI), just as in in CCC; IP header information is not used for forwarding decisions. However, what is carried with the MPLS packet is just the IP payload. cell cell cell cell cell cell cell cell header data header data header data header data +----+-------+ +----+-------+ +----+-------+ +----+-------+ |VC1 | | |VC1 | | |VC1 | | |VC1 | | +----+-------+ +----+-------+ +----+-------+ +----+-------+ | \ / \ / \ / \ / | ----- ----- ----- ----- | | | | | | | | | | | -------------- ---- ------- ------------- V | | | | cookie -- mapping -- | | | | | --- | | ---- | | | | | | v v v v | +----------- ... ---+ | | SNAP | IP payload | ATM AAL/5 PDU | +----------- ... ---+ | ____/ ____/ v / / +-----------+-------+---- ... ---+ | L2 header | label | IP payload | +-----------+-------+---- ... ---+ Figure 9: ATM AAL/5 PDUs Encapsulated as TCC At the egress PE, an MPLS packet arrives with the label allocated by the egress PE for the receive LSP for the connection. The egress PE then maps the label into the appropriate Layer 2 address (Frame Relay DLCI, ATM VC, Ethernet VLAN) [if any] for the egress subinterface, pop the L2 header and label, and encapsulate the IP payload with the Layer 2 header for the egress subinterface. Kompella, et al. Expires October 17, 2005 [Page 17] Internet-Draft Circuit Cross-Connect April 2005 +-----------+-------+---- ... ---+ | L2 header | label | IP payload | +-----------+-------+---- ... ---+ | \ \ ________| \ \ | \ \ | \ \ v +---------+---- ... ---+ Ethernet | Eth hdr | IP payload | port +---------+---- ... ---+ Figure 10: TCC Frames Decapsulated into Ethernet If the egress subinterface was Ethernet, encapsulating the outgoing IP packet required knowing the MAC address of the CE connected over that Ethernet. This MAC address could be be obtained by doing a proxy ARP on behalf of the remote CE; another option was to configure this MAC address statically. Both options were implemented. 4.2 Operational Issues Several operational issues were discovered during deployment. The first was that CCC was tied to RSVP-TE as the tunnel LSP setup protocol, whereas most providers were using LDP. The second was that since CCC did not use label stacking, every CCC connection on a PE consumed an RSVP-TE LSP. With label stacking, a single LSP, whether signaled using RSVP-TE or LDP, can simultaneously carry multiple connections, as well as other traffic. This approach had serious scaling concerns for the control plane. Another problem often encountered was that the MTU for the subinterfaces at either end of a connection didn't match. Finally, as has been mentioned before, provisioning was cumbersome. Perhaps because of these operational issues, CCC wasn't used much as a technology for providing Layer 2 VPNs to end customers. Rather, it was used as an infrastructure technology within the service provider's network. Other issues were discussed as well, although they didn't pose operational problems. For example, several bits in the Frame Relay header (such as the Forward and Backward Explicit Congestion Notification) were simply discarded; some felt that this was technically inaccurate. Also, no effort was made to ensure that the two subinterfaces in a connection had the same Layer 2 type. Also, while one could create a connection that spanned IGP areas or Autonomous Systems, doing so required allowing RSVP-TE across the area/AS boundary. Kompella, et al. Expires October 17, 2005 [Page 18] Internet-Draft Circuit Cross-Connect April 2005 4.3 Provisioning Model The provisioning model for CCC was as follows: 1. Provision an RSVP-TE (transmit) LSP. Implicitly, this does two things: define the remote end, and provide a key to tie the connection on this PE to the connection on the remote PE (via the LSP name). 2. Provision a connection, tying a subinterface to the transmit and receive LSPs. 3. Do the same at the other end of the connection. Essentially the same provisioning model was adopted by the PWE3 Working Group (see [8] and [9]), where for each end of a pseudowire, one must state what the remote endpoint is, and give an identifier for the remote end to make the connection ("VC ID"); and both ends must be provisioned. This model is acceptable for a small number of connections, or for a relatively static environment. Thus, CCC was well suited to a network infrastructure: define the connections once, then leave them alone. However, for a dynamic environment where connections are defined, removed or changed frequently, or an environment where a lot of connections are needed, CCC is a poor fit. An example of such an environment is a Layer 2 VPN offered as a service to an end customer. Every new customer means several new connections to be defined; existing customers may also require adding, removing or moving connections. Analyzing this further, we realized that the latter environment required the following features: 1. Autodiscovery: one should NOT have to define the endpoint of each connection. This is especially important when there are several related connections (such as for a Layer 2 VPN); it reduces an O(N^2) configuration task to O(N), where N is the number of sites in the VPN. Furthermore, autodiscovery eliminates potential security breaches arising from misconfiguration (see Section 4.4). 2. VPN Identifier: if one is provisioning a VPN, all the connections in that VPN, no matter on which PE, should immediately identify themselves as being in the same VPN. This helps troubleshooting immensely. Kompella, et al. Expires October 17, 2005 [Page 19] Internet-Draft Circuit Cross-Connect April 2005 3. Regular Topologies: one should be able to provision regular topologies (such as full mesh, hub-and-spoke, dual-hub-and-spoke and ring) easily and intuitively. It is acceptable for non- regular topologies to require more complex provisioning. 4. Inter-AS scenarios: being able to provision a VPN across multiple ASes is vital for today's carriers. Furthermore, this had to be coupled with label stacking (to scale the control plane, and to allow non-RSVP-TE tunnels). The solution we came up with is documented in [10] and [5]. Briefly, this solution adapts the mechanisms defined for IP VPNs ([6]) to address the needs of Layer 2 VPNs, and in so doing meets the four requirements laid out above. Furthermore, reusing the concepts of IP VPNs minimizes both the learning curve and the provisioning burden for Layer 2 VPNs. This is especially true for the provisioning of inter-AS VPNs. BGP-based Layer 2 VPNs have been deployed in a number of carriers. 4.4 Security The primary security issue with CCC is that wrong connections may be made. Since CCC's provisioning model is manual (i.e., no protocols are involved in making the connection), the concern is misconfiguration. This can happen in two ways. 4.4.1 Configuration In the figure below, suppose one wants to connect interface intf1 from CE A1 to interface intf3 on CE A2 using LSPs 'PE1-PE2:A' and 'PE2-PE1:A'. Then one would need a configuration stanza like the following on PE 1: attachment circuit: intf1 transmit LSP: PE1-PE2:A receive LSP: PE2-PE1:A and on PE 2: attachment circuit: intf3 transmit LSP: PE2-PE1:A receive LSP: PE1-PE2:A Kompella, et al. Expires October 17, 2005 [Page 20] Internet-Draft Circuit Cross-Connect April 2005 CE A1 +------+ +------+ CE A2 \ intf1 | | <=== LSP PE2-PE1:A ==== | | intf3 / \_____ | PE 1 | ==== LSP PE1-PE2:A ===> | PE 2 | _____/ _____ | | <=== LSP PE3-PE1:B | | _____ / | | ===> LSP PE1-PE3:B | | \ / intf2 +------+ +------+ intf4 \ CE B1 CE C1 Figure 11: CCC Security Issues If one mistyped 'intf2' instead of 'intf1' in the PE1 configuration above, CE B1 could get connected to CE A2, which is a potential security breach. The other mis-connnection that could happen is that one types 'PE1-PE3:B' as the transmit LSP on PE1. Then data from CE A1 goes to some CE hanging off PE3. This too could lead to a breach of security; however, as this is only a partial connection, it will likely be found quickly, and in fact the underlying network layers may detect the problem. This problem is exacerbated if multiple connections are needed among a set of CEs (i.e., a Virtual Private Network or VPN). There is no a priori relationship among the various connections; one could enforce an LSP naming scheme that alleviates the problem, but CCC offers no features on this front. This provided yet another incentive to pursue a different provisioning model for Layer 2 VPNs, namely that described in [10]. The introduction of a construct that can be used as a common VPN identifier across all connections in a VPN helps prevent misconfiguration in the first place, and eases troubleshooting if one does occur. 4.4.2 Data Plane CCC does not offer authentication or encryption services, although they are not precluded. CCC does offer isolation, that is, packets from one connection are delivered only to the remote endpoint (CE) for that connection. CCC relies on MPLS properties for this: if an LSP is set up correctly in the control and data planes, packets traversing that LSP will be delivered to its egress, and will not be mixed up with packets from another LSP. This is the same isolation property that Frame Relay or ATM virtual connections have. If the MPLS control and/or data plane is compromised, this isolation property is no longer guaranteed. Securing the MPLS control and data planes is beyond the scope of this document; however, others have addressed these issues (see [1] and [4].) Kompella, et al. Expires October 17, 2005 [Page 21] Internet-Draft Circuit Cross-Connect April 2005 5. Case Studies CCC has been quite a success despite the issues discussed above. The main deployment has been in Service Provider infrastructure networks, unlike Layer 2 over MPLS (PWE3 and Layer 2 VPNs), which is primarily viewed as a service offered to end customers. What follows is the overview of a few deployments of CCC in such an infrastructural role. 5.1 CCC in Mobile Operator Networks For mobile operators that have IP/MPLS networks, CCC can be used to fulfill ATM-cell and frame-relay transport requirements for nodes that lack IP transport capabilities. In addition to the cost savings incurred by doing this, CCC allows mobile operators to take advantage of features typically offered by RSVP signaled MPLS LSPs. Features such as fast-reroute, traffic-engineering and per-lsp-statistics can then be applied to mobile service offerings. CCC can be used to provide ATM transport for the current 3G-R99/UMTS offerings while maintaining QoS requirements. The IUcs and IUps interfaces can be mapped to different logical or physical interfaces which are in turn mapped to separate egress service queues and MPLS LSPs. The MPLS packets that carry the IUcs ATM cells can have their EXP markings set differently than those MPLS packets that are carrying IUps. This ensures that quality of service is maintained across the mobile operator's MPLS network. The use of MPLS fast- reroute also ensures that failure recovery times are within tens of milliseconds making this technology a viable option to carry voice service: ------ ----- ----- | UMTS |---IUps---| | | |----IUps---SGSN | RNC | | LSR |------------| LSR | | |---IUcs---| | | |----IUcs---Media ------ ----- ----- Gateway <--ATM---> <---MPLS---> <---ATM---> Figure 12: CCC Used to Interconnect RNC Islands CCC can also be used to provide a layer two frame-relay network for the Gb interfaces between the BSC and SGSN nodes for GPRS and EDGE services. The benefit here is for increased transport consumption efficiency and cost reduction in a mobile operator's network. This is achieved by statistically multiplexing Gb DS0's from multiple BSCs onto the mobile operator's MPLS network: Kompella, et al. Expires October 17, 2005 [Page 22] Internet-Draft Circuit Cross-Connect April 2005 --- ----- ----- --- BSC--| D | ch | | | | ch | D |---SGSN | A |--DS3--| LSR |-----------| LSR |--DS3--| A |---SGSN BSC--| C | | | | | | C | | S | | | | | | S | --- ----- ----- --- <--FR--> <--MPLS--> <--FR--> Figure 13: CCC Used to Interconnect DACSs 5.2 CCC in Carrier Networks for ATM Trunk Applications CCC can be used to transparently carry ATM traffic across an IP/MPLS backbone. Using CCC in this fashion allows the end-node ATM switches to use proprietary signaling mechanisms and exchange information as they would over a direct connection. The ATM switches themselves will not see the intermediate routers, and the routers will discreetly stitch the ATM ports together to create a seamless Layer 2 ATM connection between those ATM switches. ATM MPLS ATM ATM SW <---> LSR <------> LSR <---> ATM SW |________________| CCC RSVP LSP Figure 14: CCC Used to Interconnect ATM Trunks CCC not only offers Layer 2 VPN capabilities, but also comes with the advantages of using RSVP signaled LSPs - such as RSVP EROs, FRR, and LSP statistics. Specifying EROs allows for specific LSP engineering in the network, which is advantageous for mapping ATM traffic between core POPs. By associating ATM traffic to a particular/preferred IP/ MPLS backbone link, it is then possible to force the LSP to fail should the IP/MPLS link fail. This RSVP signalled feature is important if the MPLS reroute is not preferred in situations where the ATM switches themselves are running a PVC-reroute routing protocol. If required, the MPLS network can also perform the reroute during a primary link failure using MPLS fast-reroute (FRR) which in turn provides recovery times of within tens of milliseconds. Two other key drivers for selecting the CCC/RSVP are per-LSP statistics and selective LSP naming. Collection of per-LSP statistics allows for close monitoring and utilization graphing of the CCC LSPs. Selective LSP naming allows for the provisioning of specific LSP names that can indicate what the CCC LSP is used for, its origin and its endpoint, Kompella, et al. Expires October 17, 2005 [Page 23] Internet-Draft Circuit Cross-Connect April 2005 or various other unique values that can be added to the name field. CCC can also be combined with class-of-service properties to provide a complete ATM solution, both in terms of transport as well as traffic priority and protection. 5.3 CCC as a Core Convergence Technology in Carrier Networks CCC can also be used as the foundation for a form of convergence of multiple networks in a Service Provider environment, which, although simplistic, offers good isolation and several other benefits. Many established Service Providers have multiple purpose-built networks that offer different services to customers (e.g., ATM, frame relay, IP VPN, public Internet), but whose infrastructure is located in the same central offices and whose transmission circuits largely follow the same physical paths. Historically, the chief sharing of resources among these networks was at the SONET level, with each network consuming its own SONET circuit, and no ability to share bandwidth dynamically among the networks aside from the statically provisioned OC-n circuits. CCC offers the ability to trunk multiple disparate services across a common high-speed core using simple and effective Layer-2 separation. This approach is not new, in that overlay networks (e.g., IP-over-ATM and IP-over-frame-relay) have been built on a large scale for many years. However, CCC allows this simple approach to be extended while preserving the familiar concept of operations and provisioning that Service Providers understand and have been comfortable with for a long time. The distinct legacy networks can maintain their separate edge devices, but become "client networks" of a shared core by substituting their wide-area circuits for an appropriately-selected mesh of CCC connections across the core. This design maintains strong isolation of the individual overlay networks via Layer 2 VCs, and there is no control-plane interaction among the client networks either with the core or with each other; the hand-off is a statically provisioned Layer 2 virtual circuit. This characteristic is important in reducing shared fate and ensuring that misbehavior or failure in one network cannot affect the others or the core. In addition, because CCC is simple and does not require much in the way of control plane itself (no BGP, for example), the shared core can exist with a minimal configuration in accordance with the belief that complexity is the enemy of reliability and stability. Kompella, et al. Expires October 17, 2005 [Page 24] Internet-Draft Circuit Cross-Connect April 2005 ___ .......................... ___ FR UNI---|FR | . . |FR |---FR UNI ---|SW | . ----- ----- . |SW |--- ---|___|-------| | | |-------|___|--- . | | | | . . | LSR |=== ::: ===| LSR | . ___ . | | | | . ___ IP---| |-------| | | |-------| |---IP ---|IP | . ----- ----- . |IP |--- ---| | . Service Independent Core . | |--- --- .......................... --- <--FR--> <--MPLS--> <--FR--> Figure 15: CCC Used to Interconnect Distinct Service Edge Devices Because a single core device can provide say, emulated ATM CCC connections on one interface and emulated FR on another, CCC enables a single core to play multiple roles where a true ATM or FR core could not easily and efficiently. This approach reduces transmission costs by eliminating the separate circuits per network, and allows the core trunks to be used more efficiently by statistically multiplexing multiple client networks into one. In addition, the previously cited benefits of MPLS and RSVP-TE can be realized, including traffic engineering and restoration via fast reroute if desired. Kompella, et al. Expires October 17, 2005 [Page 25] Internet-Draft Circuit Cross-Connect April 2005 6. Security Considerations CCC security concerns stem from two primary sources. The first is misconfiguration, where a connection is mis-specified. The other is co-option, compromise or failure of the data plane. Both of these are discussed in some detail in Section 4.4. Kompella, et al. Expires October 17, 2005 [Page 26] Internet-Draft Circuit Cross-Connect April 2005 7. Acknowledgments The authors would like to thank Der-Hwa Gan, Arthi Ayyangar and Nischal Sheth for their reviews, and Der-Hwa and Arthi and others for their contributions to CCC's implementation and enhancements. Kompella, et al. Expires October 17, 2005 [Page 27] Internet-Draft Circuit Cross-Connect April 2005 8. References 8.1 Normative References [1] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. 8.2 Informative References [2] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [4] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [5] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service", draft-ietf-l2vpn-vpls-bgp-05 (work in progress), April 2005. [6] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-03 (work in progress), October 2004. [7] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07 (work in progress), September 2004. [8] Bryant, S. and P. Pate, "PWE3 Architecture", draft-ietf-pwe3-arch-07 (work in progress), March 2004. [9] Martini, L., "Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-16 (work in progress), March 2005. [10] Kompella, K., "Layer 2 VPNs Over Tunnels", draft-kompella-l2vpn-l2vpn-00 (work in progress), January 2004. Kompella, et al. Expires October 17, 2005 [Page 28] Internet-Draft Circuit Cross-Connect April 2005 Authors' Addresses Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: kireeti@juniper.net John Ospina Cingular Wireless 7277 164th Ave NE Redmond, WA 98052 US Email: john.ospina@cingular.com Shilpa Kamdar Cingular Wireless 7277 164th Ave NE Redmond, WA 98052 US Email: shilpa.kamdar@cingular.com Jeff Richmond Electric Lightwave 4400 NE 77th Ave Vancouver, WA 98662 US Email: jeff_richmond@eli.net Gregory J. Miller MCI 22001 Loudoun County Parkway Ashburn, VA 20147 US Email: Gregory.J.Miller@MCI.com Kompella, et al. Expires October 17, 2005 [Page 29] Internet-Draft Circuit Cross-Connect April 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kompella, et al. Expires October 17, 2005 [Page 30]