Internet Engineering Task Force Chandrasekar Kathirvelu INTERNET-DRAFT Karthik Muthukrishnan Walsh Thomas Expires August 2001 Lucent Technologies Andrew Malis Vivace Networks, Inc. Fred Ammann COMMCARE telecommunications February 2001 Hierarchical VPN over MPLS Transport 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 presents an approach for building hierarchical Virtual Private Network (VPN) services. This approach uses Multiprotocol Label Switching (MPLS). The central vision is for the service provider to provide a virtual router service to other SPs without participating in VPNs of those SPs. 1.0. Acronyms Kathirvelu, et al. Expires August 2001 [Page 1] INTERNET-DRAFT Hierarchical VPNs February 2001 ARP Address Resolution Protocol CE Customer Edge router LSP Label Switched Path PNA Private Network Administrator SLA Service Level Agreement SP Service Provider PE Service Provider Edge Device SPNA SP Network Administrator VPNID VPN Identifier VR Virtual Router VRL Virtual Router Link VRC Virtual Router Console P Provider Device 2.0. Introduction This draft describes an approach for building Hierarchical IP VPN services out of the backbone of the SP's network. We use the VR model to describe the relationship among the VPNs, and the MPLS Label stacking to explain how the data is transported in the hierarchical VPNs. The approach presented here does not depend on any modifications of any existing routing protocols. 3.0. Hierarchical Relationship between VPNs 3.1. Virtual Router Link A virtual router(VR) as described in [Muthuk] can be connected to other VRs by a Virtual Router Link ( VRL). Users can define a set of rules on this VRL to control the relationship between the two VPNs.Each end of the VRL is logically bound to a VR. From the VR's point of view it looks like one of its many links. The use of VRL is not limited to hierarchical relationships alone. 4. Label Distribution VPNs can use any Label distribution protocol. Within one VPN the same Label Distribution Protocol SHOULD be used in all its PE devices. Figure 1 depicts an International Service Provider (SPint) with PEs in Boston, Frankfurt and Paris. In addition fig.1 shows three different SPs in Boston , Germany and France that provide VPN services to customers. Kathirvelu, et al. Expires August 2001 [Page 2] INTERNET-DRAFT Hierarchical VPNs February 2001 +-+ +---| | VPN x +-+ VPN x | +-+ | | ( ) A ( ) +-+ +-+-- ( ) ( )-----(SPG)---| | ( ) A ( ) ( ) +-+ VPN y ( SPB )-----( SPint ) ( ) ( ) A ( ) +-+ ( ) ( )------(SPF)---| | VPN y +-+ | ( ) ( ) +-+ | |-------+ | +-+ +-+ VPN y +--------------| | VPN x +-+ Figure 1 Hierarchical VPN SPint - International Service Provider who has PEs in Boston, Frankfurt and Paris SPB - Local SP in Boston. SPG - Local SP in Germany. SPF - Local SP in France. In fig.1. SPint provides the VPN service to SP(B/G/F) called VPN A. The SPs in Boston , Germany and France are connected to the SPint through the SPint's PE in Boston , Germany and France. An MPLS peering relationship is established between SP Boston, Germany and France through VPN A. In our example A2 is the label used by SP(B) to reach SP(G). In Fig. 1 we show two levels of hierarchical VPN. The upper level (Level 0) is provided by the SPint to connect the lower level (Level 1) VPNs.(e.g., VPN x , VPN y , VPN z). Figure 2 is the expansion of SP(B). Kathirvelu, et al. Expires August 2001 [Page 3] INTERNET-DRAFT Hierarchical VPNs February 2001 VPN x +---+ VRL ( VPN x->VPN A) ---| |-----------+ | | | +---+ +-+--+ | |==========> SP1 PE (B) | | VPN A +---+ +-+--+ | | | ----| |-----------+ +---+ VRL ( VPN y->VPN A) VPN y Figure 2 Hierarchical Relationship of a VRL In Figure.2. Level 1 VPN x is connected to Level 0 VPN A by a Virtual Router Link (VRL). All three VPNs (i.e., VPN x , VPN y and VPN A) reside in the same PE of SPB. When the VRL is configured for hierarchical relationship , then the upper level VPN will allocate a label for each VRL. By using Neighbor Discovery mechanism [muth2] VPN x in SP(B) will learn about all the VPN x 's neighbor and its binding or label with Level 0 VPN A and its Level 0 Node id. (VPN A's Node id) 5. Routing/MPLS Peer Relationship Routing/MPLS peer relationship is only maintained between the same VPN peers. In the above example the relationship will be between VPN x in SPB VPN x in SPG and VPN x in SPF. In VPN x the MPLS Peers are : SPBoston <-> SPGermany SPBoston <-> SPFrance SPGermany <-> SPFrance In VPN A the MPLS Peers are : SPint Boston <-> SPint Germany SPint Boston <-> SPint France SPint France <-> SPint Germany 6. Forwarding VPN traffic from the lower level VPNs is forwarded by the upper level VPN. Figure 3. explains the Label encoding. The example label encoding is depicted for data at SPB(VPNx) with the Kathirvelu, et al. Expires August 2001 [Page 4] INTERNET-DRAFT Hierarchical VPNs February 2001 destination of SPG (VPNx). Level 1 VPNs | Level 0 VPN | Level 1 VPNs | | VPN x | | VPN x ------------| |------------- VPN y | VPN A | VPN y ------------|======================|------------- VPN z | | VPN z ------------| |-------------- | | VPN x/y/z Data +-----+ +----+----+ |Data | | Lx2|Data| +-----+ +----+----+ +----+----+-----+ | Ax2|Lx2 | Data| +----+----+-----+ +----+----+-----+-----+ | A2 |Ax2 | Lx2 |Data | +----+----+-----+-----+ Figure 3 Label Encoding Lx2 - Lower level Label in SPB (VPNx) to reach VPNx in SPG Ax2 - VRL upper level Label issued from VPN A label space. A2 - Peer VPN A Label. 7. Security Considerations Security as available in MPLS networks will be available and extended to hierarchical vpns. 8. Intellectual Property Considerations Lucent technologies may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Lucent Technologies. Lucent Technologies Kathirvelu, et al. Expires August 2001 [Page 5] INTERNET-DRAFT Hierarchical VPNs February 2001 intends to disclose those patents and license them on reasonable and non-discriminatory terms. 9. References [Callon] Callon R., et al., "A Framework for Multiprotocol Label Switching", work in Progress [Fox] Fox, B. and B. Gleeson,"Virtual Private Networks Identifier", RFC 2685, September 1999. [Rosen2] Rosen E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", work in progress [muthuk] K.Muthukrishnan, A.Malis "A Core MPLS IP VPN Architecture", RFC 2917 September 2000. 10. Authors' Addresses Karthik Muthukrishnan Lucent Technologies 1 Robbins Road Westford, MA 01886 Phone: (978) 952-1368 EMail: mkarthik@lucent.com Chandrasekar Kathirvelu Lucent Technologies 1 Robbins Road Westford, MA 01886 Phone: (978) 952-7116 EMail: ck32@lucent.com Walsh Thomas Lucent Technologies 10 Lyberty Way Westford, MA 01886 Phone: (978) 392-2311 EMail: tdwalsh@lucent.com 11. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it Kathirvelu, et al. Expires August 2001 [Page 6] INTERNET-DRAFT Hierarchical VPNs February 2001 or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kathirvelu, et al. Expires August 2001 [Page 7]