One document matched: draft-pan-pwe3-over-sub-ip-00.txt
Network Working Group Ping Pan (Ciena)
Internet Draft Tad Hofmeister
Expiration Date: January 2005
Dry-Martini: Supporting PWE3 Over Sub-IP Networks
draft-pan-pwe3-over-sub-ip-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo proposes a method for transporting layer-2 frames over
existing transport networks by establishing "pseudo-wires" between edge
nodes. The key difference with the existing PWE3 design is that, in our
proposal, pseudo-wires can be established directly on top of all types
of "tunnels", including SONET cross-connects, optical wavelength and ATM
circuits without introducing MPLS LSR functionality on all network
intermediate nodes. The general mechanism for establishing and managing
pseudo-wires is the same as what has been defined in draft-martini. At
data forwarding level, we adapt the same encapsulation methods that have
been defined in IETF PWE3 WG. This memo articulates some of the
requirements for adapting such method.
Pan, et al ^L[Page 1]
Internet Draft draft-pan-pwe3-over-sub-ip-00.txt June 2004
1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. Motivation
Draft-martini presents a mechanism that can aggregate multiple
Layer-2 flows into a single tunnel and carry them over the IP
backbone. As described in [PWE3-ARCH] [PWE3-TRANSPORT], the tunnels
(or PSN Tunnels) are either IP path or MPLS LSP's.
Each Layer-2 flow is mapped to a pseudo-wire. The setup and
maintenance of each pseudo-wire involve two endpoints (PE's) of the
connection to exchange connection and encapsulation label information
through targeted LDP [PWE3-CTRL]. Essentially, pseudo-wire operation
is almost independent from the operation taking place inside the
backbone.
Hence, we argue that the same data aggregation mechanism is
applicable for networks other than IP. For instance, the carriers may
create pseudo-wires and therefore aggregate Layer-2 flows onto
optical cross-connects from the edge of an optical backbone. Or, some
providers may choose to create pseudo-wires and aggregate data
packets over the existing ATM networks. In all cases, the underlying
network does not to have to be IP. The tunnels that pseudo-wires
aggregating into may be (and not limited to) lambda (photonic),
SONET/SDH cross-connects, ATM circuits, or Gigabit Ethernet tunnels.
For clarity, we denote these tunnels as sub-IP Tunnels. The networks
that setup and maintain sub-IP Tunnels, as Sub-IP networks.
Users can create pseudo-wires over sub-IP tunnels directly. Instead
of converging pseudo-wires over MPLS (IP) networks, the concept and
design of pseudo-wire (a.k.a. draft-martini) can be applied to
aggregate Layer-2 data flows over the existing transport networks. We
refer such mechanism as "dry-martini", after pseudo-wire's well-known
inventor.
Pan, et al ^L[Page 2]
Internet Draft draft-pan-pwe3-over-sub-ip-00.txt June 2004
3. Operation Procedure
+-------------+ +-------------+
| Payload | | Payload |
| (Data) | | (Data) |
+-------------+ +-------------+
| Layer-2 | | Layer-2 |
| (Ethernet, | L2 Services | (Ethernet, |
| ATM,...) |<==============================>| ATM, ...) |
| Frames | | Frames |
+-------------+ +-------------+
| PW | Pseudo Wires | PW |
|Demultiplexer|<==============================>|Demultiplexer|
+-------------+ +-------------+
| Sub-IP | | Sub-IP |
| Layers | | Layer |
| (SONET, | Sub-IP Tunnels | (SONET, |
| Lambda...) |<==============================>| Lambda...) |
+-------------+ +-------------+
Figure 1: Logical Protocol Layering Model
Figure-1 presents the protocol-layering model. The key difference
from the existing PWE3 architecture is pseudo-wires being created on
top of sub-IP tunnels. The mechanism for setting up pseudo-wires is
the same as defined in [PWE3-CTRL]. Packet encapsulation at edge is
the same as defined in [PWE3-ETHER] [MARTINI-ATM] and [MARTINI-FR].
The operation reference model is shown in Figure-2:
Pan, et al ^L[Page 3]
Internet Draft draft-pan-pwe3-over-sub-ip-00.txt June 2004
|<------- Pseudo Wire ------->|
| |
| |<-- Sub-IP CON --->| |
PW V V V V PW
End Service +----+ +----+ End Service
+-----+ | | PE1|===================| PE2| | +-----+
| |-----------|.............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |-----------|.............PW2.............|----------| |
+-----+ | | |===================| | | +-----+
+----+ +----+ |
Provider Edge 1 Provider Edge 2
Customer Customer
Edge 1 Edge 2
Figure 2: PWE3-over-sub-IP Reference Model
From the customer network edge, layer-2 frames enter the provider's
backbone. All layer-2 frames have a "flow-id" in their header. The
flow-id may be implemented with VLAN-ID's for Ethernet MAC frames,
DLCI for Frame Relay frames, and VPI/VCI for ATM cells. A customer
edge can be either a switch or a router.
At the provider edge, the operators use LDP and [PWE3-CTRL] to create
pseudo-wires between the network edges. All incoming layer-2 frames
are binded onto the pseudo-wires, before aggregated into pre-
established sub-IP tunnels.
Pseudo-wiring operation is independent from the underlying network's
control plane. Network operators can use the method of their choice
to manage and control sub-IP tunnels: GMPLS for optical networks,
PNNI for ATM networks, or, simply, static configuration for any
transport layer networks. So long there is an operational sub-IP
tunnel between two network edge nodes, the carrier may establish
pseudo-wires and aggregate data flows over it.
3.1. Provider Edge Control-Plane Requirements
For clarity, we repeat the procedure described in [PWE3-CTRL] in the
context of sub-IP tunnels.
Each pseudo-wire consists of two unidirectional paths, one in each
direction. Each provider edge initiates the setup of the path on
behalf of ingress L2 traffic. Each path is uniquely identified by the
Pan, et al ^L[Page 4]
Internet Draft draft-pan-pwe3-over-sub-ip-00.txt June 2004
triple <PE-1, PE-2, VCID>, where the VCID is a 32-bit quantity that
must be unique in the context of a single LDP session between two
provider edges. For a given pseudo-wire, the same VCID must be used
when setting up both paths.
To create pseudo wires between two PE's over a sub-IP tunnel, both
edge nodes MUST be IP-capable. Further, the edge nodes must be
capable of transmitting and receiving IP control messages between
each other.
There are a number of ways to exchange IP control messages (e.g., LDP
messages) between the edge nodes. One approach is to route the
messages through the underlying sub-IP network. For example, in
SONET/SDH networks, the control messages may utilize DCC channels to
communication with each other. However, this would require every
node in the sub-IP network to be IP-capable, which may be not
practical in many of the operational SONET or ATM networks. Another
approach is to establish off-band IP tunnels between the edge nodes.
However, this approach may introduce additional complexity to network
operators.
We propose to "tunnel" all control packets through the sub-IP tunnels
as regular data payload from the edge. Since all user packets must be
encapsulated with a MPLS header at ingress, we require control
packets to be encapsulated with "IP4 Explicit NULL Label" [RFC2032]
before they are tunneled into the sub-IP tunnel. At the egress, the
label is popped, and the control packets are delivered to the control
plane for further processing.
One key advantage here is that the exchange of control messages does
not disturb the sub-IP network's existing operation.
3.2. Provider Edge Data-Plane Requirements
The provider edge nodes can be (not limited to) typical ATM, SONET or
wavelength switches. In additional, they MUST be able to process and
aggregate data packets from multiple L2 users. And each edge node
MUST be able to push or pop a MPLS label for every incoming packet.
All packet encapsulation SHOULD be the same as the ones defined in
draft-martini.
Pan, et al ^L[Page 5]
Internet Draft draft-pan-pwe3-over-sub-ip-00.txt June 2004
4. QoS Considerations
When PW's are used to carry IP traffic over IP backbone, traffic
conditioning and congestion control can be taken care of by end users
(TCP flow control) or through careful link provisioning. However,
when PW's are initiated and traversing through transport networks, as
indicated here, PW-level QoS guarantee may become a mandatory
requirement for the carriers.
Since multiple pseudo-wires can be aggregated into and de-multiplexed
from sub-IP tunnels at PE's, PE's must apply admission control to
regulate user traffic at PE's. Otherwise, we may run into traffic
congestion condition at network edges. Consider the scenario
illustrated in Figure-3:
PW12 (PW12+PW32)
| |
| |
+-----+ V +-----+ |
+-----+ | |---------------| | V +-----+
| CE1 |=======| PE1 |...............| PE2 |==========| CE2 |
+-----+ | |---------------| | +-----+
+-----+ +-----+
PW32 | . |
| | . |
| | . |
+-----+ V | . |
+-----+ | |----------------+ . |
| CE3 |=======| PE3 |................... |
+-----+ | |--------------------+
+-----+
Figure-3: Over-subscription problem in PWE3
Both CE1 and CE3 communicate with CE2. A pseudo-wire, PW12, is
established between PE1 and PE2 to transfer traffic between CE1 and
CE2. Similarly, PW32 is to carry traffic between CE3 and CE2.
Note that the backbone networks (IP or sub-IP alike) may have the
ability to enforce QoS on the tunnels between PE's. And traffic going
between PE's may never experience any congestion inside the backbone.
However, to guarantee any service between two CE's, the access links
between CE and PE have to have enough network resources to
accommodate the sum of all pseudo-wire traffic going to a specific
CE. In the example, the link between PE2 and CE2 must be able to
Pan, et al ^L[Page 6]
Internet Draft draft-pan-pwe3-over-sub-ip-00.txt June 2004
support the traffic from both PW12 and PW32.
There exists two proposals addressing PW traffic assurance issues.
[PWE3-CONGESTION]
From control-plane, [PWE3-QOS] and [PWE3-CONGESTION] have been
proposed to overcome the problem.
[PWE3-CONGESTION] is to apply a TCP-like mechanism on each PW.
[PWE3-QOS] is to solve the over-subscription problem by extending
LDP.
If {PWE3-QOS] is implemented to support PWE3 QoS, at data-plane, PE's
MUST be able to provide per-flow QoS for each PW entering and leaving
the backbone.
5. Conclusion
Martini's pseudo-wire approach provides an effective and uniformed
method to carry all types of layer-2 traffic over a carrier's
backbone network. Currently, it has been designed to operates on top
of MPLS/IP networks only. We argue that the scope of PWE3 should
expand to deal with other types of networks. If the carriers only
need to aggregate layer-2 packets over their existing networks, it
would be more economical from both an equipment expense and operation
cost point view to provide PWE3 functionality on top of sub-IP
tunnels directly.
Further, we notice that since the carriers can aggregate data traffic
into sub-IP networks directly from edge with per-PW QoS guarantees,
there does not seem to have any need to introduce UNI, OUNI, EUNI or
NNI interfaces at the edge of the network.
Finally, we believe that our proposal does not and should not change
the current carrier's plan and desire of converging all data service
over MPLS backbone. Rather, it provides a practical solution for
carriers to utilize their existing infrastructure and allow them to
move toward MPLS converged network gradually.
Pan, et al ^L[Page 7]
Internet Draft draft-pan-pwe3-over-sub-ip-00.txt June 2004
6. Security Considerations
This document extends the use of PWE3 to sub-IP networks. It has the
same security requirements as in PWE3.
7. Acknowledgments
Back in the fall of 2002, we came up with the dry-martini idea for
Ciena CoreDirector switch. Tedi Tedijianto had helped with SONET/SDH
interface investigation. Calvin Leung had helped with hardware
implementation estimation. The idea of applying dry-martini on other
sub-IP technologies was triggered by a recent conference presentation
by Charles Kalmanek, et al from AT&T Lab.
8. References
[PWE3-ARCH] S. Bryant, P. Pate, "PWE3 Architecture", draft-ietf-
pwe3-arch-07.txt.
[PWE3-TRANSPORT] L. Martini, et al, "Transport of Layer 2 Frames Over
MPLS", draft-martini-l2circuit-trans-mpls-14.txt
[PWE3-CTRL] L. Martini, et al, "Pseudowire Setup and Maintenance
using LDP", draft-ietf-pwe3-control-protocol-07.txt
[PWE3-ETHER] L. Martini, et al, "Encapsulation Methods for Transport
of Ethernet Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-
encap-04.txt
[MARTINI-ATM] L. Martini, et al, "Encapsulation Methods for Transport
of ATM Cells/Frame Over IP and MPLS Networks", draft-martini-atm-
encap-mpls-03.txt
[MARTINI-FR] C. Kawa, et al, "Frame Relay Encapsulation over Pseudo-
Wires", draft-martini-frame-encap-mpls-01.txt.
[RFC3032] E. Rosen, et al, "MPLS Label Stack Encoding".
[PWE3-CONGESTION] E. Rosen, et al. "PWE3 Congestion Control
Framework", draft-rosen-pwe3-congestion-01.txt
[PWE3-QOS] H. Shah, P. Pan, et al. "Qos Signaling for PW", draft-
shah-pwe3-pw-qos-signaling-00.txt
Pan, et al ^L[Page 8]
Internet Draft draft-pan-pwe3-over-sub-ip-00.txt June 2004
9. Author Information
Ping Pan
CIENA Corp.
5965 Silver Creek Valley Road
San Jose, CA 95134
e-mail: ppan@ciena.com
Tad Hofmeister
tadh@stanfordalumni.org
Pan, et al ^L[Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 01:04:21 |