Network Working Group Hiroshi Kurakami Internet Draft Junichi Sumimoto Expires: August 2001 Muneyoshi Suzuki NTT February 23, 2001 Provider-Provisioned VPNs Interworking 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 There exist requirements of provider-provisioned virtual private networks (PPVPN) spanning multiple differently implemented SP networks from SPs perspective. This document proposes an interworking method at the interface for implementing PPVPNs spanning multiple SP networks with different technologies; it proposes the establishment of connections making use of GRE, IPsec, Frame Relay, or ATM connections at network interface, and describes how required services of the PPVPNs, such as security/privacy, quality of service, extranets, dynamic routing, and multicast, are achieved through network interface. It further discusses the applicability and scalability of the proposed interworking method and concludes that the proposed method has high applicability in interworking various types of PPVPN capable SP networks, and that justifies the relative scalability limitation which is not a critical drawback of the Kurakami, et al. Expires August 2001 [Page 1] INTERNET-DRAFT PPVPNs Interworking February, 2001 proposed method. 1. Introduction 1.1 Scope This document proposes an interworking method for network interface to implement PPVPNs spanning multiple SP networks with different technologies. The rest of Section 1 briefly reviews the definition of PPVPNs and objective of the interworking. Section 2 concisely reviews network interface in the reference model shown in [FRAMEWORK] to clarify network interface where the proposed method is working. Section 2 also clarifies the services of SP network(s) as an assumption for the interworking. Section 3 proposes and describes an interworking method for achieving required services. Section 4 further discusses the applicability and scalability of the proposed interworking method. Note that, full alignment with the final version of [FRAMEWORK] and [REQUIREMENTS] will be made before final version of this draft is submitted to IETF. 1.2 Provider Provisioned Virtual Private Networks (PPVPNs) The description of PPVPN is given in [FRAMEWORK] and [REQUIREMENTS]. Multiple PPVPN solutions have already been proposed and developed. These include BGP-VPN [VPN-2547BIS], Virtual Router(VR) architecture [RFC2917BIS] [VPN-VR], and GMN-CL [VPN-GMNCL]. 1.3 Objective for the Interworking It is quite natural to assume that multiple differently implemented SP networks of PPVPNs owned by one or more SPs co-exist, since it follows the expectation that (1)each SP chooses its best PPVPN implementation out of multiple vendor's implementations, and (2)an SP may deploy multiple networks of PPVPNs (e.g., an old network and a new network). Thus PPVPNs spanning multiple differently implemented SP networks are required. Kurakami, et al. Expires August 2001 [Page 2] INTERNET-DRAFT PPVPNs Interworking February, 2001 2. Network Interface and Services of PPVPNs (Layer 3 Network-based VPNs) 2.1 Network Interface In order to clarify the target of the proposal of this document, this section concisely reviews network interface of the reference model shown in [FRAMEWORK]. Figure 1 shows network interface which is the target of the proposed method. +---------+ +------------------------------------+ +---------+ | | | | | | | | | +------+ +------+ : +------+ +------+ : | | | | | | : | CE | | CE | : | | | P | | PE | : |device| |device| : +------+ VPN tunnel : |router| |router| : | of | | of |-:--| |================:===============| |--:-|VPN A| |VPN A| : | | : +------+ +------+ : +------+ +------+ : | PE | : | | : | +------+ : |router| Network interface | | : | | CE | : | | : +------+ : +------+ |device|-:--| |================:===============| |--:-| CE | | of | : +------+ : VPN tunnel | PE | : |device| |VPN B| : | | |router| : | of | +------+ : | | +------------+ +------------+ | | : |VPN B| | : | | | Customer | | Network | +------+ : +------+ |Customer | | | management | | management | | | : | |interface| | | function | | function | | |Customer | | | | +------------+ +------------+ | |interface| | | | | | | +---------+ +------------------------------------+ +---------+ | Access | |<---------- SP network(s) --------->| | Access | | network | | single or multiple SP domains | | network | Figure 1: Reference model for layer 3 NBVPN. o SP Networks An SP network is a network administered by a single service provider. The PPVPN operation in SP networks is outsourced to an SP, but the whole PPVPN operation may be spread over multiple SPs. Note that it is not necessary for a single SP's whole SP networks to be constructed with a uniform technology. Different SP networks may be implemented with different technologies. Kurakami, et al. Expires August 2001 [Page 3] INTERNET-DRAFT PPVPNs Interworking February, 2001 o Network Interface Network interface is defined as the interface which exists between a pair of PE routers and connects two SP networks. For more description regarding with the other components, see [FRAMEWORK]. 2.2. Assumed Services to be Supported by Interworking This document assumes the five services, security/privacy, quality of service, extranet, dynamic routing, multicast, as services of PPVPNs to be mapped through network interface primarily. Though other services may be required, interworking of these services are to be studied after detailed functions needed at network interface are made clear. 2.2.1 Security/privacy (CUG) Security/Privacy (CUG) service provides communications between various specific customer sites through a PPVPN. Other customer sites cannot reach them. This service prevents packets from being injected into the network without authorization. Private IP addressing may be used in a CUG. 2.2.2 Quality of service QoS/SLA services provide guaranteed and/or differentiated communications with PPVPN-specific SLAs covering loss rates, delay variation, latency, and bandwidth etc. 2.2.3 Extranets Extranet service enables communications between specific CUGs or customer sites belonging to other CUGs within the networks. Access control (including packet filtering and address translation) may be applied between CUGs according to policy. 2.2.4 Dynamic routing A dynamic routing service enables the exchange of unicast routing information between customer sites and a PPVPN using a routing protocol such as Open Shortest Path First (OSPF) [RFC2328] or Border Gateway Protocol 4 (BGP-4) [RFC1771]. Routing information about each customer site can be distributed from one customer site to another. In Virtual Router approach [VPN-VR], scope of the routing information distribution is restricted within each PPVPN by the security support Kurakami, et al. Expires August 2001 [Page 4] INTERNET-DRAFT PPVPNs Interworking February, 2001 (See Section 2.2.1). On the other hand, BGP-VPN [VPN-2547BIS] implements a different mechanism using BGP for dynamic routing information distribution. 2.2.5 Multicast A multicast service replicates multicast packets forwarded from customer sites in the networks and forwards them to multiple customer sites. Multicast routing information is exchanged between customer sites and an PPVPN using a multicast routing protocol. 3. Proposal of an Interworking Method This document proposes the following fundamental usage and additional usages of the connections established across network interface and describe how each of the five required services is implemented through network interface. 3.1 Proposed Connections at Network Interface This section describe a method to establish connections across network interface to provide PPVPN interworking. One or combination of the following methods can be used (although usage of multiple methods leads to the increased management burden) in establishing network interface. Note that usage of other methods is not excluded as far as the established connection satisfies the requirements of PPVPN interworking. 3.1.1 Use of GRE The connections at network interface are provided by GRE with Key and Sequence Number Extensions [RFC2890]. 3.1.2 Use of IPsec The connections at network interface are provided by IPsec [RFC2401]. 3.1.3 Use of Frame Relay The connections at network interface are provided by Frame Relay. 3.1.4 Use of IP over ATM AAL5 connections The connections at network interface are provided by IP over ATM AAL5 [RFC2684]. At least one connection is used for each of PPVPNs, and each connection is mapped to an PPVPN. Kurakami, et al. Expires August 2001 [Page 5] INTERNET-DRAFT PPVPNs Interworking February, 2001 3.2 Mapping of Security/Privacy (CUG) Each interworking connection is assigned for a specific PPVPN; in other words, each end of the interworking connection is assigned for a specific PPVPN at a PE router. This mechanism results in implementation of CUG service spanning multiple SP networks of different technologies. The procedures by which such an assignment is established are specific to the technology used by an SP network implementation. The identity of PPVPN at each end is meaningful only in the context of the specific technology of an SP network and need not be understood by another SP network interworking through the connection. To avoid packets of a PPVPN to be transferred to another PPVPN, PPVPNs do not share the same connection. Note that this document recommends that bandwidth of a connection does not interfere with bandwidth of any other connections, especially in case of QoS support service. Detailed QoS specifications of the connection are for further study. 3.3 Support of Extranet Extranet is supported by NAT/filtering function interconnecting two (or more) PPVPNs. Location of NAT/filtering function may be in one SP network supporting two PPVPNs or in a customer site belonging to two (or more) PPVPNs. In any case, any special usage is not required for the NAT/filtering function between two PPVPNs. Furthermore, no specific functionality is required for the interworking interface between two SP networks. 3.4 Mapping of the Quality of Service Attributes of a QoS/CoS class may also be assigned to each connection. This enables provisioning of multiple QoS/CoS classes within each PPVPN. Kurakami, et al. Expires August 2001 [Page 6] INTERNET-DRAFT PPVPNs Interworking February, 2001 +-----------+ +-----------+ +-----+ +-----+ +-----+ +-----+ | +-----------+ | | +-----------+ | | | | |-------------| | | | | PE | PPVPN A | PE |-------------| PE | PPVPN A | PE | | | | |-------------| | | | | +-----------+ | Connections | +-----------+ | +-----+ +-----+ for +-----+ +-----+ +-----------+ different +-----------+ SP network(s) 1 QoS/CoS Classes SP network(s) 2 Figure 2: Using multiple connections for multiple QoS/CoS classes for each PPVPN. This may be achieved by using diffserv. In this case, a bit-pattern in a field such as TOS of an IP header is used to identify a QoS/CoS class during packet transmission on the connection. +-----------+ +-----------+ +-----+ +-----+ +-----+ +-----+ | +-----------+ | | +-----------+ | | | | | | | | | | PE | PPVPN A | PE |-------------| PE | PPVPN A | PE | | | | | | | | | | +-----------+ | Connection | +-----------+ | +-----+ +-----+ supporting +-----+ +-----+ +-----------+ diffserv +-----------+ SP network(s) 1 SP network(s) 2 Figure 3: Using diffserv for supporting multiple QoS/CoS classes for each PPVPN 3.5 Cooperation of Dynamic Routing Service Route information packets, such as OSPF packets, are transmitted in isolated path of each PPVPN in exactly the same manner as that for user data packets. This enables dynamic routing information distribution within each PPVPN. One merit of this method is that the dynamic routing information distribution is executed with security of CUG service. Another merit is that one of standard routing protocols such as BGP, OSPF, or RIP can be used without any extension. Kurakami, et al. Expires August 2001 [Page 7] INTERNET-DRAFT PPVPNs Interworking February, 2001 3.6 Cooperation of Multicast Multicast control packets, such as DVMRP, are transmitted in isolated path of each PPVPN in the exactly same manner of the case of user data packets. This enables dynamic routing information distribution for constructing multicast tree within each PPVPN. One merit of this method is that the dynamic routing information distribution is executed with security of CUG service. Another merit is that one of standard multicast routing protocols such as DVMRP and PIM can be used without any extension. After once constructed the multicast tree through network interface, it is obvious that data transfer over the multicast tree is supported as well. 4. Applicability and Scalability Discussion When constructing an inter-AS PPVPN spanning multiple BGP-VPN capable SP networks, some interworking methods have been proposed [Section 10 of VPN-2547BIS]. However, among interworking methods which have been proposed so far, the method proposed in this document is applicable to various types of PPVPN capable SP networks. The rest of this section discusses scalability of the proposed method. o Number of routing protocol instances As the proposed method requires as many routing protocol instances as PPVPNs, there exists a limit in the number N of PPVPNs that one PE router can support (e.g., several hundreds) due to resource amount and performance of the PE router. However, each interworking connections is expected to require some bandwidth and total of those bandwidth is limited by the capacity of an PE router, the number of the interconnections cannot be so large. Then, this limit is not a critical drawback. o Performance of packet transmission The proposed method has the same degree of scalability as that of an interworking method using two layer label stacking of MPLS. In summary of this section, the proposed method has high applicability to various types of PPVPN capable SP networks, while it's limit of scalability is not a critical drawback. Kurakami, et al. Expires August 2001 [Page 8] INTERNET-DRAFT PPVPNs Interworking February, 2001 References [FRAMEWORK] Callon, R., Suzuki, M., et al., "A Framework for PPVPNs," , February 2001. [REQUIREMENTS] McDysan, D. et al., "Service Requirements for Provider Provisioned Virtual Private Networks," Internet-draft , February 2001. [RFC2764] Gleeson, B. et al., "A Framework for IP Based Virtual Private Networks," RFC 2764, February 2000. [VPN-2547BIS] Rosen, E. et al., "BGP/MPLS VPNs," Internet-draft , July 2000. [VPN-GMNCL] GMN-CL home page: http://www.gmncl.ecl.ntt.co.jp/top_e.html [RFC2917BIS] Muthukrishnan, K. et al., "A Core MPLS IP VPN Architecture," Internet-draft , November 2000. [VPN-VR] Ould-Brahim H. et al., "Network based IP VPN Architecture Using Virtual Routers," Internet-draft , July 2000. [RFC2684] Grossman, D. and Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5," RFC 2684, September 1999. [MPLS-ARC] Rosen E. et al., "Multiprotocol Label Switching Architecture," draft-ietf-mpls-arch-06.txt. [RFC2475] Blake S. et al., "An architecture for Differentiated Services," RFC 2475. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE," RFC 2890. [RFC2401] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol," RFC 2401. Kurakami, et al. Expires August 2001 [Page 9] INTERNET-DRAFT PPVPNs Interworking February, 2001 Authors' addresses Hiroshi Kurakami NTT Information Sharing Platform Labs. 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: kurakami.hiroshi@lab.ntt.co.jp Junichi Sumimoto NTT Information Sharing Platform Labs. 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: sumimoto.junichi@lab.ntt.co.jp Muneyoshi Suzuki NTT Information Sharing Platform Labs. 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: suzuki.muneyoshi@lab.ntt.co.jp Kurakami, et al. Expires August 2001 [Page 10]