One document matched: draft-kumaki-l3vpn-e2e-rsvp-te-reqts-00.txt
Network Working Group
Internet Draft Kenji Kumaki
Category: Informational KDDI Corporation
Expires: August 2006 February 2006
Requirements for delivering MPLS Services Over L3VPN
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-00.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 Internet Society (2006). All Rights Reserved.
Abstract
This document describes Service Provider requirements for providing
end-to-end MPLS TE LSPs over L3VPN.
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.
K.Kumaki Expires - August 2006 [Page 1]
Requirements for delivering MPLS Services Over L3VPN February 2006
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....................................................3
3. Problem Statement..............................................4
4. Reference model................................................4
5. Detailed Requirements..........................................5
5.1 Selective MPLS TE LSPs.....................................6
5.2 Graceful restart support for end-to-end MPLS TE LSPs.......6
5.3 Rerouting support for end-to-end MPLS TE LSPs..............6
5.4 FRR support for end-to-end MPLS TE LSPs....................6
5.5 Policy control support for end-to-end MPLS TE LSPs.........6
5.6 PCE features support for end-to-end MPLS TE LSPs...........7
5.7 Diversely routed end-to-end MPLS TE LSPs support...........7
5.8 Optimal path support for end-to-end MPLS TE LSPs...........7
5.9 Reoptimization support for end-to-end MPLS TE LSPs.........7
5.10 DS-TE support for end-to-end MPLS TE LSPs.................7
5.11 Complexity and Risks......................................8
5.12 Backward Compatibility....................................8
5.13 Scalability consideration.................................8
5.14 Performance consideration.................................8
5.15 Management consideration..................................9
6. Security Considerations........................................9
7. Normative References...........................................9
8. Informative References........................................10
9. Acknowledgments...............................................10
10. Author's Addresses...........................................11
11. Intellectual Property Statement..............................11
1. Introduction
L3VPN service providers are presented with two conflicting
requirements. The first requirement states that service provider
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
K.Kumaki Expires - August 2006 [Page 2]
Requirements for delivering MPLS Services Over L3VPN February 2006
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.
2. Terminology
LSP: Label Switched Path
TE LSP: Traffic Engineering Label Switched Path
MPLS TE LSP: Multi Protocol Label Switching TE LSP
K.Kumaki Expires - August 2006 [Page 3]
Requirements for delivering MPLS Services Over L3VPN February 2006
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
When service providers provide an end-to-end MPLS TE LSP, they expect
a MPLS TE LSP from a local CE to a remote CE is established. But if
service providers provide an end-to-end MPLS TE LSP using L3VPN,
especially BGP/MPLS IP-VPNs [RFC2547bis], 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, an end-to-end MPLS TE LSP established over BGP/MPLS IP-
VPNs is not scalable due to the number of RSVP control message and
retained state because a lot of MPLS TE LSPs exist in an actual
BGP/MPLS IP-VPN.
This problem happens in carrier's carrier environments [RFC2547bis]
as well as in basic BGP/MPLS IP-VPN environments.
Scalable end-to-end MPLS TE LSPs are needed through BGP/MPLS IP-VPNs.
4. Reference model
This section describes an end-to-end MPLS TE LSP and a MPLS TE LSP in
L3VPN, especially BGP/MPLS IP-VPNs.
K.Kumaki Expires - August 2006 [Page 4]
Requirements for delivering MPLS Services Over L3VPN February 2006
In a BGP/MPLS IP-VPN, an end-to-end MPLS TE LSP and a MPLS 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 the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a
reservation message from CE2 and/or CE3, it establishes an end-to-end
MPLS TE LSP through the BGP/MPLS IP-VPN.
A MPLS TE LSP is established between PE1 and PE2. This LSP is used by
vrf instance to forward customer packets within the BGP/MPLS IP-VPN.
Generally speaking, end-to-end MPLS TE LSPs are used by customers and
MPLS TE LSPs are used by service providers.
e2e MPLS TE LSP
<----------------------------------------------------------->
or
e2e MPLS TE LSP
<---------------------------------------------->
MPLS 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 end-to-end MPLS TE
K.Kumaki Expires - August 2006 [Page 5]
Requirements for delivering MPLS Services Over L3VPN February 2006
LSPs in L3VPN environments, especially BGP/MPLS IP-VPN environments.
5.1 Selective MPLS TE LSPs
The solution MAY provide the ability to decide which MPLS TE LSP a PE
uses for an end-to-end MPLS TE LSP. When a PE receives a path message
from a CE, it may be able to decide which MPLS TE LSP it uses. In
this case, various kinds of MPLS TE LSPs exist in service provider
network. For example, depending on an application (e.g. voice,
television, video and so on), the PE MAY choose an appropriate MPLS
TE LSP.
5.2 Graceful restart support for end-to-end MPLS TE LSPs
The solution SHOULD provide graceful restart for an end-to-end MPLS
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 end-to-end MPLS TE LSPs
The solution MUST provide rerouting of an end-to-end MPLS 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 end-to-end MPLS TE LSPs
The solution MUST support FRR [RFC4090] features for an end-to-end
MPLS TE LSP over vrf instance.
In BGP/MPLS IP-VPN environments, an end-to-end MPLS 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 Policy control support for end-to-end MPLS TE LSPs
The solution MAY support policy control for an end-to-end MPLS 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.
Furthermore, PEs cooperated with Operating Support System (OSS)
interpret a bandwidth customers require and may assign a bandwidth
for a customer.
K.Kumaki Expires - August 2006 [Page 6]
Requirements for delivering MPLS Services Over L3VPN February 2006
5.6 PCE features support for end-to-end MPLS TE LSPs
The solution MAY support PCE features for an end-to-end MPLS TE LSP
over vrf instance.
When an end-to-end MPLS 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.7 Diversely routed end-to-end MPLS TE LSPs support
The solution SHOULD set up a diversely routed end-to-end MPLS TE LSP
over vrf instance.
When a CE has multiple uplinks which connect to different PEs, it is
desirable that multiple end-to-end MPLS TE LSPs over vrf instance are
established. In this case, for example, the following points will be
beneficial to customers.
- If multiple end-to-end MPLS TE LSPs from a CE to a remote CE exist
and some of them do not satisfy required set of constraints, packet
forwarding from the CE to the remote CE does not impact.
- path protection (e.g. 1:1, 1:N)
5.8 Optimal path support for end-to-end MPLS TE LSPs
The solution MUST support an optimal path of an end-to-end MPLS TE
LSP over vrf instance.
Depending on an application (e.g. voice, television and video), an
optimal path is needed for an end-to-end MPLS TE LSP over vrf
instance. An optimal path may be a shortest path based on TE metric
or IGP metric.
5.9 Reoptimization support for end-to-end MPLS TE LSPs
The solution MUST support reoptimization of an end-to-end MPLS 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.
Furthermore, customers should be able to reoptimize an end-to-end
MPLS TE LSP manually.
To provide delay- or jitter-sensitive traffic (i.e. voice traffic),
an end-to-end MPLS TE LSP should be optimally established.
5.10 DS-TE support for end-to-end MPLS TE LSPs
The solution SHOULD support DS-TE [RFC4124] features for an end-to-
end MPLS TE LSP over vrf instance.
K.Kumaki Expires - August 2006 [Page 7]
Requirements for delivering MPLS Services Over L3VPN February 2006
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.11 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.12 Backward Compatibility
The deployment of end-to-end MPLS TE LSPs SHOULD NOT impact existing
MPLS TE mechanisms, but allow for a smooth migration or co-existence.
5.13 Scalability consideration
The solution MUST have a minimum impact on network scalability from
an end-to-end MPLS TE LSP over vrf instance.
Scalability of end-to-end MPLS 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, overload events and so on)
If the number of required end-to-end MPLS TE LSPs increases, there
would be scalability issues. In this case, PEs may support a
hierarchical LSP [RFC4206].
5.14 Performance consideration
The solution SHOULD be evaluated with regard to the following
criteria.
- Degree of path optimality of the end-to-end MPLS 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
K.Kumaki Expires - August 2006 [Page 8]
Requirements for delivering MPLS Services Over L3VPN February 2006
overheads and so on
5.15 Management consideration
Manageability of end-to-end MPLS 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 end-to-end MPLS TE LSPs should be got per vrf instance.
If a CE is managed by service providers, MIB information for end-to-
end TE LSPs from the CE should be got 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 end-to-end MPLS TE LSPs over vrf instance.
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 end-to-end 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.
7. Normative References
[RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
K.Kumaki Expires - August 2006 [Page 9]
Requirements for delivering MPLS Services Over L3VPN February 2006
[RFC2547bis]Rosen, E., and Rekhter, Y., "BGP/MPLS IP VPNs", Work in
Progress, October 2004.
[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.
8. Informative References
[GR-BGP/MPLS]Rekhter, Y., and Aggarwal, R., " Graceful Restart
Mechanism for BGP with MPLS", Work in Progress, August
2005.
[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.
9. Acknowledgments
The author would like to express the thanks to Ron Bonica, Koh
Yamashita, Miya Kohno, Tomohiro Otani for helpful and useful comments
and feedbacks.
K.Kumaki Expires - August 2006 [Page 10]
Requirements for delivering MPLS Services Over L3VPN February 2006
10. Author's Addresses
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Email: ke-kumaki@kddi.com
11. 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 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.
K.Kumaki Expires - August 2006 [Page 11]
Requirements for delivering MPLS Services Over L3VPN February 2006
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
K.Kumaki Expires - August 2006 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-22 23:31:21 |