One document matched: draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01.txt
Differences from draft-kumaki-l3vpn-e2e-rsvp-te-reqts-00.txt
Network Working Group
Internet Draft K. Kumaki, Ed.
Category: Informational KDDI Corporation
Expires: December 24, 2006 R. Zhang
BT infonet
June 23, 2006
Requirements for delivering MPLS Services Over L3VPN
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01.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.
This Internet-Draft will expire on December 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes Service Provider requirements for providing
end-to-end MPLS TE LSPs over L3VPN.
K.Kumaki, et al. Expires December 24, 2006 [Page 1]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01 June 2006
The main objective is to present a set of requirements which result
in general guidelines for the definition, selection and specification
of a technical solution addressing these requirements.
Specification for this solution itself is out of scope in this
document.
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 RFC-2119.
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................4
3. Problem Statement..............................................4
4. Reference model................................................5
5. Detailed Requirements..........................................6
5.1 Selective P-TE LSPs........................................6
5.2 Graceful restart support for C-TE LSPs.....................7
5.3 Rerouting support for C-TE LSPs............................7
5.4 FRR support for C-TE LSPs..................................7
5.5 Admission control support on P-TE LSP head-ends............7
5.6 Policy control support for C-TE LSPs.......................7
5.7 PCE features support for C-TE LSPs.........................8
5.8 Diversely routed C-TE LSPs support.........................8
5.9 Optimal path support for C-TE LSPs.........................8
5.10 Reoptimization support for C-TE LSPs......................8
5.11 DS-TE support for C-TE LSPs...............................9
5.12 Complexity and Risks......................................9
5.13 Backward Compatibility....................................9
5.14 Scalability consideration.................................9
5.15 Performance consideration.................................9
5.16 Management consideration.................................10
6. Security Considerations.......................................10
7. IANA Considerations...........................................11
8. Normative References..........................................11
9. Informative References........................................11
10.Acknowledgments...............................................12
11.Author's Addresses............................................12
12.Intellectual Property Statement...............................12
1. Introduction
L3VPN service providers are presented with two conflicting
requirements. The first requirement states that service provider
K.Kumaki, et al. Expires December 24, 2006 [Page 2]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01 June 2006
network must protect itself from any misconfiguration or misbehavior
on the part of any particular customer. When one customer behaves
badly, the service provider must continue to provide service to its
remaining customers.
As a consequence, many service providers maintain a security posture
in which all customer interfaces are mediated by 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.
The second requirement is for service providers to offer robust MPLS
services to their customers. In order to understand this requirement,
assume that the customer maintains sites of connectivity on either
side of a service provider network. In order to fulfill the
requirement, the customer must be able to establish and maintain an
MPLS LSP from any router in one site to any router in the other site.
For the purposes of this document, we will call this customer LSP an
"end-to-end LSP".
The customer deploys end-to-end LSPs in order to construct diverse
services that, in turn, are offered to the customer's users. These
diverse services might include L1VPN, L2VPN, L3VPN or other MPLS-
enabled services that have yet to be defined.
The end-to-end LSP must be robust. This is to say that it must be
enabled with many of the features that one would expect from a
traffic engineered intra-domain LSP. These features include traffic
engineering by means of bandwidth reservation, administrative groups
and priority. They also include differentiated services on the
forwarding plane and fast reroute on the control plane.
Furthermore, the solution must offer all of the benefits of a Layer 3
VPN. Specifically, the interfaces that connect the customer's edge
router to the service provider's edge router need not be numbered
from globally unique address space. They can be numbered from address
space that is unique only to the VPN.
At first glance, the two requirements discussed above appear to be in
conflict with one another. However, they can be harmonized using
mechanism such as LSP hierarchies and/or routing and signaling policy.
This document defines detailed requirements for providing an end-to-
end MPLS TE LSP. Although this document presents a reference model,
this reference model may not be considered as part of the solution.
The reference model is intended only to provide a conceptual
framework for subsequent solution documents.
K.Kumaki, et al. Expires December 24, 2006 [Page 3]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01 June 2006
At this time, P2P end-to-end MPLS TE LSPs are discussed in this
document. But P2MP end-to-end MPLS TE LSPs are for further study and
are therefore beyond the current scope of the document.
2. Terminology
LSP: Label Switched Path
TE LSP: Traffic Engineering Label Switched Path
MPLS TE LSP: Multi Protocol Label Switching TE LSP
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 provide advanced MPLS services
over L3VPN. Service providers have some application scenarios for
these services. For example, a C-LSP with guaranteed bandwidth
between data center or customer sites is required for voice,
K.Kumaki, et al. Expires December 24, 2006 [Page 4]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01 June 2006
television and video traffic. 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.
Thus, service providers require a C-TE LSP to provide these services
stably maintaining quality of service.
When service providers provide a C-TE LSP over L3VPN, they require
that MPLS TE LSP from a local CE to a remote CE is established. But
if service providers provide the C-TE LSP over L3VPN, especially
BGP/MPLS IP-VPN [RFC4364], they can't provide it over vrf instance.
In current BGP/MPLS IP-VPN architecture, it does not define a vrf
instance which receives a RSVP signaling packet and processes this
packet.
Furthermore, this C-TE LSP is required for a specific application.
Thus, 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.
As the reasons mentioned above, it is highly desired to support C-TE
LSPs over BGP/MPLS IP-VPN.
C-TE LSPs are highly desired in order to provide:
- 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-TE LSPs.
- Scalability for C-TE LSPs.
4. Reference model
This section describes a C-TE LSP and a P-TE LSP in L3VPN, especially
BGP/MPLS IP-VPN.
In BGP/MPLS IP-VPN, a C-TE LSP and a P-TE LSP are shown in figure 1.
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.
K.Kumaki, et al. Expires December 24, 2006 [Page 5]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01 June 2006
Generally speaking, C-TE LSPs are used by customers and P-TE LSPs are
used by service providers.
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 1 Reference model
5. Detailed Requirements
This section describes detailed requirements for C-TE LSPs in L3VPN
environments, especially BGP/MPLS IP-VPN environments.
5.1 Selective P-TE LSPs
The solution MAY provide the ability to decide which P-TE LSP a PE
uses for a C-TE LSP. When a PE receives a path message 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
K.Kumaki, et al. Expires December 24, 2006 [Page 6]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01 June 2006
3. class-type
4. on the data plane: (DSCP or EXP bits)
5.2 Graceful restart support for C-TE LSPs
The solution SHOULD provide graceful restart for a C-TE LSP over vrf
instance. Graceful restart mechanisms related to this architecture
are described in [RFC3623] [GR-BGP/MPLS] [RFC3473].
5.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.
5.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 CE traverses over
multiple PEs and Ps. To avoid link/node/SRLG failures needs to
support a fast local protection or a fast path protection.
5.5 Admission control support on P-TE LSP head-ends
The solution SHOULD support admission control on a transport TE LSP
tunnel head-end. C-TE LSPs may potentially reserve over the bandwidth
of a P-TE LSP. The transport 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 have configurable limit on
the maximum number of C-TE LSPs that it can admit. As for the amount
of bandwidth can be reserved by C-TE LSPs: there could be two
situations:
1. Let the P-TE LSP does its natural bandwidth admission
2. Set a cap on the amount of bandwidth
5.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.
In this case, the PE should control RSVP control messages per vrf
instance.
K.Kumaki, et al. Expires December 24, 2006 [Page 7]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01 June 2006
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.
5.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 [PCE-
ARCH] [PCEP] features. In this case, CE routers or PE routers have
PCC functions and PE routers and/or P routers have PCE functions.
5.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)
5.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.
5.10 Reoptimization support for C-TE LSPs
The solution MUST support reoptimization of a C-TE LSP over vrf
instance.
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.
K.Kumaki, et al. Expires December 24, 2006 [Page 8]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01 June 2006
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.
5.11 DS-TE support for C-TE LSPs
The solution SHOULD support DS-TE [RFC4124] features 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 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].
5.12 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.
5.13 Backward Compatibility
The deployment of C-TE LSPs SHOULD NOT impact existing MPLS TE
mechanisms, but allow for a smooth migration or co-existence.
5.14 Scalability consideration
The solution MUST have a minimum impact on network scalability from a
C-TE LSP over vrf instance.
Scalability of C-TE LSPs MUST addresses the following consideration.
- 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].
5.15 Performance consideration
K.Kumaki, et al. Expires December 24, 2006 [Page 9]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01 June 2006
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
5.16 Management consideration
Manageability of C-TE LSPs MUST addresses the following consideration
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 vrf instance.
If a CE is managed by service providers, MIB information for C-TE
LSPs from the CE MUST be collected per customer.
Today, diagnostic tools can detect failures of control plane and data
plane for general MPLS TE LSPs [LSP-PING].
The diagnostic tools MUST detect failures of control and data plane
for C-TE LSPs over vrf instance.
MPLS OAM for C-TE LSPs MUST be supported within the context of VRF
except for the above.
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.
6. 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
K.Kumaki, et al. Expires December 24, 2006 [Page 10]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01 June 2006
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.
7. IANA Considerations
This requirement document makes no requests for IANA action.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
[RFC4364] Rosen, E., and Rekhter, Y., "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[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.
[RFC3623] Moy, J., et al., "Graceful OSPF Restart", RFC3623,
November 2003.
[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.
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124, June
2005.
9. Informative References
[GR-BGP/MPLS]Rekhter, Y., and Aggarwal, R., " Graceful Restart
Mechanism for BGP with MPLS", Work in Progress, August
2005.
K.Kumaki, et al. Expires December 24, 2006 [Page 11]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01 June 2006
[PCE-ARCH] Farrel, A., Vasseur, J.-P., and J. Ash, "Path Computation
Element (PCE) Architecture", Work in Progress, December
2005.
[PCEP] Vasseur, J.-P., et al., "Path Computation Element(PCE)
communication Protocol (PCEP) - Version 1", Work in
Progress, December 2005.
[LSP-PING] Kompella, K. and G. Swallow, "Detecting MPLS Data Plane
Failures", Work in Progress, January 2006.
10.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.
11.Author's Addresses
Kenji Kumaki
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
12.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
K.Kumaki, et al. Expires December 24, 2006 [Page 12]
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01 June 2006
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). 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
Funding for the RFC Editor function is currently provided by the
Internet Society.
K.Kumaki, et al. Expires December 24, 2006 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 04:54:51 |