Provider Provisioned VPN Hamid Ould-Brahim Internet Draft Nortel Networks Expiration Date: July 2003 Yakov Rekhter Juniper Networks Luyuan Fang AT&T Yong Xue UUNET/WorldCom Ananth Nagarajan Sprint Eric Mannie Ebone Marco Carugi France Telecom R&D John Drake Calient Networks Dimitri Papadimitriou Alcatel December 2002 Service Requirements for Optical Virtual Private Networks draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC-2026], except that the right to produce derivative works is not granted. 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- Ould-Brahim, et. al 1 draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002 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 document addresses service requirements for provider provisioned optical virtual private network The intent of this document is to include the OVPN work as part of PPVPN charter. A VPN service model based on optical connectivity has a lot of functional elements in common with other models already chartered in PPVPN. Inclusion of this topic in the charter will facilitate convergence and maximize reusability of common techniques to provide VPN service functions independently of the VPN connectivity level. That is also a global objective of the PPVPN standardization effort. 1. Sub-IP ID Summary This document addresses service requirements for provider provisioned port based optical virtual private network. RELATED DOCUMENTS "GVPN: Generalized Provider-provisioned Port-based VPNs using BGP and GMPLS ", draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-00.txt See also the reference section. WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK Fits the PPVPN box. WHY IS IT TARGETED AT THIS WG This WG is looking at port based VPN using IP based building blocks. This work is within the scope of a port-based optical VPN. 2. Introduction Ould-Brahim, et al. July 2003 [Page 2] draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002 This document addresses service requirements for provider provisioned optical virtual private network. The scope of this draft is related to port-based VPNs only. The intent of this document is to include the OVPN work as part of PPVPN charter. 3. Conventions used in this document 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]. 4. Optical VPN Reference Model Consider a service provider network that consists of devices such as Optical Network Element (ONE) which may be Optical Cross Connects (OXCs), or SONET/SDH Cross Connects. We partition these devices into P (provider) ONEs and PE (provider edge) ONEs. The P ONEs are connected only to the ONEs within the provider's network. The PE ONEs are connected to the ONEs within the provider network, as well as to the devices outside of the provider network. We'll refer to such other devices as Client Edge Devices (CEs). An example of a CE would be a router, or a SONET/SDH Cross Connect, or an Ethernet switch. Figure 1 highlights the Optical VPN reference model as described above +---+ +---+ | P |....| P | +---+ +---+ PE / \ PE +-----+ +-----+ +--+ | | | |----| | +--+ | | | | |CE| |CE|----+-----+ | |----| | +--+\ | | | +--+ \ +-----+ | | \ | | | | +--+ \| | | |----|CE| +-----+ +-----+ +--+ \ / +---+ +---+ | P |....| P | +---+ +---+ Figure 1 Optical VPN reference Model Ould-Brahim, et al. July 2003 [Page 3] draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002 A CE is connected to a PE ONE via one or more links, where each link may consist of one or more channels or sub-channels (e.g., wavelength, or wavelength and timeslot respectively, or just timeslot). A link has two end-points - one on CE and one on PE ONE. In the context of this document we'll refer to the former as "CE port", and to the latter as "PE ONE port". 5. General Service Requirements The basic unit of the OVPN service is an optical or TDM connection between a pair of CEs, or to be more precise, between a port on one CE and a port on another CE. If a port on CE has multiplexing capabilities, the same port could be used to connect to more than one (remote) CE ports. 1) The OVPN service SHOULD support VPN membership at the granularity as fine as a single port/link/channel (e.g. an "AUG-4" in an STM-64 interface, or more simply a VC-4). 2) The OVPN service SHOULD support treating ports and links as logical constructs that are used to represent grouping of physical resources per OVPN. The OVPN service MAY be built using link bundling mechanism. 3) The OVPN service SHOULD provide support for a broad spectrum of OVPN topologies, such as hub-and-spoke, full mesh, arbitrary, etc. 4) The OVPN service SHOULD support either direct control where an in band control channel exists with the data bearing links and channels between the CE and PE ONE pair, or indirect control where an out of band control channel exists for the data bearing links and channels between the CE and PE ONE pair. Moreover, an OVPN service SHOULD allow multiple data links with one associated control channel/link. 5) In general, addressing, signaling and routing interaction between the provider's network and client networks are based on the standard control plane interconnection models currently under development in the IETF. 6) For the control and provisioning of the OVPN service, both distributed control mechanisms and centralized control mechanisms SHOULD be supported to accommodate the service control and management platforms used by different carriers. 7) As far as possible, the OVPN service SHOULD be based on technologies developed in the PPVPN Working Group and other relevant IETF working groups. Ould-Brahim, et al. July 2003 [Page 4] draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002 6. Service Provider Network Requirements 8) The OVPN service SHOULD allow links from different OVPNs to be connected to a given PE ONE. 9) The OVPN service SHOULD provide mechanisms by which ports on a PE ONE are partitioned into (disjoint) sets, with each set representing ports for a given OVPN. 10) The OVPN service SHOULD not require all ports on a given PE ONE to have the same characteristics. 11) To simplify operations and for better scalability and stability purposes, the OVPN service SHOULD provide mechanisms by which a given PE ONE that has at least one port associated with a given OVPN could learn about all other ports of that OVPN, even if these ports are on other PE ONEs, and even if these other PE ONEs belong to some other service providers. These mechanisms SHOULD be provided per OVPN basis and on a network wide scale from service provider perspective. 12) Furthermore, as a value added service, a service provider MAY provide a CE that has at least one port in a given OVPN with the information related to all other CE ports of that OVPN, including the information about various properties of these ports. 13) When a service provider network denies connectivity between a pair of CE ports, the service provider network MUST provide a reason (to at least one of these CEs) for denying the connectivity. 14) The OVPN service MAY assume that each PE ONE port has an identifier that is unambiguous at least with the Service Provider network that this port belongs to. And in the case where the OVPN service spans multiple (interconnected) service providers, it is assumed that this identifier is unambiguous across all PE ONE ports of these service providers. 15) The OVPN service SHOULD allow PE ONE ports facing the customer devices to be identified by either network layer addresses (e.g., IPv4 addresses), or by a combination of PE ONE identifier and a port/interface index (e.g., IP unnumbered interfaces). 16) To provide OVPN service that scales to a large number of customers, no single component of the service provider networks should be required to maintain all the information about all the OVPNs. Ould-Brahim, et al. July 2003 [Page 5] draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002 17) For scalability purposes, it SHOULD be desirable to minimize the amount of configuration changes when adding/deleting a port to/from a given OVPN. For the same reasons, it is also desirable that configuration/provisioning changes of a port to/from a given OVPN SHOULD involve configuration/provisioning only on the device that this port is connected to. 18) A service network SHOULD support an OVPN that spans multiple (interconnected) service providers or multiple networks within a single service provider. 19) For minimum disruption to the service provider existing VPN infrastructure (e.g., layer-3 VPNs, Layer 2 VPNs), when possible, an OVPN service SHOULD maximize reusability of existing VPN service and technology building blocks already deployed (e.g., management tools, membership schemes, etc.) and being standardized in the PPVPN WG. 6.1 Service Provider Management Requirements 20) As value added OVPN services, service provider MAY provide auto-provisioning tools to facilitate customer ordering. (e.g. web ordering, "point-and-click" solutions). Service provider MAY also provide its customer with customer specific report via web access or other means. 21) Operator should have the capability to display the OVPN topology on a per OVPN basis or multiple OVPN basis. 7. Customer Requirements 22) An OVPN customer MAY have circuits in a OVPN and "regular" circuits on the same physical interface, or even circuits in different OVPNs through the same physical interface. 23) The OVPN service MUST be able to support more than one link between a given (CE, PE ONE) pair. Moreover, the service should allow a CE to be connected to more than one PE ONE (with at least one port per each PE ONE). And, of course, a PE ONE should be able to have more than one CE connected to it. 24) The OVPN service SHOULD allow links from different OVPNs to be connected to a given PE ONE. Likewise, it should allow links from different OVPNs to be connected to a given CE. 25) The OVPN service SHOULD not require all ports on a given CE to have the same characteristics. Ould-Brahim, et al. July 2003 [Page 6] draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002 26) When a service provider network denies connectivity between a pair of CE ports, the network MUST provide a reason (to at least one of these CEs) for denying the connectivity. 27) The OVPN service SHOULD allow establishment of connectivity (e.g., establishment of an optical channel trail) between a pair of ports that belong to a given OVPN to be under control of the customer of that OVPN. The service should provide mechanisms to restrict such connectivity to only the ports that belong to that particular OVPN. This connectivity could be further restricted to only the ports with similar characteristics. 28) The OVPN service MUST allow addressing and routing used by the Service Provider network offering the service to be completely independent from the addressing and routing used by the OVPN clients of that network. Moreover, for the purpose of the OVPN service, addressing and routing used by one OVPN client, need not be coordinated with any other OVPN clients. 29) The OVPN service MAY assume that all the CE ports that belong to a given VPN have identifiers that are unambiguous within that OVPN. The service should not assume that these identifiers are unambiguous outside of that OVPN. (As a result, identifiers of CE ports connected to a given PE ONE may be ambiguous). 30) The OVPN service SHOULD allow CE ports to be identified by either network layer addresses (e.g., IPv4, IPv6, NSAP addresses), or by a combination of CE identifier and a port/interface index (e.g., IP unnumbered interfaces). 31) For the purpose of the OVPN service the administrative ownership of CE ports SHOULD be orthogonal to the OVPN membership of these ports. For example, it should be possible to either have all CE ports within a given OVPN to be under control of a single administration, or each port to be controlled by its own administration. 32) The OVPN service architecture should be able to support hierarchical VPN scenarios in which one Service Provider offers OVPN service to another Service Provider who then resells that OVPN service to his customers (as OVPN service or other types of VPN service such as Layer 2 or Layer 3 VPNs) 8. Security Considerations [TBD] 9. References Ould-Brahim, et al. July 2003 [Page 7] draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002 [PPVPN-REQ] Carugi, M., et al., "Service requirements for Provider Provisioned Virtual Private Networks", work in progress. [GMPLS-VPN] Ould-Brahim H., Rekhter Y., et al., "GVPN: Generalized Provider-provisioned Port-based VPNs using BGP and GMPLS ", draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-00.txt, work in progress [GMPLS-ARCH] Mannie, E., et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", work in progress [Framework] Rajagopalan, B. et al., "IP over Optical Networks: A Framework ", November 2000, work in progress. 10. Acknowledgments. The authors would like to acknowledge the following individuals for their comments: Raymond Aubin, Erning Ye, Bryan Gleeson. 11. Author's Addresses Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 Email: hbrahim@nortelnetworks.com Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 Email: yakov@juniper.net Luyuan Fang AT&T 200 Laurel Avenue Middletown, NJ 07748 Email: Luyuanfang@att.com Phone: +1 (732) 420 1920 Yong Xue UUNET/WorldCom Ashburn, Virginia (703)-886-5358 yxue@uu.net Ould-Brahim, et al. July 2003 [Page 8] draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002 Ananth Nagarajan Sprint 9300,Metcalf Ave Overland Park, KS 66212 Phone +1-913-534-3973 ananth.nagarajan@mail.sprint.com Eric Mannie Ebone (GTS) Terhulpsesteenweg 6A 1560 Hoeilaart Belgium Phone: +32 2 658 56 52 Email: eric.mannie@gts.com Marco Carugi France Telecom R&D Technopole Anticipa, 2 av. P. Marzin 22307 Lannion France Phone : +33 2 96053617 marco.carugi@francetelecom.com John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138 USA Phone: +1 408 972 3720 Email: jdrake@calient.net Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: Dimitri.Papadimitriou@alcatel.be Ould-Brahim, et al. July 2003 [Page 9] draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002 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 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. Ould-Brahim, et al. July 2003 [Page 10]