summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5824.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5824.txt')
-rw-r--r--doc/rfc/rfc5824.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc5824.txt b/doc/rfc/rfc5824.txt
new file mode 100644
index 0000000..94b4d13
--- /dev/null
+++ b/doc/rfc/rfc5824.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) K. Kumaki, Ed.
+Request for Comments: 5824 KDDI Corporation
+Category: Informational R. Zhang
+ISSN: 2070-1721 BT
+ Y. Kamite
+ NTT Communications Corporation
+ April 2010
+
+
+ Requirements for Supporting
+ Customer Resource ReSerVation Protocol (RSVP)
+ and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN
+
+Abstract
+
+ Today, customers expect to run triple-play services through BGP/MPLS
+ IP-VPNs. Some service providers will deploy services that request
+ Quality of Service (QoS) guarantees from a local Customer Edge (CE)
+ to a remote CE across the network. As a result, the application
+ (e.g., voice, video, bandwidth-guaranteed data pipe, etc.)
+ requirements for an end-to-end QoS and reserving an adequate
+ bandwidth continue to increase.
+
+ Service providers can use both an MPLS and an MPLS Traffic
+ Engineering (MPLS-TE) Label Switched Path (LSP) to meet their service
+ objectives. This document describes service-provider requirements
+ for supporting a customer Resource ReSerVation Protocol (RSVP) and
+ RSVP-TE over a BGP/MPLS IP-VPN.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5824.
+
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 1]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 2]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Requirements Language ...........................................4
+ 3. Terminology .....................................................5
+ 4. Problem Statement ...............................................5
+ 5. Application Scenarios ...........................................7
+ 5.1. Scenario I: Fast Recovery over BGP/MPLS IP-VPNs ............8
+ 5.2. Scenario II: Strict C-TE LSP QoS Guarantees ................8
+ 5.3. Scenario III: Load Balance of CE-to-CE Traffic .............9
+ 5.4. Scenario IV: RSVP Aggregation over MPLS-TE Tunnels ........11
+ 5.5. Scenario V: RSVP over Non-TE LSPs .........................12
+ 5.6. Scenario VI: RSVP-TE over Non-TE LSPs .....................13
+ 6. Detailed Requirements for C-TE LSP Model .......................14
+ 6.1. Selective P-TE LSPs .......................................14
+ 6.2. Graceful Restart Support for C-TE LSPs ....................14
+ 6.3. Rerouting Support for C-TE LSPs ...........................15
+ 6.4. FRR Support for C-TE LSPs .................................15
+ 6.5. Admission Control Support on P-TE LSP Head-Ends ...........15
+ 6.6. Admission Control Support for C-TE LSPs in
+ LDP-Based Core Networks ...................................16
+ 6.7. Policy Control Support for C-TE LSPs ......................16
+ 6.8. PCE Features Support for C-TE LSPs ........................16
+ 6.9. Diversely Routed C-TE LSP Support .........................16
+ 6.10. Optimal Path Support for C-TE LSPs .......................17
+ 6.11. Reoptimization Support for C-TE LSPs .....................17
+ 6.12. DS-TE Support for C-TE LSPs ..............................17
+ 7. Detailed Requirements for C-RSVP Path Model ....................18
+ 7.1. Admission Control between PE-CE for C-RSVP Paths ..........18
+ 7.2. Aggregation of C-RSVP Paths by P-TE LSPs ..................18
+ 7.3. Non-TE LSP Support for C-RSVP Paths .......................18
+ 7.4. Transparency of C-RSVP Paths ..............................18
+ 8. Commonly Detailed Requirements for Two Models ..................18
+ 8.1. CE-PE Routing .............................................18
+ 8.2. Complexity and Risks ......................................19
+ 8.3. Backward Compatibility ....................................19
+ 8.4. Scalability Considerations ................................19
+ 8.5. Performance Considerations ................................19
+ 8.6. Management Considerations .................................20
+ 9. Security Considerations ........................................20
+ 10. References ....................................................21
+ 10.1. Normative References .....................................21
+ 10.2. Informative References ...................................22
+ Acknowledgments....................................................23
+ Appendix A. Reference Model........................................24
+ A.1 End-to-End C-RSVP Path Model................................24
+ A.2 End-to-End C-TE LSP Model...................................25
+
+
+
+
+Kumaki, et al. Informational [Page 3]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+1. Introduction
+
+ Some service providers want to build a service that guarantees
+ Quality of Service (QoS) and a bandwidth from a local Customer Edge
+ (CE) to a remote CE through the network. A CE includes the network
+ client equipment owned and operated by the service provider.
+ However, the CE may not be part of the MPLS provider network.
+
+ Today, customers expect to run triple-play services such as Internet
+ access, telephone, and television through BGP/MPLS IP-VPNs [RFC4364].
+
+ As these services evolve, the requirements for an end-to-end QoS to
+ meet the application requirements also continue to grow. Depending
+ on the application (e.g., voice, video, bandwidth-guaranteed data
+ pipe, etc.), a native IP using an RSVP and/or an end-to-end
+ constrained MPLS Traffic Engineering (MPLS-TE) Label Switched Path
+ (LSP) may be required. The RSVP path may be used to provide QoS
+ guarantees and reserve an adequate bandwidth for the data. An end-
+ to-end MPLS-TE LSP may also be used to guarantee a bandwidth, and
+ provide extended functionality like MPLS fast reroute (FRR) [RFC4090]
+ for maintaining the service continuity around node and link,
+ including the CE-PE link, failures. It should be noted that an RSVP
+ session between two CEs may also be mapped and tunneled into an MPLS-
+ TE LSP across an MPLS provider network.
+
+ A number of advantages exist for deploying the model previously
+ mentioned. The first is that customers can use these network
+ services while being able to use both private addresses and global
+ addresses. The second advantage is that the traffic is tunneled
+ through the service-provider backbone so that customer traffic and
+ route confidentiality are maintained.
+
+ This document defines a reference model, example application
+ scenarios, and detailed requirements for a solution supporting a
+ customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN.
+
+ A specification for a solution is out of scope in this document.
+
+2. Requirements Language
+
+ 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 [RFC2119].
+
+
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 4]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+3. Terminology
+
+ This document uses the BGP/MPLS IP-VPN terminology defined in
+ [RFC4364] and also uses Path Computation Element (PCE) terms defined
+ in [RFC4655].
+
+ TE LSP: Traffic Engineering Label Switched Path
+
+ MPLS-TE LSP: Multiprotocol Label Switching TE LSP
+
+ C-RSVP path: Customer RSVP path: a native RSVP path with the
+ bandwidth reservation of X for customers
+
+ C-TE LSP: Customer Traffic Engineering Label Switched Path: an end-
+ to-end MPLS-TE LSP for customers
+
+ P-TE LSP: Provider Traffic Engineering Label Switched Path: a
+ transport TE LSP between two Provider Edges (PEs)
+
+ LSR: a Label Switched Router
+
+ Head-end LSR: an ingress LSR
+
+ Tail-end LSR: an egress LSR
+
+4. Problem Statement
+
+ Service providers want to deliver triple-play services with QoS
+ guarantees to their customers. Various techniques are available to
+ achieve this. Some service providers will wish to offer advanced
+ services using an RSVP signaling for native IP flows (C-RSVP) or an
+ RSVP-TE signaling for Customer TE LSPs (C-TE LSPs) over BGP/MPLS
+ IP-VPNs.
+
+ The following examples outline each method:
+
+ A C-RSVP path with the bandwidth reservation of X can be used to
+ transport voice traffic. In order to achieve recovery in under 50 ms
+ during link, node, and Shared Risk Link Group (SRLG) failures, and to
+ provide strict QoS guarantees, a C-TE LSP with bandwidth X between
+ data centers or customer sites can be used to carry voice and video
+ traffic. Thus, service providers or customers can choose a C-RSVP
+ path or a C-TE LSP to meet their requirements.
+
+ When service providers offer a C-RSVP path between hosts or CEs over
+ BGP/MPLS IP-VPNs, the CE/host requests an end-to-end C-RSVP path with
+ the bandwidth reservation of X to the remote CE/host. However, if a
+ C-RSVP signaling is to send within a VPN, the service-provider
+
+
+
+Kumaki, et al. Informational [Page 5]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ network will face scalability issues because routers need to retain
+ the RSVP state per a customer. Therefore, in order to solve
+ scalability issues, multiple C-RSVP reservations can be aggregated at
+ a PE, where a P-TE LSP head-end can perform admission control using
+ the aggregated C-RSVP reservations. The method that is described in
+ [RFC4804] can be considered as a useful approach. In this case, a
+ reservation request from within the context of a Virtual Routing and
+ Forwarding (VRF) instance can get aggregated onto a P-TE LSP. The
+ P-TE LSP can be pre-established, resized based on the request, or
+ triggered by the request. Service providers, however, cannot provide
+ a C-RSVP path over the VRF instance as defined in [RFC4364]. The
+ current BGP/MPLS IP-VPN architecture also does not support an RSVP
+ instance running in the context of a VRF to process RSVP messages and
+ integrated services (int-serv) ([RFC1633], [RFC2210]). One solution
+ is described in [RSVP-L3VPN].
+
+ If service providers offer a C-TE LSP from a CE to a CE over the
+ BGP/MPLS IP-VPN, they require that an MPLS-TE LSP from a local CE to
+ a remote CE be established. However, if a C-TE LSP signaling is to
+ send within the VPN, the service-provider network may face the
+ following scalability issues:
+
+ - A C-TE LSP can be aggregated by a P-TE LSP at a PE (i.e.,
+ hierarchical LSPs). In this case, only a PE maintains the state of
+ customer RSVP sessions.
+
+ - A C-TE LSP cannot be aggregated by a P-TE LSP at a PE, depending on
+ some policies (i.e., continuous LSPs). In this case, both Ps and
+ PEs maintain the state of customer RSVP sessions.
+
+ - A C-TE LSP can be aggregated by the non-TE LSP (i.e., LDP).
+ In this case, only a PE maintains the state of customer RSVP-TE
+ sessions. Note that it is assumed that there is always enough
+ bandwidth available in the service-provider core network.
+
+ Furthermore, if service providers provide the C-TE LSP over the
+ BGP/MPLS IP-VPN, they currently cannot provide it over the VRF
+ instance as defined in [RFC4364]. Specifically, the current BGP/MPLS
+ IP-VPN architecture does not support the RSVP-TE instance running in
+ the context of a VRF to process RSVP messages and trigger the
+ establishment of the C-TE LSP over the service-provider core network.
+ If every C-TE LSP is to trigger the establishment or resizing of a
+ P-TE LSP, the service-provider network will also face scalability
+ issues that arise from maintaining a large number of P-TE LSPs and/or
+
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 6]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ the dynamic signaling of these P-TE LSPs. Section 8.4 of this
+ document, "Scalability Considerations", provides detailed scalability
+ requirements.
+
+ Two different models have been described above. The differences
+ between C-RSVP paths and C-TE LSPs are as follows:
+
+ - C-RSVP path model: data packets among CEs are forwarded by "native
+ IP packets" (i.e., not labeled packets).
+
+ - C-TE LSP model: data packets among CEs are forwarded by "labeled IP
+ packets".
+
+ Depending on the service level and the need to meet specific
+ requirements, service providers should be able to choose P-TE LSPs or
+ non-TE LSPs in the backbone network. The selection may be dependent
+ on the service provider's policy and the node's capability to support
+ the mechanisms described.
+
+ The items listed below are selectively required to support C-RSVP
+ paths and C-TE LSPs over BGP/MPLS IP-VPNs based on the service level.
+ For example, some service providers need all of the following items
+ to provide a service, and some service providers need only some of
+ them to provide the service. It depends on the service level and
+ policy of service providers. Detailed requirements are described in
+ Sections 6, 7, and 8.
+
+ - C-RSVP path QoS guarantees.
+
+ - Fast recovery over the BGP/MPLS IP-VPN to protect traffic for the
+ C-TE LSP against CE-PE link failure and PE node failure.
+
+ - Strict C-TE LSP bandwidth and QoS guarantees.
+
+ - Resource optimization for C-RSVP paths and C-TE LSPs.
+
+ - Scalability for C-RSVP paths and C-TE LSPs.
+
+5. Application Scenarios
+
+ The following sections present a few application scenarios for C-RSVP
+ paths and C-TE LSPs in BGP/MPLS IP-VPN environments. Appendix A,
+ "Reference Model", describes a C-RSVP path, a C-TE LSP, and a
+ P-TE LSP.
+
+ In all scenarios, it is the responsibility of the service provider to
+ ensure that enough bandwidth is available to meet the customers'
+ application requirements.
+
+
+
+Kumaki, et al. Informational [Page 7]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+5.1. Scenario I: Fast Recovery over BGP/MPLS IP-VPNs
+
+ In this scenario, as shown in Figure 1, a customer uses a VoIP
+ application between its sites (i.e., between CE1 and CE2). H0 and H1
+ represent voice equipment.
+
+ In this case, the customer establishes C-TE LSP1 as a primary path
+ and C-TE LSP2 as a backup path. If the link between PE1 and CE1 or
+ the node of PE1 fails, C-TE LSP1 needs C-TE LSP2 as a path
+ protection.
+
+ Generally speaking, C-RSVP paths are used by customers, and P-TE LSPs
+ are used by service providers.
+
+ C-TE LSP1
+ <---------------------------------------------->
+ P-TE LSP1
+ <--------------------------->
+ ............. .............
+ . --- --- . --- --- --- --- . --- --- .
+ .|H0 | |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |H1 |.
+ . --- --- . --- --- --- --- . --- --- .
+ .........|... --- --- --- --- ...|.........
+ +-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
+ --- --- --- ---
+
+ <--------------------------->
+ P-TE LSP2
+ <---------------------------------------------->
+ C-TE LSP2
+
+ <--customer--> <--------BGP/MPLS IP-VPN-------> <--customer->
+ network network
+
+ Figure 1. Scenario I
+
+5.2. Scenario II: Strict C-TE LSP QoS Guarantees
+
+ In this scenario, as shown in Figure 2, service provider B (SP B)
+ transports voice and video traffic between its sites (i.e., between
+ CE1 and CE2). In this case, service provider B establishes C-TE LSP1
+ with preemption priority 0 and 100-Mbps bandwidth for the voice
+ traffic, and C-TE LSP2 with preemption priority 1 and 200-Mbps
+ bandwidth for the unicast video traffic. On the other hand, service
+ provider A (SP A) also pre-establishes P-TE LSP1 with preemption
+ priority 0 and 1-Gbps bandwidth for the voice traffic, and P-TE LSP2
+ with preemption priority 1 and 2-Gbps bandwidth for the video
+
+
+
+
+Kumaki, et al. Informational [Page 8]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ traffic. In this scenario, P-TE LSP1 and P-TE LSP2 should support
+ Diffserv-aware MPLS Traffic Engineering (DS-TE) [RFC4124].
+
+ PE1 and PE3 should choose an appropriate P-TE LSP based on the
+ preemption priority. In this case, C-TE LSP1 must be associated with
+ P-TE LSP1 at PE1, and C-TE LSP2 must be associated with P-TE LSP2 at
+ PE3.
+
+ Furthermore, PE1 and PE3 head-ends should control the bandwidth of
+ C-TE LSPs. In this case, PE1 and PE3 can choose C-TE LSPs by the
+ amount of maximum available bandwidth for each P-TE LSP,
+ respectively.
+
+ C-TE LSP1
+ <---------------------------------------------->
+ P-TE LSP1
+ <--------------------------->
+ ............. .............
+ . --- --- . --- --- --- --- . --- --- .
+ .|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|.
+ . --- --- . --- --- --- --- . --- --- .
+ .........|... --- --- --- --- ...|.........
+ +-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
+ --- --- --- ---
+
+ <--------------------------->
+ P-TE LSP2
+ <---------------------------------------------->
+ C-TE LSP2
+
+ <---SP B----> <--------BGP/MPLS IP-VPN-------> <---SP B--->
+ network SP A network network
+
+ Figure 2. Scenario II
+
+ It's possible that the customer and the service provider have
+ differing preemption priorities. In this case, the PE policy will
+ override the customers. In the case where the service provider does
+ not support preemption priorities, then such priorities should be
+ ignored.
+
+5.3. Scenario III: Load Balance of CE-to-CE Traffic
+
+ In this scenario, as shown in Figure 3, service provider C (SP C)
+ uses voice and video traffic between its sites (i.e., between CE0 and
+ CE5/CE7, between CE2 and CE5/CE7, between CE5 and CE0/CE2, and
+ between CE7 and CE0/CE2). H0 and H1 represent voice and video
+ equipment. In this case, service provider C establishes C-TE LSP1,
+
+
+
+Kumaki, et al. Informational [Page 9]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ C-TE LSP3, C-TE LSP5, and C-TE LSP7 with preemption priority 0 and
+ 100-Mbps bandwidth for the voice traffic, and establishes C-TE LSP2,
+ C-TE LSP4, C-TE LSP6, and C-TE LSP8 with preemption priority 1 and
+ 200-Mbps bandwidth for the video traffic. On the other hand, service
+ provider A also pre-establishes P-TE LSP1 and P-TE LSP3 with
+ preemption priority 0 and 1-Gbps bandwidth for the voice traffic, and
+ P-TE LSP2 and P-TE LSP4 with preemption priority 1 and 2-Gbps
+ bandwidth for the video traffic. In this scenario, P-TE LSP1,
+ P-TE LSP2, P-TE LSP3, and P-TE LSP4 should support DS-TE [RFC4124].
+
+ All PEs should choose an appropriate P-TE LSP based on the preemption
+ priority. To minimize the traffic disruption due to a single network
+ failure, diversely routed C-TE LSPs are established. In this case,
+ the FRR [RFC4090] is not necessarily required.
+
+ Also, unconstrained TE LSPs (i.e., C-TE LSPs/P-TE LSPs with
+ 0 bandwidth) [RFC5330] are applicable to this scenario.
+
+ Furthermore, the load balancing for any communication between H0 and
+ H1 can be done by setting up full-mesh C-TE LSPs between CE0/CE2 and
+ CE5/CE7.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 10]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ C-TE LSP1(P=0),2(P=1) (CE0->CE1->...->CE4->CE5)
+ (CE0<-CE1<-...<-CE4<-CE5)
+ <---------------------------------------------->
+
+ C-TE LSP3(P=0),4(P=1) (CE2->CE1->...->CE4->CE7)
+ (CE2<-CE1<-...<-CE4<-CE7)
+ <---------------------------------------------->
+ P-TE LSP1 (p=0)
+ <-------------------->
+ P-TE LSP2 (p=1)
+ <-------------------->
+ .................. ..................
+ . --- --- . --- --- --- --- . --- --- .
+ . |CE0|-|CE1|--|PE1|--|P1 |---|P2 |--|PE2|--|CE4|-|CE5| .
+ . --- /--- --- . --- --- --- --- . --- ---\ --- .
+ .|H0 | + . + . + |H1 |.
+ . --- \--- --- . --- --- --- --- . --- ---/ --- .
+ . |CE2|-|CE3|--|PE3|--|P3 |---|P4 |--|PE4|--|CE6|-|CE7| .
+ . --- --- . --- --- --- --- . --- --- .
+ .................. ..................
+ <-------------------->
+ P-TE LSP3 (p=0)
+ <-------------------->
+ P-TE LSP4 (p=1)
+ <---------------------------------------------->
+ C-TE LSP5(P=0),6(P=1) (CE0->CE3->...->CE6->CE5)
+ (CE0<-CE3<-...<-CE6<-CE5)
+
+ <---------------------------------------------->
+ C-TE LSP7(P=0),8(P=1) (CE2->CE3->...->CE6->CE7)
+ (CE2<-CE3<-...<-CE6<-CE7)
+
+ <-----SP C-----> <----BGP/MPLS IP-VPN----> <-----SP C----->
+ network SP A network network
+
+ Figure 3. Scenario III
+
+5.4. Scenario IV: RSVP Aggregation over MPLS-TE Tunnels
+
+ In this scenario, as shown in Figure 4, the customer has two hosts
+ connecting to CE1 and CE2, respectively. CE1 and CE2 are connected
+ to PE1 and PE2, respectively, within a VRF instance belonging to the
+ same VPN. The requesting host (H1) may request from H2 an RSVP path
+ with the bandwidth reservation of X. This reservation request from
+ within the context of VRF will get aggregated onto a pre-established
+ P-TE/DS-TE LSP based upon procedures similar to [RFC4804]. As in the
+ case of [RFC4804], there may be multiple P-TE LSPs belonging to
+ different DS-TE class-types. Local policies can be implemented to
+
+
+
+Kumaki, et al. Informational [Page 11]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ map the incoming RSVP path request from H1 to the P-TE LSP with the
+ appropriate class-type. Please note that the end-to-end (e2e) RSVP
+ path request may also be initiated by the CE devices themselves.
+
+ C-RSVP path
+ <----------------------------------------------------->
+
+ P-TE LSP
+ <--------------------------->
+ ............. .............
+ . --- --- . --- --- --- --- . --- --- .
+ .|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
+ . --- --- . --- --- --- --- . --- --- .
+ ............. .............
+ ^ ^
+ | |
+ VRF instance VRF instance
+
+ <-customer-> <--------BGP/MPLS IP-VPN-------> <-customer->
+ network network
+
+ Figure 4. Scenario IV
+
+5.5. Scenario V: RSVP over Non-TE LSPs
+
+ In this scenario, as shown in Figure 5, a customer has two hosts
+ connecting to CE1 and CE2, respectively. CE1 and CE2 are connected
+ to PE1 and PE2, respectively, within a VRF instance belonging to the
+ same VPN. The requesting host (H1) may request from H2 an RSVP path
+ with the bandwidth reservation of X. In this case, a non-TE LSP
+ (i.e., LDP, etc.) is provided between PEs and has LDP, which supports
+ MPLS Diffserv [RFC3270].
+
+ Note that this only provides Diffserv, and not the bandwidth
+ reservation as is done with RSVP-TE.
+
+ Local policies can be implemented to map the customer's reserved flow
+ to the LSP with the appropriate Traffic Class [RFC5462] at PE1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 12]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ C-RSVP path
+ <------------------------------------------>
+
+ Non-TE LSP
+ <--------------------------->
+ ............. .............
+ . --- --- . --- --- --- --- . --- --- .
+ .|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
+ . --- --- . --- --- --- --- . --- --- .
+ ............. .............
+ ^ ^
+ | |
+ VRF instance VRF instance
+
+ <-customer-> <-------BGP/MPLS IP-VPN-------> <-customer->
+ network network
+
+ Figure 5. Scenario V
+
+5.6. Scenario VI: RSVP-TE over Non-TE LSPs
+
+ In this scenario, as shown in Figure 6, a customer uses a VoIP
+ application between its sites (i.e., between CE1 and CE2). H0 and H1
+ represent voice equipment. In this case, a non-TE LSP means LDP, and
+ the customer establishes C-TE LSP1 as a primary path and C-TE LSP2 as
+ a backup path. If the link between PE1 and CE1 or the node of PE1
+ fails, C-TE LSP1 needs C-TE LSP2 as a path protection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 13]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ C-TE LSP1
+ <----------------------------------------->
+ Non-TE LSP
+ <-------------------------->
+ ............. .............
+ . --- --- . --- --- --- --- . --- --- .
+ .|H0 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H1 |.
+ . --- --- . --- --- --- --- . --- --- .
+ .........|... --- --- --- --- ...|.........
+ +-----|PE3|----|P3 |-----|P4 |----|PE4|-----+
+ --- --- --- ---
+
+ <-------------------------->
+ Non-TE LSP
+ <----------------------------------------->
+ C-TE LSP2
+
+ <-customer-> <------BGP/MPLS IP-VPN------> <-customer->
+ network network
+
+ Figure 6. Scenario VI
+
+6. Detailed Requirements for the C-TE LSP Model
+
+ This section describes detailed requirements for C-TE LSPs in
+ BGP/MPLS IP-VPN environments.
+
+6.1. Selective P-TE LSPs
+
+ The solution MUST provide the ability to decide which P-TE LSPs a PE
+ uses for a C-RSVP path and a C-TE LSP. When a PE receives a native
+ RSVP and/or a path message from a CE, it MUST be able to decide which
+ P-TE LSPs it uses. In this case, various kinds of P-TE LSPs exist in
+ the service-provider network. For example, the PE MUST choose an
+ appropriate P-TE LSP based on local policies such as:
+
+ 1. preemption priority
+ 2. affinity
+ 3. class-type
+ 4. on the data plane: (Differentiated Services Code Point (DSCP) or
+ Traffic Class bits)
+
+6.2. Graceful Restart Support for C-TE LSPs
+
+ The solution SHOULD support the graceful restart capability, where
+ the C-TE LSP traffic continues to be forwarded during a PE graceful
+ restart. Graceful restart mechanisms related to this architecture
+ are described in [RFC3473], [RFC3623], and [RFC4781].
+
+
+
+Kumaki, et al. Informational [Page 14]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+6.3. Rerouting Support for C-TE LSPs
+
+ The solution MUST provide the rerouting of a C-TE LSP in case of
+ link, node, and SRLG failures, or in case of preemption. Such
+ rerouting may be controlled by a CE or by a PE, depending on the
+ failure. In a dual-homed environment, the ability to perform
+ rerouting MUST be provided against a CE-PE link failure or a PE
+ failure, if another CE-PE link or PE is available between the head-
+ end and the tail-end of the C-TE LSP.
+
+6.4. FRR Support for C-TE LSPs
+
+ The solution MUST support FRR [RFC4090] features for a C-TE LSP over
+ a VRF instance.
+
+ In BGP/MPLS IP-VPN environments, a C-TE LSP from a CE traverses
+ multiple PEs and Ps, albeit tunneled over a P-TE LSP. In order to
+ avoid PE-CE link/PE node/SRLG failures, a CE (a customer's head-end
+ router) needs to support link protection or node protection.
+
+ The following protection MUST be supported:
+
+ 1. CE link protection
+ 2. PE node protection
+ 3. CE node protection
+
+6.5. Admission Control Support on P-TE LSP Head-Ends
+
+ The solution MUST support admission control on a P-TE LSP tunnel
+ head-end for C-TE LSPs. C-TE LSPs may potentially try to reserve the
+ bandwidth that exceeds the bandwidth of the P-TE LSP. The P-TE LSP
+ tunnel head-end SHOULD control the number of C-TE LSPs and/or the
+ bandwidth of C-TE LSPs. For example, the transport TE LSP head-end
+ SHOULD have a configurable limit on the maximum number of C-TE LSPs
+ that it can admit from a CE. As for the amount of bandwidth that can
+ be reserved by C-TE LSPs, there could be two situations:
+
+ 1. Let the P-TE LSP do its natural bandwidth admission
+ 2. Set a cap on the amount of bandwidth, and have the configuration
+ option to:
+
+ a. Reserve the minimum cap bandwidth or the C-TE LSP bandwidth on
+ the P-TE LSP if the required bandwidth is available
+ b. Reject the C-TE LSP if the required bandwidth by the C-TE LSP
+ is not available
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 15]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+6.6. Admission Control Support for C-TE LSPs in LDP-Based Core
+ Networks
+
+ The solution MUST support admission control for a C-TE LSP at a PE in
+ the LDP-based core network. Specifically, PEs MUST have a
+ configurable limit on the maximum amount of bandwidth that can be
+ reserved by C-TE LSPs for a given VRF instance (i.e., for a given
+ customer). Also, a PE SHOULD have a configurable limit on the total
+ amount of bandwidth that can be reserved by C-TE LSPs between PEs.
+
+6.7. Policy Control Support for C-TE LSPs
+
+ The solution MUST support the policy control for a C-TE LSP at a PE.
+
+ The PE MUST be able to perform the following:
+
+ 1. Limit the rate of RSVP messages per CE link.
+ 2. Accept and map, or reject, requests for a given affinity.
+ 3. Accept and map, or reject, requests with a specified setup and/or
+ preemption priorities.
+ 4. Accept or reject requests for fast reroutes.
+ 5. Ignore the requested setup and/or preemption priorities, and
+ select a P-TE LSP based on a local policy that applies to the
+ CE-PE link or the VRF.
+ 6. Ignore the requested affinity, and select a P-TE LSP based on a
+ local policy that applies to the CE-PE link or the VRF.
+ 7. Perform mapping in the data plane between customer Traffic Class
+ bits and transport P-TE LSP Traffic Class bits, as signaled per
+ [RFC3270].
+
+6.8. PCE Features Support for C-TE LSPs
+
+ The solution SHOULD support the PCE architecture for a C-TE LSP
+ establishment in the context of a VRF instance. When a C-TE LSP is
+ provided, CEs, PEs, and Ps may support PCE features ([RFC4655],
+ [RFC5440]).
+
+ In this case, CE routers or PE routers may be Path Computation
+ Clients (PCCs), and PE routers and/or P routers may be PCEs.
+ Furthermore, the solution SHOULD support a mechanism for dynamic PCE
+ discovery. Specifically, all PCEs are not necessarily discovered
+ automatically, and only specific PCEs that know VPN routes should be
+ discovered automatically.
+
+6.9. Diversely Routed C-TE LSP Support
+
+ The solution MUST provide for setting up diversely routed C-TE LSPs
+ over the VRF instance. These diverse C-TE LSPs MAY be traversing
+
+
+
+Kumaki, et al. Informational [Page 16]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ over two different P-TE LSPs that are fully disjoint within a
+ service-provider network. When a single CE has multiple uplinks that
+ connect to different PEs, it is desirable that multiple C-TE LSPs
+ over the VRF instance be established between a pair of LSRs. When
+ two CEs have multiple uplinks that connect to different PEs, it is
+ desirable that multiple C-TE LSPs over the VRF instance be
+ established between two different pairs of LSRs. In these cases, for
+ example, the following points will be beneficial to customers.
+
+ 1. load balance of the CE-to-CE traffic across diverse C-TE LSPs so
+ as to minimize the traffic disruption in case of a single network
+ element failure
+ 2. path protection (e.g., 1:1, 1:N)
+
+6.10. Optimal Path Support for C-TE LSPs
+
+ The solution MUST support the optimal path for a C-TE LSP over the
+ VRF instance. Depending on an application (e.g., voice and video),
+ an optimal path is needed for a C-TE LSP over the VRF instance. In
+ the case of a TE LSP, an optimal route may be the shortest path based
+ on the TE metric applied. For a non-TE LSP using LDP, the IGP metric
+ may be used to compute optimal paths.
+
+6.11. Reoptimization Support for C-TE LSPs
+
+ The solution MUST support the reoptimization of a C-TE LSP over the
+ VRF instance. These LSPs MUST be reoptimized using "make-before-
+ break" [RFC3209].
+
+ In this case, it is desirable for a CE to be configured with regard
+ to the timer-based or event-driven reoptimization. Furthermore,
+ customers SHOULD be able to reoptimize a C-TE LSP manually. To
+ provide for delay-sensitive or jitter-sensitive traffic (i.e., voice
+ traffic), C-TE LSP path computation and route selection are expected
+ to be optimal for the specific application.
+
+6.12. DS-TE Support for C-TE LSPs
+
+ The solution MUST support DS-TE [RFC4124] for a C-TE LSP over the VRF
+ instance. In the event that the service provider and the customer
+ have differing bandwidth constraint models, then only the service-
+ provider bandwidth model should be supported.
+
+ Applications, which have different traffic characteristics, are used
+ in BGP/MPLS IP-VPN environments. Service providers try to achieve
+ the fine-grained optimization of transmission resources, efficiency,
+ and further-enhanced network performance. It may be desirable to
+ perform TE at a per-class level.
+
+
+
+Kumaki, et al. Informational [Page 17]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ By mapping the traffic from a given Diffserv class of service on a
+ separate C-TE LSP, DS-TE allows this traffic to utilize resources
+ available to the given class on both shortest paths and non-shortest
+ paths, and also to follow paths that meet TE constraints that are
+ specific to the given class.
+
+7. Detailed Requirements for the C-RSVP Path Model
+
+ This section describes detailed requirements for C-RSVP paths in
+ BGP/MPLS IP-VPN environments.
+
+7.1. Admission Control between PE and CE for C-RSVP Paths
+
+ The solution MUST support admission control at the ingress PE. PEs
+ MUST control RSVP messages per a VRF instance.
+
+7.2. Aggregation of C-RSVP Paths by P-TE LSPs
+
+ The solution SHOULD support C-RSVP paths aggregated by P-TE LSPs.
+ P-TE LSPs SHOULD be pre-established manually or dynamically by
+ operators and MAY be established if triggered by C-RSVP messages.
+ Also, the P-TE LSP SHOULD support DS-TE.
+
+7.3. Non-TE LSP Support for C-RSVP Paths
+
+ The solution SHOULD support non-TE LSPs (i.e., LDP-based LSP, etc.).
+ Non-TE LSPs are established by LDP [RFC5036] between PEs and support
+ MPLS Diffserv [RFC3270]. The solution MAY support local policies to
+ map the customer's reserved flow to the LSP with the appropriate
+ Traffic Class at the PE.
+
+7.4. Transparency of C-RSVP Paths
+
+ The solution SHOULD NOT change RSVP messages from the local CE to the
+ remote CE (Path, Resv, Path Error, Resv Error, etc.). The solution
+ SHOULD allow customers to receive RSVP messages transparently between
+ CE sites.
+
+8. Commonly Detailed Requirements for Two Models
+
+ This section describes commonly detailed requirements for C-TE LSPs
+ and C-RSVP paths in BGP/MPLS IP-VPN environments.
+
+8.1. CE-PE Routing
+
+ The solution SHOULD support the following routing configuration on
+ the CE-PE links with either RSVP or RSVP-TE on the CE-PE link:
+
+
+
+
+Kumaki, et al. Informational [Page 18]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ 1. static routing
+ 2. BGP routing
+ 3. OSPF
+ 4. OSPF-TE (RSVP-TE case only)
+
+8.2. Complexity and Risks
+
+ The solution SHOULD avoid introducing unnecessary complexity to the
+ current operating network to such a degree that it would affect the
+ stability and diminish the benefits of deploying such a solution over
+ SP networks.
+
+8.3. Backward Compatibility
+
+ The deployment of C-RSVP paths and C-TE LSPs SHOULD avoid impacting
+ existing RSVP and MPLS-TE mechanisms, respectively, but should allow
+ for a smooth migration or co-existence.
+
+8.4. Scalability Considerations
+
+ The solution SHOULD minimize the impact on network scalability from a
+ C-RSVP path and a C-TE LSP over the VRF instance. As identified in
+ earlier sections, PCE provides a method for offloading computation of
+ C-TE LSPs and helps with the solution scalability.
+
+ The solution MUST address the scalability of C-RSVP paths and
+ C-TE LSPs for the following protocols.
+
+ 1. RSVP (e.g., number of RSVP messages, retained state, etc.).
+ 2. RSVP-TE (e.g., number of RSVP control messages, retained state,
+ message size, etc.).
+ 3. BGP (e.g., number of routes, flaps, overload events, etc.).
+
+8.5. Performance Considerations
+
+ The solution SHOULD be evaluated with regard to the following
+ criteria.
+
+ 1. Degree of path optimality of the C-TE LSP.
+ 2. TE LSP setup time.
+ 3. Failure and restoration time.
+ 4. Impact and scalability of the control plane due to added overhead.
+ 5. Impact and scalability of the data/forwarding plane due to added
+ overhead.
+
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 19]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+8.6. Management Considerations
+
+ The solution MUST address the manageability of C-RSVP paths and
+ C-TE LSPs for the following considerations.
+
+ 1. Need for a MIB module for the control plane (including mapping of
+ P-TE LSPs and C-TE LSPs) and bandwidth monitoring.
+ 2. Need for diagnostic tools (this includes traceroute and Ping).
+
+ The solution MUST allow routers to support the MIB module for C-RSVP
+ paths and C-TE LSPs per a VRF instance. If a CE is managed by
+ service providers, the solution MUST allow service providers to
+ collect MIB information for C-RSVP paths and C-TE LSPs from the CE
+ per a customer.
+
+ Diagnostic tools can detect failures of the control plane and data
+ plane for general MPLS-TE LSPs [RFC4379]. The solution MUST allow
+ routers to be able to detect failures of the control plane and the
+ data plane for C-TE LSPs over a VRF instance.
+
+ MPLS Operations, Administration, and Maintenance (OAM) for C-TE LSPs
+ MUST be supported within the context of VRF, except for the above.
+
+9. Security Considerations
+
+ Any solution should consider the following general security
+ requirements:
+
+ 1. The solution SHOULD NOT divulge the service-provider topology
+ information to the customer network.
+ 2. The solution SHOULD minimize the service-provider network's
+ vulnerability to Denial of Service (DoS) attacks.
+ 3. The solution SHOULD minimize the misconfiguration of DSCP marking,
+ preemption, and holding priorities of the customer traffic.
+
+ The following additional security issues for C-TE LSPs relate to both
+ the control plane and the data plane.
+
+ In terms of the control plane, in both the C-RSVP path and C-TE LSP
+ models, a PE receives IPv4 or IPv6 RSVP control packets from a CE.
+ If the CE is a router that is not trusted by service providers, the
+ PE MUST be able to limit the rate and number of IPv4 or IPv6 RSVP
+ control packets.
+
+ In terms of the data plane, in the C-TE LSP model, a PE receives
+ labeled IPv4 or IPv6 data packets from a CE. If the CE is a router
+ that is not trusted by service providers, the PE MUST be able to
+ limit the rate of labeled IPv4 or IPv6 data packets. If the CE is a
+
+
+
+Kumaki, et al. Informational [Page 20]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ trusted router for service providers, the PE MAY be able to limit the
+ rate of labeled IPv4 or IPv6 data packets. Specifically, the PE must
+ drop MPLS-labeled packets if the MPLS label was not assigned over the
+ PE-CE link on which the packet was received. The PE must also be
+ able to police traffic to the traffic profile associated with the LSP
+ on which traffic is received on the PE-CE link.
+
+ Moreover, flooding RSVP/RSVP-TE control packets from malicious
+ customers must be avoided. Therefore, a PE MUST isolate the impact
+ of such customers' RSVP/RSVP-TE packets from other customers.
+
+ In the event that C-TE LSPs are diversely routed over VRF instances,
+ the VRF should indicate to the CE how such diversity was provided.
+
+10. References
+
+10.1. Normative References
+
+ [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated
+ Services in the Internet Architecture: an Overview",
+ RFC 1633, June 1994.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
+ Services", RFC 2210, September 1997.
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
+ Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions
+ to RSVP for LSP Tunnels", RFC 3209, December 2001.
+
+ [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
+ Vaananen, P., Krishnan, R., Cheval, P., and
+ J. Heinanen, "Multi-Protocol Label Switching (MPLS)
+ Support of Differentiated Services", RFC 3270,
+ May 2002.
+
+ [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Signaling Resource ReserVation
+ Protocol-Traffic Engineering (RSVP-TE) Extensions",
+ RFC 3473, January 2003.
+
+ [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful
+ OSPF Restart", RFC 3623, November 2003.
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 21]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed.,
+ "Fast Reroute Extensions to RSVP-TE for LSP Tunnels",
+ RFC 4090, May 2005.
+
+ [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support
+ of Diffserv-aware MPLS Traffic Engineering", RFC 4124,
+ June 2005.
+
+ [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+ Networks (VPNs)", RFC 4364, February 2006.
+
+ [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+ Label Switched (MPLS) Data Plane Failures", RFC 4379,
+ February 2006.
+
+ [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+ Computation Element (PCE)-Based Architecture",
+ RFC 4655, August 2006.
+
+ [RFC4781] Rekhter, Y. and R. Aggarwal, "Graceful Restart
+ Mechanism for BGP with MPLS", RFC 4781, January 2007.
+
+ [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas,
+ Ed., "LDP Specification", RFC 5036, October 2007.
+
+ [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label
+ Switching (MPLS) Label Stack Entry: "EXP" Field
+ Renamed to "Traffic Class" Field", RFC 5462,
+ February 2009.
+
+10.2. Informative References
+
+ [RSVP-L3VPN] Davie, B., Le Faucheur, F., and A. Narayanan, "Support
+ for RSVP in Layer 3 VPNs", Work in Progress,
+ November 2009.
+
+ [RFC4804] Le Faucheur, F., Ed., "Aggregation of Resource
+ ReSerVation Protocol (RSVP) Reservations over MPLS
+ TE/DS-TE Tunnels", RFC 4804, February 2007.
+
+ [RFC5330] Vasseur, JP., Ed., Meyer, M., Kumaki, K., and
+ A. Bonda, "A Link-Type sub-TLV to Convey the Number of
+ Traffic Engineering Label Switched Paths Signalled
+ with Zero Reserved Bandwidth across a Link", RFC 5330,
+ October 2008.
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 22]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
+ Computation Element (PCE) Communication Protocol
+ (PCEP)", RFC 5440, March 2009.
+
+11. Acknowledgments
+
+ The authors would like to express thanks to Nabil Bitar,
+ David McDysan, and Daniel King for their helpful and useful comments
+ and feedback.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 23]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+Appendix A. Reference Model
+
+ In this appendix, a C-RSVP path, a C-TE LSP, and a P-TE LSP are
+ explained.
+
+ All scenarios in this appendix assume the following:
+
+ - A P-TE LSP is established between PE1 and PE2. This LSP is used by
+ the VRF instance to forward customer packets within a BGP/MPLS
+ IP-VPN.
+
+ - The service provider has ensured that enough bandwidth is available
+ to meet the service requirements.
+
+A.1. End-to-End C-RSVP Path Model
+
+ A C-RSVP path and a P-TE LSP are shown in Figure 7, in the context of
+ a BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e., LDP) in
+ some cases. In the case of a non-TE mechanism, however, it may be
+ difficult to guarantee an end-to-end bandwidth, as resources are
+ shared.
+
+ CE0/CE1 requests an e2e C-RSVP path to CE3/CE2 with the bandwidth
+ reservation of X. At PE1, this reservation request received in the
+ context of a VRF will get aggregated onto a pre-established P-TE LSP,
+ or trigger the establishment of a new P-TE LSP. It should be noted
+ that C-RSVP sessions across different BGP/MPLS IP-VPNs can be
+ aggregated onto the same P-TE LSP between the same PE pair, achieving
+ further scalability. [RFC4804] defines this scenario in more detail.
+
+ The RSVP control messages (e.g., an RSVP PATH message and an RSVP
+ RESV message) exchanged among CEs are forwarded by IP packets through
+ the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a reservation
+ message from CE2 and/or CE3, CE0/CE1 establishes a C-RSVP path
+ through the BGP/MPLS IP-VPN.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 24]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ C-RSVP path
+ <------------------------------------------>
+
+ P-TE LSP
+ <--------------------------->
+ ............. .............
+ . --- --- . --- --- --- --- . --- --- .
+ .|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
+ . --- --- . --- --- --- --- . --- --- .
+ ............. .............
+ ^ ^
+ | |
+ VRF instance VRF instance
+
+ <-customer-> <------BGP/MPLS IP-VPN------> <-customer->
+ network network
+ or or
+ another another
+ service-provider service-provider
+ network network
+
+ Figure 7. e2e C-RSVP Path Model
+
+A.2. End-to-End C-TE LSP Model
+
+ A C-TE LSP and a P-TE LSP are shown in Figure 8, in the context of a
+ BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e., LDP) in some
+ cases. As described in the previous sub-section, it may be difficult
+ to guarantee an end-to-end QoS in some cases.
+
+ CE0/CE1 requests an e2e TE LSP path to CE3/CE2 with the bandwidth
+ reservation of X. At PE1, this reservation request received in the
+ context of a VRF will get aggregated onto a pre-established P-TE LSP,
+ or trigger the establishment of a new P-TE LSP. It should be noted
+ that C-TE LSPs across different BGP/MPLS IP-VPNs can be aggregated
+ onto the same P-TE LSP between the same PE pair, achieving further
+ scalability.
+
+ The RSVP-TE control messages (e.g., an RSVP PATH message and an RSVP
+ RESV message) exchanged among CEs are forwarded by a labeled packet
+ through the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a
+ reservation message from CE2 and/or CE3, CE0/CE1 establishes a
+ C-TE LSP through the BGP/MPLS IP-VPN.
+
+ A P-TE LSP is established between PE1 and PE2. This LSP is used by
+ the VRF instance to forward customer packets within the BGP/MPLS
+ IP-VPN.
+
+
+
+
+Kumaki, et al. Informational [Page 25]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+ C-TE LSP
+ <------------------------------------------------------->
+
+ or
+
+ C-TE LSP
+ <----------------------------------------->
+
+ P-TE LSP
+ <--------------------------->
+ ............. .............
+ . --- --- . --- --- --- --- . --- --- .
+ .|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
+ . --- --- . --- --- --- --- . --- --- .
+ ............. .............
+ ^ ^
+ | |
+ VRF instance VRF instance
+
+ <-customer-> <-------BGP/MPLS IP-VPN-------> <-customer->
+ network network
+ or or
+ another another
+ service-provider service-provider
+ network network
+
+ Figure 8. e2e C-TE LSP Model
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 26]
+
+RFC 5824 Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010
+
+
+Authors' Addresses
+
+ Kenji Kumaki (Editor)
+ KDDI Corporation
+ Garden Air Tower
+ Iidabashi, Chiyoda-ku
+ Tokyo 102-8460, JAPAN
+ EMail: ke-kumaki@kddi.com
+
+
+ Raymond Zhang
+ BT
+ Farady Building, PP1.21
+ 1 Knightrider Street
+ London EC4V 5BT
+ UK
+ EMail: raymond.zhang@bt.com
+
+
+ Yuji Kamite
+ NTT Communications Corporation
+ Granpark Tower
+ 3-4-1 Shibaura, Minato-ku
+ Tokyo 108-8118
+ Japan
+ EMail: y.kamite@ntt.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumaki, et al. Informational [Page 27]
+