Provider Provisioned VPN Hamid Ould-Brahim Internet Draft Don Fedyk draft-ouldbrahim-bgpgmpls-ovpn-00.txt Peter Ashwood-Smith Expiration Date: October 2001 Nortel Networks Yakov Rekhter Juniper Networks Eric C. Rosen Cisco Systems April 2001 BGP/GMPLS Optical VPNs 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- 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 Consider a service provider network that offers Optical Virtual Private Network (OVPN) service. An important goal in the OVPN service is the ability to support what is known as "single end provisioning", where addition of a new port to a given OVPN would involve configuration/provisioning changes only on the devices connected to that port. Another important goal in the OVPN service is the ability to establish/terminate an optical connection between Ould-Brahim, et. al [Page 1]
Internet-Draft draft-ouldbrahim-bgpgmpls-ovpn-00.txt April 2001 a pair of (existing) ports within an OVPN without involving configuration/provisioning changes in any of the provider devices. In this document we describe a set of mechanisms that accomplishes these goals. Obsoletes draft-fedyk-bgpvpon-auto-00.txt 1. 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). 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 Devices (CDs). An example of a CD would be a router, or a SONET/SDH cross-connect. +---+ +---+ | P |....| P | +---+ +---+ PE / \ PE +-----+ +-----+ +--+ | | | |----| | +--+ | | | | |CD| |CD|----+-----+ | |----| | +--+\ | | | +--+ \ +-----+ | | \ | | | | +--+ \| | | |----|CD| +-----+ +-----+ +--+ \ / +---+ +---+ | P |....| P | +---+ +---+ Figure 1 Optical VPN Reference Model A CD is connected to a PE ONE via one or more ports, where each port may consists of one or more channels or sub-channels (e.g., wavelength or wavelength and timeslot respectively). For purpose of this discussion we assume that all the channels within a given port have shared similar characteristics (e.g., bandwidth, encoding, etc_), and can be interchanged from the CDs point of view. Channels on different ports of a CD need not have the same characteristics. Ould-Brahim, et al. October 2001 [Page 2]
Internet-Draft draft-ouldbrahim-bgpgmpls-ovpn-00.txt April 2001 There may be more than one port between a given CD PE ONE pair. A CD may be connected to more than one PE ONE (with at least one port per each PE ONE). And, of course, a PE ONE may have more than one CD connected to it. A pair of CDs could be connected through the service provider network via an optical connection. It is precisely this optical connection that forms the basic unit of service that the service provider network offers. If a port by which a CD is connected to a PE ONE consists of multiple channels (e.g., multiple wavelengths), the CD could establish optical connection to multiple other CDs over this single port. An important goal in the OVPN service is the ability to support what is known as "single end provisioning", where addition of a new port to a given OVPN would involve configuration/provisioning changes only on the PE ONE that has this port and on the CD that is connected to the PE ONE via this port. Another important goal in the OVPN service is the ability to establish/terminate an optical connection between a pair of (existing) ports within an OVPN without involving configuration/provisioning changes in any of the provider's ONEs. The mechanisms outlined in this document aim at achieving these goals. Specifically, as part of the Optical VPN service offering, these mechanisms (1) enable the service provider to restrict the set of ports that a given port could be connected to, (2) enable the service provider to provide a CD with the information about the ports that the CD could be connected, (3) enable a CD to establish the actual connections to a subset of ports provided by (2). The service provider does not initiate the creation of an optical circuit between a pair of PE ONE ports. This is done rather by the CDs which attach to the ports. However, the SP, by using the mechanisms outlined in this document, restricts the set of other PE ONE ports which may be the remote endpoints of optical circuits that have the given port as the local endpoint. Subject to these restrictions, the CD-to-CD connectivity is under the control of the CDs themselves. In other words, SP allows an OVPN to have a certain set of topologies, and CD-initiated signaling is used to choose a particular topology from that set. Since this model involves minimal provisioning changes when changing the connectivity among the ports within a OVPN on the providers network and the OVPNs themselves are controlled by the CDs, the tariff structure may be on a port basis or alternatively tariffs could be triggered on the basis of signaling mechanisms. Finally, it is assumed that CD-to-CD optical connectivity is based on GMPLS [GMPLS] and typically provides UNI [OIF-UNI] and/or NNI capability. This signaling is not covered in this document. Ould-Brahim, et al. October 2001 [Page 3]
Internet-Draft draft-ouldbrahim-bgpgmpls-ovpn-00.txt April 2001 2. Overview of operations This document assumes that within a given OVPN each port has an identifier that is unique within that OVPN (but need not be unique across several OVPNs). One way to accomplish this is to assign each port an IP address that is unique within a given OVPN, and use this address as a port identifier. Another way to accomplish this is to assigned each port an interface index that is unique within a given CD, assign each CD an IP address that is unique within a given OVPN, and then use a tuple <interface index, CD IP address> acts as a port identifier. If a CD is connected to a PE ONE via multiple ports and all these ports belong to the same VPN, then for the purpose of OVPN using the link bundling constructs [LINK-BUNDLING] these ports could be treated as a single port. This document assumes that within a service provider network, each port on a PE ONE has an identifier that is unique within that network. One way to accomplish this would be to assign each port on a PE ONE an interface index, assign each PE ONE an IP address that is unique within the service provider network, and then use a tuple <interface index, PE ONE IP address> as a port identifier within the provider network. PE ONE PE ONE +---------+ +--------------+ +--------+ | +------+| | +----------+ | +--------+ | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | | CD1 |--| |PIT || BGP route | | PIT | |-| CD2 | +--------+ | | ||<----------->| | | | +--------+ | +------+| Distribution| +----------+ | | | | | +--------+ | +------+| -------- | +----------+ | +--------+ | VPN-B | | |VPN-B || ( Optical ) | | VPN-B | | | VPN-B | | CD1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CD2 | +--------+ | | || (Backbone ) | | | | +--------+ | +------+| --------- | +----------+ | | | | | +--------+ | +-----+ | | +----------+ | +--------+ | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | | CD1 |--| |PIT | | | | PIT | |-| CD2 | +--------+ | | | | | | | | +--------+ | +-----+ | | +----------+ | +---------+ +--------------+ Figure 2 OVPN Components Ould-Brahim, et al. October 2001 [Page 4]
Internet-Draft draft-ouldbrahim-bgpgmpls-ovpn-00.txt April 2001 As a result, each port has an identifier that is unique within a given OVPN, and (another) identifier that is unique within the service provider network. We'll refer to the former as the customer port identifier (CPI), and to the latter as the provider port identifier (PPI). Each PE ONE maintains a Port Information Table (PIT) for each OVPN that has at least one port on that PE ONE. A PIT contains a list of <CPI, PPI> tuples for all the ports within its OVPN. A PIT on a given PE ONE is populated from two sources: the information received from the CDs attached to the ports on that PE ONEs, and the information received from other PE ONEs. We'll refer to the former as the _local_ information, and to the latter as the _remote_ information. The local information is propagated to other PE ONEs by using BGP with multi-protocol extensions. To restrict the flow of this information to only the PITs within a given OVPN, we use BGP route filtering based on the Route Target Extended Community [BGP-COMM], as follows. Each PIT on a PE ONE is configured with one or more Route Target Communities, called "export Route Targets", that are used for tagging the local information when it is exported into provider's BGP. The granularity of such tagging could be as fine as a single <PPI, CPI> pair. In addition, each PIT on a PE ONE is configured with one or more Route Target Communities, called "import Route Targets", that restrict the set of routes that could be imported from provider's BGP into the PIT to only the routes that have at least of these Communities. When a service provider adds a new OVPN port to a particular PE ONE, this port is associated at provisioning time with a PIT on that PE ONE, and this PIT is associated (again at provisioning time) with that OVPN. Once a port is configured on the PE ONE, the CD that is attached via this port to the PE ONE passes to the PE ONE the CPI information of that port. This document assumes that this is accomplished by using a (subset of) GMPLS signaling (however, the document doesn't preclude the use of other mechanisms). This information, combined with the PPI information available to the PE ONE, enables the PE ONE to create a tuple <CPI, PPI> for such port, and then use this tuple to populate the PIT of the OVPN associated with that port. A PE ONE uses the information in its PITs to provide CDs connected to that PE ONE with the information about CPIs of other ports within the same OVPN, which we'll refer to as "target ports". This document assumes that this is accomplished by using a (subset of) GMPLS Ould-Brahim, et al. October 2001 [Page 5]
Internet-Draft draft-ouldbrahim-bgpgmpls-ovpn-00.txt April 2001 signaling. Once a CD has this information, the CD uses a (subset of) GMPLS signaling to request the provider network to establish an optical connection to a target port. The request originated by the CD contains the CPI of the port on the CD that CD wants to use for the optical connection, and the CPI of the target port. When the PE ONE attached to the CD that originated the request receives the request, the PE ONE identifies the appropriate PIT, and then uses the information in that PIT to find out the PPI associated with the CPI of the target port carried in the request. The PPI should be sufficient for the PE ONE to establish an optical connection. Ultimately the request reaches the CD associated with the target CPI (note that the request still carries the CPI of the CD that originated the request). If the CD associated with the target CPI accepts the request, the optical connection is established. Note that a CD need not establish an optical connection to every target port that CD knows about _ it is a local to the CD matter to select a subset of target ports to which the CD will try to establish optical connections. A port, in addition to its CPI and PPI may also have other information associated with it that describes characteristics of the channels within that port, such as encoding supported by the channels, bandwidth of a channel, total unreserved bandwidth within the port, etc_ This information is used to ensure that ports at each end of an optical connection have compatible characteristics, and that there are sufficient unallocated resources to establish an optical connection. Distribution of this information (including the mechanisms for distributing this information) is identical to the distribution of the CPI information. Distributing changes to this information due to establishing/terminating of optical connections is identical to the distribution of the CPI information, except that thresholds should be used to contain the volume of control traffic caused by such distribution. It may happen that for a given pair of ports within an OVPN, each of the CDs connected to these ports would concurrently try to establish an optical connection to the other CD. If having a pair of optical connections between a pair of ports is viewed as undesirable, the a way to resolve this is have CD with the lower value of CPI is required to terminate the optical connection originated by the CD. This option could be controlled by configuration on the CD devices. 3 Encoding This section specifies encoding of various information defined in this document 3.1 Encoding of CPI and channel characteristics in GMPLS Signaling [TBD] Ould-Brahim, et al. October 2001 [Page 6]
Internet-Draft draft-ouldbrahim-bgpgmpls-ovpn-00.txt April 2001 3.2 Encoding of CPI, PPI, and channel characteristics in BGP [TBD] 4 Other issues While the above text assumes that the service provider network consists of ONEs and ports are connected via optical connections, the mechanisms described in this document could be applied in an environment, where the service provider network consists of SONET/SDH cross connects and ports are connected via SONET/SDH sub- channels with each other. Since the protocol used to populate a PIT with remote information is BGP, since BGP works across multiple routing domains, and since GMPLS signaling isn't restricted to a single routing domain, it follows that the mechanisms described in this document could support an environment that consists of multiple routing domains. 5. Security Considerations 6. References [BGP-COMM] Ramachandra, Tappan, "BGP Extended Communities Attribute", February 2000, work in progress. [LINK-BUNDLING] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS Traffic Engineering", work in progress. [RFC-2283] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions for BGP4", RFC2283, February 1998. [BGP-MPLS] Rekhter Y, Rosen E., "Carrying Label Information in BGP4", January 2001, work in progress. [RFC-3031] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", RFC3031, January 2001. [RFC-3032] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", RFC3032, January 2001. [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC2026, October 1996. [RFC-2685] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Ould-Brahim, et al. October 2001 [Page 7]
Internet-Draft draft-ouldbrahim-bgpgmpls-ovpn-00.txt April 2001 [VPN-BGP] Ould-Brahim H., Gleeson B., Ashwood-Smith P., Rosen E., Rekhter Y., "Using BGP as an Auto-Discovery Mechanism for Network-based VPNs", work in progress. [GMPLS] Ashwood-Smith, P., Berger, L. et al., "Generalized MPLS - Signaling Functional Description", November 2000, work in progress. [Framework] Rajagopalan, B. et al., "IP over Optical Networks: A Framework ", November 2000, work in progress. [OIF-UNI] Optical Networking Forum, "User Network Interface (UNI) 1.0 Signaling Specification", work in progress. 7. Acknowledgments. The authors would like to thank Osama Aboul-Magd, Dimitri Papadimitriou, and Penno Reinaldo for reviewing the draft and providing comments. Ould-Brahim, et al. October 2001 [Page 8]
8. 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 Don Fedyk Nortel Networks 600 Technology Park Billerica, Massachusetts 01821 U.S.A. Phone: +1 (978) 288 3041 Email: dwfedyk@nortelnetworks.com Peter Ashwood-Smith Nortel Networks P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7, Canada Phone: +1 613 763 4534 Email: petera@nortelnetworks.com Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 Email: yakov@juniper.net Eric C. Rosen Cisco Systems, Inc. 250 Apollo drive Chelmsford, MA, 01824 E-mail: erosen@cisco.com Ould-Brahim, et. al 9 draft-ouldbrahim-bgpgmpls-ovpn-00.txt April 2001 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. October 2001 [Page 10]