Internet Draft Internet Engineering Task Force Junichi Sumimoto INTERNET-DRAFT Muneyoshi Suzuki Expires August 8, 2000 NTT Osamu Tabata Atsushi Iwata NEC Corporation Yutaka Ezaki Masami Doukai Fujitsu Limited February 8, 2000 MPLS VPN Interworking <draft-sumimoto-mpls-vpn-interworking-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 We call virtual private networks (VPNs) based on Multiprotocol Label Switching (MPLS) "MPLS VPN". This document discusses motivation and a model of interworking among MPLS VPNs. It then proposes functional capabilities for the interworking such as realization of security, mapping of the QoS class, dynamic routing information distribution. Sumimoto Expires August 2000 [Page 1] INTERNET-DRAFT MPLS VPN Interworking February 8, 2000 Considering easy provisioning, we focus on an interworking where each MPLS network is once terminated and IP header look-up is executed at an egress/ingress Label Switching Router (LSR), and IP over ATM (RFC1483) is used for interworking connections. 1. Introduction MPLS enables the forwarding of IP packets under the control of a standard IP routing algorithm, but the forwarding process does not use the IP packet header directly. Instead, a short, fixed-length label is used to enable packet forwarding. We call VPNs based on MPLS "MPLS VPN". A number of MPLS VPN solutions (including pre- standard solutions) have been proposed and developed, where the interface between a user and a provider is IP. These include BGP/VPN [RFC2547], GMN-CL [GMN-CL] and [COREVPNARCH]. But there is no agreement for interworking among MPLS VPNs. VPN architecture based on MPLS is already under discussion in ITU-T SG13 [I.IPATM]. We therefore discuss the following: - Motivation for interworking among VPNs (Section 2) - Assumptions of MPLS VPNs as elements for interworking (Section 3) - Functional capabilities for interworking such as realization of security, mapping of the QoS class, dynamic routing information distribution (Section 4) 2. Motivation for interworking among MPLS VPNs (1) VPNs spread over multiple differently implemented MPLS networks owned by different VPN service providers. This follows the normal requirement and expectation that each VPN service provider chooses its best VPN implementation out of multiple vendors' implementations. (2) VPNs spread over multiple differently implemented MPLS networks owned by a VPN service provider. A VPN service provider may deploy multiple MPLS networks (e.g., an old MPLS network and a new MPLS network). The VPN interworking removes the requirement that the all user sites of one VPN need to be connected to an MPLS network. In both cases, the interworking enable VPN service providers to make flexible provisioning of VPN services. It is of benefit to VPN users as well. 3. Assumptions 3.1 MPLS Network The following MPLS network structure [MPLSARC] is assumed to be Sumimoto Expires August 2000 [Page 2] INTERNET-DRAFT MPLS VPN Interworking February 8, 2000 present as a base to provide VPN services. +--------------------+ | | +-----+ Backbone Network +-----+ User sites -+--| LSR | implementing MPLS | LSR |--+- User sites +-----+ +-----+ | | +--------------------+ Figure 1. Structure of MPLS Network 3.2 MPLS VPN 3.2.1 Security support Each user-side logical/physical port of an ingress/egress LSR belongs to only one VPN. Traffic between any pair of such ports that belong to a VPN is isolated from traffic of any other VPNs, so a host of a user site belonging to any other VPNs is not permitted to send any packets to the VPN. For example, the following mechanisms realize the traffic isolation in an MPLS backbone network. - At each egress/ingress LSR, each VPN is managed by a number, label, or identifier. In some implementations, each VPN is identified by an label (LSP), while in the other implementations, each VPN is identified by an number or identifier [VPNID] that is explicitly attached to packets in the MPLS network. 3.2.2 QoS class support The MPLS VPN supports QoS classes, for example, Assured Forwarding (AF) Classes of diffserv [RFC2475]. A QoS class of each packet is identified by attributes concerning the logical/physical interface of the egress/ingress LSR, source and/or destination IP address, port number, diffserv codepoint, and so on. The backbone network between an ingress LSR and an egress LSR controls QoS based packet forwarding. 3.2.3 Dynamic routing information distribution An MPLS network can dynamically distribute the routing information of each VPN (1)within the MPLS network and (2)between the MPLS network and a user site. Scope of the distribution is restricted within each VPN by the security support (See section 3.2.1). Sumimoto Expires August 2000 [Page 3] INTERNET-DRAFT MPLS VPN Interworking February 8, 2000 4. Proposed Model, Functional Capabilities for Interworking among MPLS VPNs 4.1 Interworking Model +---------+ +---------+ VPN A | | | | VPN A +----------------------------------------------------------------------+ | +---+ +---+ +---+ +---+ | |User site | | Element | | | | Element | | User site| | of VPN A-| | W | | | | X | |- of VPN A| | | | | | | | | | | +----------------------------------------------------------------------+ | | | |Interworking| | | | |LSR| |LSR|-----++-----|LSR| |LSR| | | | | Interface | | | | +----------------------------------------------------------------------+ | | | | | | | | | | |User site-| | Element | | | | Element | |-User site| | of VPN B | | Y | | | | Z | | of VPN B| | +---+ +---+ +---+ +---+ | +----------------------------------------------------------------------+ VPN B | | | | VPN B +---------+ +---------+ MPLS Network 1 MPLS Network 2 Figure 2. Interworking Model We call each part of a VPN that is cut by an MPLS network 'element'. 4.2 Functional Capabilities for Interworking There are the following two types of interworking. (1)Interworking where each MPLS network is once terminated and IP header look-up is executed at an egress/ingress LSR. (2)Interworking without IP header look-up at an egress/ingress LSR. As each existing MPLS VPN is implemented in unique manner, it is difficult to realize type (2). Type (1) is easy to provision since it utilize the LSR's function of IP header look-up. Therefore, we focus on type (1). We assume that the connections at the interworking interface are provided by IP over ATM (RFC1483) since IP over ATM has advantage for bandwidth control per logical connection. Use of other layer 2 protocol Sumimoto Expires August 2000 [Page 4] INTERNET-DRAFT MPLS VPN Interworking February 8, 2000 other than ATM and use of MPLS shim header is for further study. These connections are assumed to convey routing protocol packets as well as data packets of each VPN. No assumptions about which flavor of VPNs is run on the other side is required. We propose the following three functional capabilities, which are required to support MPLS VPN interworking. - Realization of security - Mapping of the QoS class - Dynamic routing information distribution in section 4.3, section 4.4, section 4.5, respectively. 4.3 Realization of Security Each end of each connection is assigned an MPLS VPN of MPLS network that is connected to the end of the connection. Any packets are not permitted to transmit between the connection and any unassigned MPLS VPNs. This mechanism result in realization of security. The procedures by which such an assignment is established are specific to the solution used by the MPLS network implementation associated with the connection. The identity of VPN at each end is meaningful only in the context of the specific MPLS network associated with the connection. We assume multiple VPNs do not share one connection. See figure 2. There used a logical connection between the MPLS network 1 and MPLS network 2 for constructing a VPN over both MPLS network 1 and MPLS network 2. The connection for the VPN A is assigned to element 'W' and 'W' is meaningful only in the context of MPLS network 1. The other side of the connection is assigned to element 'X' and 'X' is meaningful only in the context of MPLS network 2. Note. We recommend that bandwidth of a connection does not interfere with bandwidth of any other connections. Detailed QoS specifications of the connection are for further study. 4.4 Mapping of the QoS class Attributes of a QoS class may be also assigned to each connection. This enables provisioning of multiple QoS classes within each VPN. QoS control is easy and only one-time class identification in the IP layer is needed. Sumimoto Expires August 2000 [Page 5] INTERNET-DRAFT MPLS VPN Interworking February 8, 2000 +-----------+ +-----------+ +-----+ +-----+ +-----+ +-----+ | +-----------+ | | +-----------+ | | | Element | |-------------| | Element | | | LSR | | LSR |-------------| LSR | | LSR | | | W | |-------------| | X | | | +-----------+ | Connections | +-----------+ | +-----+ +-----+ for +-----+ +-----+ +-----------+ different +-----------+ MPLS network 1 QoS Classes MPLS network 2 Figure 3. Using multiple connections for multiple QoS classes for each VPN There is another optional method. We can use CoS, a bit-pattern in a field such as EXP of Shim header or TOS of an IP header, to identify a QoS class during packet transmission on the connection. The connection is shared by multiple QoS classes. A typical example of this mapping method is diffserv. This method can reduce the number of connections, while QoS control on the connection is difficult. +-----------+ +-----------+ +-----+ +-----+ +-----+ +-----+ | +-----------+ | | +-----------+ | | | Element | | | | Element | | | LSR | | LSR |-------------| LSR | | LSR | | | W | | | | X | | | +-----------+ | Connection | +-----------+ | +-----+ +-----+ supporting +-----+ +-----+ +-----------+ CoS +-----------+ MPLS network 1 MPLS network 2 Figure 4. Using CoS for supporting multiple QoS classes for each VPN 4.5 Dynamic routing information distribution Some mechanisms for routing control per VPN are required in each egress/ingress LSR. The connection between MPLS network 1 and MPLS network 2 just transmit packets of standard IP routing. Then routing information is forwarded by the functional capability described in chapter 4.3 as well as data. This enables dynamic routing information distribution within each VPN. One of standard routing protocols such as BGP, OSPF, RIP, DVMRP, PIM can be used on the connections for every VPN. 4.6 Summary Sumimoto Expires August 2000 [Page 6] INTERNET-DRAFT MPLS VPN Interworking February 8, 2000 Figure 5 summarize functional capabilities for MPLS VPN interworking with IP over ATM. Note that this document does not require any new protocols or new label modification of existing protocols. +------------+ +------------+ VPN A | | | | VPN A +----------------------------------------------------------------------+ | +---| |---+ VC for +---| |---+ | | | | Data & | | QoS class 1 | | Data & | | | | | | routing |---|------++------|---| routing | | | |User--|---|<- inform ->| | | |<- inform ->|---|--User| |site | | -ation |---|------++------|---| -ation | | site| | | | | | VC for | | | | | | | | Element W | | QoS class 2 | | Element X | | | +----------------------------------------------------------------------+ | | /| | | /| | | /| | | | | | | | | | | | | | |LSR| Prohibited |LSR| Prohibited |LSR| Prohibitd |LSR| | | to Transmit| | to Transmit | | to Transmit| | | | | | | | | | | | | | | |/ | | |/ | | |/ | | +----------------------------------------------------------------------+ | | | | | VC for | | | | | | | | Data & | | QoS class 1 | | Data & | | | | | | routing |---|------++------|---| routing | | | |User--|---|<- inform ->| | | |<- inform ->|---|--User| |site | | -ation |---|------++------|---| -ation | | site| | | | | | VC for | | | | | | +---| Element Y |---+ QoS class 2 +---| Element-Z |---+ | +----------------------------------------------------------------------+ VPN B | | || | | VPN B +------------+ Interworking +------------+ MPLS Network 1 Interface MPLS Network 2 Figure 5. Proposed VPN Interworking by using IP over ATM This document focuses on static interworking (i.e. user-plane interworking) to deploy quickly. Dynamic interworking (i.e. control- plane or management-plane interworking) should be discussed in another document to reduce manual configuration in near future. 5. Acronyms Sumimoto Expires August 2000 [Page 7] INTERNET-DRAFT MPLS VPN Interworking February 8, 2000 CoS Class of Service ISP Internet Service Provider LSP Label Switched Path LSR Label Switching Router MPLS Multiprotocol Label Switching OPS Operation System QoS Quality of Service VPN Virtual Private Network 6. References [RFC1483] Heinanen J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5," RFC1483. [VLAN] IEEE 8.2.1Q. [RFC2547] Rosen E. and Rekhter Y., "BGP/MPLS VPNs," RFC2547. [GMN-CL] GMN-CL home page: http://www.gmncl.ecl.ntt.co.jp/top_e.html [COREVPNARCH] Muthukrishnan K., et al, "Core MPLS IP VPN Architecture", draft-muthukrishnan-mpls-corevpn-arch-00.txt. [I.IPATM] ITU-T, "Transport of IP over ATM in Public Networks," Draft recommendation, I.ipatm, September, 1999. [MPLSARC] Rosen E., et al, "Multiprotocol Label Switching Architecture," draft-ietf-mpls-arch-06.txt. [VPNID] Fox B., et al, "Virtual Private Networks Identifier," RFC2685. [RFC2475] Blake S., et al, "An architecture for Differentiated Services," RFC2475. [MPLSVPN] Jamieson D., et al, "MPLS VPN Architecture," draft-jamieson-mpls-vpn-00.txt. Sumimoto Expires August 2000 [Page 8] INTERNET-DRAFT MPLS VPN Interworking February 8, 2000 7. Authors' address Junichi Sumimoto NTT (Nippon Telegraph and Telephone Corporation) Information Sharing Platform Laboratories 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Email: sumimoto.junichi@lab.ntt.co.jp Muneyoshi Suzuki NTT (Nippon Telegraph and Telephone Corporation) Information Sharing Platform Laboratories 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Email: suzuki.muneyoshi@lab.ntt.co.jp Osamu Tabata NEC Corporation 1753 Shimonumabe, Nakahara-ku, Kawasaki-shi, Kanagawa 211-8666 Email:tabata@trd.tmg.nec.co.jp Atsushi Iwata NEC Corporation C&C Media Research Laboratories 4-1-1 Miyazaki Miyamae-ku, Kawasaki Kanagawa, 216-8555 Japan E-mail: iwata@ccm.CL.nec.co.jp Yutaka Ezaki IP Network Systems Lab., Fujitsu Limited 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588, Japan E-mail: ezaki@flab.fujitsu.co.jp Masami Doukai Switching Node Systems Div., Network Systems Group, Fujitsu Limited 2-12-5 Shimokodanaka, Nakahara-ku, Kawasaki 211-0041, Japan E-mail: doukai@ss.ts.fujitsu.co.jp Sumimoto Expires August 2000 [Page 9]