L3VPN WG Hamid Ould-Brahim Internet Draft Nortel Networks Expiration Date: August 2005 Eric C. Rosen Cisco Systems Yakov Rekhter Juniper Networks (Editors) February 2005 Using BGP as an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs draft-ietf-l3vpn-bgpvpn-auto-05.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 In any Layer-3 and Layer-2 VPN scheme, the Provider Edge (PE) devices attached to a common VPN must exchange certain information as a prerequisite to establish VPN-specific connectivity. The purpose of this draft is to define a BGP based auto-discovery mechanism for layer-2 VPN architectures and Virtual router-based Ould-Brahim & Rosen & Rekhter [Page 1] Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 layer-3 VPNs [VPN-VR]. This mechanism is based on the approach used by BGP/MPLS-IP-VPN [BGP/MPLS-IP-VPN] for distributing VPN routing information within the service provider(s). In the context of L2VPNs, an auto-discovery mechanism enables a PE to determine the set of other PEs having VPN members in common along with information relative to each specific L2VPN endpoints such as attachment circuit identifier, topology information, etc. Each VPN scheme uses the mechanism to automatically discover the information needed by that particular scheme. 1. Introduction In any Layer-2 and Layer-3 VPN scheme, the Provider Edge (PE) devices attached to a common VPN must exchange certain information as a prerequisite to establish VPN-specific connectivity. The purpose of this draft is to define a BGP based auto-discovery mechanism for layer-2 VPNs (i.e., [VPLS-BGP], [L2VPN-ROSEN], [VPLS- LDP]) and layer-3 VPNs based on Virtual Router(VR [VPN-VR]) solution. This mechanism is based on the approach used by BGP/MPLS- IP-VPN for distributing VPN routing information within the service provider(s). Each VPN scheme uses the mechanism to automatically discover the information needed by that particular scheme. In BGP/MPLS-IP-VPN, VPN-specific routes are exchanged, along with the information needed to enable a PE to determine which routes belong to which VRFs. In VR model, virtual router (VR) addresses must be exchanged, along with the information needed to enable the PEs to determine which VRs are in the same VPN ("membership"), and which of those VRs are to have VPN connectivity ("topology"). Once the VRs are reachable through the tunnels, routes ("reachability") are then exchanged by running existing routing protocols per VPN basis. In the context of L2VPNs, an auto-discovery mechanism enables a PE to determine the set of other PEs having VPN members in common along with information relative to each specific L2VPN endpoints such as attachment circuit identifier, topology information, etc. The BGP-4 multiprotocol extensions are used to carry various information about VPNs for both layer-2 and layer-3 VPN architectures. VPN-specific information associated with the NLRI is encoded either as attributes of the NLRI, or as part of the NLRI itself, or both. 2. Provider-Provisioned VPN Reference Model Both the layer-2 and layer-3 vpn architectures ([VPLS-BGP],[VPLS- LDP], [L2VPN-ROSEN], [VPN-VR], [BGP/MPLS-IP-BPN]) are using a network reference model as illustrated in figure 1. Ould-Brahim & Rosen & Rekhter February 2005 [Page 2] Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 PE PE +--------------+ +--------------+ +--------+ | +----------+ | | +----------+ | +--------+ | VPN-A | | | VPN-A | | | | VPN-A | | | VPN-A | | Sites |--| |Database /| | BGP route | | Database/| |-| sites | +--------+ | |Processing| |<----------->| |Processing| | +--------+ | +----------+ | Distribution| +----------+ | | | | | +--------+ | +----------+ | | +----------+ | +--------+ | VPN-B | | | VPN-B | | -------- | | VPN-B | | | VPN-B | | Sites |--| |Database /| |-(Backbones)-| | Database/| |-| sites | +--------+ | |Processing| | -------- | |Processing| | +--------+ | +----------+ | | +----------+ | | | | | +--------+ | +----------+ | | +----------+ | +--------+ | VPN-C | | | VPN-C | | | | VPN-C | | | VPN-C | | Sites |--| |Database /| | | | Database/| |-| sites | +--------+ | |Processing| | | |Processing| | +--------+ | +----------+ | | +----------+ | +--------------+ +--------------+ Figure 1: Network based VPN Reference Model It is assumed that the PEs can use BGP to distribute information to each other. This may be via direct IBGP peering, via direct EBGP peering, via multihop BGP peering, through intermediaries such as Route Reflectors, through a chain of intermediate BGP connections, etc. It is assumed also that the PE knows what architecture it is supporting. 3. Carrying VPN information in BGP Multi-Protocol (BGP-MP) Attributes The BGP-4 multiprotocol extensions are used to carry various information about VPNs for both layer-2 and layer-3 VPN architectures. VPN-specific information associated with the NLRI is encoded either as attributes of the NLRI, or as part of the NLRI itself, or both. The addressing information in the NLRI field is ALWAYS within the VPN address space, and therefore MUST be unique within the VPN. The address specified in the BGP next hop attribute, on the other hand, is in the service provider addressing space. 3.1 Carrying Layer-3 VPN Information in BGP-MP This is done as follows. The NLRI is a VPN-IP address or a labeled VPN-IP address. Ould-Brahim & Rosen & Rekhter February 2005 [Page 3] Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 In the case of the virtual router, the NLRI address prefix is an address of one of the virtual routers configured on the PE. Thus this mechanism allows the virtual routers to discover each other, to set up adjacencies and tunnels to each other, etc. In the case of BGP/MPLS-IP-VPN, the NLRI prefix represents a route to an arbitrary system or set of systems within the VPN. 3.2 Carrying Layer-2 VPN Information in BGP-MP The NLRI carries VPN layer-2 addressing information called VPN-L2 address. A VPN-L2 address is composed of a quantity beginning with an 8 bytes Route Distinguisher (RD) field and a variable length quantity (see section 5 for specific encodings of this quantity). Different layer-2 VPN solutions use the same common AFI, but different SAFI. The AFI indicates that the NLRI is carrying a VPN-l2 address, while the SAFI indicates solution-specific semantics and syntax of the VPN-l2 address that goes after the RD. The RD must be chosen so as it ensures that each NLRI is globally unique (i.e., the same NLRI does not appear in two VPNs). BGP Route target extended community is used to constrain route distribution between PEs. The BGP Next hop carries the service provider tunnel endpoint address. This draft doesn't preclude the use of additional extended communities for encoding specific l2vpn parameters. 4. Interpretation of VPN Information in Layer-3 VPNs 4.1 Interpretation of VPN Information in the BGP/MPLS-IP-VPN Model For details see [BGP/MPLS-IP-VPN]. 4.2 Interpretation of VPN Information in the VR Model 4.2.1 Membership Discovery The VPN-ID format as defined in [RFC-2685] is used to identify a VPN. All virtual routers that are members of a specific VPN share the same VPN-ID. A VPN-ID is carried in the NLRI to make addresses of VRs globally unique. Making these addresses globally unique is necessary if one uses BGP for VRs' auto-discovery. 4.2.1.1 Encoding of the VPN-ID in the NLRI For the virtual router model, the VPN-ID is carried within the route distinguisher (RD) field. In order to hold the 7-bytes VPN-ID, the first byte of RD type field is used to indicate the existence of the VPN-ID format. A value of 0x80 in the first byte of RD's type field Ould-Brahim & Rosen & Rekhter February 2005 [Page 4] Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 indicates that the RD field is carrying the VPN-ID format. In this case, the type field range 0x8000-0x80ff will be reserved for the virtual router case. 4.2.1.2 VPN-ID Extended Community A new extended community is used to carry the VPN-ID format. This attribute is transitive across the Autonomous system boundary. The type field of the VPN-ID extended community is of regular type to be assigned by IANA [BGP-COMM]. The remaining 7 bytes hold the VPN-ID value field as per [RFC-2685]. The BGP UPDATE message will carry information for a single VPN. It is the VPN-ID Extended Community, or more precisely route filtering based on the Extended Community that allows one VR to find out about other VRs in the same VPN. 4.2.2 VPN Topology Information A new extended community is used to indicate different VPN topology values. This attribute is transitive across the Autonomous system boundary. The value of the type field for extended type is assigned by IANA. The first two bytes of the value field (of the remaining 6 bytes) are reserved. The actual topology values are carried within the remaining four bytes. The following topology values are defined: Value Topology Type 1 "Hub" 2 "Spoke" 3 "Mesh" Arbitrary values can also be used to allow specific topologies to be constructed. In a hub and spoke topology, spoke VRs (i.e., PE having VRs as spokes within the VPN) will advertise their BGP information with VPN topology extended community with value of "2". Spoke VRs will only be allowed to connect to hub VRs. Hence spoke VR-based PEs will not import VPN information with VPN topology information set to "2". Hub sites can connect to both hub and spoke sites (i.e., Hub VRs can import VPN topology of both values "1", "2", or "3". In a mesh topology, mesh sites connect to each other, each VR will advertise VPN topology information of "3". Furthermore, in the presence of both hub and spoke and mesh topologies within the same VPN, mesh sites can as well connect to hub sites and vice versa. 5. Interpretation of VPN Information in Layer-2 VPNs Ould-Brahim & Rosen & Rekhter February 2005 [Page 5] Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 The interpretation of the VPN information for L2VPN solutions is described in the following sections. 5.1 Single-sided Provisioning with Discovery Point-to-Point L2VPNs As described in [L2VPN-ROSEN], the single-sided provisioning model with discovery model for point-to-point L2VPNs requires that each Attachment Circuit of a point-to-point L2VPN must be provisioned with a local name. The local name consists of a Attachment Group Identifier (AGI) (which can represent a VPN-ID) and an Attachment Individual Identifier which is unique relative to the AGI. If two Attachment circuits are to be connected by a PW, only one of them needs to be provisioned with a remote name (which of course is the local name of the other Attachment Circuit). Neither needs to be provisioned with the address of the remote PE, but both must have the same VPN-id. As part of an auto-discovery procedure, each PE advertises its pairs. Each PE compares its local pairs with the pairs advertised by the other PEs. If PE1 has a local pair with value , and PE2 has a local pair with value , PE1 will thus be able to discover that it needs to connect to PE2. When signaling, it will use "fred" as the TAII, and will use V as he AGI. PE1's local name for the Attachment Circuit is sent as the SAII. 5.2 Colored Pools In the "Colored Pools" model of operation, each PE may contain several pools of Attachment Circuits, each pool associated with a particular VPN. A PE may contain multiple pools per VPN, as each pool may correspond to a particular CE device. It may be desired to create one pseudowire between each pair of pools that are in the same VPN; the result would be to create a full mesh of CE-CE VCs for each VPN. In order to use BGP-based auto-discovery, the color associated with a colored pool must be encodable as both an RT (Route Target) and an RD (Route Distinguisher). The globally unique identifier of a pool must be encodable as NLRI; the color would be encoded as the RD and the pool identifier as a four-byte quantity which is appended to the RD to create the NLRI. Auto-discovery procedures by having each PE distribute, via BGP, the NLRI for each of its pools, with itself as the BGP next hop, and with the RT that encodes the pool's color. If a given PE has a pool with a particular color (RT), it must receive, via BGP, all NLRI with that same color (RT). Typically, each PE would be a client of a small set of BGP route reflectors, which would redistribute this information to the other clients. If a PE has a pool with a particular color, it can then receive all Ould-Brahim & Rosen & Rekhter February 2005 [Page 6] Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 the NLRI which have that same color, and from the BGP next hop attribute of these NLRI will learn the IP addresses of the other PE routers which have pools switches with the same color. It also learns the unique identifier of each such remote pool, as this is encoded in the NLRI. The remote pool's relative identifier can be extracted from the NLRI and used in the signaling, as specified below. 5.3 VPLS In order to use BGP-based auto-discovery for VPLS-based VPNs where discovery and signaling are separate components such as [VPLS-LDP] solutions, the globally unique identifier associated with a VPLS must be encodable as an 8-byte Route Distinguisher (RD). If the globally unique identifier for a VPLS is an RFC2685 VPN-id, it can be encoded as an RD as specified in section 4.2.1.1. However, any other method of assigning a unique identifier to a VPLS and encoding it as an RD (using the encoding techniques of [BGP/MPLS-IP-VPN]) will do. Each VSI needs to have a unique identifier, which can be encoded as a BGP NLRI. This is formed by prepending the RD (from the previous paragraph) to an IP address of the PE containing the virtual LAN switch (VSI). Note that it is not strictly necessary for all the VSIs in the same VPLS to have the same RD, all that is really necessary is that the NLRI uniquely identify a virtual LAN switch. Each VSI needs to be associated with one or more Route Target (RT) Extended Communities. These control the distribution of the NLRI, and hence will control the formation of the overlay topology of pseudowires that constitutes a particular VPLS. Auto-discovery proceeds by having each PE distribute, via BGP, the NLRI for each of its VSIs, with itself as the BGP next hop, and with the appropriate RT for each such NLRI. Typically, each PE would be a client of a small set of BGP route reflectors, which would redistribute this information to the other clients. If a PE has a VSI with a particular RT, it can then receive all the NLRI which have that same RT, and from the BGP next hop attribute of these NLRI will learn the IP addresses of the other PE routers which have VSIs with the same RT. If a particular VPLS is meant to be a single fully connected LAN, all its VSIs will have the same RT, in which case the RT could be (though it need not be) an encoding of the VPN-id. If a particular VPLS consists of multiple VLANs, each VLAN must have its own unique RT. A VSI can be placed in multiple VLANS (or even in multiple VPLSes) by assigning it multiple RTs. Note that hierarchical VPLS can be set up by assigning multiple RTs to some of the virtual LAN switches; the RT mechanism allows one to Ould-Brahim & Rosen & Rekhter February 2005 [Page 7] Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 have complete control over the pseudowire overlay which constitutes the VPLS topology. 5.3.1 VPLS using BGP as a signaling Mechanism The interpretation of VPN information for VPLS services using BGP as the signaling component is described in [VPLS-BGP]. Note that this solution complies with procedures described in section 3.2. 6. Tunnel Discovery Layer-3 VPNs and Layer-2 VPNs must be implemented through some form of tunneling mechanism, where the packet formats and/or the addressing used within the VPN can be unrelated to that used to route the tunneled packets across the backbone. There are numerous tunneling mechanisms that can be used by a network based VPN (e.g., IP/IP [RFC-2003], GRE tunnels [RFC-1701], IPSec [RFC-2401], and MPLS tunnels [RFC-3031]). Each of these tunnels allows for opaque transport of frames as packet payload across the backbone, with forwarding disjoint from the address fields of the encapsulated packets. A provider edge router may terminate multiple types of tunnels and forward packets between these tunnels and other network interfaces in different ways. BGP can be used to carry tunnel endpoint addresses between edge routers. For scalability purposes, this draft recommends the use of tunneling mechanisms with demultiplexing capabilities such as IPSec, MPLS, and GRE (with respect to using GRE -the key field, it is no different than just MPLS over GRE, however there is no specification on how to exchange the key field, while there is a specification and implementations on how to exchange the label). Note that IP in IP doesn't have demultiplexing capabilities. The BGP next hop will carry the service provider tunnel endpoint address. As an example, if IPSec is used as tunneling mechanism, the IPSec tunnel remote address will be discovered through BGP, and the actual tunnel establishment is achieved through IPSec signaling protocol. When MPLS tunneling is used, the label carried in the NLRI field is associated with an address of a VR, where the address is carried in the NLRI and is encoded as a VPN-IP address. The auto-discovery mechanism should convey minimum information for the tunnels to be setup. The means of distributing multiplexors must be defined either via some sort of tunnel-protocol-specific signaling mechanism, or via additional information carried by the auto-discovery protocol. That information may or may not be used directly within the specific signaling protocol. On one end of the spectrum, the combination of IP address (such as BGP next hop and IP address carried within the NLRI) and the label and/or VPN-ID Ould-Brahim & Rosen & Rekhter February 2005 [Page 8] Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 provides sufficient information for a PE to setup per VPN tunnels or shared tunnels per set of VPNs. On another end of the spectrum additional specific tunnel related information can be carried within the discovery process if needed. 7. Scalability Considerations In this section, we briefly summarize the main characteristics of our model with respect to scalability. Recall that the Service Provider network consists of (a) PE routers, (b) BGP Route Reflectors, (c) P routers (which are neither PE routers nor Route Reflectors), and, in the case of multi-provider VPNs, (d) ASBRs. A PE router, unless it is a Route Reflector should not retain VPN-related information unless it has at least one VPN with an Import Target identical to one of the VPN-related information Route Target attributes. Inbound filtering should be used to cause such information to be discarded. If a new Import Target is later added to one of the PE's VPNs (a "VPN Join" operation), it must then acquire the VPN-related information it may previously have discarded. This can be done using the refresh mechanism described in [BGP- RFSH]. The outbound route filtering mechanism of [BGP-ORF], [BGP-CONS] can also be used to advantage to make the filtering more dynamic. Similarly, if a particular Import Target is no longer present in any of a PE's VPNs (as a result of one or more "VPN Prune" operations), the PE may discard all VPN-related information which, as a result, no longer have any of the PE's VPN's Import Targets as one of their Route Target Attributes. Note that VPN Join and Prune operations are non-disruptive, and do not require any BGP connections to be brought down, as long as the refresh mechanism of [BGP-RFSH] is used. As a result of these distribution rules, no one PE ever needs to maintain all routes for all VPNs; this is an important scalability consideration. Route reflectors can be partitioned among VPNs so that each partition carries routes for only a subset of the VPNs supported by the Service Provider. Thus no single route reflector is required to maintain VPN-related information for all VPNs. For inter-provider VPNs, if multi-hop EBGP is used, then the ASBRs need not maintain and distribute VPN-related information at all. Ould-Brahim & Rosen & Rekhter February 2005 [Page 9] Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 P routers do not maintain any VPN-related information. In order to properly forward VPN traffic, the P routers need only maintain routes to the PE routers and the ASBRs. As a result, no single component within the Service Provider network has to maintain all the VPN-related information for all the VPNs. So the total capacity of the network to support increasing numbers of VPNs is not limited by the capacity of any individual component. An important consideration to remember is that one may have any number of INDEPENDENT BGP systems carrying VPN-related information. This is unlike the case of the Internet, where the Internet BGP system must carry all the Internet routes. Thus one significant (but perhaps subtle) distinction between the use of BGP for the Internet routing and the use of BGP for distributing VPN-related information, as described in this document is that the former is not amenable to partition, while the latter is. 8. Security Considerations This document describes a BGP-based auto-discovery mechanism which enables a PE router that attaches to a particular VPN to discover the set of other PE routers that attach to the same VPN. Each PE router that is attached to a given VPN uses BGP to advertise that fact. Other PE routers which attach to the same VPN receive these BGP advertisements. This allows that set of PE routers to discover each other. Note that a PE will not always receive these advertisements directly from the remote PEs; the advertisements may be received from "intermediate" BGP speakers. It is of critical importance that a particular PE should not be "discovered" to be attached to a particular VPN unless that PE really is attached to that VPN, and indeed is properly authorized to be attached to that VPN. If any arbitrary node on the Internet could start sending these BGP advertisements, and if those advertisements were able to reach the PE routers, and if the PE routers accepted those advertisements, then anyone could add any site to any VPN. Thus the auto-discovery procedures described here presuppose that a particular PE trusts its BGP peers to be who they appear to be, and further that it can trusts those peers to be properly securing their local attachments. (That is, a PE must trust that its peers are attached to, and are authorized to be attached to, the VPNs to which they claim to be attached.). If a particular remote PE is a BGP peer of the local PE, then the BGP authentication procedures of RFC 2385 can be used to ensure that the remote PE is who it claims to be, i.e., that it is a PE that is trusted. Ould-Brahim & Rosen & Rekhter February 2005 [Page 10] Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 If a particular remote PE is not a BGP peer of the local PE, then the information it is advertising is being distributed to the local PE through a chain of BGP speakers. The local PE must trust that its peers only accept information from peers that they trust in turn, and this trust relation must be transitive. BGP does not provide a way to determine that any particular piece of received information originated from a BGP speaker that was authorized to advertise that particular piece of information. Hence the procedures of this document should be used only in environments where adequate trust relationships exist among the BGP speakers. Some of the VPN schemes which may use the procedures of this document can be made robust to failures of these trust relationships. That is, it may be possible to keep the VPNs secure even if the auto-discovery procedures are not secure. For example, a VPN based on the VR model can use IPsec tunnels for transmitting data and routing control packets between PE routers. An illegitimate PE router which is discovered via BGP will not have the shared secret which makes it possible to set up the IPsec tunnel, and so will not be able to join the VPN. Similarly, [IPSEC-2547] describes procedures for using IPsec tunnels to secure VPNs based on the BGP/MPLS-IP-VPN model. The details for using IPsec to secure a particular sort of VPN depend on that sort of VPN and so are out of scope of the current document. 9. IANA Considerations 9.1 IANA Considerations for L2VPNs New AFI value to be assigned by IANA to indicate that the NLRI is carrying VPN-L2 Address as described in section 3.2. New SAFI number is required for single-sided Point-to-point L2VPN solutions. New SAFI number for Colored pools L2VPNs New SAFI number for VPLS-based L2VPNs solutions using LDP-based signalling. 9.2 IANA Considerations for VR-based L3VPNs SAFI number "129" for indicating that the NLRI is carrying information for VR-based solution. SAFI number "140" for indicating that the NLRI is carrying information for VR for non-labeled prefixes. New Extended Community to be assigned by IANA and used for Topology values for VR-based L3VPN solution see section 4.2.2. Ould-Brahim & Rosen & Rekhter February 2005 [Page 11] Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 New Extended Community to be assigned by IANA for carrying VPN-ID format based on RFC2685 format (see section 4.2.1.2) 10. Use of BGP Capability Advertisement A BGP speaker that uses VPN information as described in this document with multiprotocol extensions should use the Capability Advertisement procedures [RFC-3392] to determine whether the speaker could use Multiprotocol Extensions with a particular peer. 11. Acknowledgement The authors would like to acknowledge Benson Schliesser, and Thomas Narten for the constructive and fruitful comments. 12. Normative References [BGP-COMM] Ramachandra, Tappan, et al., "BGP Extended Communities Attribute", June 2001, work in progress [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions for BGP4", February 1998, RFC 2283 [RFC-3107] Rekhter Y, Rosen E., "Carrying Label Information in BGP4", January 2000, RFC3107 [BGP/MPLS-IP-VPN] Rosen E., et al, "BGP/MPLS VPNs", Work in Progress. [RFC-2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. [RFC-3392] Chandra, R., et al., "Capabilities Advertisement with BGP-4", RFC3392, May 2002. [VPN-VR] Knight, P., Ould-Brahim H., Gleeson, B., "Network based IP VPN Architecture using Virtual Routers", Work in Progress. 13. Informative References [L2VPN-ROSEN] Rosen, E., Radoaca, V., "Provisioning Models and Endpoint Identifiers in L2VPN Signaling", Work in Progress. [VPLS-BGP] Kompella, K., et al., "Virtual Private LAN Service", Work in Progress. [VPLS-LDP] Kompella, V., Lasserre, M., et al., "Virtual Private LAN Services over MPLS", Work in Progress. Ould-Brahim & Rosen & Rekhter February 2005 [Page 12] Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 [RFC-1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC2003, October 1996. [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC2026, October 1996. [RFC-2401] Kent S., Atkinson R., "Security Architecture for the Internet Protocol", RFC2401, November 1998. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [TLS-TISSA] "BGP/MPLS Layer-2 VPN", draft-tsenevir-bgpl2vpn-01.txt, work in progress, July 2001. [IPSEC-2547] Rosen, E., et al., "Use of PE-PE IPsec in RFC2547 VPNs", Work in Progress. [BGP-RFSH] Chen, A., "Route Refresh Capability for BGP-4", RFC2918, September 2000. [BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering Capability for BGP-4", Work in Progress. [BGP-CONS] Marques, P., et al., "Constrained VPN route distribution" work in progress, draft-ietf-l3vpn-rt-constrain-01.txt 14. Annex: Auto-Discovery in VR and MPLS-IP-VPN Interworking Scenarios Two interwoking scenarios are considered when the network is using both virtual routers and BGP/MPLS-IP-VPN. The first scenario is a CE-PE relationship between a PE (implementing BGP/MPLS-IP-VPN), and a VR appearing as a CE to the PE. The connection between the VR, and the PE can be either direct connectivity, or through a tunnel (e.g., IPSec). The second scenario is when a PE is implementing both architectures. In this particular case, a single BGP session configured on the service provider network can be used to advertise either BGP/MPLS- IP-VPN VPN information or the virtual router related VPN information. From the VR and the BGP/MPLS-IP-VPN point of view there is complete separation from data path and addressing schemes. However the PE's interfaces are shared between both architectures. A PE implementing only BGP/MPLS-IP-VPN will not import routes from a BGP UPDATE message containing the VPN-ID extended community. On the other hand, a PE implementing the virtual router architecture will not import routes from a BGP UPDATE message containing the route target extended community attribute. Ould-Brahim & Rosen & Rekhter February 2005 [Page 13] Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 The granularity at which the information is either BGP/MPLS-IP-VPN related or VR-related is per BGP UPDATE message. Different SAFI numbers are used to indicate that the message carried in BGP multiprotocol extension attributes is to be handled by the VR or BGP/MPLS-IP-VPN architectures. SAFI number of 128 is used for BGP/MPLS-IP-VPN related format. A value of 129 for the SAFI number is for the virtual router (where the NLRI are carrying a labeled prefixes), and a SAFI value of 140 is for non labeled addresses. 15. Contributors Bryan Gleeson Tahoe Networks 3052 Orchard Drive San Jose, CA 95134 USA Email: bryan@tahoenetworks.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 Luyuan Fang AT&T 200 Laurel Avenue Middletown, NJ 07748 Email: Luyuanfang@att.com Phone: +1 (732) 420 1920 Jeremy De Clercq Alcatel Francis Wellesplein 1 B-2018 Antwerpen, Belgium Phone: +32 3 240 47 52 Email: jeremy.de_clercq@alcatel.be Riad Hartani Caspian Networks 170 Baytech Drive San Jose, CA 95143 Phone: 408 382 5216 Email: riad@caspiannetworks.com Tissa Senevirathne Force10 Networks Ould-Brahim & Rosen & Rekhter February 2005 [Page 14] draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 1440 McCarthy Blvd, Milpitas, CA 95035. Phone: 408-965-5103 Email: tsenevir@hotmail.com 17. Authors Information Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7, Canada Email: hbrahim@nortelnetworks.com Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 E-mail: erosen@cisco.com Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 Email: yakov@juniper.net Ould-Brahim & Rosen & Rekhter February 2005 [Page 15] draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Ould-Brahim & Rosen & Rekhter February 2005 [Page 16] CCAMP WG Hamid Ould-Brahim Internet Draft Nortel Networks Expiration Date: August 2005 Yakov Rekhter Juniper Networks (Editors) February 2005 GVPN Services: Generalized VPN Services using BGP and GMPLS Toolkit draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 This draft describes a suite of port-based Provider-provisioned VPN services called Generalized VPNs (GVPNs) that uses BGP as a VPN auto-discovery and GMPLS as a signaling mechanism. GVPN Ould-Brahim, Rekhter November 2004 [Page 1] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 services are "generalized" as the interfaces on the customerÆs and provider ports could be any of the interfaces supported by Generalized MPLS (GMPLS). GVPN services outlined in this document are: (1) a port-based Generalized Virtual Private Wire (GVPW) where the basic unit of service is a Label Switched Path (LSP) between a pair of customerÆs ports within a given VPN port-topology. (2) a Generalized Virtual Private Cross-connect (GVPXC) service where the service provider network appears to the customer network as a GMPLS-enabled Virtual Private node. A GVPXC service provides flexible traffic engineering on the client network and eliminates the need for n square routing peering between CEs. Since GVPNs uses GMPLS as the signaling mechanism, and since GMPLS applies to both TDM and Optical interfaces, it results that GVPN services include L1VPNs:Optical/TDM VPNs (though they need not be restricted to). Original Contributors of the initial versions of this document: Hamid Ould-Brahim (Nortel) Yakov Rekhter (Juniper) Luyuan Fang (AT&T) Don Fedyk (Nortel) Peter Ashwood-Smith (Nortel) Eric C. Rosen (Cisco) Eric Mannie (KPN Qwest) John Drake (Boing) Yong Xue (Worldcomm/UUNET) Riad Hartani (Caspian Networks) Dimitri Papadimitrio (Alcatel) Lou Berger (Movaz) 1. Generalized VPN Services Consider a service provider network that consists of devices that supports Generalized MPLS (e.g., Optical Cross Connect, SDH Cross Connect, etcà). 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. February 2005 [Page 2] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 +---+ +---+ | P | | P | +---+ +---+ PE / \ PE +-----+ +-----+ +--+ | | | |----| | +--+ | | | | |CE| |CE|----+-----+ | |----| | +--+\ | | | +--+ \ +-----+ | | \ | | | | +--+ \| | | |----|CE| +-----+ +-----+ +--+ \ / +---+ +---+ | P |....| P | +---+ +---+ Figure 1: Generalized Port-Based VPN Reference Model We define a "Generalized VPN" service as a Provider-provisioned VPN service that uses BGP as a VPN auto-discovery and GMPLS as a signaling and routing mechanisms. GVPN services are "generalized" as the interfaces on the customerÆs and provider ports could be any of the interfaces supported by Generalized MPLS (GMPLS). Since GVPN uses GMPLS as the signaling mechanism, and since GMPLS applies to both TDM and Optical interfaces, it results that GVPN services includes Optical/TDM VPNs (though they need not be restricted to). Note that this draft assumes that (1) GMPLS is used as a signaling both within the service provider, as well as between the customer and the service provider; (2) GMPLS is used not just as a signaling mechanism, but as a routing mechanism within the provider network and for services such as generalized virtual private cross-connect. 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 Ould-Brahim & Rekhter. February 2005 [Page 3] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 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 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]. 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. This document assumes that the interface between the CE and PE used for the purpose of signaling is based on GMPLS protocols [GMPLS-RSVP-TE] and follows the procedures described in [GMPLS- OVERLAY]. 1.1 Addressing, Ports, Links, and Control Channels Ould-Brahim & Rekhter. February 2005 [Page 4] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 This document assumes that within a given GVPN each port on a CE that connects the CE to a PE 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), and then use a tuple as a port identifier within the provider network. 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. 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 . Ould-Brahim & Rekhter. February 2005 [Page 5] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 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. This document assumes also 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. An important goal of GVPN services (particularly with respect to GVPW and GVPXC services - see sections below) 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 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. 2. Port-based Generalized Virtual Private Wire (GVPW) A Generalized Virtual Private Wire (GVPW) is a port-based VPN service where a pair of CEs could be connected through the service provider network via a GMPLS-based LSP within a given VPN port topology. It is precisely this LSP that forms Ould-Brahim & Rekhter. February 2005 [Page 6] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 the basic unit of the GVPW 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. 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/toolkit 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. A PE maintains for each GVPW configured on that PE a port information tables (PIT) associated with each GVPW that has at least one port configured on a PE. A PIT contains a list of tuples for all the ports within its GVPN. Note that a PIT may as well hold routing information (for example when CPIs are learnt using a routing protocol). 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 Virtual Private Wire 2.1 VPN Auto-discovery Mechanism This document assumes a BGP-based auto-discovery for supporting GVPW services. Ould-Brahim & Rekhter. February 2005 [Page 7] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 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 (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. 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). Ould-Brahim & Rekhter. February 2005 [Page 8] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 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. 2.1.1 Encoding of CPI, PPI, and channel characteristics 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: Ould-Brahim & Rekhter. February 2005 [Page 9] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 +---------------------------------------+ | Length (1 octet) | +---------------------------------------+ | PPI AFI (2 octets) | +---------------------------------------+ | PPI Length (1 octet) | +---------------------------------------+ | PPI (variable) | +---------------------------------------+ | CPI AFI (2 octets) | +---------------------------------------+ | CPI (length) | +---------------------------------------+ | CPI (variable) | +---------------------------------------+ 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): Ould-Brahim & Rekhter. February 2005 [Page 10] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 A variable length field that contains the CPI value (either an address or tuple. 2.2 Signaling 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, to request the provider network to establish an LSP to a target port. For inter-CE connectivity, 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. 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 Ould-Brahim & Rekhter. February 2005 [Page 11] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 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 the appropriate CPIs, and then sends the Path message to the CE that has the target port. 2.3 GVPW Routing Considerations It is also desirable, that the service provider, as a value added service, may provide to a GVPW-based CE with a list of ports on all other CEs that belong to the same VPN. 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. 3. Generalized Virtual Private Cross-Connect (GVPXC) A GVPXC is a GVPN service where the service provider network appears as a virtual private cross-connect. A GVPXC operates similarly to a physical optical cross-connect except that it applies to GMPLS-based interfaces and allows a wide spectrum of port topology such as hub and spoke, full mesh, and arbitrary topologies. The GVPXC port topology is defined by the customer, and enforced by the service provider. Customers can signal any inter-port connectivity according to the topology implemented by Ould-Brahim & Rekhter. February 2005 [Page 12] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 the VPOXC. Client devices operate within the VPOXC space independently from the service provider network operations. GVPXC +-------------------------------+ | +---+ +---+ | | | P |....| P | | | +---+ +---+ | | PE / \ PE | | +-----+ +-----+ | +--+ | | | | |-|--| | +--+ | | | | | | |CE| |CE|--|-+-----+ | |-|--| | +--+\ | | | | | +--+ \| +-----+ | | | | | | | | | +--+ |\| | | |-|--|CE| | +-----+ +-----+ | +--+ | \ / | | +---+ +---+ | | | P |....| P | | | +---+ +---+ | | | +-------------------------------+ Figure 4: GVPXC Reference Model The bandwidth associated with each GVPXC depends on the access bandwidth of each CE to the GVPXC and the port topology implemented within the GVPXC. As sites are added or removed to the GVPXC, the total GVPXC bandwidth is accordingly adjusted. The basic unit of the GVPXC service is a GMPLS LSP between a port on one CE and a port on another CE crossing the GVPXC node. In the case of TDM LSP, 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 GVPXC. The number of ports depends on the concatenation capabilities of these interfaces keeping in mind that when provided, virtual concatenation does not constraint the GVPXC 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. A GVPXC port can be moved to another PE port (or even to another PE) without changing the GVPXC addressing used by the customer to request connectivity. Addition/Deletion/Changes of the VPOXC port addresses requires no coordination with the service provider addressing scheme. GVPXC may be used by a customer to exchange customerÆs GMPLS routing information related to the customerÆs network, as from customerÆs point of Ould-Brahim & Rekhter. February 2005 [Page 13] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 view (and specifically from customerÆs routing/signaling point of view) the service appears as a single GMPLS-capable node. 3.1 GVPXC Routing Considerations From a customerÆs point of view a GVPXC can be deployed in one of the two deployment scenarios: a) with off-line path computation or b) with on-line path computation In off-line path computation mode, an off-line tool is used by the customer to compute paths for all LSPs that cross the GVPXC node. Each node within the private network is provided with the outcome of computation for the LSP that cross the GVPXC and are originated by the node. On-line path computation assumes that the GVPXC node participates in the GMPLS routing with customerÆs network , or to be more precise, participates in flooding GMPLS routing information of the client to whom that node belongs. GVPXC-A +-----------------------------------------+ | PE1 PE2 | | +-----------+ +-----------+ | +-----+ VPN-LSP| | | | | +-----+ |CE1-A|<--------->+------+ GVSI-LSP | +------+ | | |CE2-A| +-----+ | | |GVSI-A| |<---------->| |GVSI-A|<---->+-----+ | | +------+ | | +------+ | | +-----------------------------------------+ | | | | | | GVPXC-B | | +-----------------------------------------+ +-----+ VPN-LSP| +------+ | | +------+ | | +-----+ |CE1-B|<--------->|GVSI-B| | GVSI-LSP | |GVSI-B|<---->|CE2-B| +-----+ | | +------+ |<---------->| +------+ | | +-----+ | | | | | | | +-----------+ +-----------+ | | | +-----------------------------------------+ Figure 5: Anatomy of the GVPXC In order for the GVPXC to participate in GMPLS routing with the customerÆs network, the GVPXC needs to a) establish a routing adjacency with attached CEs, b) generate routing information with traffic engineering (TE) information for the set of CE-PE TE-links attached to the GVPXC, and c) floods TE-Link routing information (such as the ones learnt from other customerÆs network nodes) to the attached CEs using normal GMPLS routing procedures. Ould-Brahim & Rekhter. February 2005 [Page 14] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 To accomplish the above steps, each PE maintains for each GVPXC service VPN information tables. We refer to such information as Generalized Virtual Switching Instance (GVSI). A GVSI can be viewed as a combination of GVPXC Routing and Forwarding tables and GVPXC Port information Table. GVSIs associated with one GVPXC are inter-connected by tunnel-based control channels. One realization of the control channel between a pair of GVSI is to use an IP/MPLS-based tunnels where plain private IGP adjacency can be established. Note that such adjacency is only used for distributing customer's routing information among the GVSIs. When receiving routing updates from the CE neighbors, the PE (or more precisely the GVSI configured on that PE) updates its IGP database and propagates the updates to other GVSIs using basic IGP procedures across the tunnel-based control-channels. The approach for distributing private reachability is similar to the virtual router approach used in layer-3 VPNs with the exception that a) the tunnel-based control channels are not visible to the CE and b) since the GVPXC represents a virtual node, the GVSIs will advertise VPN routing updates with the same GVPXC ROUTER_ID. 3.2 Auto-Discovery VPN auto-discovery procedures described in [BGP-VPN-AUTO- DISCOVERY] are used to enable the PEs to determine which GVSIs are in the same GVPXC. Once the GVSIs are reachable through the control-based tunnels, private routes are then exchanged by running an instance of routing protocol per pair of GVSIs basis. Carrying GVSIs information in BGP-MP is done as follows. The NLRI address prefix is an address of one of the GVSIs configured on the PE. BGP Route target extended community is used to constrain route distribution between PEs (GVSIs). The BGP Next hop carries the service provider control-channel tunnel endpoint address which is in the service provider addressing space. In addition to GVSI related information, NLRI will also carry the tuples as described in section 2.1.1.1. This information is used to establish end to end LSP between CEs across the GVPXC node (see section below). 3.3 Signaling An LSP initiated within the VPN domain may contain a path that crosses the GVPXC node. We refer to the LSP that crosses the GVPXC node as a VPN-LSP. The creation/termination of a VPN-LSP could be driven either by mechanisms outside of GMPLS (e.g., via configuration control on the CE), or by mechanisms within Ould-Brahim & Rekhter. February 2005 [Page 15] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 GMPLS (e.g., as a result of the CE at the head-end of the VPN- LSP receiving LSP setup requests originated by some other LSRs within the VPN space). A CE may decide to use the VPN-LSP as a forwarding Adjacency (FA) using procedures described in [LSP-HIERARCHY], and announces this LSP as a Traffic Engineering (TE) link into the same instance of the CE GMPLS control plane (or more precisely CE ISIS/OSPF component) as the one that was used to create the VPN-LSP. In this case, ISIS/OSPF floods the information about VPN-LSP just as it floods the information about any other links. As a result of this flooding, an LSR within the VPN has in its TE link state database the information about not just basic TE links (from other nodes including GVPXC TE-links), but VPN-LSPs as well. In order to establish the VPN-LSPs, the GVSIs/PEs are inter- connected at the data-plane level through GMPLS-based LSPs. We refer to such LSPs as GVSI-LSPs (see figure 5). A GVSI-LSP is either pre-configured or constructed dynamically as a result of a PE receiving a VPN-LSP PATH message. A given GVSI-LSP may map exactly to one VPN-LSP or to many VPN-LSPs. When a GVSI-LSP is created dynamically, its attributes are inherited from the VPN-LSP, which induced its creation and from the information maintained in the port information table associated with the GVSI using procedures described in [LSP-HIERARCHY]. And for provisioned GVSI-LSPs, a policy-based mechanism may be needed to associate attributes to the GVSI-LSPs. Note that GVSI-LSP can be used as FA within the provider network. Note that the bandwidth of the GVSI-LSP must be at least as big as the LSP that induced it, but may be bigger if only discrete bandwidths are available for the GVSI-LSP. Upon receiving the VPN-LSP PATH message, the ingress PE must then determine the egress PE using the GVSI IGP database and the PIT table or just the PIT table (in case the ERO contains already the destination CPI corresponding to an existing entry in the PIT table)The PE then tries to find an existing GVSI-LSP between the ingress PE and the egress PE . If a match is found, where the GVSI-LSP has enough unreserved bandwidth for the VPN-LSP being signaled, and the G-PID of the GVSI-LSP is compatible with the G-PID of the VPN-LSP being signaled, the PE uses that GVSI-LSP. Otherwise (if no existing GVSI-LSP is found), the PE sets up a new GVSI-LSP. That is, it initiates a new LSP setup just for the GVSI-LSP. Once the GVSI-LSP is established, the PE encapsulates the original VPN-LSP PATH message in an IP tunnel, and unicasts the message to the tail end of the GVSI-LSP. Ould-Brahim & Rekhter. February 2005 [Page 16] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 The Path message for the original VPN-LSP MUST contain an IF_ID RSVP_HOP object instead of an RSVP_HOP object; and the data interface identification MUST identify the GVSI-LSP. The ingress PE adjusts the ERO of the VPN-LSP path message and sends it to the egress PE of the GVSI-LSP, not to the next hop along the GVSI-LSP's path. The egress PE will process the VPN-LSP using normal GMPLS signaling procedures and sends it to the egress CE. VPN-LSPs are then nested across the GVSI-LSPs. 4. Others Issues o 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 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/mechanisms 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 (GVSI), 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. o 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 Ould-Brahim & Rekhter. February 2005 [Page 17] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 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 in this draft. o Multiple Routing Domains 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. o Addressing 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. o GVPNs and Layer-2/3 VPNs 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). 5. Security Considerations Ould-Brahim & Rekhter. February 2005 [Page 18] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 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. 6. References [BGP-VPN-AUTODISCOVERY] Ould-Brahim, H., Rosen, E., Rekhter, Y., "Using BGP as an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs", draft-ietf-l3vpn-bgpvpn-auto-05.txt, work in progress [GMPLS-SIGNALING] Berger, L. (editor), "Generalized MPLS - Signaling Functional Description", January 2003, RFC3471. [GMPLS-RSVP-TE] Berger, L. (editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC3473, January 2003. [GMPLS-ROUTING] Kompella, K., Rekhter, Y., "Routing Extensions in Support of Generalized MPLS", work in progress [GMPLS-HIERARCHY] Kompella, K., Rekhter, Y., "LSP Hierarchy with Generalized MPLS TE", 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. [GMPLS-OVERLAY] Swallow, G., et al., "GMPLS RSVP Support for the Overlay Model", work in progress. 7. 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 Ould-Brahim & Rekhter. February 2005 [Page 19] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 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 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 Ould-Brahim & Rekhter. August 2005 [Page 20] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 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. August 2005 [Page 21] draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of and Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Ould-Brahim & Rekhter. August 2005 [Page 22]