Request for Comments: 4216 Infonet Services Corporation
Category: Informational J.-P. Vasseur, Ed.
Cisco Systems, Inc.
November 2005
MPLS Inter-Autonomous System (AS)
Traffic Engineering (TE) Requirements
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document discusses requirements for the support of inter-AS MPLS
Traffic Engineering (MPLS TE). Its main objective is to present a
set of requirements and scenarios which would result in general
guidelines for the definition, selection, and specification
development for any technical solution(s) meeting these requirements
and supporting the scenarios.
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Contributing Authors ............................................4
3. Definitions and Requirements Statement ..........................5
3.1. Definitions ................................................5
3.2. Objectives and Requirements of Inter-AS Traffic
Engineering ................................................7
3.2.1. Inter-AS Bandwidth Guarantees .......................7
3.2.2. Inter-AS Resource Optimization ......................8
3.2.3. Fast Recovery across ASes ...........................8
3.3. Inter-AS Traffic Engineering Requirements Statement ........9
4. Application Scenarios ...........................................9
4.1. Application Scenarios Requiring Inter-AS Bandwidth
Guarantees .................................................9
4.1.1. Scenario I - Extended or Virtual PoP (VPoP) .........9
4.1.2. Scenario II - Extended or Virtual Trunk ............11
4.1.3. Scenario III - End-to-End Inter-AS MPLS TE
from CE to CE ......................................12
4.2. Application Scenarios Requiring Inter-AS Resource
Optimization ..............................................13
4.2.1. Scenario IV - TE across multi-AS within a
Single SP ..........................................13
4.2.2. Scenario V - Transit ASes as Primary and
Redundant Transport ................................14
5. Detailed Requirements for Inter-AS MPLS Traffic Engineering ....16
5.1. Requirements within One SP Administrative Domain ..........16
5.1.1. Inter-AS MPLS TE Operations and Interoperability ...16
5.1.2. Protocol Signaling and Path Computations ...........16
5.1.3. Optimality .........................................17
5.1.4. Support of Diversely Routed Inter-AS TE LSP ........17
5.1.5. Re-Optimization ....................................18
5.1.6. Fast Recovery Support Using MPLS TE Fast Reroute ...18
5.1.7. DS-TE Support ......................................18
5.1.8. Scalability and Hierarchical LSP Support ...........19
5.1.9. Mapping of Traffic onto Inter-AS MPLS TE Tunnels ...19
5.1.10. Inter-AS MPLS TE Management .......................19
5.1.10.1. Inter-AS MPLS TE MIB Requirements ........19
5.1.10.2. Inter-AS MPLS TE Fault Management
Requirements .............................20
5.1.11. Extensibility .....................................21
5.1.12. Complexity and Risks ..............................21
5.1.13. Backward Compatibility ............................21
5.1.14. Performance .......................................21
5.2. Requirements for Inter-AS MPLS TE across Multiple SP ......22
5.2.1. Confidentiality ....................................22
5.2.2. Policy Control .....................................23
5.2.2.1. Inter-AS TE Agreement Enforcement
Polices ...................................23
5.2.2.2. Inter-AS TE Rewrite Policies ..............24
5.2.2.3. Inter-AS Traffic Policing .................24
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. Normative References ...........................................25
9. Informative References .........................................25
Appendix A. Brief Description of BGP-based Inter-AS Traffic
Engineering ...........................................27
1. Introduction
The MPLS Traffic Engineering (TE) mechanism documented in [TE-RSVP]
may be deployed by Service Providers (SPs) to achieve some of the
most important objectives of network traffic engineering as described
in [TE-OVW]. These objectives are summarized as:
- Supporting end-to-end services requiring Quality of Service (QoS)
guarantees
- Performing network resource optimization
- Providing fast recovery
However, this traffic engineering mechanism can only be used within
an Autonomous System (AS).
This document discusses requirements for an inter-AS MPLS Traffic
Engineering mechanism that may be used to achieve the same set of
objectives across AS boundaries within or beyond an SP’s
administrative domains.
The document will also present a set of application scenarios where
the inter-AS traffic engineering mechanism may be required. This
mechanism could be implemented based upon the requirements presented
in this document.
These application scenarios will also facilitate discussions for a
detailed requirements list for this inter-AS Traffic Engineering
mechanism.
Please note that there are other means of traffic engineering
including Interior Gateway Protocol (IGP); metrics-based (for use
within an AS); and Border Gateway Protocol (BGP) attribute-based (for
use across ASes, as described in Appendix A), which provide coarser
control of traffic paths. However, this document addresses
requirements for a MPLS-based, fine-grained approach for inter-AS TE.
This document doesn’t make any claims with respect to whether it is
possible to have a practical solution that meets all the requirements
listed in this document.
1.1. 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].
2. Contributing Authors
The co-authors listed below contributed to the text and content of
this document. (The contact information for the editors appears in
section 9, and is not repeated below.)
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
EMail : ke-kumaki@kddi.com
Paul Mabey
Qwest Communications
950 17th Street,
Denver, CO 80202, USA
EMail: pmabey@qwest.com
Nadim Constantine
Infonet Services Corporation
2160 E. Grand Ave.
El Segundo, CA 90025. USA
EMail: nadim_constantine@infonet.com
Pierre Merckx
EQUANT
1041 route des Dolines - BP 347
06906 SOPHIA ANTIPOLIS Cedex, FRANCE
EMail: pierre.merckx@equant.com
Ting Wo Chung
Bell Canada
181 Bay Street, Suite 350
Toronto, Ontario, Canada, M5J 2T3
EMail: ting_wo.chung@bell.ca
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, France
EMail: jeanlouis.leroux@francetelecom.com
Yonghwan Kim
SBC Laboratories, Inc.
4698 Willow Road
Pleasanton, CA 94588, USA
EMail: Yonghwan_Kim@labs.sbc.com
3. Definitions and Requirements Statement
3.1. Definitions
The following provides a list of abbreviations and acronyms
specifically pertaining to this document:
SP: Service Providers including regional or global
providers.
SP Administrative
Domain: a single SP administration over a network or
networks that may consist of one AS or multiple
ASes.
IP-only networks: SP’s network where IP routing protocols such as
IGP/BGP are activated.
IP/MPLS networks: SP’s network where MPLS switching capabilities and
signaling controls (e.g., ones described in
[MPLS-ARCH]) are activated in addition to IP
routing protocols.
Intra-AS TE: A generic definition for traffic engineering
mechanisms operating over IP-only and/or IP/MPLS
network within an AS.
Inter-AS TE: A generic definition for traffic engineering
mechanisms operating over IP-only and/or IP/MPLS
network across one or multiple ASes. Since this
document only addresses IP/MPLS networks, any
reference to Inter-AS TE in this document refers
only to IP/MPLS networks and is not intended to
address IP-only TE requirements.
TE LSP: MPLS Traffic Engineering Label Switched Path.
Intra-AS MPLS TE: An MPLS Traffic Engineering mechanism where its TE
Label Switched Path (LSP), Head-end Label Switching
Router (LSR), and Tail-end LSR reside in the same
AS for traffic engineering purposes.
Inter-AS MPLS TE: An MPLS Traffic Engineering mechanism where its TE
LSPs, Head-end LSR, and Tail-end LSR do not reside
within the same AS or both Head-end LSR and Tail-
end LSR are in the same AS, but the TE LSP
transiting path may be across different ASes.
ASBRs: Autonomous System Border Routers used to connect to
another AS of a different or the same Service
Provider via one or more links that interconnect
ASes.
Inter-AS TE Path: A TE path traversing multiple ASes and ASBRs, e.g.,
AS1-ASBR1-inter-AS link(s)-ASBR2-AS2... ASBRn-ASn.
Inter-AS TE
Segment: A portion of the Inter-AS TE path.
Inter-AS DS-TE: Diffserv-aware Inter-AS TE.
CE: Customer Edge Equipment
PE: Provider Edge Equipment that has direct connections
to CEs.
P: Provider Equipment that has backbone trunk
connections only.
VRF: Virtual Private Network (VPN) Routing and
Forwarding Instance.
PoP: Point of presence or a node in SP’s network.
SRLG: A set of links may constitute a ’shared risk link
group’ (SRLG) if they share a resource whose
failure may affect all links in the set as defined
in [GMPLS-ROUT].
PCC: Path Computation Client; any client application
requesting a path computation to be performed by
the 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.
Please note that the terms of CE, PE, and P used throughout this
document are generic in their definitions. In particular, whenever
such acronyms are used, it does not necessarily mean that CE is
connected to a PE in a VRF environment described in such IETF
documents as [BGP-MPLSVPN].
3.2. Objectives and Requirements of Inter-AS Traffic Engineering
As mentioned in section 1 above, some SPs have requirements for
achieving the same set of traffic engineering objectives as presented
in [TE-OVW] across AS boundaries.
This section examines these requirements in each of the key
corresponding areas: 1) Inter-AS bandwidth guarantees; 2) Inter-AS
Resource Optimization and 3) Fast Recovery across ASes, i.e.,
Recovery of Inter-AS Links/SRLG and ASBR Nodes.
3.2.1. Inter-AS Bandwidth Guarantees
The Diffserv IETF working group has defined a set of mechanisms
described in [DIFF_ARCH], [DIFF_AF], and [DIFF_EF] or [MPLS-Diff].
These mechanisms can be activated at the edge of or over a Diffserv
domain to contribute to the enforcement of a QoS policy (or a set of
QoS policies), which can be expressed in terms of maximum one-way
transit delay, inter-packet delay variation, loss rate, etc.
Many SPs have partial or full deployment of Diffserv implementations
in their networks today, either across the entire network or
minimally on the edge of the network across CE-PE links.
In situations where strict QoS bounds are required, admission control
inside the backbone of a network is in some cases required in
addition to current Diffserv mechanisms.
When the propagation delay can be bounded, the performance targets,
such as maximum one-way transit delay, may be guaranteed by providing
bandwidth guarantees along the Diffserv-enabled path.
One typical example of this requirement is to provide bandwidth
guarantees over an end-to-end path for VoIP traffic classified as EF
(Expedited Forwarding [DIFF_EF]) class in a Diffserv-enabled network.
When the EF path is extended across multiple ASes, inter-AS bandwidth
guarantee is then required.
Another case for inter-AS bandwidth guarantee is the requirement for
guaranteeing a certain amount of transit bandwidth across one or
multiple ASes.
Several application scenarios are presented to further illustrate
this requirement in section 4 below.
3.2.2. Inter-AS Resource Optimization
In Service Provider (SP) networks, the BGP protocol [BGP] is deployed
to exchange routing information between ASes. The inter-AS
capabilities of BGP may also be employed for traffic engineering
purposes across the AS boundaries. Appendix A provides a brief
description of the current BGP-based inter-AS traffic engineering
practices.
SPs have managed to survive with this coarse set of BGP-based traffic
engineering facilities across inter-AS links in a largely best-effort
environment. Certainly, in many cases, ample bandwidth within an
SP’s network and across inter-AS links reduces the need for more
elaborate inter-AS TE policies.
However, in the case where a SP network is deployed over multiple
ASes (for example, as the number of inter-AS links grows), the
complexity of the inter-AS policies and the difficulty in inter-AS TE
path optimization increase to a level such that it may soon become
unmanageable.
Another example is where inter-AS links are established between
different SP administrative domains. Nondeterministic factors such
as uncoordinated routing and network changes, as well as sub-optimum
traffic conditions, would potentially lead to a complex set of
inter-AS traffic engineering policies where current traffic
engineering mechanisms would probably not scale well.
In these situations where resource optimization is required and/or
specific routing requirements arise, the BGP-based inter-AS
facilities will need to be complemented by a more granular inter-AS
traffic engineering mechanism.
3.2.3. Fast Recovery across ASes
When extending services such as VoIP across ASes, customers often
require SPs to maintain the same level of performance targets, such
as packet loss and service availability, as achieved within an AS.
As a consequence, fast convergence in a stable fashion upon
link/SRLG/node failures becomes a strong requirement. This is
clearly difficult to achieve with current inter-domain techniques,
especially in cases of link/SRLG failures between ASBRs or ASBR node
failures.
3.3. Inter-AS Traffic Engineering Requirements Statement
Just as in the applicable case of deploying MPLS TE in an SP’s
network, an inter-AS TE method in addition to BGP-based traffic
engineering capabilities needs to be deployed across inter-AS links
where resource optimization, bandwidth guarantees and fast recovery
are required.
This is especially critical in a Diffserv-enabled, multi-class
environment described in [PSTE] where statistical performance targets
must be maintained consistently over the entire path across different
ASes.
The approach of extending current intra-AS MPLS TE capabilities
[TE-RSVP] across inter-AS links for IP/MPLS networks is considered
here because of already available implementations and operational
experiences.
Please note that the inter-AS traffic engineering over an IP-only
network is for future consideration since there is not sufficient
interest for similar requirements to those of IP/MPLS networks at
this time. More specifically, this document only covers the inter-AS
TE requirements for packet-based IP/MPLS networks.
4. Application Scenarios
The following sections present a few application scenarios over
IP/MPLS networks where requirements cannot be addressed with the
current intra-AS MPLS TE mechanism and give rise to considerations
for inter-AS MPLS traffic engineering requirements.
Although not explicitly noted in the following discussions, fast
recovery of traffic path(s) crossing multiple ASes in a stable
fashion is particularly important in the case of link/SRLG/node
failures at AS boundaries for all application scenarios presented
here.
4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees
4.1.1. Scenario I - Extended or Virtual PoP (VPoP)
A global service provider (SP1) would like to expand its reach into a
region where a regional service provider’s (SP2) network has already
established a denser network presence.
In this scenario, the SP1 may establish interconnections with SP2 in
one or multiple points in that region. In their customer-dense
regions, SP1 may utilize SP2’s network as an extended transport by
co-locating aggregation routers in SP2’s PoPs.
In order to ensure bandwidth capacity provided by SP2 and to achieve
some degrees of transparency to SP2’s network changes in terms of
capacity and network conditions, one or more inter-AS MPLS TE LSPs
can be built between SP1’s ASBR or PE router inside AS1 and SP1’s PE
routers co-located in SP2’s PoPs, as illustrated in the diagram
below:
<===========Inter-AS MPLS TE Tunnel===========>
----- -----
________|ASBR |___Inter-AS___|ASBR |________
| | RTR | Link | RTR | |
---- ----- ----- ----- -----
|SP1 |_Inter-AS_| SP2 | | SP1 |
|VPoP| Link |P/PE | |P/PE |
---- ----- ----- ----- -----
|________|ASBR |___Inter-AS___|ASBR |________|
| RTR | Link | RTR |
----- -----
<=================Inter-AS MPLS TE Tunnel======================>
+-SP1 AS1-+ +---SP2 AS2-----+ +------SP1 AS1------+
In situations where end-to-end Diffserv paths must be maintained,
both SPs’ networks may need to provision Diffserv PHB at each hop in
order to support a set of traffic classes with compatible performance
targets. The subsequent issues regarding Service Level Agreement
(SLA) boundaries, reporting and measuring system interoperability and
support demarcations are beyond the scope of this document and are
not discussed further.
If either SP1’s or SP2’s network is not a Diffserv-aware network, the
scenario would still apply to provide bandwidth guarantees.
The SP2, on the other hand, can similarly choose to expand its reach
beyond its servicing region over SP1’s network via inter-AS MPLS TE
tunnels.
It is worth mentioning that these remote aggregation routers co-
located in another SP’s network are unlikely to host SP1’s IGP and
BGP routing planes and will more likely maintain their own AS or be
part of the SP1’s AS. In this case, such TE tunnels may cross
several ASes, but the Head-end and Tail-end LSRs of TE tunnel may
have the same AS number, as shown in the diagram above.
4.1.2. Scenario II - Extended or Virtual Trunk
Instead of co-locating a PE router in SP2’s PoP, SP1 may also choose
to aggregate customer VPN sites onto a SP2’s PE router where inter-AS
TE tunnels can be built and signaled through SP2’s MPLS network
between the SP2 PoP (to which SP1 and customer CEs are directly
connected) and SP1’s ASBR or PE routers inside SP1’s network. This
allows SP1’s customers connected to SP2 PE router to receive a
guaranteed bandwidth service up to the TE LSP tail-end router located
in SP1’s network.
In this scenario, there could be two applicable cases:
Case 1 - the inter-AS MPLS TE tunnel functions as an extended or
virtual trunk aggregating SP1’s CE’s local-loop access circuits on
SP2’s MPLS network over which the bandwidth can be guaranteed to the
TE LSP tail-end router located in SP1’s network, as shown in the
diagram below:
<====Inter-AS MPLS TE Tunnel====>
or
< ===Inter-AS MPLS TE Tunnel===============>