Provider Provisioned VPN WG Hamid Ould-Brahim Internet Draft Nortel Networks Expiration Date: July 2003 Yakov Rekhter Juniper Networks - Editors Don Fedyk Peter Ashwood-Smith Nortel Networks Eric C. Rosen Cisco Systems Eric Mannie KPNQwest Luyuan Fang AT&T John Drake Calient Networks Yong Xue UUNET/WorldCom Riad Hartani Caspian Networks Dimitri Papadimitrio Alcatel Lou Berger Movaz Networks December 2002 GVPN: Generalized Provider-provisioned Port-based VPNs using BGP and GMPLS draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-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 Ould-Brahim, Rekhter, et. al 1 draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 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 Provider- provisioned Port-based Generalized VPN service (GVPN). The service is a Port-based VPN, where the basic unit of the service is a Label Switched Path (LSP) between a pair of customer's ports. The service is "generalized" as the interfaces on the customer's ports and provider ports could be any of the interfaces supported by Generalized MPLS (GMPLS). An important goal of such service is the ability to support what is known as "single end provisioning", where addition of a new port to a given VPN would involve configuration changes only on the devices connected to that port. Another important goal of such service is the ability to establish/terminate an LSP between a pair of (existing) customer's ports within a VPN without involving configuration changes in any of the provider devices. In this document we describe a set of mechanisms built around BGP as a VPN auto-discovery, and GMPLS as a signaling that accomplishes these goals. 1. Sub-IP Summary ID This ID targets the PPVPN working group as it deals with a VPN solution similar to the existing port-based VPNs. It describes an approach to allow service providers to offer GMPLS based VPN services. A pair of client devices (a router, a SONET/SDH cross-connect, or an Ethernet switch) could be connected Ould-Brahim, Rekhter, et al. December 2002 [Page 2] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 through the service provider network via an LSP. It is this LSP that forms the basic unit of service that the service provider network offers. RELATED DOCUMENTS draft-ouldbrahim-ovpn-requirements-01.txt. Others can be found in the "references" 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 over an IP/MPLS infrastructure. This work is exactly a port-based VPN using IP related building blocks. JUSTIFICATION The current PPVPN chairs have already discussed this work and are considering expanding the PPVPN charter to include Generalized Port-based VPN as part of PPVPN mandate. 2. Generalized Port-Based VPN Reference Model Consider a service provider network that consists of devices that supports Generalized MPLS (e.g., Optical Cross Connect, SDH Cross Connect, etc_). Following the framework suggested in [PPVPN-FRAMEWORK], we partition these devices into P (provider) and PE (provider edge) nodes (in the context of this document we'll refer to these devices as just "PE"). The P nodes are connected only to the nodes within the provider's network (in the context of this document we'll refer to these devices as just "P"). The PEs are connected to the other nodes within the provider network (either Ps, or PEs), 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 an SDH cross-connect, or an Ethernet switch. Ould-Brahim, Rekhter, et al. December 2002 [Page 3] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 +---+ +---+ | P |....| P | +---+ +---+ PE / \ PE +-----+ +-----+ +--+ | | | |----| | +--+ | | | | |CE| |CE|----+-----+ | |----| | +--+\ | | | +--+ \ +-----+ | | \ | | | | +--+ \| | | |----|CE| +-----+ +-----+ +--+ \ / +---+ +---+ | P |....| P | +---+ +---+ Figure 1 Generalized Port-Based VPN Reference Model A CE is connected to a PE via one or more links.In the context of this document a link is the same as a GMPLS Traffic Engineering (TE) link construct, as defined in [GMPLS-ROUTING]. In the context of this document a link is a logical construct that is used to represent grouping on a per VPN basis of physical resources used to connect a CE to a PE. Interfaces at the end of each link could be any of the interfaces that are supported by GMPLS. Likewise, CEs and PEs could be any devices that are supported by GMPLS (e.g, optical cross connects, SDH cross-connects, LSRs, etc_). Each link may consist 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 link have shared similar characteristics (e.g., bandwidth, encoding, etc_), and can be interchanged from the CEs point of view. Channels on different links of a CE need not have the same characteristics. There may be more than one link between a given CE PE pair. A CE may be connected to more than one PE (with at least one port per each PE). And, of course, a PE may have more than one CE connected to it. If a CE is connected to a PE ONE via multiple links and all these links belong to the same VPN, then for the purpose of this document these links could be treated as a single link using the link bundling constructs [LINK-BUNDLING]. Ould-Brahim, Rekhter, et al. December 2002 [Page 4] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 In general a link may have only data bearing channels, or only control bearing channels, or both. For the purpose of this discussion we assume that for a given CE-PE pair at least one of the links between them has at least one data bearing channel, and at least one control bearing channel, or there is an IP connectivity between the CE and the PE that could be used for exchanging control information (more on this in Section 4). A link has two end-points - one on CE and one on PE. In the context of this document we'll refer to the former as "CE port", and to the latter as "PE port". From the above it follows that a CE is connected to a PE 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), and all the channels within a given port have shared similar characteristics (e.g., bandwidth, encoding, etc_), and can be interchanged from the CEs point of view. Channels on different ports of a CE need not have the same characteristics. Just like links, in the context of this document ports are logical construct that are used to represent grouping of physical resources on a per GVPN basis that are used to connect a CE to a PE. At any given point in time, a given port on a PE is associated with at most one GVPN, or to be more precise with at most one Port Information Table (although different ports on a given PE could be associated with different GVPNs, or to be more precise with different Port Information Tables). This association is established and maintained by the service provider provisioning system. A pair of CEs could be connected through the service provider network via an LSP. It is precisely this LSP that forms the basic unit of the GVPN service that the service provider network offers. If a port by which a CE is connected to a PE consists of multiple channels (e.g., multiple wavelengths), the CE could establish LSPs to multiple other CEs over this single port. An important goal in the GVPN service is the ability to support what is known as "single end provisioning", where addition of a new port to a given GVPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. Another important goal in the GVPN service is the ability to establish/terminate an LSP between a pair of (existing) ports within a GVPN without involving configuration changes in any of the provider's devices. The mechanisms outlined in this document aim at achieving these goals. Specifically, as part of the GVPN 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 CE Ould-Brahim, Rekhter, et al. December 2002 [Page 5] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 with the information about the ports that the CE could be connected, (3) enable a CE to establish the actual LSP to a subset of ports provided by (2). Finally, the mechanisms allow different GVPN topologies to be supported ranging from hub-and- spoke to complete mesh. The service provider does not initiate the creation of an LSP between a pair of PE ports. This is done rather by the CEs, which attach to the ports. However, the SP, by using the mechanisms outlined in this document, restricts the set of other PE ports which may be the remote endpoints of LSPs that have the given port as the local endpoint. Subject to these restrictions, the CE-to-CE connectivity is under the control of the CEs themselves. In other words, SP allows a GVPN to have a certain set of topologies (expressed as a port-to-port connectivity matrix), and CE-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 GVPN on the providers network and the GVPNs themselves are controlled by the CEs, 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 establishing CE-to-CE LSPs is based on GMPLS signaling [GMPLS]. 3. Overview of operations This document assumes that within a given GVPN each port on a CE that connects the CE to a PE ONE has an identifier that is unique within that GVPN (but need not be unique across several GVPNs). One way to accomplish this is to assign each port an IP address that is unique within a given GVPN, and use this address as a port identifier. Another way to accomplish this is to assigned each port on a CE an index that is unique within that CE, assign each CE an IP address that is unique within a given GVPN, and then use a tuple as a port identifier. This document assumes that within a service provider network, each port on a PE has an identifier that is unique within that network. One way to accomplish this would be to assign each port on a PE an index that is unique within that PE, assign each PE an IP address that is unique within the service provider network (in the case of multi-provider operations, the address has to be unique across all the providers involved), Ould-Brahim, Rekhter, et al. December 2002 [Page 6] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 and then use a tuple as a port identifier within the provider network. PE PE +---------+ +--------------+ +--------+ | +------+| | +----------+ | +--------+ | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | | CE1 |--| |PIT || BGP route | | PIT | |-| CE2 | +--------+ | | ||<----------->| | | | +--------+ | +------+| Distribution| +----------+ | | | | | +--------+ | +------+| -------- | +----------+ | +--------+ | VPN-B | | |VPN-B || | | VPN-B | | | VPN-B | | CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 | +--------+ | | || (Backbone ) | | | | +--------+ | +------+| --------- | +----------+ | | | | | +--------+ | +-----+ | | +----------+ | +--------+ | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | | CE1 |--| |PIT | | | | PIT | |-| CE2 | +--------+ | | | | | | | | +--------+ | +-----+ | | +----------+ | +---------+ +--------------+ Figure 2 Generalized VPN Components As a result, each link connecting the CE to the PE is associated with a CE port that has a unique identifier within a given GVPN, and with a PE port that has a unique identifier 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). This document assumes that in addition to PPI, each port on PE has also an identifier that is unique within the GVPN of that port. One way to accomplish this is to assign each port an IP address that is unique within a given GVPN, and use this address as a port identifier. Another way to accomplish this is to assign each port an index that is unique within a given PE, assign each PE an IP address that is unique within a given GVPN (but need not be unique within the service provider network), and then use a tuple acts as a port identifier. We'll refer to such port identifier as VPN-PPI. Note that PE IP address used for VPN-PPI need not be the same as PE IP address used for PPI. If for a given port on a PE its PPI and VPN-PPI are both unnumbered, then they both could use exactly the same port index. Ould-Brahim, Rekhter, et al. December 2002 [Page 7] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 Note that IP addresses used for CPIs, PPIs and VPN-PPIs could be either IPv4 or IPv6 addresses. For a given link connecting a CE to a PE, if CPI is an IP address, then VPN-PPI has to be an IP address as well. And if CPI is an , then VPN-PPI has to be an . However, for a given port on PE, whether VPN-PPI of that port is an IP address or an is independent of whether PPI of that port is an IP address or an . This document assumes that assignment of PPIs is controlled solely by the service provider (without any coordination with the GVPN customers), while assignment of CPIs and VPN-PPIs is controlled solely by the GVPN that the CPIs and VPN-PPIs belong to. And, of course, each GVPN could assign its CPIs and VPN- PPIs on its own, without any coordination with other GVPNs. Each PE maintains a Port Information Table (PIT) for each GVPN that has at least one port on that PE. A PIT contains a list of tuples for all the ports within its GVPN. A PIT on a given PE is populated from two sources: the information related to the CEs' ports attached to the ports on that PE ONEs (this information could be optionally received from the CEs), and the information received from other PEs. We'll refer to the former as the "local" information, and to the latter as the "remote" information. Propagation of local information to other PEs is accomplished by using BGP VPN auto-discovery procedures, as specified in [BGP-VPN-AUTODISCOVERY]. To restrict the flow of this information to only the PITs within a given GVPN, we use BGP route filtering based on the Route Target Extended Community [BGP-COMM], as follows. Each PIT on a PE 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 pair. In addition, each PIT on a PE 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 GVPN port to a particular PE, this port is associated at provisioning time with a PIT on that PE, and this PIT is associated (again at provisioning time) with that GVPN. Ould-Brahim, Rekhter, et al. December 2002 [Page 8] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 Once a port is configured on the PE, the CE that is attached via this port to the PE MAY pass to the PE the CPI information of that port. This document assumes that this is accomplished by using BGP (however, the document doesn't preclude the use of other mechanisms). This information, combined with the PPI information available to the PE, enables the PE to create a tuple for such port, and then use this tuple to populate the PIT of the GVPN associated with that port. In order to establish an LSP, a CE needs to identify all other CEs in the CE's GVPN it wants to connect to. A CE may already have obtained the CE list through configuration or through some other schemes (such schemes are outside the scope of this draft). It is also desirable, that the service provider, as a value added service, may provide a CE with a list of all other CEs in the CE's GVPN. This is accomplished by passing the information stored in the PE PITs to the attached CE. A way to accomplish this is by using BGP Multi-protocol extensions (however this draft doesn't preclude other mechanisms to be used). Although optional, this draft recommends the PE to signal to the attached CEs the remote CPIs it learnt from the remote CEs part of the same GVPN. A CE may decide to initiate an LSP setup request to a remote CE only when it learns the CPI of the remote CE from the PE. This has the benefit to avoid rejecting LSP setup request while the PE is populating the PITs. Once a CE obtains the information about the CPIs of other ports within the same GVPN, which we'll refer to as "target ports", the CE uses a (subset of) GMPLS signaling, as described in Section 4, to request the provider network to establish an LSP to a target port. The request originated by the CE contains the CPI of the port on the CE that CE wants to use for the LSP, and the CPI of the target port. When the PE attached to the CE that originated the request receives the request, the PE 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 to establish an LSP. Ultimately the request reaches the CE associated with the target CPI (note that the request still carries the CPI of the CE that originated the request). If the CE associated with the target CPI accepts the request, the LSP is established. Note that a CE need not establish an LSP to every target port that CE knows about - it is a local to the CE matter to select a subset of target ports to which the CE will try to establish LSPs. Ould-Brahim, Rekhter, et al. December 2002 [Page 9] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 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 could be further augmented with the information about certain capabilities of the Service Provider network (e.g., support RSOH DCC transparency, arbitrary concatenation, etc_). This information is used to ensure that ports at each end of an LSP have compatible characteristics, and that there are sufficient unallocated resources to establish an LSP. Distribution of this information (including the mechanisms for distributing this information) is identical to the distribution of the information. Distributing changes to this information due to establishing/terminating of LSPs is identical to the distribution of the 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 a GVPN, each of the CEs connected to these ports would concurrently try to establish an LSP to the other CE. If having a pair of LSPs between a pair of ports is viewed as undesirable, the way to resolve this is to require the CE with the lower value of CPI to terminate the LSP originated by the CE. This option could be controlled by configuration on the CE devices. 4. Signaling between CE and PE (Simple UNI -SUNI) Signaling between CE and PE uses a (proper) subset of GMPLS signaling [GMPLS]. For the purpose of GMPLS signaling between CE and PE, this document assumes that there is an IP control channel between the CE and the PE. This channel could be either a single IP hop, or an IP private network, or even an IP VPN. We'll refer to the CE's address of this channel as the CE Control Channel Address (CE-CC-Addr), and to the PE's address of this channel as the PE Control Channel Address (PE-CC-Addr). Both CE-CC-Addr and PE-CC-Addr are required to be unique within the GVPN they belong to, but are not required to be unique across multiple GVPNs. Assignment of CE-CC-Addr and PE-CC-Addr are controlled by the GVPN these addresses belong to. Multiple ports on a CE could share the same control channel only as long as all these ports belong to the same GVPN. Likewise, multiple ports on a PE could share the same control channel only as long as all these ports belong to the same GVPN. Ould-Brahim, Rekhter, et al. December 2002 [Page 10] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 When a CE sends an RSVP Path message to a PE, the source IP address in the IP packet that carries the message is set to the appropriate CE-CC-Addr, and the destination IP address in the packet is set to the appropriate PE-CC-Addr. When the PE sends back to the CE the corresponding Resv message, the source IP address in the IP packet that carries the message is set to the PE-CC-Addr, and the destination IP address is set to the CE-CC- Addr. Likewise, when a PE sends an RSVP Path message to a CE, the source IP address in the IP packet that carries the message is set to the appropriate PE-CC-Addr, and the destination IP address in the packet is set to the appropriate CE-CC-Addr. When the CE sends back to the PE the corresponding Resv message, the source IP address in the IP packet that carries the message is set to the CE-CC-Addr, and the destination IP address is set to the PE-CC-Addr. In addition to being used for IP addresses in the IP packet that carries RSVP messages between CE and PE, CE-CC-Addr and PE-CC-Addr are also used in the Next/Previous Hop Address field of the IF_ID RSVP_HOP object that is carried between CEs and PEs. In the case where a link between CE and PE is a numbered non- bundled link, the CPI and VPN-PPI of that link are used for the Type 1 or 2 TLVs of the IF_ID RSVP HOP object that is carried between the CE and PE. In the case where a link between CE and PE is an unnumbered non-bundled link, the CPI and VPN-PPI of that link are used for the IP Address field of the Type 3 TLV. In the case where a link between CE and PE is a bundled link, the CPI and VPN-PPI of that link are used for the IP Address field of the Type 3 TLVs. When a CE originates a Path message to establish an LSP from a particular port on that CE to a particular target port the CE uses the CPI of its port in the Sender Template object. If the CPI of the target port is an IP address, then the CE uses it in the Session object. And if the CPI of the target port is a tuple, then the CE uses the IP address part of the tuple in the Session object, and the whole tuple as the Unnumbered Interface ID subobject in the ERO. When the Path message arrives at the ingress PE, the PE selects the PIT associated with the GVPN, and then uses this PIT to map CPIs carried in the Session and the Sender Template objects to the appropriate PPIs. Once the mapping is done, the ingress PE replaces CPIs with these PPIs. As a result, the Session and the Sender Template objects that are carried in the GMPLS signaling within the service provider network carry PPIs, and not CPIs. At the egress PE, the PE performs the reverse mapping _ it maps PPIs carried in the Session and the Sender Template object into Ould-Brahim, Rekhter, et al. December 2002 [Page 11] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 the appropriate CPIs, and then sends the Path message to the CE that has the target port. 5. Encoding This section specifies encoding of various information defined in this document. 5.1 Encoding of channel characteristics in GMPLS Signaling [TBD] 5.2 Encoding of CPI, PPI, and channel characteristics in BGP This section defines encoding of the GVPN-specific information in BGP. 5.2.1 Encoding of CPI and PPI information in BGP The mapping is carried using the Multiprotocol Extensions BGP [RFC2858]. [RFC2858] defines the format of two BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI that can be used to announce and withdraw the announcement of reachability information. We introduce a new address family identifier (AFI) for GVPN (to be assigned by the IANA), a new subsequent address family identifier (to be assigned by the IANA), and also a new NLRI format for carrying the CPI and PPI information. One or more tuples could be carried in the above mentioned BGP attributes. The format of encoding a single tuple is shown in Figure 3 below: +---------------------------------------+ | Length (1 octet) | +---------------------------------------+ | PPI AFI (2 octets) | +---------------------------------------+ | PPI Length (1 octet) | +---------------------------------------+ | PPI (variable) | +---------------------------------------+ | CPI AFI (2 octets) | +---------------------------------------+ | CPI (length) | +---------------------------------------+ | CPI (variable) | +---------------------------------------+ Ould-Brahim, Rekhter, et al. December 2002 [Page 12] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 Figure 3: NLRI BGP encoding The use and meaning of these fields are as follows: Length: A one octet field whose value indicates the length of the Information tuple in octets. PPI AFI: A two octets field whose value indicates address family identifier of PPI PPI Length: A one octet field whose value indicates the length of of the PPI field PPI field: A variable length field that contains the value of the PPI (either an address or tuple CPI AFI field: A two octets field whose value indicates address family of the CPI. CPI Length: A once octet field whose value indicates the length of the CPI field. CPI (variable): A variable length field that contains the CPI value (either an address or tuple. 5.2.2 Encoding channel characteristics in BGP [TBD] 6. One vs more than one GVPN The solution described in this document requires each customer port to be in at most one GVPN, or to be more precise requires each customer port connected to a given PE to be associated Ould-Brahim, Rekhter, et al. December 2002 [Page 13] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 with at most one PIT on that PE. It has been asserted that this requirement is too restrictive, as it doesn't allow to realize certain connectivity scenarios. To understand why this assertion is incorrect we'd like to make several observations. First, the solution described in this document allows control connectivity between customers' ports at the granularity of individual ports. This is because each local port on a PE could have its own PIT, and the granularity of the information that is used to populate this PIT could be as fine as a single remote port (port on some other PE). Second, ports that are present in a given PIT need not have the same administrative control. For example, some ports in a given PIT may belong to the same organization (have the same administrative control) as the local ports associated with that PIT, while some other ports in exactly the same PIT may belong to organizations different from the one associated with the local ports. In that sense, a single PIT could combine both an Intranet and an Extranet. As a result, it should be abundantly obvious to the informed reader that the solution described in this document allows to realize any arbitrary inter-port connectivity matrix. Therefore, no other solution could be less restrictive than then one described in this document. 7. Exchanging VPN-ID between CE and PE The solution described in this document assumes that an association of a particular port on a CE with a particular GVPN (or to be more precise with a particular PIT on a PE) is done by the GVPN service provider, as part of the provisioning the port on the PE (associating the PE's port with a particular PIT, and connecting the CE's port with the PE's port). Once this association is established, the CE could request establishment of an LSP to any customer's port present in the PIT. Important to note that in order to select a particular port within the PIT for the purpose of establishing an LSP to that port the only information that the CE needs to identify that port is the CPI of that port. Also important to note that the CPI is either an IP address, or a combination of , but it doesn't include any such thing as VPN-ID. Therefore, the solution described in this document doesn't involve exchanging VPN-IDs between CE and PE in (GMPLS) signaling. Moreover, the lack of exchanging VPN-ID in signaling has no adverse effect on the ability to support any arbitrary inter-port connectivity matrix, and more generally on the flexibility of the solution described here. Ould-Brahim, Rekhter, et al. December 2002 [Page 14] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 8. Other issues 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. The mechanisms described in this document allow for a wide range of choices with respect to addresses used for CPI, PPI, and VPN-PPI. For example, one could use either IPv4 addresses, or IPv6 addresses, or NSAPs. Different GVPN customers of a given service provider may use different types of addresses. Moreover, different GVPNs attaching to the same PE may use different addressing schemes. The types of addresses used for PPIs within a given service provider network are independent from the type of addresses used for CPI and VPN-PPI by the GVPN customers of that provider. While in the context of this document a CE is a device that uses the GVPN service, such a device, in turn, could be used to offer VPN services (e.g., RFC2547, Virtual Routers, Layer 2 VPNs) to other devices (thus becoming a PE with respect to these devices). Moreover, a CE device that uses the GVPN service could, in turn be used to offer GVPN services to other devices (thus becoming a PE with respect to these devices). 9. Security Considerations Since association of a particular port with a particular GVPN (or to be more precise with a particular PIT) is done by the service provider as part of the service provisioning process (and thus can't be altered via signaling between CE and PE), and since signaling between CE and PE is assumed to be over a private network (and thus can't be spoofed by entities outside the private network), the solution described in this document doesn't require authentication in signaling. 10. References [BGP-COMM] Ramachandra, Tappan, "BGP Extended Communities Attribute", February 2000, work in progress. [BGP-VPN-AUTODISCOVERY] Ould-Brahim, et al., _Using BGP as an Auto-Discovery Mechanism for Network-based VPNs_, work in progress Ould-Brahim, Rekhter, et al. December 2002 [Page 15] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 [Framework] Rajagopalan, B. et al., "IP over Optical Networks: A Framework ", February 2002, work in progress. [GMPLS] Ashwood-Smith, P., Berger, L. et al., "Generalized MPLS -Signaling Functional Description", November 2001, work in progress. [GMPLS-ROUTING] Kompella, et al., _Routing Extensions in Support of Generalized MPLS_, work in progress [LINK-BUNDLING] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS Traffic Engineering", work in progress. [GVPN-REQ] Ould-Brahim, H., Rekhter, Y., et al., "Service Requirements for Optical Virtual Private Networks", work in progress, July 2001. [PPVPN-FRAMEWORK] Callon, R., Suzuki, M., Gleeson, B., Malis, A., Muthukrishnanm K, Rosen, E., Sargor, C., Yu, J., _A Framework for Provider Provisioned Virtual Private Networks_, draft-ietf-ppvpn-framework-04.txt, February 2002 [RFC-2858] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions for BGP4", RFC2858, June 2000. [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC2026, October 1996. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [VPN-BGP] Ould-Brahim H., Gleeson B., Ashwood-Smith P., Rosen E., Rekhter Y., Declerq J., Fang L., Hartani R., "Using BGP as an Auto-Discovery Mechanism for Network-based VPNs", work in progress, January 2002. [VPOXC] Ould-Brahim, H., Rekhter Y., et al, "Provider Provisioned GMPLS-based Virtual Private Cross-Connect", draft-ouldbrahim-ppvpn-vpoxc-00.txt, work in progress. 11. Acknowledgments. 12. Author's Addresses Ould-Brahim, Rekhter, et al. December 2002 [Page 16] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 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 Don Fedyk Nortel Networks 600 Technology Park Billerica, Massachusetts 01821 U.S.A Phone: +1 (978) 288 3041 Email: dwfedyk2nortelnetworks.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 Eric C. Rosen Cisco Systems, Inc. 250 Apollo drive Chelmsford, MA, 01824 E-mail: erosen@cisco.com Eric Mannie KPNQwest Terhulpsesteenweg 6A 1560 Hoeilaart Belgium Phone: +32 2 658 56 52 Email: eric.mannie@ebone.com Luyuan Fang AT&T 200 Laurel Avenue Ould-Brahim, Rekhter, et al. December 2002 [Page 17] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 Middletown, NJ 07748 Email: Luyuanfang@att.com Phone: +1 (732) 420 1920 John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138 USA Phone: +1 408 972 3720 Email: jdrake@calient.net 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 Dimitri Papadimitrio Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: Dimitri.Papadimitriou@alcatel.be Lou Berger Movaz Networks, Inc. 7626 jones Branch Drive, Suite 615 McLean, VA 22102 Phone: +1 703 847 1801 Email: lberger@movaz.com Ould-Brahim, Rekhter, et al. December 2002 [Page 18] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt July 2003 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, Rekhter, et al. December 2002 [Page 19]