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 , 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]