| TOC |
|
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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on January 4, 2009.
RFC 4364 and RFC 4659 define an approach to building provider-provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to use RSVP to perform admission control on the links between CE and PE routers. This document specifies procedures by which RSVP messages travelling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
[Note to RFC Editor: This section to be removed before publication]
Changes in this version (draft-ietf-tsvwg-rsvp-l3vpn-00) relative to the last (draft-davie-tsvwg-rsvp-l3vpn-02):
1.
Introduction
1.1.
Terminology
2.
Problem Statement
2.1.
Model of Operation
3.
Admission Control on PE-CE Links
3.1.
Path Message Processing at Ingress PE
3.2.
Path Message Processing at Egress PE
3.3.
Resv Processing at Egress PE
3.4.
Resv Processing at Ingress PE
3.5.
Other RSVP Messages
4.
Admission Control in Provider's Backbone
5.
Inter-AS operation
5.1.
Inter-AS Option A
5.2.
Inter-AS Option B
5.2.1.
Admission control on ASBR
5.2.2.
No admission control on ASBR
5.3.
Inter-AS Option C
6.
Operation with RSVP disabled
7.
Other RSVP procedures
7.1.
Refresh overhead reduction
7.2.
Cryptographic Authentication
7.3.
RSVP Aggregation
7.4.
Support for CE-CE RSVP-TE
8.
Object Definitions
8.1.
VPN-IPv4 and VPN-IPv6 SESSION objects
8.2.
VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects
8.3.
VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects
8.4.
VPN-IPv4 and VPN-IPv6 RSVP_HOP objects
8.5.
Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects
8.6.
AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE objects
8.7.
AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC objects
9.
IANA Considerations
10.
Security Considerations
11.
Acknowledgments
Appendix A.
Alternatives Considered
Appendix A.1.
GMPLS UNI approach
Appendix A.2.
VRF label approach
Appendix A.3.
VRF label plus VRF address approach
12.
References
12.1.
Normative References
12.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
[RFC4364] (Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs),” February 2006.) and [RFC4659] (De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, “BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN,” September 2006.) define a Layer 3 VPN service known as BGP/MPLS VPNs for IPv4 and for IPv6 respectively. [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.) defines the Resource Reservation Protocol (RSVP) which may be used to perform admission control as part of the Integrated Services (int-serv) architecture [RFC1633] (Braden, B., Clark, D., and S. Shenker, “Integrated Services in the Internet Architecture: an Overview,” June 1994.)[RFC2210] (Wroclawski, J., “The Use of RSVP with IETF Integrated Services,” September 1997.).
Customers of a layer 3 VPN service may run RSVP for the purposes of admission control in their own networks. Since the links between Provider Edge (PE) and Customer Edge (CE) routers in a layer 3 VPN may often be resource constrained, it may be desirable to be able to perform admission control over those links. In order to perform admission control using RSVP in such an environment, it is necessary that RSVP control messages, such as Path messages and Resv messages, are appropriately handled by the PE routers. This presents a number of challenges in the context of BGP/MPLS VPNs:
This document describes a set of procedures to overcome these challenges and thus to enable admission control using RSVP over the PE-CE links. We note that similar techniques may be applicable to other protocols used for admission control such as NSIS [RFC4080] (Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, “Next Steps in Signaling (NSIS): Framework,” June 2005.).
Additionally, it may be desirable to perform admission control over the provider's backbone on behalf of one or more L3VPN customers. Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for customer routes, and thus cannot natively process RSVP messages for customer flows. Also the core is a shared resource that carries traffic for many customers, so issues of resource allocation among customers and trust (or lack thereof) must also be addressed. This draft also specifies procedures for supporting such a scenario.
This draft deals with establishing reservations for unicast flows only. Because the support of multicast traffic in BGP/MPLS VPNs is still evolving, and raises additional challenges for admission control, we leave the support of multicast flows for further study at this point.
| TOC |
This document draws freely on the terminology defined in [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.) and [RFC4364] (Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs),” February 2006.). For convenience, we provide a few brief definitions here:
| TOC |
The problem space of this document is the support of admission control between customer sites when the customer subscribes to a BGP/MPLS VPN. We subdivide the problem into (a) the problem of admission control on the PE-CE links (in both directions), and (b) the problem of admission control across the provider's backbone.
For the PE-CE link subproblem, the most basic challenge is that RSVP control messages contain IP addresses that are drawn from the customer's address space, and PEs must be able to deal with traffic from many customers who may have non-unique (or overlapping) address spaces. Thus, it is essential that a PE be able in all cases to identify the correct VPN context in which to process an RSVP control message. Much of this draft deals with this issue.
For the case of making reservations across the provider backbone, we observe that BGP/MPLS VPNs do not create any per-customer forwarding state in the P (provider core) routers. Thus, in order to make reservations on behalf of customer-specified flows, it is clearly necessary to make some sort of aggregated reservation from PE-PE and then map individual, customer-specific reservations onto an aggregate reservation. That is similar to the problem tackled in [RFC3175] (Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, “Aggregation of RSVP for IPv4 and IPv6 Reservations,” September 2001.) and [RFC4804] (Le Faucheur, F., “Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels,” February 2007.), with the additional complications of handling customer-specific addressing associated with BGP/MPLS VPNs.
Finally, we note that RSVP Path messages are normally addressed to the destination of a session, and contain the router alert IP option. Routers along the path to the destination that are configured to process RSVP messages must detect the presence of the router alert option to allow them to intercept Path messages. However, the egress PEs of a network supporting BGP/MPLS VPNs receive packets destined for customer sites as MPLS-encapsulated packets, and may forward those based only on examination of the MPLS label. Hence, a Path message would be forwarded without examination of the IP options and would therefore not receive appropriate processing at the PE. This problem of recognizing and processing Path messages is also discussed below.
| TOC |
Figure 1 illustrates the basic model of operation with which this document is concerned.
--------------------------
/ Provider \
|----| | Backbone | |----|
Sender->| CE1| |-----| |-----| |CE2 |->Receiver
| |--| | |---| |---| | |---| |
|----| | | | P | | P | | | |----|
| PE1 |---| |-----| |-----| PE2 |
| | | | | | | |
| | |---| |---| | |
|-----| |-----|
| |
\ /
--------------------------
Figure 1. Model of Operation for RSVP-based admission control over MPLS/BGP VPN
To establish a unidirectional reservation for a point-to-point flow from Sender to Receiver that takes account of resource availability on the CE-PE and PE-CE links only, the following steps must take place:
In each of the steps involving Resv messages (6 through 10) the node sending the Resv uses the previously established Path state to determine the "RSVP Previous Hop (PHOP)" and sends a Resv message to that address. We note that establishing that Path state correctly at PEs is one of the challenges posed by the BGP/MPLS environment.
| TOC |
In the following sections we trace through the steps outlined in Section 2.1 (Model of Operation) and expand on the details for those steps where standard RSVP procedures need to be extended or modified to support the BGP/MPLS VPN environment. For all the remaining steps described in the preceding section, standard RSVP processing rules apply.
All the procedures described below support both IPv4 and IPv6 addressing. In all cases where IPv4 is referenced, IPv6 can be substituted with identical procedures and results. Object definitions for both IPv4 and IPv6 are provided in Section 8 (Object Definitions).
| TOC |
When a Path message arrives at the ingress PE (step 3 of Section 2.1 (Model of Operation)) the PE needs to establish suitable Path state and forward the Path message on to the egress PE. In the following paragraphs we described the steps taken by the ingress PE.
The Path message is addressed to the eventual destination (the receiver at the remote customer site) and carries the IP Router Alert option, in accordance with [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.). The ingress PE must recognize the router alert, intercept these messages and process them as RSVP signalling messages.
As noted above, there is an issue in recognizing Path messages as they arrive at the egress PE (PE 2 in Figure 1). The approach defined here is to address the Path messages sent by the ingress PE directly to the egress PE, and send it without IP Router Alert; that is, rather than using the ultimate receiver's destination address as the destination address of the Path message, we use the loopback address of the egress PE as the destination address of the Path message. This approach has the advantage that it does not require any new data plane capabilities for the egress PE beyond those of a standard BGP/MPLS VPN PE. Details of the processing of this message at the egress PE are described below in Section 3.2 (Path Message Processing at Egress PE). The approach of addressing a Path message directly to an RSVP next hop (that may or may not be the next IP hop) is already used in other environments such as those of [RFC4206] (Kompella, K. and Y. Rekhter, “Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE),” October 2005.) and [RFC4804] (Le Faucheur, F., “Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels,” February 2007.).
For an RSVP Path message, the existing SESSION and SENDER_TEMPLATE objects can no longer uniquely identify a flow on VPN PE nodes. We propose a new format of SESSION and SENDER_TEMPLATE objects which contain a VPN-IPv4 format address. The ingress and egress PE nodes translate between the regular IPv4 addresses for messages to and from the CE, and VPN-IPv4 addresses for messages to and from PE routers.
The details of operation at the ingress PE are as follows. When the ingress PE (PE1 in Figure 1) receives a Path message from CE1 that is addressed to the receiver, the VRF that is associated with the incoming interface is identified, just as for normal data path operations. The Path state for the session is stored, and is associated with that VRF, so that potentially overlapping addresses among different VPNs do not appear to belong to the same session. The destination address of the receiver is looked up in the appropriate VRF, and the BGP Next-Hop for that destination is identified. That next-hop is the egress PE (PE2 in Figure 1). A new VPN-IPv4 SESSION object is constructed, containing the Route Distinguisher (RD) that is part of the VPN-IPv4 route prefix for this destination, and the IPv4 address from the SESSION. In addition, a new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the original IPv4 address from the incoming SENDER_TEMPLATE plus the RD that is used by this PE to advertise that prefix for this customer into the VPN. A new Path message is constructed with a destination address equal to the address of the egress PE identified above. This new Path message will contain all the objects from the original Path message, replacing the original SESSION and SENDER_TEMPLATE objects with the new VPN-IPv4 type objects. The RSVP_HOP object in the Path message contains an IP address of the ingress PE. The Path message is sent without IP Router Alert.
| TOC |
When a Path message arrives at the egress PE, it is addressed to the PE itself, and is handed to RSVP for processing. The router extracts the RD and IPv4 address from the VPN-IPv4 SESSION object, and determines the local VRF context by finding a matching VPN-IPv4 prefix with the specified RD that has been advertised by this router into BGP. The entire incoming RSVP message, including the VRF information, is stored as part of the Path state.
Now the RSVP module can construct a Path message which differs from the Path it received in the following ways:
- a.
- Its destination address is the IP address extracted from the SESSION Object;
- b.
- The SESSION and SENDER_TEMPLATE objects are converted back to IPv4-type by discarding the attached RD
- c.
- The RSVP_HOP Object contains the IP address of the outgoing interface of the egress PE and an LIH, as per normal RSVP processing.
The router then sends the Path message on towards its destination over the interface identified above. This Path message carries the IP Router-Alert option as required by [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.).
| TOC |
When a receiver at the customer site originates a Resv message for the session, normal RSVP procedures apply until the Resv, making its way back towards the sender, arrives at the "egress" PE (it is "egress" with respect to the direction of data flow, i.e. PE2 in figure 1). On arriving at PE2, the SESSION and FILTER_SPEC objects in the Resv, and the VRF in which the Resv was received, are used to find the matching Path state stored previously. At this stage, admission control can be performed on the PE-CE link.
Assuming admission control is successful, the PE constructs a Resv message to send to the RSVP HOP stored in the Path state, i.e., the ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced with the same VPN-IPv4 SESSION object received in the Path. The IPv4 FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object, which copies the VPN-IPv4 address from the SENDER_TEMPLATE received in the matching Path message. The RSVP_HOP in the Resv message contains an IP address of the Egress PE that is reachable by the ingress PE. The Resv message is sent to the IP address contained within the RSVP_HOP object in the Path message.
If admission control is not successful on the egress PE, a ResvError message is sent towards the receiver as per normal RSVP processing.
| TOC |
Upon receiving a Resv message at the ingress PE (with respect to data flow, i.e. PE1 in Figure 1), the PE determines the local VRF context and associated Path state for this Resv by decoding the received SESSION and FILTER_SPEC objects. It is now possible to generate a Resv message to send to the appropriate CE. The Resv message sent to the ingress CE will contain IPv4 SESSION and FILTER_SPEC objects, derived from the appropriate Path state. Since we assume in this section that admission control over the Provider’s backbone is not needed, the ingress PE does not perform any admission control for this reservation.
| TOC |
Processing of PathError, PathTear, ResvError, ResvTear and ResvConf messages is generally straightforward and follows the rules of [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.). These additional rules must be observed for messages transmitted within the VPN (i.e. between the PEs):
| TOC |
The preceding section outlines how per-customer reservations can be made over the PE-CE links. This may be sufficient in many situations where the backbone is well engineered with ample capacity and there is no need to perform any sort of admission control in the backbone. However, in some cases where excess capacity cannot be relied upon (e.g., during failures or unanticipated periods of overload) it may be desirable to be able to perform admission control in the backbone on behalf of customer traffic.
Because of the fact that routes to customer addresses are not present in the P routers, along with the concerns of scalability that would arise if per-customer reservations were allowed in the P routers, it is clearly necessary to map the per-customer reservations described in the preceding section onto some sort of aggregate reservations. Furthermore, customer data packets need to be tunneled across the provider backbone just as in normal BGP/MPLS VPN operation.
Given these considerations, a feasible way to achieve the objective of admission control in the backbone is to use the ideas described in [RFC4804] (Le Faucheur, F., “Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels,” February 2007.). MPLS-TE tunnels can be established between PEs as a means to perform aggregate admission control in the backbone.
An MPLS-TE tunnel from an ingress PE to an egress PE can be thought of as a virtual link of a certain capacity. The main change to the procedures described above is that when a Resv is received at the ingress PE, an admission control decision can be performed by checking whether sufficient capacity of that virtual link remains available to admit the new customer reservation. We note also that [RFC4804] (Le Faucheur, F., “Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels,” February 2007.) uses the IF_ID RSVP_HOP object to identify the tunnel across the backbone, rather than the simple RSVP_HOP object described in Section 3.1 (Path Message Processing at Ingress PE). The procedures of [RFC4804] (Le Faucheur, F., “Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels,” February 2007.) should be followed here as well.
To achieve effective admission control in the backbone, there needs to be some way to separate the data plane traffic that has a reservation from that which does not. We assume that packets that are subject to admission control on the core will be given a particular MPLS EXP value, and that no other packets will be allowed to enter the core with this value unless they have passed admission control. Some fraction of link resources will be allocated to queues on core links for packets bearing that EXP value, and the MPLS-TE tunnels will use that resource pool to make their constraint-based routing and admission control decisions. This is all consistent with the principles of aggregate RSVP reservations described in [RFC3175] (Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, “Aggregation of RSVP for IPv4 and IPv6 Reservations,” September 2001.).
| TOC |
[RFC4364] (Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs),” February 2006.) defines three modes of inter-AS operation for MPLS/BGP VPNs, referred to as options A, B and C. In the following sections we describe how the scheme described above can operate in each inter-AS environment.
| TOC |
Operation of RSVP in Inter-AS Option A is quite straightforward. Each ASBR operates like a PE, and the ASBR-ASBR links can be viewed as PE-CE links in terms of admission control. If the procedures defined in Section 3 (Admission Control on PE-CE Links) are enabled on both ASBRs, then CAC may be performed on the inter-ASBR links. In addition, the operator of each AS can independently decide whether or not to perform CAC across his backbone. The new objects described in this document MUST NOT be sent in any RSVP message between two Option-A ASBRs.
| TOC |
To support inter-AS Option B, we require some additional processing of RSVP messages on the ASBRs. Recall that, when packets are forwarded from one AS to another in option B, the VPN label is swapped by each ASBR as a packet goes from one AS to another. The BGP next hop seen by the ingress PE will be the ASBR, and there need not be IP visibility between the ingress and egress PEs. Hence when the ingress PE sends the Path message to the BGP next hop of the VPN-IPv4 route towards the destination, it will be received by the ASBR. The ASBR determines the next hop of the route in a similar way as the ingress PE - by finding a matching BGP VPN-IPv4 route with the same RD and a matching prefix.
The provider(s) who interconnect ASes using option B may or may not desire to perform admission control on the inter-AS links. This choice affects the detailed operation of ASBRs. We describe the two modes of operation - with and without admission control at the ASBRs - in the following sections.
| TOC |
In this scenario, the ASBR performs full RSVP signalling and admission control. The RSVP database is indexed on the ASBR using the VPN-IPv4 SESSION, SENDER_TEMPLATE and FILTER_SPEC objects (which uniquely identify RSVP sessions and flows as per the requirements of [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.)). These objects are forwarded unmodified in both directions by the ASBR. All other procedures of RSVP are performed as if the ASBR was a RSVP hop. In particular, the RSVP_HOP objects sent in Path and Resv messages contain IP addresses of the ASBR, which MUST be reachable by the neighbor to whom the message is being sent. Note that since the VPN-IPv4 SESSION, SENDER_TEMPLATE and FILTER_SPEC objects satisfy the uniqueness properties required for a RSVP database implementation as per [RFC2209] (Braden, B. and L. Zhang, “Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules,” September 1997.), no customer VRF awareness is required on the ASBR.
| TOC |
If the ASBR is not doing admission control, it is desirable that per-flow state not be maintained on the ASBR. This requires adjacent RSVP hops (i.e. the ingress and egress PEs of the respective ASes) to send RSVP messages directly between them. Not however that such routers in an Option B environment are not required to have direct IP reachability to each other. To mitigate this issue, we propose the use of label switching to forward RSVP messages from a PE in one AS to a PE in another AS. A detailed description of how this is achieved follows.
We first define a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4 RSVP_HOP object enables RSVP control plane reachability between any two adjacent RSVP hops in a MPLS VPN, regardless of whether they have IP reachability. RSVP nodes sending Path or Resv messages across a MPLS VPN MAY use the VPN-IPv4 PHOP object to achieve signalling across Option-B ASBRs without requiring the ASBRs to install state. The requirements ("SHOULD", "MUST" etc.) specified in the remainder of this section only apply when the implementation supports the OPTIONAL use of the VPN-IPv4 HOP object.
The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message sender and a logical interface handle as before, but in addition carries a VPN-IPv4 address which also represents the sender of the message. The message sender MUST also advertise this VPN-IPv4 HOP address into BGP with an associated label, and this advertisement MUST be propagated by BGP throughout the VPN and to adjacent ASes in order to provide reachability to this PE. Frames received by the PE marked with this label MUST be given to the local control plane for processing. This VPN-IPv4 address MAY be created specially for this task, or MAY be any previously-advertised address representing any VRF (e.g. local PE-CE link address). In the case where the address is specially created for control protocols, the BGP advertisement for this address SHOULD be marked such that it is not redistributed outside the MPLS VPN. Two possible methods to achieve this goal are:
When an ASBR that is not installing local RSVP state receives a Path message, it looks up the next-hop of the matching BGP route as described in Section 3.1 (Path Message Processing at Ingress PE), and sends the Path message to the next-hop, without modifying any RSVP objects (including the RSVP_HOP). This process is repeated at subsequent ASBRs until the Path message arrives at a router that is installing local RSVP state (either the ultimate egress PE, or an ASBR configured to perform CAC). This router receives the Path and processes it as described in Section 3.2 (Path Message Processing at Egress PE) if it is a PE, or Section 5.2.1 (Admission control on ASBR) if it is an ASBR performing CAC. When this router sends the Resv upstream, it queries BGP for a next-hop and label for the VPN-IPv4 address in the PHOP, encapsulates the Resv with that label and sends it upstream. This message will be received for control processing directly on the upstream RSVP hop (the hop that last updated the RSVP_HOP field in the Path message), without any involvement of intermediate ASBRs. Further, the router sending this Resv message MUST include in its RSVP_HOP object a VPN-IPv4 address advertised by itself into BGP with a label, so that hop-by-hop RSVP messages in the downstream direction (e.g. ResvError) can be sent directly to it. Note that the VPN-IPv4 address is only used to identify a LSP for neighbor reachability. The IPv4 address in the RSVP_HOP object is used for all other purposes, including neighbor matching between Path/Resv and SRefresh messages ([RFC2961] (Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, “RSVP Refresh Overhead Reduction Extensions,” April 2001.)), authentication ([RFC2747] (Baker, F., Lindell, B., and M. Talwar, “RSVP Cryptographic Authentication,” January 2000.)), etc.
The ASBR is not expected to process any other RSVP messages apart from the Path message as described above. The ASBR also does not need to store any RSVP state. Note that any ASBR along the path that wishes to do admission control or insert itself into the RSVP signalling flow, may do so by writing its own RSVP_HOP object with IPv4 and VPN-IPv4 address pointing to itself.
If an Option-B ASBR receives a RSVP Path message with an IPv4 type PHOP, does not wish to perform admission control but is willing to install local state for this flow, the ASBR MUST process and forward RSVP signalling messages for this flow as described in section 5.2.1 (except admission control). If an Option-B ASBR receives a RSVP Path message with an IPv4 type PHOP, but does not wish to install local state or perform admission control for this flow, the ASBR MUST NOT forward the Path message. In addition, the ASBR SHOULD send a PathError message of Error Code [TBD], Error Value [TBD], signifying to the upstream RSVP hop that the supplied PHOP object is insufficient to provide reachability across this VPN. The upstream node, on receipt of this PathError, SHOULD re-send the Path message including a RSVP_HOP of VPN-IPv4 type.
| TOC |
Operation of RSVP in Inter-AS Option C is also quite straightforward, because there exists an LSP directly from ingress PE to egress PE. In this case, there is no significant difference in operation from the single AS case described in Section 3 (Admission Control on PE-CE Links). Furthermore, if it is desired to provide admission control from PE to PE, it can be done by building an inter-AS TE tunnel and then using the procedures described in Section 4 (Admission Control in Provider's Backbone).
| TOC |
It is often the case that RSVP will not be enabled on the PE-CE links. In such an environment, a customer may reasonably expect that RSVP messages sent into the L3 VPN network should be forwarded just like any other IP datagrams. This transparency is useful when the customer wishes to use RSVP within his own sites or perhaps to perform admission control on the CE-PE links (in CE->PE direction only), without involvement of the PEs. For this reason, a PE SHOULD NOT discard or modify RSVP messages sent towards it from a CE when RSVP is not enabled on the PE-CE links. Similarly a PE SHOULD NOT discard or modify RSVP messages which are destined for one of its attached CEs, even when RSVP is not enabled on those links. Note that the presence of the router alert option in some RSVP messages may cause them to be forwarded outside of the normal forwarding path, but that the guidance of this paragraph still applies in that case. Note also that this guidance applies regardless of whether RSVP-TE is used in some, all, or none of the L3VPN network.
| TOC |
This section describes modifications to other RSVP procedures introduced by MPLS VPNs
| TOC |
The following points should be noted regarding RSVP refresh overhead reduction ([RFC2961] (Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, “RSVP Refresh Overhead Reduction Extensions,” April 2001.)) across a MPLS VPN:
| TOC |
The following points should be noted regarding RSVP cryptographic authentication ([RFC2747] (Baker, F., Lindell, B., and M. Talwar, “RSVP Cryptographic Authentication,” January 2000.)) across a MPLS VPN:
| TOC |
[RFC3175] (Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, “Aggregation of RSVP for IPv4 and IPv6 Reservations,” September 2001.) and [RFC4860] (Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, “Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations,” May 2007.) describe mechanisms to aggregate multiple individual RSVP reservations into a single larger reservation on the basis of a common DSCP/PHB for traffic classification. The following points should be noted in this regard:
| TOC |
[I‑D.kumaki‑l3vpn‑e2e‑rsvp‑te‑reqts] (Kumaki, K., “Requirements for supporting Customer RSVP and RSVP-TE Over a BGP/MPLS IP-VPN,” February 2008.) describes a set of requirements for the establishment for CE-CE MPLS LSPs across networks offering an L3VPN service. The requirements specified in that draft are similar to those addressed by this document, in that both address the issue of handling RSVP requests from customers in a VPN context. It is possible that the solution described here could be adapted to meet the requirements of [I‑D.kumaki‑l3vpn‑e2e‑rsvp‑te‑reqts] (Kumaki, K., “Requirements for supporting Customer RSVP and RSVP-TE Over a BGP/MPLS IP-VPN,” February 2008.). To the extent that this draft uses signalling extensions described in [RFC3473] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions,” January 2003.) which have already been used for GMPLS/TE, we expect that CE-CE RSVP/TE will be incremental work built on these extensions. These extensions will be considered in a separate document.
| TOC |
| TOC |
The usage of the VPN-IPv4 SESSION Object is described in Section 3.1 (Path Message Processing at Ingress PE) and Section 3.2 (Path Message Processing at Egress PE). The VPN-IPv4 SESSION object should appear in all RSVP messages that ordinarily contain a SESSION object and are sent between ingress PE and egress PE in either direction. The object MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS option B and C cases, as described above, when it may appear on inter-AS links). The VPN-IPv4 address in this object is built by combining the IPv4 address from the incoming SESSION with the RD in the BGP advertisement from the egress PE for this prefix and customer.
The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION object, using VPN-IPv6 addresses[RFC4659] (De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, “BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN,” September 2006.).
The formats of the objects are as follows:
o VPN-IPv4 SESSION object: Class = 1, C-Type = TBA
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
o VPN-IPv6 SESSION object: Class = 1, C-Type = TBA
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
The protocol ID, flags, and DstPort are identical to the IPv4 and IPv6 SESSION objects.
| TOC |
The usage of the VPN-IPv4 SENDER_TEMPLATE Object is described in Section 3.1 (Path Message Processing at Ingress PE) and Section 3.2 (Path Message Processing at Egress PE). The VPN-IPv4 SENDER_TEMPLATE object should appear in all RSVP messages that ordinarily contain a SENDER_TEMPLATE object and are sent between ingress PE and egress PE in either direction (such as Path, PathError, and PathTear). The object MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS option B and C cases, as described above, when it may appear on inter-AS links). The VPN-IPv4 address in this object is built by combining the IPv4 address from the incoming SENDER_TEMPLATE with the RD in the BGP advertisement from the ingress PE for this prefix and customer. The format of the object is as follows:
o VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = TBA
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 SrcAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | SrcPort |
+-------------+-------------+-------------+-------------+
o VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = TBA
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 SrcAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | SrcPort |
+-------------+-------------+-------------+-------------+
The SrcPort is identical to the IPv4 and IPv6 SENDER_TEMPLATE objects. The Reserved field must be set to zero on transmit and ignored on receipt.
| TOC |
The usage of the VPN-IPv4 FILTER_SPEC Object is described in Section 3.3 (Resv Processing at Egress PE) and Section 3.4 (Resv Processing at Ingress PE). The VPN-IPv4 FILTER_SPEC object should appear in all RSVP messages that ordinarily contain a FILTER_SPEC object and are sent between ingress PE and egress PE in either direction (such as Resv, ResvError, and ResvTear). The object MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS option B and C cases, as described above, when it may appear on inter-AS links). The VPN-IPv4 address in this object is built by combining the IPv4 address from the incoming FILTER_SPEC with the RD in the BGP advertisement from the ingress PE for this prefix and customer.
o VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = TBA
Definition same as VPN-IPv4 SENDER_TEMPLATE object.
o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = TBA
Definition same as VPN-IPv6 SENDER_TEMPLATE object.
The protocol ID, flags, and DstPort are identical to the IPv4 and IPv6 SESSION objects.
| TOC |
Usage of the VPN-IPv4 RSVP_HOP Object is described in Section 5.2.2 (No admission control on ASBR). The VPN-IPv4 RSVP_HOP object is used to establish signalling reachability between RSVP neighbors separated by one or more Option-B ASBRs. This object may appear in all RSVP messages that carry a RSVP_HOP object, and that travel between the Ingress and Egress PEs. It MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS option B and C cases, as described above, when it may appear on inter-AS links). The format of the object is as follows:
o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = TBA
+-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 Next/Previous Hop Address (12 bytes) |
+
+
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
o VPN-IPv6 RSVP_HOP object: Class = 3, C-Type = TBA
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Next/Previous Hop Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 Next/Previous Hop Address (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
| TOC |
The usage of Aggregated VPN-IPv4 SESSION object is described in Section 7.3 (RSVP Aggregation). The AGGREGATE-VPN-IPv4 SESSION object should appear in all RSVP messages that ordinarily contain a AGGREGATE-IPv4 SESSION object as defined in [RFC3175] (Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, “Aggregation of RSVP for IPv4 and IPv6 Reservations,” September 2001.) and are sent between ingress PE and egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4 SESSION object should appear in all RSVP messages that ordinarily contain a GENERIC-AGGREGATE-IPv4 SESSION object as defined in [RFC4860] (Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, “Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations,” May 2007.) and are sent between ingress PE and egress PE in either direction. These objects MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS option B and C cases, as described above, when it may appear on inter-AS links). The processing rules for these objects are otherwise identical to those of the VPN-IPv4 SESSION object defined in Section 8.1 (VPN-IPv4 and VPN-IPv6 SESSION objects). The VPN-IPv4 address in this object is built by combining the IPv4 address from the incoming SESSION with the RD in the BGP advertisement from the egress PE for this prefix and customer. The format of the object is as follows:
o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = TBA
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////// | Flags | /////// | DSCP |
+-------------+-------------+-------------+-------------+
o AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = TBA
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | Reserved | DSCP |
+-------------+-------------+-------------+-------------+
The flags and DSCP are identical to the AGGREGATE-IPv4 and AGGREGATE-IPv6 SESSION objects.
o GENERIC-AGGREGATE-VPN-IPv4 SESSION object:
Class = 1, C-Type = TBA
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
o GENERIC-AGGREGATE-VPN-IPv6 SESSION object:
Class = 1, C-Type = TBA
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
The flags, PHB-ID, vDstPort and Extended vDstPort are identical to the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE-IPv6 SESSION objects.
| TOC |
The usage of Aggregated VPN-IPv4 SENDER_TEMPLATE object is described in Section 7.3 (RSVP Aggregation). The AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object should appear in all RSVP messages that ordinarily contain a AGGREGATE-IPv4 SENDER_TEMPLATE object as defined in [RFC3175] (Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, “Aggregation of RSVP for IPv4 and IPv6 Reservations,” September 2001.) and [RFC4860] (Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, “Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations,” May 2007.), and are sent between ingress PE and egress PE in either direction. These objects MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS option B and C cases, as described above, when it may appear on inter-AS links). The processing rules for these objects are otherwise identical to those of the VPN-IPv4 SENDER_TEMPLATE object defined in Section 8.2 (VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects). The VPN-IPv4 address in this object is built by combining the IPv4 address from the incoming SENDER_TEMPLATE with the RD in the BGP advertisement from the ingress PE for this prefix and customer. The format of the object is as follows:
o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object:
Class = 11, C-Type = TBA
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 AggregatorAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
o AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object:
Class = 11, C-Type = TBA
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 AggregatorAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
The flags and DSCP are identical to the AGGREGATE-IPv4 and AGGREGATE-IPv6 SESSION objects.
| TOC |
The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in Section 7.3 (RSVP Aggregation). The AGGREGATE-VPN-IPv4 FILTER_SPEC object should appear in all RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC object as defined in [RFC3175] (Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, “Aggregation of RSVP for IPv4 and IPv6 Reservations,” September 2001.) and [RFC4860] (Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, “Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations,” May 2007.), and are sent between ingress PE and egress PE in either direction. These objects MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS option B and C cases, as described above, when it may appear on inter-AS links). The processing rules for these objects are otherwise identical to those of the VPN-IPv4 FILTER_SPEC object defined in Section 8.3 (VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects). The VPN-IPv4 address in this object is built by combining the IPv4 address from the incoming FILTER_SPEC with the RD in the BGP advertisement from the ingress PE for this prefix and customer. The format of the object is as follows:
o AGGREGATE-VPN-IPv4 FILTER_SPEC object:
Class = 10, C-Type = TBA
Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object.
o AGGREGATE-VPN-IPv6 FILTER_SPEC object:
Class = 10, C-Type = TBA
Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object.
| TOC |
This document requires IANA assignment of new RSVP C-Types to accommodate the new objects described in Section 8 (Object Definitions). In addition, a new PathError code/value is required to identify a signalling reachability failure and the need for a VPN-IPv4 or VPN-IPv6 RSVP_HOP object as described in Section 5.2.2 (No admission control on ASBR).
| TOC |
[RFC4364] (Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs),” February 2006.) addresses the security considerations of BGP/MPLS VPNs in general. General RSVP security considerations are addressed in [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.). To ensure the integrity of RSVP, the RSVP Authentication mechanisms defined in [RFC2747] (Baker, F., Lindell, B., and M. Talwar, “RSVP Cryptographic Authentication,” January 2000.) and [RFC3097] (Braden, R. and L. Zhang, “RSVP Cryptographic Authentication -- Updated Message Type Value,” April 2001.)may be used. These protect RSVP message integrity hop-by-hop and provide node authentication as well as replay protection, thereby protecting against corruption and spoofing of RSVP messages. [I‑D.behringer‑tsvwg‑rsvp‑security‑groupkeying] (Behringer, M. and F. Faucheur, “Applicability of Keying Methods for RSVP Security,” November 2007.) discusses applicability of various keying approaches for RSVP Authentication. We note that the RSVP signaling in MPLS VPN is likely to spread over multiple administrative domains (e.g. the service provider operating the VPN service, and the customers of the service). Therefore the considerations in [I‑D.behringer‑tsvwg‑rsvp‑security‑groupkeying] (Behringer, M. and F. Faucheur, “Applicability of Keying Methods for RSVP Security,” November 2007.) about inter-domain issues are likely to apply. Since RSVP messages travel through the L3VPN cloud directly addressed to PE or ASBR routers (without IP Router-Alert), P routers remain isolated from RSVP messages signalling customer reservations. Providers MAY choose to block PEs from sending IP Router-Alert datagrams to P routers as a security practice, without impacting the functionality described herein.
Beyond those general issues, four specific issues are introduced by this document: resource usage on PEs, resource usage in the provider backbone, PE route advertisement outside the AS, and signalling exposure to ASBRs and PEs. We discuss these in turn.
A customer who makes resource reservations on the CE-PE links for his sites is only competing for link resources with himself, as in standard RSVP, at least in the common case where each CE-PE link is dedicated to a single customer. Thus, from the perspective of the CE-PE links, this draft does not introduce any new security issues. However, because a PE typically serves multiple customers, there is also the possibility that a customer might attempt to use excessive computational resources on a PE (CPU cycles, memory etc.) by sending large numbers of RSVP messages to a PE. In the extreme this could represent a form of denial-of-service attack. In order to prevent such an attack, a PE should have mechanisms to limit the fraction of its processing resources that can be consumed by any one CE or by the set of CEs of a given customer. For example, a PE might implement a form of rate limiting on RSVP messages that it receives from each CE. We observe that these security risks and measures related to PE resource usage are very similar for any control plane protocol operating between CE and PE (e.g. RSVP, routing, multicast)
The second concern arises only when the service provider chooses to offer resource reservation across the backbone, as described in Section 4 (Admission Control in Provider's Backbone). In this case, the concern may be that a single customer might attempt to reserve a large fraction of backbone capacity, perhaps with a co-ordinated effort from several different CEs, thus denying service to other customers using the same backbone. [RFC4804] (Le Faucheur, F., “Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels,” February 2007.) provides some guidance on the security issues when RSVP reservations are aggregated onto MPLS tunnels, which are applicable to the situation described here. We note that a provider may use local policy to limit the amount of resources that can be reserved by a given customer from a particular PE, and that a policy server could be used to control the resource usage of a given customer across multiple PEs if desired.
A third issue may arise when Inter-AS Option B is used and admission control is not required on the inter-AS link (Section 5.2.2 (No admission control on ASBR)). In this case, the VPN PE includes a VPN-IPv4 address in the PHOP/NHOP objects it generates, which is used by the peer to determine a VPN label to communicate back with this PE. This results in a direct VPN-IPv4 route to a PE being exported to another AS, and potentially could allow customers to direct RSVP messages to remote PEs if those routes were advertised to the customers. However, as described in Section 5.2.2 (No admission control on ASBR), a variety of techniques may be used to prevent such routes from being advertised to customers. Alternatively, ASBRs may implement the signalling procedures described in Section 5.2.1 (Admission control on ASBR), even if admission control is not required on the inter-AS link, as these procedures do not require any direct P/PE route advertisement out of the AS.
Finally, certain operations described herein (Section 3 (Admission Control on PE-CE Links)) require an ASBR or PE to receive and locally process a signalling packet addressed to the BGP next-hop address advertised by that router. This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364] (Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs),” February 2006.). This could be viewed as opening ASBRs and PEs to being directly addressable by customer devices where they were not open before, and could be considered a security issue. If a provider wishes to mitigate this situation, it would be possible to use one of the approaches described in Section 5.2.2 (No admission control on ASBR) to prevent such routers from being reachable by customers. That is, whenever a signalling message is to be sent to a PE or ASBR, the address of the router in question would be looked up in the "control protocol" VPN, and the message would then be sent on the LSP that is found as a result of that lookup. This would allow the provider to restrict advertisement of PE and ASBR addresses so that these addresses are not reachable by customer devices.
| TOC |
Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric Rosen for their many contributions to solving the problems described in this draft. Thanks to Ferit Yegenoglu and Dan Tappan for their useful comments.
| TOC |
At this stage a number of alternatives to the approach described above have been considered. We document some of the approaches considered here to assist future discussion. None of these has been shown to improve upon the approach described above, and the first two seem to have significant drawbacks relative to the approach described above.
| TOC |
[RFC4208] (Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, “Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model,” October 2005.) defines the GMPLS UNI. In Section 7 the operation of the GMPLS UNI in a VPN context is briefly described. This is somewhat similar to the problem tackled in the current document. The main difference is that the GMPLS UNI is primarily aimed at the problem of allowing a CE device to request the establishment of an LSP across the network on the other side of the UNI. Hence the procedures in [RFC4208] (Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, “Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model,” October 2005.) would lead to the establishment of an LSP across the VPN provider's network for every RSVP request received, which is not desired in this case.
To the extent possible, the approach described in this document is consistent with [RFC4208] (Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, “Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model,” October 2005.), while filling in more of the details and avoiding the problem noted above.
| TOC |
Another approach to solving the problems described here involves the use of label switching to ensure that Path, Resv, and other RSVP messages are directed to the appropriate VRF. One challenge with such an approach is that [RFC4364] (Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs),” February 2006.) does not require labels to be allocated for VRFs, only for customer prefixes, and that there is no simple, existing method for advertising the fact that a label is bound to a VRF. If, for example, an ingress PE sent a Path message labelled with a VPN label that was advertised by the egress PE for the prefix that matches the destination address in the Path, there is a risk that the egress PE would simply label-switch the Path directly on to the CE without performing RSVP processing.
A second challenge with this approach is that an IP address needs to be associated with a VRF and used as the PHOP address for the Path message sent from ingress PE to egress PE. That address must be reachable from the egress PE, and exist in the VRF at the ingress PE. Such an address is not always available in today's deployments, so this represents at least a change to existing deployment practices.
| TOC |
It is possible to create an approach based on that described in the previous section which addresses the main challenges of that approach. The basic approach has two parts: (a) define a new BGP Extended Community to tag a route (and its associated MPLS label) as pointing to a VRF; (b) allocate a "dummy" address to each VRF, specifically to be used for routing RSVP messages. The dummy address (which could be anything, e.g. a loopback of the associated PE) would be used as a PHOP for Path messages and would serve as the destination for Resv messages but would not be imported into VRFs of any other PE.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC2205] | Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” RFC 2205, September 1997 (TXT, HTML, XML). |
| [RFC3175] | Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, “Aggregation of RSVP for IPv4 and IPv6 Reservations,” RFC 3175, September 2001 (TXT). |
| [RFC4364] | Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs),” RFC 4364, February 2006 (TXT). |
| [RFC4659] | De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, “BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN,” RFC 4659, September 2006 (TXT). |
| [RFC4804] | Le Faucheur, F., “Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels,” RFC 4804, February 2007 (TXT). |
| TOC |
| TOC |
| Bruce Davie | |
| Cisco Systems, Inc. | |
| 1414 Mass. Ave. | |
| Boxborough, MA 01719 | |
| USA | |
| Email: | bsd@cisco.com |
| Francois le Faucheur | |
| Cisco Systems, Inc. | |
| Village d'Entreprise Green Side - Batiment T3 | |
| 400, Avenue de Roumanille | |
| Biot Sophia-Antipolis 06410 | |
| France | |
| Email: | flefauch@cisco.com |
| Ashok Narayanan | |
| Cisco Systems, Inc. | |
| 1414 Mass. Ave. | |
| Boxborough, MA 01719 | |
| USA | |
| Email: | ashokn@cisco.com |
| TOC |
Copyright © The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
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.