Network Working Group K. Kumaki, Ed.
Internet Draft KDDI R&D Labs
Intended Status: Informational R. Zhang
Created: July, 2009 BT
Expires: December, 2009 Y. Kamite
NTT Communications
Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS
IP-VPN
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 December 6, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
K.Kumaki, et al. [Page 1]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
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.
Abstract
Today, customers expect to run triple play services through BGP/MPLS
IP-VPNs. Some Service Providers will deploy services that request QoS
guarantees from a local CE to a remote CE across the network. As a
result, the application (e.g., voice, video, bandwidth-guaranteed
data pipe, etc.) requirements for end-to-end QOS and reserving
adequate bandwidth continue to increase.
Service Providers can use both MPLS and an MPLS-TE LSP to meet the
service objectives. This document describes service provider
requirements for supporting customer RSVP and RSVP-TE over a
BGP/MPLS IP-VPN.
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].
K.Kumaki, et al. [Page 2]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
Table of Contents
1. Introduction..................................................4
2. Terminology...................................................5
3. Problem Statement.............................................5
4. Reference Model...............................................7
4.1 End-to-End C-RSVP Path Model..............................8
4.2 End-to-End C-TE LSP Model.................................9
5. Application Scenarios.........................................10
5.1 Scenario I: Fast Recovery over BGP/MPLS IP-VPN............10
5.2 Scenario II: Strict C-TE LSP QoS Guarantees...............10
5.3 Scenario III: Load Balance of CE-to-CE Traffic............11
5.4 Scenario IV: RSVP Aggregation over MPLS TE Tunnels........13
5.5 Scenario V: RSVP over Non-TE LSP..........................14
5.6 Scenario VI: RSVP-TE over Non-TE LSP......................15
6. Detailed Requirements for C-TE LSPs Model.....................16
6.1 Selective P-TE LSPs......................................16
6.2 Graceful Restart Support for C-TE LSPs...................16
6.3 Rerouting Support for C-TE LSPs..........................16
6.4 FRR Support for C-TE LSPs................................16
6.5 Admission Control Support on P-TE LSP Head-Ends..........17
6.6 Admission Control Support for C-TE LSPs in LDP-based Core
Networks......................................................17
6.7 Policy Control Support for C-TE LSPs.....................18
6.8 PCE Features Support for C-TE LSPs.......................18
6.9 Diversely Routed C-TE LSPs Support.......................18
6.10 Optimal Path Support for C-TE LSPs.......................19
6.11 Reoptimization Support for C-TE LSPs.....................19
6.12 DS-TE Support for C-TE LSPs..............................19
7. Detailed Requirements for C-RSVP Paths Model..................19
7.1 Admission Control between PE-CE for C-RSVP Paths..........19
7.2 Aggregation of C-RSVP Paths by P-TE LSPs..................20
7.3 Non-TE LSPs support for C-RSVP Paths......................20
7.4 Transparency of C-RSVP Paths..............................20
8. Common Detailed Requirements for Two Models...................20
8.1 CE-PE Routing............................................20
8.2 Complexity and Risks.....................................20
8.3 Backward Compatibility...................................20
8.4 Scalability Considerations...............................21
8.5 Performance Considerations...............................21
8.6 Management Considerations................................21
9. Security Considerations.......................................22
10. IANA Considerations..........................................22
11. References...................................................23
11.1 Normative References.....................................23
11.2 Informative References...................................23
12. Acknowledgments..............................................24
13. Author's Addresses...........................................24
K.Kumaki, et al. [Page 3]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
1. Introduction
Some Service Providers want to build a service which guarantees QoS
and bandwidth from a local CE to a remote CE through the network.
A CE includes 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 through BGP/MPLS
IP-VPNs [RFC4364]. As these services evolve, the requirements for
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.), native IP using RSVP and/or
an end-to-end constrained MPLS-TE Label Switched Path (LSP) may be
required. The RSVP path may be used to provide QoS guarantees and
reserve adequate bandwidth for the data. An end-to-end MPLS-TE LSP
may also be used to guarantee bandwidth, and provide extended
functionality like MPLS fast reroute (FRR) [RFC4090] for
maintaining service continuity around node and link, including 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 whilst being able to use both private addresses and
global addresses. The second advantage is that traffic is
tunneled through the Service Provider backbone, so that
customer traffic and route confidentiality is maintained.
This document defines a reference model, example application
scenarios and detailed requirements for a solution supporting
customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN.
Specification for a solution is out of scope in this document.
K.Kumaki, et al. [Page 4]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
2. Terminology
This document uses BGP/MPLS IP VPN terminology defined in [RFC4364].
The document also uses Path Computation Element terms which are
defined in [RFC4655].
TE LSP: Traffic Engineering Label Switched Path
MPLS TE LSP: Multi Protocol Label Switching TE LSP
C-RSVP path: Customer RSVP path: a native RSVP path with 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 PEs
Head-end LSR: ingress LSR
Tail-end LSR: egress LSR
LSR: Label Switched Router
3. 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 RSVP signaling for native IP flows C-RSVP) or 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 bandwidth reservation of X can be used to
transport voice. In order to achieve sub-50msec recovery during
link/node/SRLG failure 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.
K.Kumaki, et al. [Page 5]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
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
bandwidth reservation of X to the remote CE/host. However, if a C-
RSVP signaling is to send within VPN, the service provider network
will face scalability issues. Therefore, in order to solve
scalability issues, multiple C-RSVP reservations can be aggregated at
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 VRF 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 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 of solutions is described in
[RSVP-L3VPN].
If service providers offer a C-TE LSP from CE to CE over BGP/MPLS IP-
VPN, they require that a MPLS TE LSP from a local CE to a remote CE
be established. However, if a C-TE LSP signaling is to send within
VPN, the service provider network may face the following scalability
issues:
- A C-TE LSP can be aggregated by a P-TE LSP at PE. (i.e.
hierarchical LSPs) In this case, only PEs maintain state about
customer RSVP-TE sessions.
- A C-TE LSP cannot be aggregated by a P-TE LSP at PE depending on
some policies. (i.e. contiguous LSPs) In this case, both
Ps and PEs maintain state about customer RSVP sessions.
- A C-TE LSP can be aggregated by non-TE LSP (i.e. LDP). In this
case, only PEs maintain state about customer RSVP-TE sessions. Note
that there it is assumed their always enough bandwidth available
in service provider core network
Furthermore, if service providers provide the C-TE LSP over a
BGP/MPLS IP-VPN, they currently cannot provide it over VRF instance
as defined in RFC4364. Specifically the current BGP/MPLS IP-VPN
architecture does not support an 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 dynamic signaling of these P-TE LSPs. Section 8.4,
Scalability Considerations, of this document provides detailed
scalability requirements.
K.Kumaki, et al. [Page 6]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
Two different models are 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. Selection may be
dependent on the Service Providers policy and node capability to
support the mechanisms described.
The following items are required selectively 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. Some service providers need some of them to
provide a service. It depends on a service level and a policy of
service providers. Detailed requirements are described in sections 6,
7 and 8.
- C-RSVP path QoS guarantees.
- Fast recovery over BGP/MPLS IP-VPN to protect traffic for 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.
4. Reference Model
In this section, a C-RSVP path, a C-TE LSP and a P-TE LSP are
explained.
All scenarios in this section 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 BGP/MPLS IP-
VPN
- The Service Provider has ensured that enough bandwidth is available
to meet the service requirements.
[Editors Note] In a future version of this document this section,
Reference Model, will be moved to an appendix. Editor notes will be
removed in the final version of this document.
K.Kumaki, et al. [Page 7]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
4.1 End-to-End C-RSVP Path Model
A C-RSVP path and a P-TE LSP are shown in figure 1 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 non-TE mechanism, however, it may
be difficult to guarantee end-to-end bandwidth as resources are
shared.
CE0/CE1 requests an e2e C-RSVP path to CE3/CE2 with 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
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.
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 1 e2e C-RSVP path model
K.Kumaki, et al. [Page 8]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
4.2 End-to-End C-TE LSP Model
A C-TE LSP and a P-TE LSP are shown in figure 2 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 previous sub-section, it may be difficult to
guarantee end-to-end QoS in some cases.
CE0/CE1 requests an e2e TE LSP path to CE3/CE2 with 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. a RSVP PATH message and a RSVP
RESV message) exchanged among CEs are forwarded by labeled packet
through 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 BGP/MPLS IP-
VPN.
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 2 e2e C-TE LSP model
K.Kumaki, et al. [Page 9]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
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.
5.1 Scenario I: Fast Recovery over BGP/MPLS IP-VPN
In this scenario, as shown in figure 3, a customer uses a VoIP
application between its sites (i.e., between CE1 and CE2). H0 and H1
are 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 PE1 fails, C-TE LSP1 needs C-TE LSP2 as a path protection.
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 3 Scenario I
5.2 Scenario II: Strict C-TE LSP QoS Guarantees
In this scenario, as shown in figure 4, a service provider B
transports voice and video traffic between its sites (i.e., between
CE1 and CE2).
K.Kumaki, et al. [Page 10]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
In this case, service provider B establishes C-TE LSP1 with
preemption priority 0 and bandwidth 100Mbps for voice traffic, and C-
TE LSP2 with preemption priority 1 and bandwidth 200Mbps for unicast
video traffic. On the other hand, service provider A also pre-
establishes P-TE LSP1 with preemption priority 0 and bandwidth 1Gbps
for voice traffic, and P-TE LSP2 with preemption priority 1 and
bandwidth 2Gbps for video traffic. These P-TE LSP1 and P-TE LSP2
should support DS-TE. [RFC4124]
PE1 and PE3 should choose an appropriate P-TE LSP based on 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 max 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 4 Scenario II
Its possible that the customer and service provider have differing
preemption priorities. In this case then the PE policy will overide
the customers. In the case that service provider does not support
premption priorities then priorities should be ignored.
5.3 Scenario III: Load Balance of CE-to-CE Traffic
In this scenario, as shown in figure 5, service provider 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 are voice and video equipment.
K.Kumaki, et al. [Page 11]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
In this case, service provider C establishes C-TE LSP1, C-TE LSP3, C-
TE LSP5 and C-TE LSP7 with preemption priority 0 and bandwidth
100Mbps for voice traffic, and establishes C-TE LSP2, C-TE LSP4, C-TE
LSP6 and C-TE LSP8 with preemption priority 1 and bandwidth 200Mbps
for video traffic. On the other hand, service provider A also pre-
establishes P-TE LSP1 and P-TE LSP3 with preemption priority 0 and
bandwidth 1Gbps for voice traffic, and P-TE LSP2 and P-TE LSP4 with
preemption priority 1 and bandwidth 2Gbps for video traffic. These 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 preemption
priority. To minimize the traffic disruption due to a single network
failure, diversely routed C-TE LSPs are established. In this case,
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, load balancing for a communication between H0 and H1 can
be done by setting up full mesh C-TE LSPs between CE0/CE2 and
CE5/CE7.
K.Kumaki, et al. [Page 12]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
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 5 Scenario III
5.4 Scenario IV: RSVP Aggregation over MPLS TE Tunnels
In this scenario, as shown in figure 6, the customer has two hosts
connecting off 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 to H2 an RSVP path
with 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
map the incoming RSVP path request from H1 to the P-TE LSP with the
appropriate class-type. Please note that the e2e RSVP path request
may also be initiated by the CE devices themselves.
K.Kumaki, et al. [Page 13]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
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 6 Scenario IV
5.5 Scenario V: RSVP over Non-TE LSP
In this scenario, as shown in figure 7, a customer has two hosts
connecting off 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 to H2 an RSVP path
with 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
bandwidth reservation as is done with RSVP-TE.
Local policies can be implemented to map customer's reserved flow to
the LSP with the appropriate EXP at PE1.
K.Kumaki, et al. [Page 14]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
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 7 Scenario V
5.6 Scenario VI: RSVP-TE over Non-TE LSP
In this scenario, as shown in figure 8, a customer uses a VoIP
application between its sites (i.e., between CE1 and CE2). H0 and H1
are 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 PE1 fails,
C-TE LSP1 needs C-TE LSP2 as a path protection.
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 8 Scenario VI
K.Kumaki, et al. [Page 15]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
6. Detailed Requirements for C-TE LSPs 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 LSP a PE
uses for a C-RSVP path and a C-TE LSP. When a PE receives a native
RSVP and/or a path messages from a CE, it MUST be able to decide
which P-TE LSP it uses. In this case, various kinds of P-TE LSPs
exist in 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: (DSCP or EXP bits)
6.2 Graceful Restart Support for C-TE LSPs
The solution SHOULD support the graceful restart capability, where 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].
6.3 Rerouting Support for C-TE LSPs
The solution MUST provide rerouting of a C-TE LSP in case of
link/node/SRLG failures or preemption. Such rerouting may be
controlled by a CE or by a PE depending on the failure. In a dual
homed enviroment, the ability to perform rerouting MUST be
provided against a CE-PE link failure or a PE failure if another
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
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.
K.Kumaki, et al. [Page 16]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
The following protection MUST be supported:
1. CE-PE link protection
2. PE node protection
3. CE node protection (supposed that there are one or more C-TE nodes
at customer sites)
[Editors Note] Further scenarios will be added in the next version
of this document Editor notes will be removed in the final
version of this document.
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
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 perform local policy bandwidth admission
2. Set a cap on the amount of CE and VRF bandwidth and have the
configuration option to:
a. Reserve the minimum of the 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
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
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 per a vrf instance (i.e. per a 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.
[Editors Note] Further scenarios will be added in the next version
of this document Editor notes will be removed in the final
version of this document.
K.Kumaki, et al. [Page 17]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
6.7 Policy Control Support for C-TE LSPs
The solution MUST support policy control for a C-TE LSP at a PE.
The PE MUST be able to perform at least the following:
1. Limit the rate of RSVP-TE messages per PE-CE link
2. Accept or reject requests for a given affinity
3. Accept or reject requests with a specified setup and/or pre-
emption priorities.
4. Accept or reject requests for fast reroutes
5. Neglect the requested setup and/or pre-emption priorities and
select a P-TE LSP based on a local policy that applies to the CE-PE
link or 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 VRF.
7. Perform mapping in data plane between customer exp bits and
transport P-TE LSP exp bits, as signaled per [RFC3270[.
6.8 PCE Features Support for C-TE LSPs
The solution SHOULD support 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 [RFC4655] and [RFC5440]
features.
In this case, CE routers or PE routers may be 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 LSPs Support
The solution MUST provide for setting up diversely routed C-TE LSPs
over VRF instance. These diverse C-TE LSPs MAY be traversing over
two different P-TE LSPs that are fully disjoint within a service
provider network. When a single CE has multiple uplinks which connect
to different PEs, it is desirable that multiple C-TE LSPs over VRF
instance are established between a pair of LSRs. When two CEs have
multiple uplinks which connect to different PEs, it is desirable that
multiple C-TE LSPs over VRF instance are established between two
different pairs of LSRs. In these cases, for example, the following
points will be beneficial to customers.
1. load balance of CE-to-CE traffic across diverse C-TE LSPs so as to
minimize the traffic disruption in case of a single network element
or link failure.
2. path protection (e.g. 1:1, 1:N)
K.Kumaki, et al. [Page 18]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
6.10 Optimal Path Support for C-TE LSPs
The solution MUST support an optimal path for a C-TE LSP over VRF
instance. Depending on an application (e.g. voice and video), an
optimal path is needed for a C-TE LSP over vrf instance. An optimal
path may be a shortest path based on TE metric, in the case of a
TE-LSP or IGP metric, in the case of LDP.
6.11 Reoptimization Support for C-TE LSPs
The solution MUST support reoptimization of a C-TE LSP over VRF
instance. These LSPs MUST be reoptimized using make-before-break.
In this case, it is desirable for a CE to be configured with
regard to timer-based or event-driven reoptimization. Furthermore,
customers SHOULD be able to reoptimize a C-TE LSP manually. To
provide delay-sensitive or jitter-sensitive traffic (i.e.
voice traffic), a C-TE LSP path computation and route selection is
expected to 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 vrf
instance.
Applications, which have different traffic characteristics, are used
in BGP/MPLS IP-VPN environments. Service providers try to achieve
fine-grained optimization of transmission resources, efficiency and
further enhanced network performance. It may be desirable to perform
TE at a per-class level.
By mapping the traffic from a given diff-serv class of service on a
separate C-TE LSP, it allows this traffic to utilize resources
available to the given class on both shortest paths and non-shortest
paths, and follow paths that meet TE constraints which are specific
to the given class.
7. Detailed Requirements for C-RSVP Paths Model
This section describes detailed requirements for C-RSVP paths in
BGP/MPLS IP-VPN environments.
7.1 Admission Control between PE-CE for C-RSVP Paths
The solution MUST support admission control at the ingress/egress PE.
PEs MUST be able to control the amount of RSVP messages per a VRF.
K.Kumaki, et al. [Page 19]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
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 by manually or dynamically, MAY
be established triggered by C-RSVP message. Also, P-TE LSP SHOULD
support DS-TE.
7.3 Non-TE LSPs support for C-RSVP Paths
The solution SHOULD support non-TE LSPs (i.e. LDP-based LSP,
etc). They are provided between PEs and supports MPLS diffserv
[RFC3270]. Local policies can be implemented to map customer's
reserved flow to the LSP with the appropriate EXP at PE.
7.4 Transparency of C-RSVP Paths
The solution SHOULD NOT change RSVP messages from local CE to remote
CE (Path, Resv, Path Error, Resv Error, etc). Customers SHOULD
receive RSVP messages transparently between CE sites.
8. Common Detailed Requirements for Two Models
This section describes common detailed requirements for C-TE LSPs and
C-RSVP paths in BGP/MPLS IP-VPN environments.
8.1 CE-PE Routing
The solution MUST support the following routing configuration on the
CE-PE links with either RSVP or RSVP-TE on the CE-PE link:
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
allow for a smooth migration or co-existence.
K.Kumaki, et al. [Page 20]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
8.4 Scalability Considerations
The solution should minimize impact on network scalability from a
C-RSVP path and a C-TE LSP over VRF instance. As indentified in
earlier sections, PCE provides a method for offloading
computation of C-TE LSPs and help with solution scalability.
Scalability of C-RSVP paths and C-TE LSPs MUST address the following
consideration.
1. RSVP (e.g. number and rate of RSVP messages, retained state etc).
2. RSVP-TE (e.g. number and rate of RSVP control messages, retained
state, message size etc).
3. BGP (e.g. number of routes, flaps, overloads 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. C-TE LSP setup time.
3. Failure detection and restoration time.
4. Impact and scalability of the control plane due to added
overheads and so on.
5. Impact and scalability of the data/forwarding plane due to added
overheads and so on.
8.6 Management Considerations
Manageability of C-RSVP paths and C-TE LSPs MUST addresses the
following considerations.
1. Need for a MIB module for control plane and monitoring.
2. Need for diagnostic tools (this include Trace Route and PING)
MIB module for C-RSVP paths and C-TE LSPs MUST collect per a vrf
instance.
If a CE is managed by service providers, MIB information for C-RSVP
paths and C-TE LSPs from the CE MUST be collected per a customer.
Diagnostic tools can detect failures of control plane and data
plane for general MPLS TE LSPs [RFC4379]. Any diagnostic tool
MUST be capable of detecting failures of the control and data plane
for C-TE LSPs over a VRF instance.
MPLS OAM for C-TE LSPs MUST be supported within the context of VRF
except for the above.
K.Kumaki, et al. [Page 21]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
9. Security Considerations
Security issues for C-TE LSPs relate to both control plane and data
plane.
In terms of control plane, in the models of C-RSVP paths and C-TE
LSPs both, a PE receives IPv4 or IPv6 RSVP control packets from a CE.
If the CE is an untrusted router for service providers, the PE MUST
be able to limit the rate and number of IPv4 or IPv6 RSVP control
packets. If the CE is a trusted router for service providers, the PE
MAY be able to limit IPv4 or IPv6 control packets.
In terms of data plane, in the model of C-TE LSPs, a PE receives
labeled IPv4 or IPv6 data packets from a CE. If the CE is an
untrusted router for service providers, the PE MUST be able to limit
labeled IPv4 or IPv6 data packets. If the CE is a trusted router for
service providers, the PE MAY be able to limit 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 customer's RSVP/ RSVP-TE packets from other customers.
In BGP/MPLS IP-VPN environments, from a CE point of view, IP TTL
should decrease at a local PE and a remote PE to hide service
provider network topology.
[Editors Note] Further security considerations are being evaluated
and the authors expect to document further requirements in this
section. This editor note will be removed in the final version of
this document.
10. IANA Considerations
This requirement document makes no requests for IANA action.
K.Kumaki, et al. [Page 22]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
11. References
11.1 Normative References
[RFC1633] Braden, R., et al., "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.
[RFC3270] Le Faucheur, F., "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270, May 2002.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January
2003.
[RFC3623] Moy, J., et al., "Graceful OSPF Restart", RFC3623,
November 2003.
[RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124, June
2005.
[RFC4364] Rosen, E., and Rekhter, Y., "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4379] Kompella, K. and G. Swallow, "Detecting MPLS Data Plane
Failures", RFC 4379, February 2006.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "Path Computation
Element (PCE) Architecture", RFC 4655, August 2006.
[RFC4781] Rekhter, Y., and Aggarwal, R., "Graceful Restart
Mechanism for BGP with MPLS", RFC 4781, January 2007.
11.2 Informative References
[RSVP-L3VPN] Davie, B., et al., "Support for RSVP in Layer 3 VPNs",
Work in Progress, May 2009.
K.Kumaki, et al. [Page 23]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC4804] Le Faucheur, F., et al., "Aggregation of RSVP
Reservations over MPLS TE/DS-TE Tunnels", RFC4804,
February 2007.
[RFC5330] Vasseur, J.-P., et al., "A Link-Type sub-TLV to
convey the number of Traffic Engineering Label
Switched Paths signaled with zero reserved bandwidth
across a link", RFC5330, October 2008.
12. Acknowledgments
The author would like to express the thanks to Nabil Bitar,
David McDysan and Daniel King for their helpful comments and
feedback.
13. Author's Addresses
Kenji Kumaki (Editor)
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Email: ke-kumaki@kddi.com
Raymond Zhang
BT Infonet
2160 E. Grand Ave.
El Segundo, CA 90025
Email: raymond.zhang@bt.infonet.com
Yuji Kamite
NTT Communications Corporation
Tokyo Opera City Tower
3-20-2 Nishi Shinjuku, Shinjuku-ku
Tokyo 163-1421, Japan
Email: y.kamite@ntt.com
K.Kumaki, et al. [Page 24]
draft-ietf-l3vpn-e2e-rsvp-te-reqts-03 July 2009