Provider Provisioned VPN Hamid Ould-Brahim Internet Draft Nortel Networks Expiration Date: July 2003 Yakov Rekhter Juniper Networks Luyuan Fang AT&T Marco Carugi France Telecom Yong Xue UUNET/WorldCom Riad Hartani Caspian Networks Dimitri Papadimitrio Alcatel December 2002 Provider Provisioned GMPLS-based Virtual Private Cross-Connect Service draft-ouldbrahim-ppvpn-vpoxc-02.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. Ould-Brahim, Rekhter, et. al 1 draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002 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 document describes a GMPLS-based Virtual Private Network service called GMPLS-based Virtual Private Cross-Connect (VPOXC). A VPOXC is a provider provisioned VPN service part of the customer private network but administered and under the control of the service provider. A VPOXC operates similarly to a physical optical cross-connect except that it allows a wide spectrum of port topology such as hub and spoke, full mesh, and arbitrary topologies. To the VPOXC customer, the service provider network appears as a virtual private optical cross- connect where customer sites are attached to. The VPOXC port topology is defined by the customer, and enforced by the service provider. Customers can signal any optical connectivity according to the port topology implemented by the VPOXC. Client devices operate within the VPOXC space independently from the service provider network operations. Sub-IP Summary ID This ID targets the PPVPN working group as it deals with a port-based VPN service. This document describes a GMPLS-based Virtual Private Network service called GMPLS-based Virtual Private Cross-Connect (VPOXC). A VPOXC is a provider provisioned VPN service administered and under the control of the service provider. A VPOXC operates similarly to a physical optical cross-connect except that it is using shared resources and implements a wide spectrum of port topology besides just the full mesh port topology. To the VPOXC customer, the service provider network appears as a virtual private optical cross- connect where customer sites are attached to. The VPOXC port topology is defined by the customer, and enforced by the service provider. Customers can signal any optical connectivity according to the topology implemented by the VPOXC. Client devices operate within the VPOXC space independently from the service provider network operations. RELATED DOCUMENTS Ould-Brahim, et al. July 2003 [Page 2] draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002 draft-ouldbrahim-ovpn-requirement-01.txt draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt 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 services and solutions. This work addresses a port-based Optical VPN service. JUSTIFICATION VPOXC based Optical VPNs can also be provided using Provider Provisioned VPN mechanisms. The service described in this draft fits most of the generic requirements for PPVPN (similarly to l2vpn or VPLS). 1. Introduction This document describes a GMPLS-based Virtual Private Network service called GMPLS-based Virtual Private Cross-Connect (VPOXC). A VPOXC is a provider provisioned VPN service administered and under the control of the service provider. A VPOXC operates similarly to a physical optical cross-connect except that it is using shared resources and implements a wide spectrum of port topology besides just the full mesh port topology (hub and spoke, arbitrary and full mesh are private port topologies that can be supported within the VPOXC). To the VPOXC customer, the service provider network appears as a virtual private optical cross-connect where customer sites are attached to. The VPOXC port topology is defined by the customer, and enforced by the service provider. Customers can signal any optical connectivity according to the topology implemented by the VPOXC. Client devices operate within the VPOXC space independently from the service provider network operations. The bandwidth associated with each VPOXC depends on the access bandwidth of each CE to the VPOXC and the port topology implemented within the VPOXC. As sites are added or removed to the VPOXC, the total VPOXC bandwidth is accordingly adjusted. Given the fact that VPOXCs are optical virtual private network services, therefore they are subject to the same requirements described in [OVPN-REQ]. 2. VPOXC Service Model Ould-Brahim, et al. July 2003 [Page 3] draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002 A VPOXC customer defines a port topology to be supported by service provider. Within this port topology, the customer selects any connectivity topology. The service provider restricts and constrains port-to-port connectivity according to the topology implemented within the VPOXC. A service provider network offering VPOXC services 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. To each CE part of the same VPN the service provider appears a virtual private optical cross-connect where customer ports are attached to it. VPOXC +-------------------------------+ | +---+ +---+ | | | P |....| P | | | +---+ +---+ | | PE / \ PE | | +-----+ +-----+ | +--+ | | | | |-|--| | +--+ | | | | | | |CE| |CE|--|-+-----+ | |-|--| | +--+\ | | | | | +--+ \| +-----+ | | | | | | | | | +--+ |\| | | |-|--|CE| | +-----+ +-----+ | +--+ | \ / | | +---+ +---+ | | | P |....| P | | | +---+ +---+ | | | +-------------------------------+ Figure 1 VPOXC based Optical VPN reference Model For the purpose of the VPOXC service, the resources used to connect a CE to a (VPOXC) PE are represented as TE link [CCAMP- ROUTING]. As such, all the constructs (e.g., link bundling) applicable to TE links are applicable here as well. For a given TE link that connects a CE to a (VPOXC) PE the end point of that link connected to the CE is referred to as "CE port", while the end point of that link connected to the (VPOXC) PE is referred to as "VPOXC port". Ould-Brahim, et al. July 2003 [Page 4] draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002 The basic unit of the VPOXC service is an optical or TDM connection between a port on one CE and a port on another CE through the VPOXC. The TDM connection (also referred to TDM LSP in the GMPLS context) rules are driven by [GMPLS-SONET-SDH] for SDH/Sonet interfaces. These rules must be used when establishing TDM connections from CE-port(s) to CE-port(s) over the VPOXC. The number of ports depends on the concatenation capabilities of these interfaces keeping in mind that when provided, virtual concatenation does not constraint the VPOXC port capability. If a port on CE has multiplexing capabilities, the same port could be used to connect to more than one (remote) CE ports. Ports within a VPOXC need not have the same characteristics But only ports with compatible characteristics could be connected (e.g., GigE port to GigE port , but not GigE port to OC-48 port). Furthermore, administrative ownership of VPOXC ports is orthogonal to the VPN membership of these ports _Ports within a VPOXC could belong to the same (intranet), or different (extranet) organizations. Association between a CE with a particular VPOXC is established/maintained by the Provider's provisioning system and therefore could be changed only via provider's provisioning system. A VPOXC port can be moved to another PE port (or even to another PE) without changing the VPOXC addressing used by the customer to request optical connectivity. Addition/Deletion/Changes of the VPOXC port addresses requires no coordination with the service provider addressing scheme. Each VPOXC is associated with one or more control channels used by the CEs to request optical connections. The control channel is addressed using addresses defined within the private network addressing space. Note that a control channel can be an IP tunnel, FR/ATM VCs, etc. Each PE that provides multiple VPOXC services is going to have multiple control channels, one per VPOXC. The VPOXC ports can 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). A VPOXC service assumes that all the CE ports that are attached to a given VPOXC have identifiers that are unambiguous within that VPOXC. The service provider should not assume that these identifiers are unambiguous outside of that VPOXC. CE ports attaching to the VPOXC can 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). Ould-Brahim, et al. July 2003 [Page 5] draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002 The VPOXC addressing, routing, and signaling used by the Service Provider network offering the service are completely independent from the addressing, routing, and signaling used by the VPOXC clients of that network. Moreover, for the purpose of the VPOXC service, addressing, routing and signaling used by one VPOXC client, need not be coordinated with any other VPOXC clients. To simplify operations and for better scalability and stability purposes, the VPOXC service can be implemented using mechanisms by which a given CE that has at least one port associated with a given VPOXC could learn about all other ports of that VPOXC, even if these ports are on other PE ONEs, and even if these other PE ONEs belong to some other service providers. Furthermore, as a value added service, a service provider may provide a CE that has at least one port in a given VPOXC with the information related to all other CE ports of that VPOXC, including the information about various properties of these ports. Given the fact that a VPOXC is part of the customer private network, VPOXC customer may choose to run private routing protocol within the VPOXC (for example using both GMPLS signaling and GMPLS routing at the VPOXC level). Private routing exchange will be discussed in future revisions of this draft. 3. Security Considerations In order to meet privacy requirements, VPOXC addresses should only be visible within that VPOXC and must not be leaked to other VPOXCs (OVPNs). 4. References [OVPN-REQ] Ould-Brahim, H., et al., "Service Requirements for Optical Virtual Private Networks", draft-ouldbrahim-ovpn requirement-01.txt, work in progress. [BGPGMPLS-OVPN] Ould-Brahim H., Rekhter Y., et al., "BGP/GMPLS Optical VPNs", draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt, work in progress [CCAMP-ROUTING] Kompella, K, Rekhter, Y., et al., _Routing Extensions in Support of Generalized MPLS_, draft-ietf- ccamp-gmpls-routing-01.txt, work in progress Ould-Brahim, et al. July 2003 [Page 6] draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002 [GMPLS-SONET-SDH] Mannie, E., et al., "GMPLS Extensions for SONET and SDH Control", draft-ietf-ccamp-gmpls-sonet-sdh- 02.txt 5. 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 Marco Carugi France Telecom R&D Technopole Anticipa, 2 av. P. Marzin 22307 Lannion France Phone : +33 2 96053617 marco.carugi@francetelecom.com Yong Xue UUNET/WorldCom Ashburn, Virginia (703)-886-5358 yxue@uu.net Riad Hartani Caspian Networks 170 Baytech Drive San Jose, CA 95143 Phone: 408 382 5216 Email: riad@caspiannetworks.com Ould-Brahim, et al. July 2003 [Page 7] draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002 Dimitri Papadimitrio 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 8] draft-ouldbrahim-ppvpn-vpoxc-02.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 9]