One document matched: draft-kompella-ccc-02.txt
Differences from draft-kompella-ccc-01.txt
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: <subinterface>
encapsulation type: <encaps type>
transmit LSP: <name of transmit LSP>
receive LSP: <name of 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 <name> to <dest> {
[explicit path | cspf];
[bandwidth specification];
[protection style];
}
This defines an LSP named "<name>" on the configured LSR, say A, and
requests that LSR A signal the LSP to the LSR identified by "<dest>"
(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
<physical port number + VLAN ID> 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: "<remote subinterface>".
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]
| PAFTECH AB 2003-2026 | 2026-04-21 16:54:44 |