One document matched: draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05.txt
Differences from draft-kumaki-l3vpn-e2e-rsvp-te-reqts-04.txt
Network Working Group
Internet Draft K. Kumaki, Ed.
Category: Informational KDDI Corporation
Created: November 19, 2007 R. Zhang
Expires: May 19, 2008 BT
Requirements for supporting Customer RSVP and RSVP-TE Over a BGP/MPLS
IP-VPN
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Recently some service providers try to build a converged network as a
next generation network (NGN) and provide a service which guarantees
a bandwidth from a local CE to a remote CE through the network.
Today, customers expect triple play services through BGP/MPLS IP-VPNs.
And their requirements for end-to-end QoS and session management of
applications are increasing. Depending on an application, an end-to-
K.Kumaki, et al. [Page 1]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
end native RSVP path and an end-to-end MPLS TE LSP are required and
they need to meet with some constraint requirements.
This document describes Service Provider requirements for supporting
customer RSVP and RSVP-TE over a BGP/MPLS VPN.
Conventions used in this document
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].
Table of Contents
1. Introduction..................................................3
2. Terminology...................................................3
3. Problem Statement.............................................4
4. Reference model...............................................5
5. Application Scenarios..........................................7
5.1 Scenario I: Fast recovery over BGP/MPLS IP-VPN.............7
5.2 Scenario II: Strict C-TE LSP QoS guarantees................7
5.3 Scenario III: load balance of CE-to-CE traffic.............8
5.4 Scenario IV: RSVP Aggregation over MPLS TE Tunnels.........9
6. Detailed Requirements.........................................10
6.1 Selective P-TE LSPs.....................................10
6.2 Graceful Restart Support for C-TE LSPs..................10
6.3 Rerouting Support for C-TE LSPs.........................11
6.4 FRR Support for C-TE LSPs...............................11
6.5 Admission Control Support on P-TE LSP Head-Ends.........11
6.6 Policy Control Support for C-TE LSPs....................11
6.7 PCE Features Support for C-TE LSPs......................12
6.8 Diversely Routed C-TE LSPs Support......................12
6.9 Optimal Path Support for C-TE LSPs......................12
6.10 Reoptimization Support for C-TE LSPs....................12
6.11 DS-TE Support for C-RSVP paths and C-TE LSPs............13
6.12 CE-PE Routing...........................................13
6.13 RSVP requirements.......................................13
6.14 Complexity and Risks....................................13
6.15 Backward Compatibility..................................13
6.16 Scalability Considerations..............................14
6.17 Performance Considerations..............................14
6.18 Management Considerations...............................14
7. Security Considerations......................................15
8. IANA Considerations..........................................15
9. Normative References.........................................15
10.Informative References........................................16
11.Acknowledgments...............................................16
12.Author's Addresses............................................16
13.Intellectual Property Statement...............................17
K.Kumaki, et al. [Page 2]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
1. Introduction
Recently some service providers want to build a converged network as
a next generation network (NGN) and provide a service which
guarantees a bandwidth from a local CE to a remote CE through the
network.
Today, customers expect triple play services through BGP/MPLS IP-VPNs
[RFC4364]. And their requirements for end-to-end QoS and session
management of applications are increasing. Depending on an
application (e.g., voice, television, video and so on), an end-to-end
native RSVP path and an end-to-end MPLS TE LSP are required and they
need to meet with some constraint requirements. For example, an end-
to-end native RSVP path satisfies to guarantee a bandwidth, and an
end-to-end MPLS TE LSP satisfies to guarantee a bandwidth, to support
FRR features [RFC4090] and to support an optimal path.
If service providers offer the above applications in BGP/MPLS IP-VPNs,
they have the following two advantages.
The first advantage is for customers to be able to use both private
addresses and global addresses without limiting to the way of
assigning addresses. This is because service providers can assign
both private addresses and global addresses which a customer wants.
The second advantage is for service providers to be able to protect
confidentiality from customers. This is because customers join a
Virtual Routing and Forwarding (VRF) instance. Customers cannot
forward packets through the service provider's general forwarding
instance, nor can they join the service provider's intra-domain
routing or MPLS signaling domain.
Thus, it is highly desirable that some triple play services are
provided for existing customers and new customers by expanding the
existing BGP/MPLS IP-VPNs.
This document defines reference model, application scenarios and
detailed requirements for supporting customer RSVP and RSVP-TE over a
BGP/MPLS IP-VPN.
Also, specification for this solution itself is out of scope in this
document.
2. Terminology
LSP: Label Switched Path
TE LSP: Traffic Engineering Label Switched Path
MPLS TE LSP: Multi Protocol Label Switching TE LSP
K.Kumaki, et al. [Page 3]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
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 PEs for service providers
VPN: Virtual Private Network
CE: Customer Edge Equipment
PE: Provider Edge Equipment that has direct connections to CEs from
the Layer3 point of view.
P: Provider Equipment that has backbone trunk connections only.
VRF: Virtual Private Network (VPN) Routing and Forwarding Instance
PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or
route based on a network graph and applying computational
constraints.
Head-end LSR: ingress LSR
Tail-end LSR: egress LSR
LSR: Label Switched Router
3. Problem Statement
Some service providers think that they offer advanced services using
RSVP or RSVP-TE over BGP/MPLS IP-VPN. Service providers have some
application scenarios for these services. For example, a C-RSVP path
with bandwidth reservation of X is required for voice and a C-TE LSP
with guaranteed bandwidth between data center or customer sites is
required for voice, television and video. Because traffic such as
voice, television and video is very sensitive, it is required to
ensure sub-50msec recovery in link/node/SRLG, strict QoS guarantees
and optimal path depending on services. Thus, service providers or
customers can choose a C-RSVP path or a C-TE LSP depending on
services.
K.Kumaki, et al. [Page 4]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
If service providers offer a C-RSVP path between hosts or CEs over
BGP/MPLS IP-VPN, they require that a C-RSVP path from a local host to
a remote host is established. The host requests to remote host an
end-to-end C-RSVP path with bandwidth reservation of X. This
reservation request from within the context of VRF gets aggregated
onto a pre-established P-TE LSP. One of solutions is described in
[RSVP-L3VPN].
Also, 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 is established. In order to maintain a separation between
customer addressing and routing and provider addressing and routing,
service providers want to offer this service over BGP/MPLS IP-VPN
[RFC4364], that maintain the customer site to site routing. But if
service providers provide the C-TE LSP over a BGP/MPLS IP-VPN, they
can't provide it over vrf instance as defined in RFC4364. The current
BGP/MPLS IP-VPN architecture does not include 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.
Furthermore, there is a possibility that these C-TE LSPs are provided
every specific application such as voice, television and video.
In this way, service providers must maintain quite a few C-TE LSPs.
But, a C-TE LSP established over BGP/MPLS IP-VPN is not scalable due
to the number of RSVP control message and retained state because it
may result in a lot of MPLS TE LSPs in an actual BGP/MPLS IP-VPN.
Therefore, scalable C-TE LSPs are required through BGP/MPLS IP-VPN.
This problem happens in carrier's carrier environments [RFC4364] as
well as in basic BGP/MPLS IP-VPN environments.
The following items are mainly required to support C-RSVP paths and
C-TE LSPs over BGP/MPLS IP-VPN.
- 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 QoS guarantees.
- Resource optimization for C-RSVP paths and C-TE LSPs.
- Scalability for C-TE LSPs.
4. Reference model
This section describes a C-RSVP path, a C-TE LSP and a P-TE LSP in
BGP/MPLS IP-VPN.
In BGP/MPLS IP-VPN, a C-RSVP path, a C-TE LSP and a P-TE LSP are
shown in figure 1.
K.Kumaki, et al. [Page 5]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
CE0 and/or CE1 request an e2e C-RSVP path with bandwidth reservation
of X to CE2 and/or CE3 respectively. This reservation request from
within the context of VRF will get aggregated onto a pre-established
P-TE LSP.
CE0 and/or CE1 send a path message to CE2 and/or CE3 respectively
over vrf instance. The rsvp control messages (i.e. a RSVP PATH
message and a RSVP RESV message and so on) are forwarded by labeled
packet through BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a
reservation message from CE2 and/or CE3, it establishes a C-TE LSP
through BGP/MPLS IP-VPN.
A P-TE LSP is established between PE1 and PE2. This LSP is used by
vrf instance to forward customer packets within BGP/MPLS IP-VPN.
Generally speaking, C-RSVP paths and C-TE LSPs are used by customers
and P-TE LSPs are used by service providers.
C-RSVP path
<---------------------------------------------->
or
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
K.Kumaki, et al. [Page 6]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
Figure 1 Reference Model
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, a customer uses a VoIP application between its
sites (i.e., between CE1 and CE2). H0 and H1 are voice equipments.
This scenario I is shown in figure 2.
In this case, the customer establishes C-TE LSP1 which is a primary
path and C-TE LSP2 which is a backup path. If the link between PE1
and CE1 or the node (i.e., PE1) fails, C-TE LSP1 needs 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 2 Scenario I
5.2 Scenario II: Strict C-TE LSP QoS guarantees
In this scenario, service provider B controls voice, video and
television traffic between its sites (i.e., between CE1 and CE2).
This scenario II is shown in figure 3.
In this case, service provider B establishes C-TE LSP1 with
preemption priority 0, available bandwidth 100Mbps for voice traffic
and C-TE LSP2 with preemption priority 1, available bandwidth 200Mbps
for video and television traffic. On the other hand, service provider
A also pre-establishes P-TE LSP1 with preemption priority 0,
available bandwidth 1Gbps for voice traffic and P-TE LSP2 with
K.Kumaki, et al. [Page 7]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
preemption priority 1, available bandwidth 2Gbps for video and
television 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, P-TE LSP1 should choose C-TE LSP1 at PE1 and
P-TE LSP2 should choose C-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 3 Scenario II
5.3 Scenario III: load balance of CE-to-CE traffic
In this scenario, service provider C uses voice, video and television
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, video and television equipments.
This scenario III is shown in figure 4.
In this case, service provider C establishes C-TE LSP1, C-TE LSP3, C-
TE LSP5 and C-TE LSP7 with preemption priority 0, available bandwidth
100Mbps for voice traffic, and establishes C-TE LSP2, C-TE LSP4, C-TE
LSP6 and C-TE LSP8 with preemption priority 1, available bandwidth
200Mbps for video and television traffic. On the other hand, service
provider A also pre-establishes P-TE LSP1 and P-TE LSP3 with
preemption priority 0, available bandwidth 1Gbps for voice traffic
and P-TE LSP2 and P-TE LSP4 with preemption priority 1, available
K.Kumaki, et al. [Page 8]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
bandwidth 2Gbps for video and television 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) are applicable to this scenario.
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 4 Scenario III
5.4 Scenario IV: RSVP Aggregation over MPLS TE Tunnels
In this scenario, the customer in this case has two hosts connecting
off CE1 and CE2 respectively. CE1 and CE2 are connected to PE1 and
K.Kumaki, et al. [Page 9]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
PE2 respectively within a VRF instance belonging to the same VPN.
The requesting host (H1) may request to H2 an e2e path with
bandwidth reservation of X. This scenario IV is shown in figure 5.
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 acting as a VoIP codec for example.
C-RSVP e2e path
<---------------------------------------------->
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H1 | |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |H2 |.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
vrf instance vrf instance
Figure 5 Scenario IV
6. Detailed Requirements
This section describes detailed requirements for C-RSVP paths and C-T
E LSPs in BGP/MPLS IP-VPN environments.
6.1 Selective P-TE LSPs
The solution MAY 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 a path messages from a CE, it may 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 MAY 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
K.Kumaki, et al. [Page 10]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
The solution SHOULD provide graceful restart capability for a C-TE
LSP over vrf instance. Graceful restart mechanisms related to this
architecture are described in [RFC3473] [RFC3623] [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. Rerouting
capability 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 over
multiple PEs and Ps, albeit tunneled over a P-TE LSP. In order to
avoid PE-CE link/PE node/SRLG failures needs to support a fast local
protection or a fast path 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. C-TE LSPs may potentially reserve over the bandwidth of a
P-TE LSP. The P-TE LSP tunnel head-end SHOULD control the number of
C-TE LSPs or the bandwidth of C-TE LSPs.
For example, the transport TE LSP head-end MUST have a configurable
limit on the maximum number of C-TE LSPs that it can admit. 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 of the cap bandwidth or the C-TE LSP bandwidth
on the P-TE LSP if that required bandwidth is available
b. Reject the C-TE LSP if the required bandwidth by the C-TE LSP is
not available
6.6 Policy Control Support for C-TE LSPs
The solution MAY support policy control for a C-TE LSP at a PE.
A PE receives RSVP control messages from a CE. The PE has the
possibility that receives unexpected packets from the CE site.
The PE MAY control RSVP control messages per vrf instance.
Especially, if a CE is not managed by service providers, the PE has
the high possibility that receives unexpected packets from the CE
site.
K.Kumaki, et al. [Page 11]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
In this case, the PE should control RSVP control messages per vrf
instance.
In case that a transport TE LSP tunnel head-end controls the
bandwidth of C-TE LSPs, an ingress policy can be applied on the
customer facing interface on the PE to control the max reservable
resources.
Furthermore, PEs cooperated with Operating Support System (OSS)
interpret a bandwidth customers require and may assign a bandwidth
for a customer.
6.7 PCE Features Support for C-TE LSPs
The solution MAY support PCE features for a C-TE LSP over vrf
instance.
When a C-TE LSP is provided, CEs, PEs and Ps may support PCE
[RFC4655] [PCEP] features. In this case, CE routers or PE routers
have PCC functions and PE routers and/or P routers have PCE functions.
6.8 Diversely Routed C-TE LSPs Support
The solution SHOULD set up a diversely routed C-TE LSP over vrf
instance.
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.
- load balance of CE-to-CE traffic across diverse C-TE LSP so as to
minimize the traffic disruption in case of a single network element
failure
- path protection (e.g. 1:1, 1:N)
6.9 Optimal Path Support for C-TE LSPs
The solution MUST support an optimal path of a C-TE LSP over vrf
instance.
Depending on an application (e.g. voice, television 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 or IGP metric.
6.10 Reoptimization Support for C-TE LSPs
The solution MUST support reoptimization of a C-TE LSP over vrf
instance.
K.Kumaki, et al. [Page 12]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
These LSPs must be reoptimized by make-before-break.
In this case, it is desirable for a head-end LSR 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- or jitter-sensitive traffic (i.e. voice traffic),
a C-TE LSP should be optimally established.
6.11 DS-TE Support for C-RSVP paths and C-TE LSPs
The solution SHOULD support DS-TE [RFC4124] features for a C-RSVP
path and 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 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. Requirements for DS-TE are described in [RFC3564].
6.12 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
6.13 RSVP requirements
Requirements for RSVP on the PE-CE link will be included in a future
update of this document.
6.14 Complexity and Risks
The solution SHOULD NOT introduce 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.
6.15 Backward Compatibility
The deployment of C-RSVP paths and C-TE LSPs SHOULD NOT impact
existing RSVP and MPLS TE mechanisms respectively, but allow for a
smooth migration or co-existence.
K.Kumaki, et al. [Page 13]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
6.16 Scalability Considerations
The solution MUST have a minimum impact on network scalability from a
C-RSVP path and a C-TE LSP over vrf instance.
Scalability of C-RSVP paths and C-TE LSPs MUST addresses the
following consideration.
- RSVP (e.g. number of RSVP messages, retained state and so on).
- RSVP-TE (e.g. number of RSVP control messages, retained state,
message size and so on).
- BGP (e.g. number of routes, flaps, overloads events and so on).
If the number of required C-TE LSPs increases, there would be
scalability issues. In this case, PEs may support a hierarchical LSP
[RFC4206].
6.17 Performance Considerations
The solution SHOULD be evaluated with regard to the following
criteria.
- Degree of path optimality of the C-TE LSP.
- TE LSP setup time.
- Failure and restoration time.
- Impact and scalability of the control plane due to added
overheads and so on.
- Impact and scalability of the data/forwarding plane due to added
overheads and so on.
6.18 Management Considerations
Manageability of C-RSVP paths and C-TE LSPs MUST addresses the
following considerations for section 5.
- Need for a MIB module for control plane and monitoring.
- Need for diagnostic tools.
MIB module for C-TE LSPs MUST collect per a vrf instance.
If a CE is managed by service providers, MIB information for C-TE
LSPs from the CE MUST be collected per a customer.
Today, diagnostic tools can detect failures of control plane and data
plane for general MPLS TE LSPs [RFC4379].
The diagnostic tools MUST detect failures of 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 14]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
In BGP/MPLS IP-VPN environments, from a CE point of view, IP TTL
decreases at a local PE and a remote PE. But from a PE point of view,
both IP TTL and MPLS TTL decreases between PEs.
7. Security Considerations
Security issues for C-TE LSPs relate to both control plane and data
plane.
In terms of control plane, 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 control IPv4 or IPv6 RSVP control
packets. If the CE is a trusted router for service providers, the PE
MAY be able to control IPv4 or IPv6 control packets.
In terms of data plane, 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 control labeled IPv4 or IPv6 data
packets. If the CE is a trusted router for service providers, the PE
MAY be able to control labeled IPv4 or IPv6 data packets.
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.
8. IANA Considerations
This requirement document makes no requests for IANA action.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions ", RFC 3473, January
2003.
[RFC3564] Le Faucheur, F., and Lai, W., "Requirements for Support
of Differentiated Services-aware MPLS Traffic Engineering
", RFC 3564, July 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.
K.Kumaki, et al. [Page 15]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124, June
2005.
[RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 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.
10.Informative References
[RSVP-L3VPN] Davie, B., et al., "Support for RSVP in Layer 3 VPNs",
Work in Progress, June 2007.
[PCEP] Vasseur, J.-P., et al., "Path Computation Element(PCE)
communication Protocol (PCEP) - Version 1", Work in
Progress, February 2007.
[RFC4804] Le Faucheur, F., et al., "Aggregation of RSVP
Reservations over MPLS TE/DS-TE Tunnels", RFC4804,
February 2007.
11.Acknowledgments
The author would like to express the thanks to Ron Bonica, Koh
Yamashita, Miya Kohno, Tomohiro Otani for their helpful and useful
comments and feedback.
12.Author's Addresses
Kenji Kumaki (Editor)
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Email: ke-kumaki@kddi.com
K.Kumaki, et al. [Page 16]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
Raymond Zhang
BT Infonet
2160 E. Grand Ave.
El Segundo, CA 90025
Email: raymond.zhang@bt.infonet.com
13.Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgement
K.Kumaki, et al. [Page 17]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-05 November 2007
Funding for the RFC Editor function is currently provided by the
Internet Society.
K.Kumaki, et al. [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 04:54:57 |