draft-ietf-tewg-interas-mpls-te-req-06.txt   draft-ietf-tewg-interas-mpls-te-req-07.txt 
IETF Internet Draft Raymond Zhang, Editor IETF Internet Draft Raymond Zhang, Editor
Internet Engineering Task Force Infonet Services Corporation Internet Engineering Task Force Infonet Services Corporation
Document: JP Vasseur, Co-Editor draft-ietf-tewg-interas-mpls-te-req-07.txt JP Vasseur, Co-Editor
draft-ietf-tewg-interas-mpls-te-req-06.txt CISCO Systems, Inc Expires: Dec. 2004 CISCO Systems,Inc
January 2004 June 2004
Expires: July 2004
MPLS Inter-AS Traffic Engineering requirements MPLS Inter-AS Traffic Engineering requirements
draft-ietf-tewg-interas-mpls-te-req-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are Working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or made obsolete by other
at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use an Internet-Draft
reference material or to cite them other than as "work in progress." as reference material or to cite it other than as "work in
progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document discusses requirements for the support of inter-AS This document discusses requirements for the support of inter-AS
MPLS Traffic Engineering (MPLS TE). The main objective of this MPLS Traffic Engineering (MPLS TE). Its main objective is to
document is to present a set of requirements which would result in a present a set of requirements which would result in general
set of general guidelines in the definition, selection and guidelines for the definition, selection and
specification development for any technical solution(s) meeting specification development for any technical solution(s) meeting
these requirements. these requirements.
Summary for Sub-IP related Internet Drafts Summary for Sub-IP related Internet Drafts
RELATED DOCUMENTS: RELATED DOCUMENTS:
None None
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
TEWG TEWG
WHY IS IT TARGETED AT THIS WG(s) WHY IS IT TARGETED AT THIS WG(s)
It is stated in the charter that documenting SP requirements in this It is stated in the charter that documenting SP requirements in this
area are one of the work items to be undertaken by TEWG. area is one of the work items to be undertaken by TEWG.
JUSTIFICATION JUSTIFICATION
The TEWG charter further states that "The working group may also The TEWG charter further states that "The working group may also
consider the problems of traffic engineering across autonomous consider the problems of traffic engineering across autonomous
systems boundaries." systems boundaries."
MPLS Inter-AS TE requirements June 2004
This draft discusses the requirements for a traffic engineering This draft discusses the requirements for a traffic engineering
mechanism across autonomous systems boundaries that would also be mechanism across autonomous systems boundaries that would also be
interoperable with current intra-AS traffic engineering mechanisms. interoperable with current intra-AS traffic engineering mechanisms.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119. this document are to be interpreted as described in RFC-2119.
skipping to change at page 2, line 51 skipping to change at page 2, line 53
5.1.6. Fast Recovery support using MPLS TE Fast Reroute..............16 5.1.6. Fast Recovery support using MPLS TE Fast Reroute..............16
5.1.7. DS-TE Support.................................................17 5.1.7. DS-TE Support.................................................17
5.1.8. Scalability and Hierarchical LSP Support......................17 5.1.8. Scalability and Hierarchical LSP Support......................17
5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels..............17 5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels..............17
5.1.10. Inter-AS MPLS TE Management..................................18 5.1.10. Inter-AS MPLS TE Management..................................18
5.1.10.1. Inter-AS MPLS TE MIB Requirements..........................18 5.1.10.1. Inter-AS MPLS TE MIB Requirements..........................18
5.1.10.2. Inter-AS MPLS TE Fault Management Requirements.............18 5.1.10.2. Inter-AS MPLS TE Fault Management Requirements.............18
5.1.11. Extensibility................................................19 5.1.11. Extensibility................................................19
5.1.12. Complexity and Risks.........................................19 5.1.12. Complexity and Risks.........................................19
5.1.13. Backward Compatibility.......................................19 5.1.13. Backward Compatibility.......................................19
5.1.14. Performance..................................................19
MPLS Inter-AS TE requirements June 2004
5.2. Requirements for Inter-AS MPLS TE across Multiple SP 5.2. Requirements for Inter-AS MPLS TE across Multiple SP
Administrative Domains..........................................19 Administrative Domains..........................................20
5.2.1. Confidentiality...............................................19 5.2.1. Confidentiality...............................................20
5.2.2. Policy Control................................................20 5.2.2. Policy Control................................................20
5.2.2.1. Inter-AS TE Agreement Enforcement Polices...................20 5.2.2.1. Inter-AS TE Agreement Enforcement Polices...................21
5.2.2.2. Inter-AS TE Rewrite Policies................................21 5.2.2.2. Inter-AS TE Rewrite Policies................................21
5.2.2.3 Inter-AS Traffic Policing....................................22
5.2.2.3 Inter-AS Traffic Policing....................................21 6. Security Considerations...........................................22
6. Evaluation Criteria...............................................22 7. Acknowledgement...................................................22
6.1. Detailed Requirement Satisfactions..............................22 8. Editor's Addresses................................................22
6.2. Performance.....................................................22 9. Normative References............................................. 23
7. Security Considerations...........................................22 10. Informative References...........................................23
8. Acknowledgement...................................................22 11. Full Copyright Statement.........................................25
9. Editor's Addresses................................................23
10. Normative References.............................................23
11. Informative References...........................................24
12. Full Copyright Statement.........................................25
Appendix A. Brief Description of BGP based Inter-AS Traffic Appendix A. Brief Description of BGP based Inter-AS Traffic
Engineering..............................................26 Engineering..............................................26
1. Introduction 1. Introduction
The MPLS Traffic Engineering mechanism documented in [TE-RSVP] may The MPLS Traffic Engineering (TE) mechanism documented in [TE-RSVP]
be deployed by Service Providers to achieve some of the most may be deployed by Service Providers to achieve some of the most
important objectives of network traffic engineering as described in important objectives of network traffic engineering as described in
[TE-OVW]. These objectives are summarized as listed below: [TE-OVW]. These objectives are summarized as:
- Supporting end-to-end services requiring QoS guarantees - Supporting end-to-end services requiring QoS guarantees
- Performing network resource optimization - Performing network resource optimization
- Providing fast recovery - Providing fast recovery
However, this traffic engineering mechanism can only be used within However, this traffic engineering mechanism can only be used within
an Autonomous System (AS). an Autonomous System (AS).
This document discusses requirements for an inter-AS MPLS Traffic This document discusses requirements for an inter-AS MPLS Traffic
Engineering mechanism that may be used to achieve the same set of Engineering mechanism that may be used to achieve the same set of
objectives across AS boundaries within or beyond SPs'administrative objectives across AS boundaries within or beyond a SP's
domains. aministrative domains.
The document will also present a set of application scenarios where The document will also present a set of application scenarios where
the inter-AS traffic engineering mechanism may be required. the inter-AS traffic engineering mechanism may be required.
These application scenarios will also be used to further facilitate These application scenarios will facilitate discussions for a
the discussions for a list of detailed requirements for such an detailed requirements list for this inter-AS Traffic Engineering
inter-AS Traffic Engineering mechanism along with the evaluation mechanism.
criteria for any technical solution(s) meeting these requirements.
Please note that there are other means of traffic engineering Please note that there are other means of traffic engineering
including IGP metrics based (for use within an AS) and BGP attribute including Interior Gateway Protocol (IGP); metrics based (for use
based (for use across ASes; see Appendix A) traffic engineering within an AS); and Border Gateway Protocol (BGP) attribute based
mechanisms. However, these means offer coarser control of traffic (for use across ASes, as described in Appendix A). However, because
paths, and do not readily offer bandwidth guarantees or fast these means offer coarser control of traffic paths and do not
restoration, and therefore will not be discussed further in this readily offer bandwidth guarantees or fast restoration, they will
document. not be discussed further in this document.
This document doesn't make any claims with respect to whether it is This document doesn't make any claims with respect to whether it is
possible to have a practical solution that meets all the possible to have a practical solution that meets all the
requirements listed in this document. requirements listed in this document.
MPLS Inter-AS TE requirements June 2004
2. Contributing Authors 2. Contributing Authors
This document was the collective work of several. The text and The text and content of this document was contributed to by the
content of this document was contributed by the editors and the
co-authors listed below (The contact information for the editors co-authors listed below (The contact information for the editors
appears in section 9, and is not repeated below.): appears in section 9, and is not repeated below.):
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Garden Air Tower Garden Air Tower
Iidabashi, Chiyoda-ku, Iidabashi, Chiyoda-ku,
Tokyo 102-8460, Tokyo 102-8460, JAPAN
JAPAN
E-mail : ke-kumaki@kddi.com E-mail : ke-kumaki@kddi.com
Paul Mabey Paul Mabey
Qwest Communications Qwest Communications
950 17th Street, 950 17th Street,
Denver, CO 80202 Denver, CO 80202, USA
USA
Email: pmabey@qwest.com Email: pmabey@qwest.com
Nadim Constantine Nadim Constantine
Infonet Services Corporation Infonet Services Corporation
2160 E. Grand Ave. 2160 E. Grand Ave.
El Segundo, CA 90025 El Segundo, CA 90025. USA
USA
Email: nadim_constantine@infonet.com Email: nadim_constantine@infonet.com
Pierre Merckx Pierre Merckx
EQUANT EQUANT
1041 route des Dolines - BP 347 1041 route des Dolines - BP 347
06906 SOPHIA ANTIPOLIS Cedex 06906 SOPHIA ANTIPOLIS Cedex, FRANCE
FRANCE
Email: pierre.merckx@equant.com Email: pierre.merckx@equant.com
Ting Wo Chung Ting Wo Chung
Bell Canada Bell Canada
181 Bay Street, Suite 350 181 Bay Street, Suite 350
Toronto, Ontario, Canada, M5J 2T3 Toronto, Ontario, Canada, M5J 2T3
Email: ting_wo.chung@bell.ca Email: ting_wo.chung@bell.ca
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex, France
France
E-mail: jeanlouis.leroux@francetelecom.com E-mail: jeanlouis.leroux@francetelecom.com
Yonghwan Kim Yonghwan Kim
SBC Laboratories, Inc. SBC Laboratories, Inc.
4698 Willow Road 4698 Willow Road
Pleasanton, CA 94588 Pleasanton, CA 94588, USA
USA
Email: Yonghwan_Kim@labs.sbc.com Email: Yonghwan_Kim@labs.sbc.com
MPLS Inter-AS TE requirements June 2004
3. Definitions and Requirements Statement 3. Definitions and Requirements Statement
3.1. Definitions 3.1. Definitions
The following provides a list of abbreviations or acronyms The following provides a list of abbreviations or acronyms
specifically pertaining to this document: specifically pertaining to this document:
SP: Service Providers including regional or global providers SP: Service Providers including regional or global providers
skipping to change at page 5, line 33 skipping to change at page 5, line 28
IP-only networks: SP's network where IP routing protocols such as IP-only networks: SP's network where IP routing protocols such as
IGP/ BGP are activated IGP/ BGP are activated
IP/MPLS networks: SP's network where MPLS switching capabilities and IP/MPLS networks: SP's network where MPLS switching capabilities and
signaling controls (e.g. ones described in signaling controls (e.g. ones described in
[MPLS-ARCH]) are activated in addition to IP [MPLS-ARCH]) are activated in addition to IP
routing protocols. routing protocols.
Intra-AS TE: A generic definition for traffic engineering mechanisms Intra-AS TE: A generic definition for traffic engineering mechanisms
operating over IP-only and/ or IP/MPLS network within an operating over IP-only and/ or IP/MPLS network within
an
AS. AS.
Inter-AS TE: A generic definition for traffic engineering mechanisms Inter-AS TE: A generic definition for traffic engineering mechanisms
operating over IP-only and/ or IP/MPLS network across operating over IP-only and/ or IP/MPLS network across
one or multiple ASes. one or multiple ASes.
TE LSP: MPLS Traffic Engineering Label Switched Path TE LSP: MPLS Traffic Engineering Label Switched Path
Intra-AS MPLS TE: An MPLS Traffic Engineering mechanism where its Intra-AS MPLS TE: An MPLS Traffic Engineering mechanism where its
TE LSPs Head-end LSR and Tail-end LSR reside in TE Label Switched Path (LSP), Head-end Label
Switching Router (LSR) and Tail-end LSR reside in
the same AS for traffic engineering purposes. the same AS for traffic engineering purposes.
Inter-AS MPLS TE: An MPLS Traffic Engineering mechanism where its Inter-AS MPLS TE: An MPLS Traffic Engineering mechanism where its
TE LSPs Head-end LSR and Tail-end LSR do not TE LSPs Head-end LSR and Tail-end LSR do not
reside within the same AS or both Head-end LSR and reside within the same AS or both Head-end LSR and
Tail-end LSR are in the same AS but the TE LSP Tail-end LSR are in the same AS but the TE LSP
transiting path may be across different ASes transiting path may be across different ASes
ASBR Routers: Border routers used to connect to another AS of a ASBR Routers: Border routers used to connect to another AS of a
different or the same Service Provider via one or more different or the same Service Provider via one or more
links inter-connecting between ASes. links inter-connecting between ASes.
Inter-AS TE Path: An TE path traversing multiple ASes and ASBRs, Inter-AS TE Path: An TE path traversing multiple ASes and ASBRs,
e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2... e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2...
ASBRn-ASn. ASBRn-ASn.
Inter-AS TE Segment: A portion of the Inter-AS TE path. Inter-AS TE Segment: A portion of the Inter-AS TE path.
MPLS Inter-AS TE requirements June 2004
Inter-AS DS-TE: Diffserv-aware Inter-AS TE.
CE: Customer Edge Equipment CE: Customer Edge Equipment
PE: Provider Edge Equipment that has direct connections to CEs. PE: Provider Edge Equipment that has direct connections to CEs.
P: Provider Equipment that has backbone trunk connections only. P: Provider Equipment that has backbone trunk connections only.
VRF: Virtual Private Network (VPN) Routing and Forwarding Instance. VRF: Virtual Private Network (VPN) Routing and Forwarding Instance.
PoP: Point of presence or a node in SP's network. PoP: Point of presence or a node in SP's network.
skipping to change at page 6, line 51 skipping to change at page 6, line 49
3.2.1. Inter-AS Bandwidth Guarantees 3.2.1. Inter-AS Bandwidth Guarantees
The DiffServ IETF working group has defined a set of mechanisms The DiffServ IETF working group has defined a set of mechanisms
described in [DIFF_ARCH], [DIFF_AF] and [DIFF_EF] or [MPLS-Diff] described in [DIFF_ARCH], [DIFF_AF] and [DIFF_EF] or [MPLS-Diff]
that can be activated at the edge or over a DiffServ domain to that can be activated at the edge or over a DiffServ domain to
contribute to the enforcement of a (set of) QoS policy(ies), which contribute to the enforcement of a (set of) QoS policy(ies), which
can be expressed in terms of maximum one-way transit delay, can be expressed in terms of maximum one-way transit delay,
inter-packet delay variation, loss rate, etc. inter-packet delay variation, loss rate, etc.
Many SPs have some or full deployment of Diffserv implementations in Many SPs have partial or full deployment of Diffserv implementations
their networks today, either across the entire network or at the in their networks today, either across the entire network or
least, on the edge of the network across CE-PE links. minimally on the edge of the network across CE-PE links.
In situations where strict QOS bounds are required, admission In situations where strict Quality of Service (QOS) bounds are
control inside the backbone of a network is in some cases required required, admission control inside the backbone of a network is in
in addition to current Diffserv mechanisms. some cases required in addition to current Diffserv mechanisms.
MPLS Inter-AS TE requirements June 2004
When the propagation delay can be bounded, the performance targets, When the propagation delay can be bounded, the performance targets,
such as maximum one-way transit delay may be guaranteed by providing such as maximum one-way transit delay, may be guaranteed by
bandwidth guarantees along the Diffserv-enabled path. providing bandwidth guarantees along the Diffserv-enabled path.
One typical example of this requirement is to provide bandwidth One typical example of this requirement is to provide bandwidth
guarantees over an end-to-end path for VoIP traffic classified as EF guarantees over an end-to-end path for VoIP traffic classified as EF
(Expedited Forwarding [DIFF_EF]) class in a Diffserv-enabled (Expedited Forwarding [DIFF_EF]) class in a Diffserv-enabled
network. When the EF path is extended across multiple ASes, network. When the EF path is extended across multiple ASes,
inter-AS bandwidth guarantee is then required. inter-AS bandwidth guarantee is then required.
Another case for inter-AS bandwidth guarantee is the requirement for Another case for inter-AS bandwidth guarantee is the requirement for
guaranteeing a certain amount of transit bandwidth across one or guaranteeing a certain amount of transit bandwidth across one or
multiple ASes. multiple ASes.
skipping to change at page 7, line 33 skipping to change at page 7, line 35
In Service Provider (SP) networks, the BGP protocol [BGP] is In Service Provider (SP) networks, the BGP protocol [BGP] is
deployed to exchange routing information between ASes. The inter-AS deployed to exchange routing information between ASes. The inter-AS
capabilities of BGP may also be employed for traffic engineering capabilities of BGP may also be employed for traffic engineering
purposes across the AS boundaries. Appendix A provides a purposes across the AS boundaries. Appendix A provides a
brief description of the current BGP-based inter-AS traffic brief description of the current BGP-based inter-AS traffic
engineering practices. engineering practices.
SPs have managed to survive with this coarse set of BGP-based SPs have managed to survive with this coarse set of BGP-based
traffic engineering facilities across inter-AS links in a largely traffic engineering facilities across inter-AS links in a largely
best effort environment. Certainly in many cases ample bandwidth best-effort environment. Certainly in many cases ample bandwidth
within SP's network and across inter-AS links reduces the need for within SP's network and across inter-AS links reduces the need for
more elaborated inter-AS TE policies. more elaborate inter-AS TE policies.
However, in the case where a SP network is deployed over multiple However, in the case where a SP network is deployed over multiple
ASes, for example, as the number of inter-AS links grows, the ASes, for example, as the number of inter-AS links grows, the
complexity of the inter-AS policies and the difficulty in inter-AS complexity of the inter-AS policies and the difficulty in inter-AS
TE path optimization increase to a level such that it may soon TE path optimization increase to a level such that it may soon
become unmanageable. become unmanageable.
Another example is where inter-AS links are established between Another example is where inter-AS links are established between
different SP administrative domains. Un-deterministic factors such different SP administrative domains. Un-deterministic factors such
as un-coordinated routing and network changes as well as sub-optimum as un-coordinated routing and network changes, as well as sub-
traffic conditions would potentially lead to a complex set of optimum traffic conditions would potentially lead to a complex set
Inter-AS traffic engineering policies where current traffic of Inter-AS traffic engineering policies where current traffic
engineering mechanisms would probably not scale well. engineering mechanisms would probably not scale well.
In these situations where resource optimization is required and/ or In these situations where resource optimization is required and/ or
specific routing requirements arise, the BGP-based inter-AS specific routing requirements arise, the BGP-based inter-AS
facilities will need to be complemented by a more granular inter-AS facilities will need to be complemented by a more granular inter-AS
traffic engineering mechanism. traffic engineering mechanism.
MPLS Inter-AS TE requirements June 2004
3.2.3. Fast Recovery across ASes 3.2.3. Fast Recovery across ASes
When extending services such as VoIP across ASes, customers often When extending services such as VoIP across ASes, customers often
demands SPs to maintain the same level of performance targets such reqiure SPs to maintain the same level of performance targets, such
as packet loss and service availability as ones that can be achieved as packet loss and service availability, as achieved within an AS.
within an AS. As a consequence, fast convergence in a stable As a consequence, fast convergence in a stable fashion upon
fashion upon link/SRLG/node failures becomes a strong requirement. link/SRLG/node failures becomes a strong requirement. This is
This is clearly difficult to achieve with current inter-domain clearly difficult to achieve with current inter-domain techniques,
techniques, especially in cases of link/SRLG failures between ASBRs especially in cases of link/SRLG failures between ASBRs or ASBR node
or ASBR node failures. failures.
3.3. Inter-AS Traffic Engineering Requirements Statement 3.3. Inter-AS Traffic Engineering Requirements Statement
Just as in the applicable case of deploying MPLS TE in a SP's Just as in the applicable case of deploying MPLS TE in a SP's
network, an inter-AS TE method in addition to BGP-based traffic network, an inter-AS TE method in addition to BGP-based traffic
engineering capabilities needs to be deployed across inter-AS links engineering capabilities needs to be deployed across inter-AS links
over where resource optimization, QOS guarantees and fast recovery where resource optimization, QOS guarantees and fast recovery
are required. are required.
This is especially critical in a Diffserv-enabled, multi-class This is especially critical in a Diffserv-enabled, multi-class
environment described in [PSTE] where statistical performance environment described in [PSTE] where statistical performance
targets must be maintained consistently over the entire path targets must be maintained consistently over the entire path
across different ASes. across different ASes.
The approach of extending current intra-AS MPLS TE capabilities The approach of extending current intra-AS MPLS TE capabilities
[TE-RSVP] across inter-AS links for IP/MPLS networks is considered [TE-RSVP] across inter-AS links for IP/MPLS networks is considered
here because of already available implementations and operational here because of already available implementations and operational
experiences. experiences.
Please note that the inter-AS traffic engineering over an IP-only Please note that the inter-AS traffic engineering over an IP-only
network is for future consideration since there is no sufficient network is for future consideration since there is not sufficient
interest for similar requirements to those of IP/MPLS networks interest for similar requirements to those of IP/MPLS networks
at this time. More specifically, this document only covers the at this time. More specifically, this document only covers the
inter-AS TE requirements for packet based IP/MPLS networks. inter-AS TE requirements for packet based IP/MPLS networks.
4. Application Scenarios 4. Application Scenarios
The following sections present a few application scenarios over The following sections present a few application scenarios over
IP/MPLS networks where requirements cannot be addressed with current IP/MPLS networks where requirements cannot be addressed with current
intra-AS MPLS TE mechanism and give rise to considerations for intra-AS MPLS TE mechanism and give rise to considerations for
inter-AS MPLS traffic engineering requirements. inter-AS MPLS traffic engineering requirements.
Although not explicitly noted in the following discussions, fast Although not explicitly noted in the following discussions, fast
recovery of traffic path(s) crossing multiple ASes in a stable recovery of traffic path(s) crossing multiple ASes in a stable
fashion is particularly important in case of link/SRLG/node failures fashion is particularly important in the case of link/SRLG/node
at AS boundaries for all application scenarios presented here. failures at AS boundaries for all application scenarios presented
here.
MPLS Inter-AS TE requirements June 2004
4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees 4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees
4.1.1 Scenario I - Extended or Virtual PoP (VPoP) 4.1.1 Scenario I - Extended or Virtual PoP (VPoP)
A global service provider (SP1), for example would like to expand A global service provider (SP1) would like to expand its reach into
its reach in a region where a regional service provider's (SP2) a region where a regional service provider's (SP2) network has
network has already established an extended coverage in its PoP already established a denser network presence.
density.
In this scenario, the SP1 may establish interconnections with SP2 in In this scenario, the SP1 may establish interconnections with SP2 in
one or multiple points in that region. It may then use SP2's one or multiple points in that region. In their customer dense
network as an extended transport by co-locating aggregation routers regions, SP1 may utilize SP2's network as an extended transport by
in some SP2's PoPs that are in the regions where SP1 has a larger co-locating aggregation routers in SP2's PoPs.
number of customer sites.
In order to ensure bandwidth capacity provided by SP2 and achieve In order to ensure bandwidth capacity provided by SP2 and achieve
some degrees of transparency to SP2's network changes in terms of some degrees of transparency to SP2's network changes in terms of
capacity and network conditions, one or more Inter-AS MPLS TE capacity and network conditions, one or more Inter-AS MPLS TE
trunk(s) can be built between SP1's ASBR or PE router inside AS1 and trunk(s) can be built between SP1's ASBR or PE router inside AS1 and
SP1's PE routers co-locating in SP2's PoPs, as illustrated in the SP1's PE routers co-locating in SP2's PoPs, as illustrated in the
diagram below: diagram below:
<===========Inter-AS MPLS TE Tunnel===========> <===========Inter-AS MPLS TE Tunnel===========>
----- ----- ----- -----
________|ASBR |___Inter-AS___|ASBR |________ ________|ASBR |___Inter-AS___|ASBR |________
| | RTR | Link | RTR | | | | RTR | Link | RTR | |
---- ----- ----- ----- ----- ---- ----- ----- ----- -----
|SP1 |_____| SP2 | | SP1 | |SP1 |_Inter-AS_| SP2 | | SP1 |
|VPoP| |P/PE | |P/PE | |VPoP| Link |P/PE | |P/PE |
---- ----- ----- ----- ----- ---- ----- ----- ----- -----
|________|ASBR |___Inter-AS___|ASBR |________| |________|ASBR |___Inter-AS___|ASBR |________|
| RTR | Link | RTR | | RTR | Link | RTR |
----- ----- ----- -----
<=================Inter-AS MPLS TE Tunnel=================> <=================Inter-AS MPLS TE Tunnel======================>
+-SP1 AS1-+ +-------SP2 AS2-----+ +------SP1 AS1------+ +-SP1 AS1-+ +---SP2 AS2-----+ +------SP1 AS1------+
In situations where end-to-end Diffserv paths must be maintained, In situations where end-to-end Diffserv paths must be maintained,
both SP's networks may need to provision Diffserv PHB at each hop both SP's networks may need to provision Diffserv PHB at each hop
supporting a set of traffic classes with compatible performance supporting a set of traffic classes with compatible performance
targets. The subsequent issues regarding Service Level Agreement targets. The subsequent issues regarding Service Level Agreement
(SLA) boundaries, reporting and measuring system inter-operability (SLA) boundaries, reporting and measuring system inter-operability
and support demarcations are beyond the scope of this document and and support demarcations are beyond the scope of this document and
will therefore not be discussed here. will therefore not be discussed here.
Note also that either the SP1 or SP2 network may not be a If either SP1s or SP2s network is not a Diffserv-aware network,
Diffserv-aware network. The scenario would still apply to provide the scenario would still apply to provide bandwidth guarantees.
bandwidth guarantees.
The SP2, on the other hand, can similarly choose to expand its reach 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 beyond its servicing region over SP1's network via inter-AS MPLS
TE paths. TE paths.
MPLS Inter-AS TE requirements June 2004
It is worth mentioning that these remote aggregation routers It is worth mentioning that these remote aggregation routers
co-located in other SP's network will unlikely participate in co-located in another SP's network are unlikely to host SP1's IGP
hosting SP's IGP and BGP routing planes and will most likely and BGP routing planes and will more likely maintain their own AS or
maintain its own AS or be part of the SP1's AS. In this case, such be part of the SP1's AS. In this case, such TE tunnels may cross
TE tunnels may cross several ASes, but the Head-end and Tail-end several ASes, but the Head-end and Tail-end LSRs of TE tunnel may
LSRs of TE tunnel may have the same AS number, as shown in the have the same AS number, as shown in the diagram above.
diagram above.
4.1.2. Scenario II - Extended or Virtual Trunk 4.1.2. Scenario II - Extended or Virtual Trunk
Instead of co-locating a PE router in SP2's PoP, SP1, for example Instead of co-locating a PE router in SP2's PoP, SP1 may also choose
may also choose to aggregate customer VPN sites onto a SP2's PE to aggregate customer VPN sites onto a SP2's PE router where inter-
router where inter-AS TE tunnels can be built and signaled through AS TE tunnels can be built and signaled through SP2's MPLS network
SP2's MPLS network between the SP2 PoP (to which SP1 customer CEs between the SP2 PoP (to which SP1a customer CEs are directly
are directly connected) and SP1's ASBR or PE routers inside SP2's connected) and SP1's ASBR or PE routers inside SP2's network. This
network. This allows SP1s customers connected to SP2 PE router to allows SP1's customers connected to SP2 PE router to receive a
receive a guaranteed bandwidth service up to the TE LSP tail-end guaranteed bandwidth service up to the TE LSP tail-end router
router located in SP1's network. located in SP1's network.
In this scenario, there could be two applicable cases: In this scenario, there could be two applicable cases:
Case 1 - the inter-AS MPLS TE tunnel functions as an extended or Case 1 - the inter-AS MPLS TE tunnel functions as an extended or
virtual trunk aggregating SP1 CE's local-loop access circuits on virtual trunk aggregating SP1s CE's local-loop access circuits on
SP2's MPLS network over which the bandwidth can be guaranteed to the SP2's MPLS network over which the bandwidth can be guaranteed to the
TE LSP tail-end router located in SP1s network, as shown in the TE LSP tail-end router located in SP1's network, as shown in the
diagram below: diagram below:
<====Inter-AS MPLS TE Tunnel====> <====Inter-AS MPLS TE Tunnel====>
or or
< ===Inter-AS MPLS TE Tunnel===============> < ===Inter-AS MPLS TE Tunnel===============>
---- ----- ----- ----- ----- ---- ----- ----- ----- -----
| CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 | | CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE | | | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- ----- ---- ----- ----- ----- -----
+SP1 Customer AS3+ +-----SP2 AS2---+ +-SP1 AS1-------+ +SP1 Customer ASx+ +-----SP2 AS2---+ +-SP1 AS1-------+
Case 2 - the inter-AS MPLS TE tunnel in this case functions as an Case 2 - the inter-AS MPLS TE tunnel in this case functions as an
extended or virtual local access link from SP1's CE on SP2's network extended or virtual local access link from SP1's CE on SP2's network
to the SP1's ASBR or PE: to the SP1's ASBR or PE:
<==============Inter-AS MPLS TE Tunnel==============> <==============Inter-AS MPLS TE Tunnel==============>
or or
<==============Inter-AS MPLS TE Tunnel========================> <==============Inter-AS MPLS TE Tunnel========================>
---- ----- ----- ----- ----- ---- ----- ----- ----- -----
| CE |____Local_____| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 | | CE |____Local_____| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE | | | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- ----- ---- ----- ----- ----- -----
+SP1 Customer AS3+ +------SP2 AS2---+ +--SP1 AS1-----+ +SP1 Customer ASx+ +------SP2 AS2---+ +--SP1 AS1-----+
MPLS Inter-AS TE requirements June 2004
In case 2 above, SP2 may elect to establish an aggregating or In case 2 above, SP2 may elect to establish an aggregating or
hierarchical intra-AS MPLS TE tunnel between the transiting P or PE hierarchical intra-AS MPLS TE tunnel between the transiting P or PE
router and SP2's ASBR router just to reduce the number of tunnel router and SP2's ASBR router just to reduce the number of tunnel
states signaled from the SP2 PE to where SP1's CEs are connected. states signaled from the SP2 PE to where SP1's CEs are connected.
4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE 4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE
In this scenario as illustrated below, customers require to In this scenario as illustrated below, customers require the
establish MPLS TE tunnel from CE1 to CE2 end-to-end across several establishment of MPLS TE tunnel from CE1 to CE2 end-to-end across
SP's networks. One application example would be the guaranteed several SPs networks. One application example would be the
bandwidth for voice- or video-over-IP services. guaranteed bandwidth for voice- or video-over-IP services.
<======================Inter-AS MPLS TE Tunnel==================> <======================Inter-AS MPLS TE Tunnel==================>
--- ----- ----- ----- ----- --- --- ----- ----- ----- ----- ---
|CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2| |CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2|
| | | PE | | RTR | Link | RTR | | PE | | | | | | PE | | RTR | Link | RTR | | PE | | |
--- ----- ----- ----- ----- --- --- ----- ----- ----- ----- ---
+Cust AS1+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASx+ +Cust ASx+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASy+
The diagram below illustrates another example where CE1 and CE2 are The diagram below illustrates another example where CE1 and CE2 are
customers of SP1 with eBGP peering relationships established across customers of SP1 with extenal BGP (eBGP) peering relationships
the CE-PE links. A inter-AS MPLS TE tunnel may then be established established across the CE-PE links. An inter-AS MPLS TE tunnel may
from CE1 in AS1 to CE2 which may belong to the same AS or different then be established from CE1 in ASx to CE2 which may belong to the
AS than that of CE1 across SP1's network in AS2. same AS or a different AS than that of CE1 across SP1's network in
AS2.
<===============Inter-AS MPLS TE Tunnel=====================> <===============Inter-AS MPLS TE Tunnel=====================>
--- ----- ---- ---- ----- --- --- ----- ---- ---- ----- ---
|CE1|______| SP1 |_____|SP1 |____|SP1 |____| SP1 |_________|CE2| |CE1|______| SP1 |_____|SP1 |____|SP1 |____| SP1 |_________|CE2|
| | | PE1 | |P1 | |P2 | | PE2 | | | | | | PE1 | |P1 | |P2 | | PE2 | | |
--- ----- ---- ---- ----- --- --- ----- ---- ---- ----- ---
+-Cust AS1-+ +-------------SP1 AS2----------------+ +-Cust ASx-+ +-Cust ASx-+ +-------------SP1 AS2----------------+ +-Cust ASy-+
The above example shows that SP1's network has a single AS. The above example shows that SP1's network has a single AS.
Obviously, there may be multiple ASes between CE1 and CE2 as well in Obviously, there may be multiple ASes between CE1 and CE2 as well as
the SP1's network. in the SP1's network.
In addition, where both CE1 and CE2 residing in the same AS, they In addition, where both CE1 and CE2 reside in the same AS, they will
likely share the same private AS number. likely share the same private AS number.
Scenario III however, will not scale well should there be a larger Scenario III however, will not scale well if there is a greater
number of inter-AS TE MPLS tunnels in some degrees of partial mesh number of inter-AS TE MPLS tunnels in some degrees of partial mesh
or full mesh. Therefore, it is expected that this scenario will or full mesh. Therefore, it is expected that this scenario will
not have a large number of deployments, unless some mechanisms such have few deployments, unless some mechanisms such as hierarchical
as hierarchical intra-AS TE-LSPs are used to reduce the number of intra-AS TE-LSPs are used to reduce the number of signaling states.
signaling states
MPLS Inter-AS TE requirements June 2004
4.2. Application Scenarios Requiring Inter-AS Resource Optimization 4.2. Application Scenarios Requiring Inter-AS Resource Optimization
The scenarios presented in this section mainly deal with inter-AS The scenarios presented in this section mainly deal with inter-AS
resource optimization. resource optimization.
4.2.1. Scenario IV - TE across multi-AS within a Single SP 4.2.1. Scenario IV - TE across multi-AS within a Single SP
Administrative Domain Administrative Domain
As mentioned in [TE-APP], SPs have generally admitted that the As mentioned in [TE-APP], SPs have generally admitted that the
current MPLS TE mechanism provides a great deal of tactical and current MPLS TE mechanism provides a great deal of tactical and
strategic values in areas of traffic path optimization [TE-RSVP] and strategic value in areas of traffic path optimization [TE-RSVP] and
rapid local repair capabilities [TE-FRR] via a set of on-line or rapid local repair capabilities [TE-FRR] via a set of on-line or
off-line constraint-based searching algorithms. off-line constraint-based searching algorithms.
From a service provider's perspective, another way of stating the From a service provider's perspective, another way of stating the
objectives of traffic engineering is to be able to deliver more objectives of traffic engineering is to utilize available capacity
customer traffic with already available capacity in the network in the network for delivering customer traffic without violating
without violating performance targets, and/ or to provide better QOS performance targets, and/ or to provide better QOS services via an
services via an improved network utilization, operating more likely improved network utilization, operating more likely below congestion
below congestion thresholds. thresholds.
It is worth noting that situations where resource provisioning is It is worth noting that situations where resource provisioning is
not an issue, e.g. low density in inter-AS connectivity or ample not an issue, e.g. low density in inter-AS connectivity or ample
inter-AS capacity may not require more scalable and granular TE inter-AS capacity, it may not require more scalable and granular TE
facilities beyond BGP routing policies since such policies could be facilities beyond BGP routing policies since such policies can be
rather simple and because inter-AS resource optimization is not an rather simple and because inter-AS resource optimization is not an
absolute requirement. absolute requirement.
However many SPs, especially those with networks across multiple However many SPs, especially those with networks across multiple
continents as well as sparsely connected, have designed their Continents, as well as those with sparsely connected networks, have
multi-AS routing policies, for example, along or within the designed their multi-AS routing policies along or within the
continental or sub-continental boundaries where the number of ASes continental or sub-continental boundaries where the number of ASes
can range from a very few to dozens. Generally, inter-continent or can range from a very few to dozens. Generally, inter-continent or
sub-continent capacity is very expensive. Some Service Providers sub-continent capacity is very expensive. Some Service Providers
have multiple ASes in the same country and would like to optimize have multiple ASes in the same country and would like to optimize
resources over their inter-region links. This would demand a resources over their inter-region links. This would demand a
more scalable degree of resource optimization, which warrants the more scalable degree of resource optimization, which warrants the
consideration of extending current intra-AS MPLS TE capabilities consideration of extending current intra-AS MPLS TE capabilities
across inter-AS links. across inter-AS links.
In addition, one may only realize higher efficiency in conducting In addition, one may only realize higher efficiency in conducting
traffic optimization and path protection/ restoration planning when traffic optimization and path protection/ restoration planning when
coordinating all network resources (not partially) as a whole. For coordinating all network resources (not partially) as a whole. For
a network which may consist of many ASes, this could be realized via a network which may consist of many ASes, this could be realized via
the establishment of inter-AS TE LSPs as shown in the diagragm the establishment of inter-AS TE LSPs as shown in the diagragm
below: below:
MPLS Inter-AS TE requirements June 2004
<===================Inter-AS MPLS Tunnel=============> <===================Inter-AS MPLS Tunnel=============>
-------- -------- -------- -------- -------- --------
| |_______________| |____________| | | |_______________| |____________| |
| SP1 |_______________| SP1 |____________| SP1 | | SP1 |_______________| SP1 |____________| SP1 |
| AS1 |_______________| AS2 |____________| AS3 | | AS1 |_______________| AS2 |____________| AS3 |
| | | | | | | | | | | |
-------- -------- -------- -------- -------- --------
|| || || ||
|| --------- || || --------- ||
||___________________| SP1 |________________|| ||___________________| SP1 |________________||
skipping to change at page 13, line 56 skipping to change at page 13, line 58
[ ---- ---- ] [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] [ ---- ---- ]
[ |P/PE|__|ASBR|]_Inter-AS_[|ASBR|.|ASBR|]_Inter-AS_[|ASBR| |P/PE|] [ |P/PE|__|ASBR|]_Inter-AS_[|ASBR|.|ASBR|]_Inter-AS_[|ASBR| |P/PE|]
[ |RTR | |RTR |] Link [|RTR | |RTR |] Link [|RTR | |RTR |] [ |RTR | |RTR |] Link [|RTR | |RTR |] Link [|RTR | |RTR |]
[ ---- ---- ] [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] [ ---- ---- ]
[ ] [ ] [ ] [ ] [ ] [ ]
<================Inter-AS MPLS TE Tunnel=====================> <================Inter-AS MPLS TE Tunnel=====================>
+SP1 Regional ASx+ +Transit SP2 AS2,etc...SPi ASi+ +------SP1 AS1-+ +SP1 Regional ASx+ +Transit SP2 AS2,etc...SPi ASi+ +------SP1 AS1-+
This scenario can be viewed as a broader case of Scenario I shown in This scenario can be viewed as a broader case of Scenario I shown in
section 4.1.1 where the "VPoP" could be expanded into a regional section 4.1.1 where the "VPoP" could be expanded into a regional
network of SP1. By the same token, the AS number for SP1's network of SP1. By the same token, the AS number for SP1's regional
regional network ASx may be the same as or different from AS1. network ASx may be the same as or different from AS1.
MPLS Inter-AS TE requirements June 2004
The inter-AS MPLS TE LSP in this case may also be used to backup an The inter-AS MPLS TE LSP in this case may also be used to backup an
internal path as depicted in the diagram below, although this could internal path as depicted in the diagram below, although this could
introduce routing complexities: introduce routing complexities:
<===========Inter-AS MPLS TE Tunnel=======> <===========Inter-AS MPLS TE Tunnel=======>
+----------------------------SP1 AS1-----------------------------+ +----------------------------SP1 AS1-----------------------------+
[ ] [ ]
[ ---- ---- ---- ---- ] [ ---- ---- ---- ---- ]
[ |P/PE|__|ASBR|__________Primary Intera-AS________|P | |PE |] [ |P/PE|__|ASBR|__________Primary Intera-AS________|P | |PE |]
skipping to change at page 14, line 33 skipping to change at page 14, line 35
| | [ ] | | | | [ ] | |
| | [ ---- ---- ] | | | | [ ---- ---- ] | |
| |__ Inter-AS_[|ASBR|..|ASBR|]_Inter-AS_| | | |__ Inter-AS_[|ASBR|..|ASBR|]_Inter-AS_| |
| Link [|RTR | |RTR |] Link | | Link [|RTR | |RTR |] Link |
| [ ---- ---- ] | | [ ---- ---- ] |
| [ ] | | [ ] |
| | | |
+======Backup Inter-AS MPLS TE Tunnel======+ +======Backup Inter-AS MPLS TE Tunnel======+
+Transit SP2 AS2,SP3 AS3,etc....SPi ASi+ +Transit SP2 AS2,SP3 AS3,etc....SPi ASi+
5. Detailed Requirements for Inter-AS MPLS Traffic Engnineering 5. Detailed Requirements for Inter-AS MPLS Traffic Engineering
This section discusses detailed requirements for inter-AS MPLS TE in This section discusses detailed requirements for inter-AS MPLS TE in
two principal areas: 1) requirements for inter-AS MPLS TE in the two principal areas: 1) requirements for inter-AS MPLS TE in the
same SP administrative domain and 2) requirements for inter-AS MPLS same SP administrative domain and 2) requirements for inter-AS MPLS
TE across different SP administrative domains. TE across different SP administrative domains.
5.1. Requirements within one SP Administrative Domain 5.1. Requirements within one SP Administrative Domain
This section presents detailed requirements for inter-AS MPLS TE This section presents detailed requirements for inter-AS MPLS TE
within the same SP administrative domain. within the same SP administrative domain.
5.1.1. Inter-AS MPLS TE Operations and Interoperability 5.1.1. Inter-AS MPLS TE Operations and Interoperability
The inter-AS MPLS TE solution SHOULD be consistent with requirements The inter-AS MPLS TE solution SHOULD be consistent with requirements
discussed in [TE-REQ] and the derived solution MUST be such that discussed in [TE-REQ] and the derived solution MUST be such that
it will interoperate seamlessly with current intra-AS MPLS TE it will interoperate seamlessly with current intra-AS MPLS TE
mechanism and inherit its capability sets from [TE-RSVP]. mechanism and inherit its capability sets from [TE-RSVP].
The proposed solution SHOULD allow to provision at the Head/Tail end The proposed solution SHOULD allow the provisioning of a TE LSP at
with end-to-end RSVP signaling (eventually with loose paths) the Head/Tail end with end-to-end Resource Reservation Protocol
traversing across the interconnected ASBRs, without further (RSVP) signaling (eventually with loose paths) traversing across the
provisioning required along the transit path. interconnected ASBRs, without further provisioning required along
the transit path.
MPLS Inter-AS TE requirements June 2004
5.1.2. Protocol Signaling and Path Computations 5.1.2. Protocol Signaling and Path Computations
One can conceive that an inter-AS MPLS TE tunnel path signaled One can conceive that an inter-AS MPLS TE tunnel path signaled
across inter-AS links consists of a sequence of intra-AS segments. across inter-AS links consists of a sequence of intra-AS segments.
The proposed solution SHOULD provide the ability to either The proposed solution SHOULD provide the ability to either
explicitly select or auto-discover the following elements explicitly select or auto-discover the following elements when
when signaling the inter-AS TE LSP path: signaling the inter-AS TE LSP path:
- a set of AS numbers as loose HoPs - a set of AS numbers as loose HoPs and/or
- a set of LSRs including ASBRs - a set of LSRs including ASBRs
and to specify the above elements in the ERO and record them in the It should also specify the above elements in the Explicit Route
RRO of the Resv message just to keep track of the set of ASes or Object (ERO) and record them in the Record Route Object (RRO) of the
ASBRs traversed by the inter-As TE LSP. Resv message just to keep track of the set of ASes or ASBRs
traversed by the inter-As TE LSP.
In the case of establishing inter-AS TE LSP traversing multiple ASes In the case of establishing inter-AS TE LSP traversing multiple ASes
within the same SP networks, the solution SHOULD also allow the within the same SP networks, the solution SHOULD also allow the
Headend LSR to explicitly specify the hops across anyone of Head-end LSR to explicitly specify the hops across any one of
the transiting ASes and the TE tunnel headhend SHOULD also check the transiting ASes and the TE tunnel Head-end SHOULD also check
the explicit segment to make sure that the constrainsts are met. the explicit segment to make sure that the constraints are met.
In addition, The proposed solution SHOULD also provide the ability In addition, the proposed solution SHOULD provide the ability
to specify and signal that certain loose or explicit nodes (e.g. AS to specify and signal that certain loose or explicit nodes (e.g. AS
numbers, etc.) and resources to be explicitly excluded in the numbers, etc.) and resources are to be explicitly excluded in the
inter-AS TE LSP path establishment, such as one defined in inter-AS TE LSP path establishment, such as one defined in
[EXCLUDE-ROUTE] for instance. [EXCLUDE-ROUTE] for instance.
5.1.3 Optimality 5.1.3 Optimality
The solution SHOULD allow the set up of an inter-AS TE LSP that The solution SHOULD allow the set-up of an inter-AS TE LSP that
complies with a set of TE constraints defined in [TE-REQ]) and complies with a set of TE constraints defined in [TE-REQ]) and
follow an optimal path. follows an optimal path.
An optimal path is defined as a path whose end-to-end cost is An optimal path is defined as a path whose end-to-end cost is
minimal, based upon either an IGP or a TE metric. Note that in minimal, based upon either an IGP or a TE metric. Note that in
the case of an inter-AS path across several ASes having completely the case of an inter-AS path across several ASes having completely
different IGP metric policies, the notion of minimal path might different IGP metric policies, the notion of minimal path might
require IGP metric normalization, for example. require IGP metric normalization.
The solution SHOULD provide mechanism(s) to compute and establish an The solution SHOULD provide mechanism(s) to compute and establish an
optimal end-to-end path for the inter-AS TE LSP and SHOULD also optimal end-to-end path for the inter-AS TE LSP and SHOULD also
allow for reduced suboptimality since the path may not remain allow for reduced optimality (or sub-optimality) since the path may
optimal for the life-time of the LSP not remain optimal for the life-time of the LSP
5.1.4 Support of diversely routed inter-AS TE LSP 5.1.4 Support of diversely routed inter-AS TE LSP
In some cases it might be desirable to set up multiple inter-AS TE In some cases it might be desirable to set up multiple inter-AS TE
LSPs between a pair of LSRs, when: LSPs between a pair of LSRs when:
(1) A single TE LSP satisfying the required set of constraints (1) a single TE LSP satisfying the required set of constraints
cannot be found, in which case it may require load splitting. cannot be found, in which case it may require load splitting;
MPLS Inter-AS TE requirements June 2004
(2) Multiple TE paths may be required to limit the impact of a (2) multiple TE paths may be required to limit the impact of a
network element failure to a portion of the traffic. As an network element failure to a portion of the traffic (as an
example, two VoIP gateways may load balance the traffic among example, two VoIP gateways may load balance the traffic among
a set of inter-AS TE LSPs. a set of inter-AS TE LSPs);
(3) Path protection (e.g. 1:1 or 1:N) as discussed in (3) path protection (e.g. 1:1 or 1:N) as discussed in
[MPLS-Recov]. [MPLS-Recov].
In the examples above, being able to set up diversely routed TE LSPs In the examples above, being able to set up diversely routed TE LSPs
becomes a requirement for inter-AS TE. becomes a requirement for inter-AS TE.
The solution SHOULD be able to set up a set of link/SRLG/Node The solution SHOULD be able to set up a set of link/SRLG/Node
diversely routed inter-AS TE LSPs. diversely routed inter-AS TE LSPs.
5.1.5. Re-optimization 5.1.5. Re-optimization
Once an inter-AS TE LSP has been established and should there be any Once an inter-AS TE LSP has been established, and should there be
resource or other changes inside anyone of the ASes, the any resource or other changes inside anyone of the ASes, the
solution MUST be able to re-optimize the LSP accordingly and solution MUST be able to re-optimize the LSP accordingly and
non-disruptively, either upon expiration of a configurable timer or non-disruptively, either upon expiration of a configurable timer or
triggered by a network event or a manual request at the TE tunnel triggered by a network event or a manual request at the TE tunnel
Head-end. Head-End.
The solution SHOULD provide an option for the Head-End LSRs to The solution SHOULD provide an option for the Head-End LSRs to
control if re-optimizing or not should there exist a more optimal control if re-optimizing or not should there exist a more optimal
path in one of the ASes. path in one of the ASes.
In the case of an identical set of traversed path, the solution In the case of an identical set of traversed path, the solution
SHOULD provide an option for the Head-End LSRs to control if SHOULD provide an option for the Head-End LSRs to control if
re-optimizing or not should there exist a more optimal path in one re-optimizing or not should there exist a more optimal path in one
of the transit ASes along the inter-AS TE LSP path. of the transit ASes along the inter-AS TE LSP path.
Furthermore, the solution MUST provide the ability to reject Furthermore, the solution MUST provide the ability to reject
re-optimizatization at AS boundaries. re-optimization at AS boundaries.
5.1.6. Fast Recovery support using MPLS TE Fast Reroute 5.1.6. Fast Recovery support using MPLS TE Fast Reroute
There are in general two or more inter-AS links between multiple There are in general two or more inter-AS links between multiple
pair of ASBRs for redundancy. The topological density between ASes pair of ASBRs for redundancy. The topological density between ASes
in a SP network with multi-ASes is generally much higher. In the in a SP network with multi-ASes is generally much higher. In the
event of an inter-AS link failure, rapid local protection SHOULD event of an inter-AS link failure, rapid local protection SHOULD
also be made available and interoperate with current intra-AS MPLS also be made available and interoperate with current intra-AS MPLS
TE fast re-route mechanism from [TE-FRR]. TE fast re-route mechanism from [TE-FRR].
The traffic routed onto an inter-AS TE tunnel SHOULD also be fast The traffic routed onto an inter-AS TE tunnel SHOULD also be fast
protected against any node failure where the node could be internal protected against any node failure where the node could be internal
to an AS or at the AS boundary. to an AS or at the AS boundary.
MPLS Inter-AS TE requirements June 2004
5.1.7. DS-TE Support 5.1.7. DS-TE Support
The proposed inter-AS MPLS TE solution SHOULD also satisfy core The proposed inter-AS MPLS TE solution SHOULD satisfy core
requirements documented in [DS-TE] and interoperate seamlessly with requirements documented in [DS-TE] and interoperate seamlessly with
current intra-AS MPLS DS-TE mechanism [DSTE-PROT]. the current intra-AS MPLS DS-TE mechanism [DSTE-PROT].
It is worth pointing out that the compatibility clause in section It is worth pointing out that the compatibility clause in section
4.1 of [DS-TE] SHOULD also be faithfully applied in the development 4.1 of [DS-TE] SHOULD also be faithfully applied to the solution
of the solutions. development
5.1.8. Scalability and Hierarchical LSP Support 5.1.8. Scalability and Hierarchical LSP Support
The proposed solution(s) MUST have minimum impact on the network The proposed solution(s) MUST have a minimum impact on network
scalability from both intra and inter-AS perspectives. scalability from both intra and inter-AS perspectives.
This requirement applies to all of the following: This requirement applies to all of the following:
- IGP (impact in terms of IGP flooding, Path computation, etc.). - IGP (impact in terms of IGP flooding, Path computation, etc.)
- BGP (impact in terms of additional information carried within - BGP (impact in terms of additional information carried within
BGP, number of routes, flaps, overload events, etc.). BGP, number of routes, flaps, overload events, etc.)
- RSVP TE (message rate, number of retained states, ,etc.). - RSVP TE (message rate, number of retained states, ,etc.)
It is also conceivable that there would potentially be scalability It is also conceivable that there would potentially be scalability
issues as the number of required inter-AS MPLS TE tunnels increases. issues as the number of required inter-AS MPLS TE tunnels increases.
In order to reduce the number of tunnel states to be maintained by In order to reduce the number of tunnel states to be maintained by
each transiting PoP, the proposed solution SHOULD allow TE LSP each transiting PoP, the proposed solution SHOULD allow TE LSP
aggregation such that individual tunnels can be carried onto one or aggregation such that individual tunnels can be carried onto one or
more aggregating LSP(s). One such mechanism, for example is more aggregating LSP(s). One such mechanism, for example is
described in [MPLS-LSPHIE]. described in [MPLS-LSPHIE].
5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels 5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels
There SHOULD be several possibilities to map a particular traffic There SHOULD be several possibilities to map particular traffic
to a particular destination onto a specific inter-AS TE LSP. to a particular destination onto a specific inter-AS TE LSP.
For example, static routing could be used if IP destination For example, static routing could be used if IP destination
addresses are known. Another example is to utilize static routing addresses are known. Another example is to utilize static routing
using recursive BGP route resolution. using recursive BGP route resolution.
In cases where inter-AS MPLS TE tunnels are terminated at P routers The proposed solution SHOULD also provide the ability to "announce"
in a PoP where there could also be multiple PE routers, the proposed the inter-AS MPLS TE tunnels as a link into the IGPs (ISIS or OSPF)
solution SHOULD provide the ability whereby to "announce" the with the link's cost associated with it. By doing so, PE routers
inter-AS MPLS TE tunnels as a link into the IGPs (ISIS or OSPF) with that do not participate in the inter-AS TE path computation can take
the link's cost associated with it. By doing so, PE routers that do into account such links in its IGP-based SPF computation.
not participate in the inter-AS TE path computation can take into
account such links in its IGP-based SPF computation. MPLS Inter-AS TE requirements June 2004
5.1.10. Inter-AS MPLS TE Management 5.1.10. Inter-AS MPLS TE Management
5.1.10.1. Inter-AS MPLS TE MIB Requirements 5.1.10.1. Inter-AS MPLS TE MIB Requirements
An inter-AS TE MIB is required for use with network management An inter-AS TE Management Information Base (MIB) is required for use
protocols by SPs to manage and configure inter-AS traffic with network management protocols by SPs to manage and configure
engineering tunnels. This new MIB MUST extend (and not reinvent) inter-AS traffic engineering tunnels. This new MIB SHOULD extend
the existing MIBs to accommodate this new functionality. (and not reinvent) the existing MIBs to accommodate this new
functionality.
An inter-AS TE MIB should include features, for example: An inter-AS TE MIB should have features that include:
- the setup of inter-AS TE tunnels with associated constraints - The setup of inter-AS TE tunnels with associated constraints
(e.g. resources) (e.g. resources)
- the collection of traffic and performance statistics not only - The collection of traffic and performance statistics not only
at the tunnel Headend, but any other points of the TE tunnel. at the tunnel headend, but any other points of the TE tunnel.
- the inclusion of both IPv4/v6 + AS# or AS# subobjects in the - The inclusion of both IPv4/v6 + AS# or AS# subobjects in the
ERO in the path message, e.g: ERO in the path message, e.g:
EXPLICIT_ROUTE class object: EXPLICIT_ROUTE class object:
address1 (loose IPv4 Prefix, /AS1) address1 (loose IPv4 Prefix, /AS1)
address2 (loose IPv4 Prefix, /AS1) address2 (loose IPv4 Prefix, /AS1)
AS2 (AS number) AS2 (AS number)
address3 (loose IPv4 prefix, /AS3) address3 (loose IPv4 prefix, /AS3)
address4 (loose IPv4 prefix, /AS3) - destination address4 (loose IPv4 prefix, /AS3) - destination
or or
address1 (loose IPv4 Prefix, /AS1) address1 (loose IPv4 Prefix, /AS1)
address2 (loose IPv4 Prefix, /AS1) address2 (loose IPv4 Prefix, /AS1)
address3 (loose IPv4 Prefix, /AS2) address3 (loose IPv4 Prefix, /AS2)
address4 (loose IPv4 Prefix, /AS2) address4 (loose IPv4 Prefix, /AS2)
address5 (loose IPv4 prefix, /AS3) address5 (loose IPv4 prefix, /AS3)
address6 (loose IPv4 prefix, /AS3) - destination address6 (loose IPv4 prefix, /AS3) - destination
- Similarly, the inclusion of the RRO object in the resv. message - Similarly, the inclusion of the RRO object in the resv message
recording subojects such as interface IPv4/v6 address (if not recording sub-objects such as interface IPv4/v6 address (if not
hidden), AS number, a label, a node-id (when required), etc. hidden), AS number, a label, a node-id (when required), etc.
- inter-AS specific attributes as discussed in section 5 of this - Inter-AS specific attributes as discussed in section 5 of this
document including, for example inter-AS MPLS TE tunnel document including, for example inter-AS MPLS TE tunnel
accounting records across each AS segment. accounting records across each AS segment
5.1.10.2. Inter-AS MPLS TE Fault Management Requirements 5.1.10.2. Inter-AS MPLS TE Fault Management Requirements
In a MPLS network, a SP wants to detect both control plane and data In a MPLS network, a SP wants to detect both control plane and data
plane failures. But tools for fault detection over LSPs haven't plane failures. But tools for fault detection over LSPs haven't
been widely developed so far. SPs today manually troubleshoot such been widely developed so far. SPs today manually troubleshoot such
failures in a hop-by-hop fashion across the data path. If they failures in a hop-by-hop fashion across the data path. If they
detect an error on the data plane, they have to check the control detect an error on the data plane, they have to check the control
plane in order to determine where the faults come from. plane in order to determine where the faults come from.
MPLS Inter-AS TE requirements June 2004
The proposed solution SHOULD be able to interoperate with fault The proposed solution SHOULD be able to interoperate with fault
detection mechanisms of intra-AS TE and MAY or MAY NOT require the detection mechanisms of intra-AS TE and MAY or MAY NOT require the
inter-AS TE tunnel ending addresses to be known or routable across inter-AS TE tunnel ending addresses to be known or routable across
IGP areas (OSPF) or levels(IS-IS) within the transiting ASes with IGP areas (OSPF) or levels(IS-IS) within the transiting ASes with
working return paths. working return paths.
For example, [LSPPING] is being considered as a failure detection For example, [LSPPING] is being considered as a failure detection
mechanism over the data plane against the control plane and could mechanism over the data plane against the control plane and could
be used to troubleshoot intra-AS TE LSPs. Such facilities, if be used to troubleshoot intra-AS TE LSPs. Such facilities, if
adopted, SHOULD then be extended to inter-AS TE paths. adopted, SHOULD then be extended to inter-AS TE paths.
The above example, however depicts one such mechanism that does However, the above example depicts one such mechanism that does
require a working return path such that diagnostic test packets can require a working return path such that diagnostic test packets can
return via an alternate data plane, such as a global IPv4 path in return via an alternate data plane, such as a global IPv4 path in
the event that the LSP is broken. the event that the LSP is broken.
[MPLS-TTL] presents how TTL may be processed across a hierarchical [MPLS-TTL] presents how TTL may be processed across a hierarchical
MPLS networks and such a facility as this SHOULD also be extended MPLS networks and such a facility as this SHOULD also be extended
to inter-AS TE links. to inter-AS TE links.
5.1.11. Extensibility 5.1.11. Extensibility
The solution(s) MUST allow extensions as both inter-AS MPLS TE and The solution(s) MUST allow extensions as both inter-AS MPLS TE and
current intra-AS MPLS TE specifications evolve. current intra-AS MPLS TE specifications evolve.
5.1.12. Complexity and Risks 5.1.12. Complexity and Risks
The proposed solution(s) SHOULD not introduce unnecessary complexity The proposed solution(s) SHOULD NOT introduce unnecessary complexity
to the current operating network to such a degree that it would to the current operating network to such a degree that it would
affect the stability and diminish the benefits of deploying such a affect the stability and diminish the benefits of deploying such a
solution over SP networks. solution over SP networks.
5.1.13. Backward Compatibility 5.1.13. Backward Compatibility
The deployment of inter-AS MPLS TE SHOULD not have impact on The deployment of inter-AS MPLS TE SHOULD NOT impact on
existing BGP-based traffic engineering or MPLS TE mechanisms to existing BGP-based traffic engineering or MPLS TE mechanisms, but
allow for a smooth migration or co-existence. allow for a smooth migration or co-existence.
5.1.14. Performance
The solution SHOULD be evaluated taking into account various
performance criteria:
- Degree of path optimality of the inter-AS TE LSP path
- TE LSP setup time
- Failure and restoration time
- Impact and scalability of the control plane due to added
overheads, etc.
- Impact and scalability of the data/forwarding plane due to
added overheads, etc.
MPLS Inter-AS TE requirements June 2004
5.2. Requirements for Inter-AS MPLS TE across Multiple SP 5.2. Requirements for Inter-AS MPLS TE across Multiple SP
Administrative Domains. Administrative Domains
The requirements for inter-AS MPLS TE across multiple SP admin The requirements for inter-AS MPLS TE across multiple SP admin
domains SHOULD include all requirements discussed in section 5.1 domains SHOULD include all requirements discussed in section 5.1
above in addition to what are presented in this section here. above in addition to those that are presented in this section here.
Please note that the SP with multi-AS networks may choose not to Please note that the SP with multi-AS networks may choose not to
turn on the features discussed in the following two sections when turn on the features discussed in the following two sections when
building TE tunnels across ASes in its own domain. building TE tunnels across ASes in its own domain.
5.2.1. Confidentiality 5.2.1. Confidentiality
Since an inter-AS TE LSP may span multiple ASes belonging to Since an inter-AS TE LSP may span multiple ASes belonging to
different SPs, the solution MIGHT allow to "hide" the set of hops different SPs, the solution MIGHT allow hiding the set of
used by the TE LSP within an AS as illustrated in the following hops used by the TE LSP within an AS as illustrated in the following
example: example:
[ ASBR1-----ASBR2 ] [ ASBR1-----ASBR2 ]
[ ] [ ] [ ] [ ]
[ A ] [ B ] [ A ] [ B ]
[ AS1 ] [ AS2 ] [ AS1 ] [ AS2 ]
[ SP1 ]-----[ SP2 ] [ SP1 ]-----[ SP2 ]
[ ] [ ] [ ] [ ]
Suppose there is an inter-AS TE LSP from A (within AS1 of SP1) to B Suppose there is an inter-AS TE LSP from A (within AS1 of SP1) to B
(within AS2 of SP2). When computing an inter-AS TE LSP path, the (within AS2 of SP2). When computing an inter-AS TE LSP path, the
set of hops within AS2 might be hidden to AS1. In this case, the set of hops within AS2 might be hidden to AS1. In this case, the
solution will allow A to learn that the more optimal TE LSP path to solution will allow A to learn that the more optimal TE LSP path to
B that complies with the set of constraints traverses ASBR2 without B that complies with the set of constraints traverses ASBR2 without
a detailed knowledge of the lists of the hops used within AS2. a detailed knowledge of the lists of hops used within AS2.
Optionally, the TE LSP path cost within AS2 could be provided to A, Optionally, the TE LSP path cost within AS2 could be provided to A,
via for example PCC-PCS signaling [PATH-COMP], such that A (PCC) via for example PCC-PCS signaling [PATH-COMP], such that A (PCC)
could use this information to compute an optimal path, even if the could use this information to compute an optimal path, even if the
computed path is not provided by AS2. computed path is not provided by AS2.
In addition, the management requirements discussed in section 5.1.10 In addition, the management requirements discussed in section 5.1.10
above, when used across different SP admin domains, SHOULD include above, when used across different SP admin domains, SHOULD include
similar confidentiality requirements discussed here in terms of similar confidentiality requirements discussed here in terms of
"hiding" intermediate hops or interface address and/ or labels in "hiding" intermediate hops or interface address and/ or labels in
the transiting or peering SPs. the transiting or peering SPs.
5.2.2. Policy Control 5.2.2. Policy Control
In some cases, policy control might be necessary at the AS In some cases, policy control might be necessary at the AS
boundaries, namely ingress policy controls enabling SPs to enforce boundaries, namely ingress policy controls enabling SPs to enforce
the inter-AS policies per interconnect agreements or modify some the inter-AS policies per interconnect agreements or modify some
requested parameters conveyed by incoming inter-AS MPLS TE signaling requested parameters conveyed by incoming inter-AS MPLS TE signaling
requests. requests.
It is worth noting that such policy control mechanism may also be MPLS Inter-AS TE requirements June 2004
It is worth noting that such a policy control mechanism may also be
used between ASes within a SP. used between ASes within a SP.
This section only discusses the elements that may be used to form a This section only discusses the elements that may be used to form a
set of ingress control policies. However, how exactly SPs establish set of ingress control policies but exactly how SPs establish
bilateral or multilateral agreements upon which the control policies bilateral or multilateral agreements upon which the control policies
can be built are beyond the scope of this document. can be built are beyond the scope of this document.
5.2.2.1. Inter-AS TE Agreement Enforcement Polices 5.2.2.1. Inter-AS TE Agreement Enforcement Polices
The following provides a set of TE-LSP parameters in the inter-AS TE The following provides a set of TE-LSP parameters in the inter-AS TE
requests(RSVP Path Message) that could be enforced at the AS Requests (RSVP Path Message) that could be enforced at the AS
boundaries: boundaries:
- RSVP-TE session attributes: affinities and preemption - RSVP-TE session attributes: affinities and preemption
priorities priorities
- Per AS or SP bandwidth admission control to ensure that RSVP-TE - Per AS or SP bandwidth admission control to ensure that RSVP-TE
messages do not request for bandwidth resources over their messages do not request for bandwidth resources over their
allocation. allocation
- Request origins which can be represented by Head-End tunnel
- Request origins which can be represented by HE tunnel ending IP ending IP address, originating AS#, neighbor AS#, neighbor ASBR
address, originating AS#, neighbor AS#, neighbor ASBR interface interface IP address, etc.
IP address, etc. - DS-TE TE-Class <Class-Type, Preemption>
- DS-TE TE-Class <Class-Type, Preemption>.
- FRR attribute: local protection desired bit, node protection - FRR attribute: local protection desired bit, node protection
desired bit and bandwidth protection desired bit carried in the desired bit and bandwidth protection desired bit carried in the
SESSION SESSION
- ATTRIBUTE or the FAST-REROUTE objects in the RSVP Path message - ATTRIBUTE or the FAST-REROUTE objects in the RSVP Path message
as defined in [TE-FRR]. as defined in [TE-FRR]
- Optimization allowed or not. - Optimization allowed or not allowed
In some cases, a TE policy server could also be used for the In some cases, a TE policy server could also be used for the
enforcement of inter-AS TE policies. This requirement could allow enforcement of inter-AS TE policies. Implementations SHOULD allow
SPs to make the inter-AS TE policies scale better. the use of a policy enforcement server. This requirement could
allow SPs to make the inter-AS TE policies scale better.
The signaling of a non policy compliant request SHOULD trigger the The signaling of a non policy compliant request SHOULD trigger the
generation of a RSVP Path Error message by the policy enforcing generation of a RSVP Path Error message by the policy enforcing
node towards the Head-end LSR, indicating the cause. The node towards the Head-end LSR, indicating the cause. The
Head-end LSR SHOULD take appropriate actions, such as re-route, upon Head-end LSR SHOULD take appropriate actions, such as re-route, upon
receipt of such a message. receipt of such a message.
5.2.2.2. Inter-AS TE Rewrite Policies 5.2.2.2. Inter-AS TE Rewrite Policies
In some situations, SPs may need to rewrite some attributes of the In some situations, SPs may need to rewrite some attributes of the
incoming inter-AS TE signaling requests due to for example, a lack incoming inter-AS TE signaling requests due to a lack of resources
of resources for a particular TE-Class, non compliant preemption, for a particular TE-Class, non-compliant preemption, or upon mutual
upon mutual agreements. The following lists a set of parameters agreements. The following lists parameters that can potentially be
that can potentially be rewritten at the AS boundaries: rewritten at the AS boundaries:
- RSVP-TE session attributes: affinities and preemption - RSVP-TE session attributes: affinities and preemption
priorities priorities
- DS-TE TE-Class <Class-Type, Preemption>. - DS-TE TE-Class <Class-Type, Preemption>
- ERO expansion requests - ERO expansion requests
MPLS Inter-AS TE requirements June 2004
Simimarly, the re-writing node SHOULD generate a RSVP Path Error Similarly, the re-writing node SHOULD generate a RSVP Path Error
Message towards the Head-end LSR indicating the cause in terms Message towards the Head-end LSR indicating the cause in terms
of types of changes made so as to maintain the end-to-end integrity of types of changes made so as to maintain the end-to-end integrity
of inter-AS TE LSP. of inter-AS TE LSP.
5.2.2.3 Inter-AS Traffic Policing 5.2.2.3 Inter-AS Traffic Policing
The proposed solution SHOULD also provide a set of policing The proposed solution SHOULD also provide a set of policing
mechanisms which could be configured on the inter-AS links, mechanisms which could be configured on the inter-AS links
to ensure that traffic routed through the tunnel does not exceed to ensure that traffic routed through the tunnel does not exceed
the bandwidth negotiated during LSP signaling. the bandwidth negotiated during LSP signaling.
For example, an ingress policer could be configured to enforce For example, an ingress policer could be configured to enforce
the traffic contract on the mutually agreed resource requirements the traffic contract on the mutually agreed resource requirements
of the established inter-AS TE LSP (i.e. RSVP bandwidth) on the of the established inter-AS TE LSP (i.e. RSVP bandwidth) on the
interface to which the inter-AS link is connected. interface to which the inter-AS link is connected.
6. Evaluation Criteria 6. Security Considerations
There may be multiple solutions to satisfy the requirements for
Inter-AS MPLS TE presented in previous sections.
This section provides general guidelines, which could be applied in
the selection of an optimum solution.
6.1. Detailed Requirement Satisfactions
The proposed solution SHOULD include at least all of the
Application Scenarios presented in section 4 above. It MUST meet all
the requirements described in section 5 each time a MUST is
specified.
If a solution can fulfill just a subset of those requirements in
section 5, then it MUST be explicitly documented
6.2. Performance
The solution SHOULD be evaluated taking into account various
performance criteria:
- Degree of path optimality of the inter-AS TE LSP path
- TE LSP setup time.
- Fail and restoration time
- Impact and scalability of the control plane due to added
overheads, etc.
- Impact and scalability of the data/forwarding plane due to
added overheads, etc.
Other criteria might be added as this draft will evolve.
7. Security Considerations
The proposed solution(s) MUST address security issues across The proposed solution(s) MUST address security issues across
multiple SP administrative domains. Although inter-AS MPLS TE is multiple SP administrative domains. Although inter-AS MPLS TE is
not expected to add specific security extensions beyond those of not expected to add specific security extensions beyond those of
current intra-AS TE, greater considerations MUST be given in terms current intra-AS TE, greater considerations MUST be given in terms
of how to establish a trusted model across AS boundaries. SPs of how to establish a trusted model across AS boundaries. SPs
SHOULD have a means to authenticating, such as using RSVP INTEGRITY SHOULD have a means to authenticate (such as using RSVP INTEGRITY
object, allowing and possibly denying inter-AS signaling requests Object), allow and possibly denying inter-AS signaling requests
and SHOULD be protected from DoS attacks. and SHOULD be protected from DoS attacks.
8. Acknowledgement 7. Acknowledgement
We would like to thank Yuichi Ikejiri, David Allan, Kurt Erik We would like to thank Yuichi Ikejiri, David Allan, Kurt Erik
Lindqvist, Dave McDysan, Christian Jacquenet, Kireeti Kompella, Lindqvist, Dave McDysan, Christian Jacquenet, Kireeti Kompella,
Ed Kern, Jim Boyle, Thomas Nadeauor and Yakov Rekhter for their Ed Kern, Jim Boyle, Thomas Nadeauor and Yakov Rekhter for their
suggestions and helpful comments during the discussions of this suggestions and helpful comments during the discussions of this
draft. draft.
9. Editor's Addresses 8. Editor's Addresses
Raymond Zhang Raymond Zhang
Infonet Services Corporation Infonet Services Corporation
2160 E. Grand Ave. 2160 E. Grand Ave.
El Segundo, CA 90025 El Segundo, CA 90025
USA USA
Email: raymond_zhang@infonet.com Email: raymond_zhang@infonet.com
JP Vasseur JP Vasseur
CISCO Systems, Inc. CISCO Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough , MA - 01719 Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
MPLS Inter-AS TE requirements June 2004
10. Normative References 9. Normative References
[TE-REQ], Awduche et. al., "Requirements for Traffic Engineering [TE-REQ], Awduche et. al., "Requirements for Traffic Engineering
over MPLS", RFC2702, September 1999. over MPLS", RFC2702, September 1999.
[TE-RSVP], Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP [TE-RSVP], Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001 Tunnels", RFC 3209, December 2001
[GMPLS-ROUT], Kompella, et. al., "RGeneralized Multi-Protocol Label 10. Informative References
[MPLS-ARCH], Rosen, et. al., "Multiprotocol Label Switching
Architecture", RFC 3031, January 2001
[BGP-MPLSVPN], Rosen, et. al., "BGP/MPLSVPN", draft-ietf-l3vpn
-rfc2547bis-01.txt, September 2003 (work in progress).
[DIFF_ARCH], Blake, et. al., "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[DIFF_AF], Heinanen,et. al., "Assured Forwarding PHB Group", RFC
2597, June 1999.
[DIFF_EF], Davie, et. al., "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[MPLS-Diff], Le Faucheur, et. al., "MPLS Support of Differentiated
Services", RFC 3270, May 2002
[TE-OVW], Awduche, et. al., "Overview and Principles of Internet
Traffic Engineering", RFC 3272,May 2002
[PSTE], Li, et. al., "A Provider Architecture for Differentiated
Services and Traffic Engineering", RFC 2430, October 1998
[TE-APP], Boyle, et. al., "Applicability Statement of Traffic
Engineering", RFC 3346, August 2002.
[TE-SURVIV], Lai, et. al., "Network Hierachy and Multilayer
Suvivability", RFC 3386, November, 2002.
[GMPLS-ROUT], Kompella, et. al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions, RFC 3473, January 2003. Engineering (RSVP-TE) Extensions, RFC 3473, January 2003.
[BGP], Rekhter, et. al., "A Border Gateway Protocol 4 (BGP-4)", [BGP], Rekhter, et. al., "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995 RFC 1771, March 1995
[LSPPING], Kompella, et.. al.," Detecting Data Plane Liveliness in [LSPPING], Kompella, et.. al.," Detecting Data Plane Liveliness in
MPLS", Internet Draft <draft-ietf-mpls-lsp-ping-03.txt>, June 2003, MPLS", Internet Draft <draft-ietf-mpls-lsp-ping-05.txt>,
(Work in Progress) August 2004, (Work in Progress)
MPLS Inter-AS TE requirements June 2004
[MPLS-TTL], Agarwal, et. al., "Time to Live (TTL) Processing in MPLS [MPLS-TTL], Agarwal, et. al., "Time to Live (TTL) Processing in MPLS
Networks", RFC 3443, January, 2003 Networks", RFC 3443, January, 2003
[DS-TE], Le Faucheur, et. al., ''Requirements for support of [DS-TE], Le Faucheur, et. al., ''Requirements for support of
DiffServ-aware MPLS Traffic Engineering'', RFC 3564, July, 2003 DiffServ-aware MPLS Traffic Engineering'', RFC 3564, July, 2003
[DSTE-PROT], Le Faucheur, et. al., "Protocol extensions for support [DSTE-PROT], Le Faucheur, et. al., "Protocol extensions for support
of Diff-Serv-aware MPLS Traffic Engineering", draft-ietf-tewg-diff of Diff-Serv-aware MPLS Traffic Engineering", draft-ietf-tewg-diff
-te-proto-05.txt, September, 2003 (Work in Progress). -te-proto-04.txt, September 2004 (Work in Progress).
[TE-FRR], Pan, et. al., "Fast Reroute Techniques in RSVP-TE", [TE-FRR], Pan, et. al., "Fast Reroute Techniques in RSVP-TE",
draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, June 2003 draft-ietf-mpls-rsvp-lsp-fastreroute-05.txt, November 2003
(Work in Progress). (Work in Progress).
[ISIS-TE], Smit, Li, "IS-IS extensions for Traffic Engineering", [ISIS-TE], Smit, Li, "IS-IS extensions for Traffic Engineering",
draft-ietf-isis-traffic-05.txt, August, 2003 (Work in Progress). draft-ietf-isis-traffic-05.txt, August, 2003 (Work in Progress).
[OSPF-TE] Katz, Yeung, "Traffic Engineering Extensions to OSPF", [OSPF-TE] Katz, Yeung, "Traffic Engineering (TE) Extensions to
draft-ietf-ospf-ospfv3-traffic-01.txt, June, 2001 OSPF Version 2", RFC 2370, September 2003.
(Work in Progress).
[PATH-COMP], Vasseur, et. al., ''RSVP Path computation request and [PATH-COMP], Vasseur, et. al., ''RSVP Path computation request and
reply messages'', draft-vasseur-mpls-computation-rsvp-03.txt, June reply messages'', draft-vasseur-mpls-computation-rsvp-03.txt, June
2002. (Work in Progress) 2002. (Work in Progress)
[OSPF-TE-CAP], Vasseur, Psenak. "OSPF TE TLV capabilities", [OSPF-TE-CAP], Vasseur, Psenak. "OSPF TE TLV capabilities",
draft-vasseur-mpls-ospf-te-cap-00.txt, October 2002. draft-vasseur-mpls-ospf-te-cap-00.txt, October 2002.
(Work in Progress) (Work in Progress)
[MPLS-LSPHIE] Kompella, Rekhter, "LSP Hierarchy with Generalized [MPLS-LSPHIE] Kompella, Rekhter, "LSP Hierarchy with Generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt , March 2002. MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt , September 2002.
(work in progress) (work in progress)
[MPLS-Recov], Sharma V., et al, "Framework for Multi-Protocol Label [MPLS-Recov], Sharma V., et al, "Framework for Multi-Protocol Label
Switching (MPLS)-based Recovery", RFC 3469, Feb, 2003 Switching (MPLS)-based Recovery", RFC 3469, Feb, 2003
[BGP-Label], Rekhter and Rosen, "Carrying Label Information in [BGP-Label], Rekhter and Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001 BGP-4", RFC 3107, May 2001
[INTER-AS-TE], Vasseur and Zhang, "Inter-AS MPLS Traffic [INTER-AS-TE], Vasseur and Ayyangar, "Inter-AS MPLS Traffic
Engineering", draft-vasseur-inter-as-te-01.txt, June, 2003 (work Engineering", draft-vasseur-ccamp-inter-area-as-te-00.txt,
in progress). August, 2004 (work in progress).
[EXCLUDE-ROUTE], Farrel, et. al., "draft-ietf-ccamp-rsvp-te-exclude [EXCLUDE-ROUTE], Farrel, et. al., "draft-ietf-ccamp-rsvp-te-exclude
-route-00.txt", June 2003 (work in progress). -route-01.txt", June 2004 (work in progress).
11. Informative References
[MPLS-ARCH], Rosen, et. al., "Multiprotocol Label Switching
Architecture", RFC 3031, January 2001
[BGP-MPLSVPN], Rosen, et. al., "BGP/MPLSVPN", draft-ietf-l3vpn
-rfc2547bis-01.txt, July 2002 (work in progress).
[DIFF_ARCH], Blake, et. al., "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[DIFF_AF], Heinanen,et. al., "Assured Forwarding PHB Group", RFC
2597, June 1999.
[DIFF_EF], Davie, et. al., "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[MPLS-Diff], Le Faucheur, et. al., "MPLS Support of Differentiated
Services", RFC 3270, May 2002
[TE-OVW], Awduche, et. al., "Overview and Principles of Internet
Traffic Engineering", RFC 3272,May 2002
[PSTE], Li, et. al., "A Provider Architecture for Differentiated
Services and Traffic Engineering", RFC 2430, October 1998
[TE-APP], Boyle, et. al., "Applicability Statement of Traffic
Engineering", RFC 3346, August 2002.
[TE-SURVIV], Lai, et. al., "Network Hierachy and Multilayer MPLS Inter-AS TE requirements June 2004
Suvivability", RFC 3386, November, 2002.
12. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
skipping to change at page 26, line 5 skipping to change at page 26, line 5
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
MPLS Inter-AS TE requirements June 2004
Appendix A. Brief Description of BGP based Inter-AS Traffic Appendix A. Brief Description of BGP based Inter-AS Traffic
Engineering Engineering
In today's Service Provider (SP) network, BGP is deployed to meet In today's Service Provider (SP) network, BGP is deployed to meet
two different sets of requirements: two different sets of requirements:
- Establishing a scalable exterior routing plane separating from - Establishing a scalable exterior routing plane separate from
data forwarding plane within SP's administrative domain The data forwarding plane within SP's administrative domain
- Exchanging network reachability information with different BGP - Exchanging network reachability information with different BGP
autonomous systems (ASes) that could belong to a different SP autonomous systems (ASs) that could belong to a different SP
or simply, a different AS within a SP network. or simply, a different AS within a SP network
Over connections across the AS boundaries, traffic engineering may Over connections across the AS boundaries, traffic engineering may
also be accomplished via a set of BGP capabilities by appropriately also be accomplished via a set of BGP capabilities by appropriately
enforcing BGP-based inter-AS routing policies. The current enforcing BGP-based inter-AS routing policies. The current
BGP-based inter-AS traffic engineering practices may be summarized BGP-based inter-AS traffic engineering practices may be summarized
as follows: as follows:
- "Closest exit" routing where egress traffic from one SP to - "Closest exit" routing where egress traffic from one SP to
another follows the path defined by the lowest IGP or intra-AS another follows the path defined by the lowest IGP or intra-AS
MPLS TE tunnel metrics of the BGP next-HOP of exterior routes MPLS TE tunnel metrics of the BGP next-HOP of exterior routes
learned from other AS over the inter-AS links learned from other AS over the inter-AS links
- "BGP path attribute" based routing selection mechanism where - "BGP path attribute" based routing selection mechanism where
the egress traffic path is determined by interconnect (peering the egress traffic path is determined by interconnect (peering
or transit) policies based upon one or a combination of BGP or transit) policies based upon one or a combination of BGP
path attributes, like AS_PATH, MULTI_EXIT_DISC (MED), and path attributes, like AS_PATH, MULTI_EXIT_DISC (MED), and
Local_Pref. Local_Pref.
SPs have often faced a number of un-deterministic factors in their SPs have often faced a number of un-deterministic factors in the
practices of inter-AS traffic engineering employing the methods practices of inter-AS traffic engineering employing the methods
mentioned above: mentioned above:
- Sub-optimum traffic distribution across inter-AS links - Sub-optimum traffic distribution across inter-AS links
- Un-deterministic traffic condition changes due to uncoordinated - Un-deterministic traffic condition changes due to uncoordinated
IGP routing policies or topology changes within other AS and IGP routing policies or topology changes within other AS and
uncoordinated BGP routing policy changes (MED or as-prepend, uncoordinated BGP routing policy changes (MED or as-prepend,
etc.) etc.)
In addition, to achieve some degrees of granularity, SPs may choose In addition, to achieve some degrees of granularity, SPs may choose
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/