Layer 2 MPLS VPNs FAQ. 1. Q. What is a Layer 2 MPLS VPN?

Transcription

1 FAQ Layer 2 MPLS VPNs 1. Q. What is a Layer 2 MPLS VPN? 1. A. An MPLS-based Layer 2 VPN uses an MPLS network in the provider core to deliver Layer 2 services to the customers. The service provider-to-customer interconnection is a Layer 2 technology, such as Frame Relay, ATM, or Ethernet VLAN. Layer 2 MPLS VPN is, therefore, similar to a traditional Frame Relay or ATM VPN, but the difference is that the service provider network is MPLS-based, rather than being bound by the access technology. 2. Q. What are the goals of a Layer 2 MPLS VPN? 2. A. From the point of view of the service provider s customer, a Layer 2 MPLS VPN is exactly the same as a Layer 2 VPN. However, a single access line from the customer-premises equipment (CPE) could be used for multiple services public IP services, as well as Layer 2 and Layer 3 VPNs, for example. In the former case, the Layer 3 hop terminates on a platform other than the directly attached CPE; whereas, in the latter case, the Layer 3 hop terminates on the directly attached CPE. From a service provider s point of view, a Layer 2 MPLS VPN allows the use of a single network technology (namely, MPLS) to offer many services, including IP, Layer 2 VPNs, Layer 3 VPNs (such as RFC 2547bis), MPLS traffic engineering, and Differentiated Services (DiffServ). A single network architecture that offers multiple services is often referred to as a converged network. A single access line to provide multiple services is also beneficial to a service provider. 3. Q. Will MPLS replace Frame Relay or ATM as the VPN technology of choice? 3. A. The technology serving customers will remain the same. This allows the service provider to migrate the customers transparently without either service disruption or an elaborate transition plan. On the other hand, Layer 2 MPLS VPNs allow service providers full freedom to choose internal network technologies independent of the Layer 2 VPN service offerings. A common choice of technology for the service provider s core network is SONET/SDH. Copyright 2001, Juniper Networks, Inc. 1

2 4. Q. What are the benefits of a Layer 2 MPLS VPN to a service provider and to an enterprise customer? 4. A. To a service provider, this is a significant migration step toward a single IP- and MPLS-based infrastructure for all services. Existing tail-circuit technology (Frame Relay or ATM) can be re-used. This not only makes the transition familiar to operators and maximizes the service provider s investment, but also retains the operational simplicity of those existing technologies (thus no responsibility for customer routing). Autoprovisioning makes deployment easier at scale. By using label-stacking techniques, Layer 2 MPLS VPNs are specifically designed for scalability and for deployment in carrier-of-carriers environments. For enterprise customers, the scalability of this technology is well-suited to large corporations. MPLS can provide multiprotocol connectivity (IPX and SNA, for instance), and it also easily supports IP multicasting. Customers that are accustomed to managing their own routing domains can continue to do so. They can also deploy extra security, such as IPSec encryption. 5. Q. How is it different from Circuit Cross-connect? 5. A. There are two major advantages of Layer 2 MPLS VPNs over Circuit Cross-connect: First, with Circuit Cross-connect, you must configure point-to-point circuits. Building a VPN in this manner is tedious, because adding or removing a site requires a fair amount of work, as well as touching lots of routers. With Layer 2 MPLS VPNs, you can configure a VPN specifically, so the configuration is much more straightforward. Adding or removing a site is also much simpler, and in many cases it involves touching only the one router attached to the site. Second, each Circuit Cross-connect requires a dedicated provider edge-to-provider edge label-switched path (PE-to-PE LSP), and this LSP must be signalled by using RSVP. (Using Label Distribution Protocol [LDP] makes no sense in a Circuit Cross-connect, point-to-point scenario, because it employs a reverse-path tree approach.) Layer 2 MPLS VPNs use label stacking, so a single PE-to-PE LSP can be used for multiple VPNs and, in fact, for multiple services. This makes it an extremely scalable technology. Furthermore, this LSP can be set up through any means, including RSVP and LDP. Label-stacking techniques also support greater infrastructure scalability. 6. Q. How is a Layer 2 MPLS VPN different from a Layer 3 MPLS VPN? 6. A. The main difference, from the service provider s point-of-view, is that there is no Layer 3 routing information exchange between the customer and the service provider. The other difference is that the service provider does not need to care nor to know what network-layer protocol the customer uses. On the flip side, Layer 2 MPLS VPNs currently require that all sites in the service provider s customer network connect to the service provider with the same Layer 2 technology (for example, that all use Frame Relay). This Layer 2 dependence gives the customer Layer 3 independence, because the customer can run any Layer 3 protocol. There is also an intermediate solution, called Layer 2 interworking, whereby each customer site can connect with a different Layer 2 technology, but the Layer 3 protocol is limited to IP. In a Layer 3 MPLS VPN, however, the various sites can connect with any technology. Copyright 2001, Juniper Networks, Inc. 2

3 7. Q. When should a service provider deploy a Layer 2 MPLS VPN rather than another VPN technology? 7. A. The simplest case is when the service provider s customer is already using a Layer 2 VPN. Migration is fairly straightforward in this case. Other situations where a Layer 2 MPLS VPN is preferable are when a service provider is using non-ip protocols or has a large number of routes in its network. An important factor to note in contrasting Layer 2 and Layer 3 MPLS VPNs is that Layer 2 MPLS VPNs usually require the provider s customer to have more routing expertise. 8. Q. What are alternate Layer 2 MPLS VPN proposals? 8. A. More than one Layer 2 MPLS VPN architecture has been under consideration by the Provider-provisioned Virtual Private Network Working Group (PPVPN WG) of the IETF. The primary proposals were known as draft-kompella and draft-martini, and these were the file names of the versions of those drafts as of November 2001: Draft-martini-l2circuit-trans-mpls-07.txt Draft-martini-l2circuit-encap-mpls-03.txt Draft-kompella-ppvpn-l2vpn-00.txt Note: Be sure to check the Internet Drafts section of the IETF Web site for updates, because the drafts change often. The answer to question number 12 explains the status of those drafts in November Q. What are the Martini drafts? 9. A. The two Martini drafts, together, propose an MPLS-based intraprovider solution for transport and encapsulation of various Layer 2 technologies over point-to-point links. The Martini trans draft defines signaling for setting up point-to-point circuits in an MPLS network. Static label assignment may be used, and all implementations should support static assignment. If signaling is used, the VC label must be distributed using LDP between the ingress and egress label-switching routers (LSRs). A new type of virtual circuit forwarding equivalence classes (FEC) element is defined in order to establish an LDP session, using the extended-discovery mechanism of LDP. The trans draft is a companion draft to the Martini encaps draft. The Martini encaps draft defines the format of Layer 2 packets that are carried within MPLS LSPs. To ensure that sequentiality is preserved on a Layer 2 virtual circuit, the encaps draft defines a sequencing control word, which is desirable for Frame Relay PDUs and ATM AAL5. However, using it is optional in certain circumstances. (Please see the explanation in the answer to question 12.) The control word must retain the backward explicit congestion notification (BECN) bit and the forward explicit congestion notification (FECN) bit from the Frame Relay header or, in the case of ATM AAL5, the Explicit Forward Congestion Indicator (EFCI). These and the cell loss priority (CLP) bit are carried in the control word. The control word is optional for ATM cell mode, Ethernet, Ethernet VLAN, PPP, and HDLC. Martini drafts also require that the Layer 2 circuit type must be the same on ingress and egress. Copyright 2001, Juniper Networks, Inc. 3

4 10. Q. What is the Kompella Internet Draft? 10. A. The Kompella draft describes how to build end-to-end (CE-to-CE) customer VPNs by using MPLS in the provider core. It also defines the frame format for each Layer 2 VPN encapsulation type within MPLS LSPs. The ingress PE assigns the MPLS label, the LSP behaves as a Layer 2 tunnel, and then the egress PE forwards the Layer 2 traffic with the appropriate DLCI, VPI/VCI, and so forth. A Layer 2 connection between two specific CEs is characterized within the MPLS network by the PEs to which the CEs are attached. Like draft-martini, draft-kompella initially recommended that the circuit type must be the same on ingress and egress links. However, the latest draft-kompella allows Layer 2 interworking, as long as only IP is used for Layer 3. An added benefit of restricting interworking to IP only as the Layer 3 technology is that the provider's network can provide IP DiffServ or any other IP-based QoS mechanism to the Layer 2 VPN customer. Signaling to establish the VPN LSP can be done with BGP or LDP. An advantage of using BGP signaling is that service providers have a working knowledge of BGP, and this mechanism can enable the establishment of interprovider VPNs. Two new identifiers to the BGP multiprotocol extension are proposed in order to negotiate the Layer 2 VPN capability with BGP peers: Address family indicator (AFI) Subsequent address family indicator (SAFI) In addition, there is a new NLRI format within BGP multiprotocol extensions for carrying the Layer 2 VPN CE information. The prototype implementation uses vendor-specific AFI, SAFI, and NLRI assignments. 11. Q. What are the differences between the Kompella and Martini Internet Drafts? 11. A. The Martini drafts address intraprovider tunneling mechanisms, one application of which might be a VPN. Martini has inherent scalability issues, because each ingress and egress router requires n*n configuration statements in order to create full-mesh VPNs between PEs. Draft-Kompella proposes an auto-discovery mechanism of VPN sites. Adding a new site is purely the local PE s task, using an over-provisioning technique. The Kompella draft also allows for building interprovider VPNs for a carrier-of-carriers environment. Draft-Kompella proposes a limited form of Layer 2 interworking for IP only, which enables unlike connections to be part of the same Layer 2 MPLS VPN. Draft-Martini restricts both ends of point-to-point connections to establish like-layer 2 connectivity in all cases. Copyright 2001, Juniper Networks, Inc. 4

5 12. Q. What is the status of Martini and Kompella drafts? 12. A. Significant changes were made to Layer 2 MPLS VPNs by the PPVPN WG, during the 51st IETF meeting, held in London in August The action taken by the PPVPN working group progressed draft-kompella to the status of a working group activity and declared draft-martini-trans to be obsolete. Draft-Martini-encaps has been submitted to the Pseudo Wire Emulation Edge-to-Edge (PWE3) Working Group. Draft Kompella mentioned that LDP for signaling VPN information has been postponed for future discussion (BGP is still the recommended auto-discovery and signaling mechanism for draft-kompella). Draft-Kompella would reference draft-martini-encaps and adopt the encapsulation formats defined within that document. Earlier versions of draft-martini-encaps stated that the sequencing control word was mandatory for Frame Relay and AAL5. The draft is now revised to declare that the existence of the control word is required for Frame Relay and AAL5. However, its use is optional, although desirable. This means that the ingress or egress LSRs can choose to ignore the control word. According to the RFC 2119 interpretation, the adjective "optional" means that one vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product, while another vendor may omit the same item. An implementation that does not include a particular option must be able to interoperate with another implementation that does include the option, although perhaps with reduced functionality. In the same vein, an implementation that includes a particular option must interoperate with another implementation that does not include the option (except, of course, for the feature the option provides). 13. Q. Will these Internet Drafts merge as a single standard? 13. A. Draft-Martini-trans has become obsolete. Draft-Martini-encaps and draft-kompella are now progressing in different working groups, because the former has been moved to the IETF s PWE3 working group. The two drafts are complementary, thus it is unlikely that they will merge. However, since the encapsulation of Layer 2 data for transport in a Layer 2 VPN is identical in both, draft-kompella would reference draft-martini-encaps and adopt the encapsulation formats except for IP-only Layer 2 interworking. Copyright 2001, Juniper Networks, Inc. 5

6 14. Q. What is the position of the other drafts proposed in the IETF s PPVPN Working Group? 14. A. There are three other drafts under consideration by the IETF s PPVPN Working Group. As of November 2001, they were available on the IETF Web site as these files: Draft-shah-mpls-l2vpn-ext-00.txt Draft-shah-mpls-l2vpn-reduce-00.txt Draft-ietf-ppvpn-l2vpn-00.txt (formerly draft-rosen-ppvpn-l2vpn-00.txt) Note: Be sure to check the Internet Drafts section of the IETF Web site for updates, because the drafts change often. The two Shah drafts are, in fact, extensions to draft-kompella. The draft-shah-mpls-l2vpn-ext-00.txt describes extensions to draft-kompella that enable range on PE routers to be increased for the MPLS labels without needing to be contiguous for all of the CE devices. Draft-shah-mpls-l2vpn-reduce-00.txt proposes how PE routers can reduce the over-provisioning of resources. The latest version of draft-kompella has absorbed most of the things proposed in the two Shah drafts. Therefore, the Shah drafts are likely to be merged into draft-kompella in future. Draft-ietf-ppvpn-l2vpn-00.txt (formerly known as draft-rosen) proposes requirements, framework, and architecture to provide point-to-point virtual circuits between pairs of service provider customer sites over an IP infrastructure. 15. Q. Does Juniper Networks support Layer 2 MPLS VPNs? 15. A. Yes. We introduced initial support in JUNOS Internet software release 5.0, which first shipped in August JUNOS software supports draft-kompella. 16. Q. Could IPSec be transported over Kompella and Martini Internet Draft-based VPN networks? 16. A. Certainly. If the customer wants more security than is provided by simple isolation, encryption, or authentication, using IPSec or other means would complement Layer 2 MPLS VPNs well. In fact, this is highly recommended. 17. Q. Are there specific network architecture or design considerations for Layer 2 MPLS VPNs with respect to Frame Relay? 17. A. One important VPN architecture consideration is that in Layer 2 MPLS VPNs, it is much easier to provision full-mesh connectivity than it is with traditional Layer 2 VPNs. Thus, a customer migrating from a Layer 2 VPN to a Layer 2 MPLS VPN can consider a more expansive VPN architecture. Copyright 2001, Juniper Networks, Inc. All rights reserved. Juniper Networks is registered in the U.S. Patent and Trademark Office and in other countries as a trademark of Juniper Networks, Inc. Internet Processor, Internet Processor II, JUNOS, JUNOScript, M5, M10, M20, M40, and M160 are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Part Number: /01 Copyright 2001, Juniper Networks, Inc. 6