draft-ietf-tewg-interas-mpls-te-req-08.txt   draft-ietf-tewg-interas-mpls-te-req-09.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
draft-ietf-tewg-interas-mpls-te-req-08.txt JP Vasseur, Co-Editor draft-ietf-tewg-interas-mpls-te-req-09.txt JP Vasseur, Co-Editor
Expires: Feb. 2005 CISCO Systems,Inc Expires: March. 2005 CISCO Systems,Inc
August 2004 September 2004
MPLS Inter-AS Traffic Engineering requirements MPLS Inter-AS Traffic Engineering requirements
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 subject to all provisions
all provisions of Section 10 of RFC2026. Internet-Drafts are working of section 3 of RFC 3667. By submitting this Internet-Draft, each
documents of the Internet Engineering Task Force (IETF), its areas, author represents that any applicable patent or other IPR claims of
and its working groups. Note that other groups may also distribute which he or she is aware have been or will be disclosed, and any of
working documents as Internet-Drafts. which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or made obsolete by other months
documents at any time. It is inappropriate to use an Internet-Draft and may be updated, replaced, or obsoleted by other documents at any
as reference material or to cite it other than as "work in time. It is inappropriate to use Internet-Drafts as reference
progress". material or to cite them 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.
Copyright Notice
Copyright (C) The Internet Society (2004).
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). Its main objective is to MPLS Traffic Engineering (MPLS TE). Its main objective is to
present a set of requirements which would result in general present a set of requirements and scenarios which would result in
guidelines for the definition, selection and general guidelines for the definition, selection and specification
specification development for any technical solution(s) meeting development for any technical solution(s) meeting these requirements
these requirements. and supporting the scenarios.
MPLS Inter-AS TE requirements June 2004
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].
MPLS Inter-AS TE requirements............... September 2004
Table of Contents Table of Contents
1. Introduction.......................................................3 1. Introduction.......................................................3
2. Contributing Authors...............................................4 2. Contributing Authors...............................................4
3. Definitions and Requirements Statement.............................5 3. Definitions and Requirements Statement.............................5
3.1. Definitions......................................................5 3.1. Definitions......................................................5
3.2. Objectives and Requirements of Inter-AS Traffic Engineering......6 3.2. Objectives and Requirements of Inter-AS Traffic Engineering......6
3.2.1. Inter-AS Bandwidth Guarantees..................................6 3.2.1. Inter-AS Bandwidth Guarantees..................................6
3.2.2. Inter-AS Resource Optimization.................................7 3.2.2. Inter-AS Resource Optimization.................................7
3.2.3. Fast Recovery across ASes......................................8 3.2.3. Fast Recovery across ASes......................................8
skipping to change at page 3, line 4 skipping to change at page 2, line 45
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 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..........................................20 Administrative Domains..........................................20
5.2.1. Confidentiality...............................................20 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...................21 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....................................22
6. Security Considerations...........................................22 6. Security Considerations...........................................22
7. Acknowledgement...................................................22 7. Acknowledgements..................................................22
8. Editor's Addresses................................................22 8. Editor's Addresses................................................22
9. Normative References............................................. 23 9. Normative References............................................. 23
10. Informative References...........................................23 10. Informative References...........................................23
MPLS Inter-AS TE requirements September 2004
11. Full Copyright Statement.........................................25 11. Full Copyright Statement.........................................25
12. Intellectual Property............................................25
13. Acknowledgement..................................................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 (TE) mechanism documented in [TE-RSVP] The MPLS Traffic Engineering (TE) mechanism documented in [TE-RSVP]
may be deployed by Service Providers to achieve some of the most may be deployed by Service Providers (SPs) to achieve some of the
important objectives of network traffic engineering as described in most important objectives of network traffic engineering as
[TE-OVW]. These objectives are summarized as: described in [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 a SP's objectives across AS boundaries within or beyond a SP's
aministrative 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. This
mechanism could be implemented based upon the requirements presented
in this document.
These application scenarios will facilitate discussions for a These application scenarios will also facilitate discussions for a
detailed requirements list for this inter-AS Traffic Engineering detailed requirements list for this inter-AS Traffic Engineering
mechanism. mechanism.
Please note that there are other means of traffic engineering Please note that there are other means of traffic engineering
including Interior Gateway Protocol (IGP); metrics based (for use including Interior Gateway Protocol (IGP); metrics based (for use
within an AS); and Border Gateway Protocol (BGP) attribute based within an AS); and Border Gateway Protocol (BGP) attribute based
(for use across ASes, as described in Appendix A). However, because (for use across ASes, as described in Appendix A), which provide
these means offer coarser control of traffic paths and do not coarser control of traffic paths. However, this document addresses
readily offer bandwidth guarantees or fast restoration, they will requirements for a MPLS based, fine-grained approach for inter-AS
not be discussed further in this document. TE.
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 MPLS Inter-AS TE requirements.............. September 2004
2. Contributing Authors 2. Contributing Authors
The text and content of this document was contributed to by the The text and content of this document was contributed to by 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
skipping to change at page 5, line 5 skipping to change at page 5, line 5
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex, France 22307 Lannion Cedex, 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, USA Pleasanton, CA 94588, USA
Email: Yonghwan_Kim@labs.sbc.com Email: Yonghwan_Kim@labs.sbc.com
MPLS Inter-AS TE requirements June 2004 MPLS Inter-AS TE requirements.............. September 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 30 skipping to change at page 5, line 30
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 operating over IP-only and/ or IP/MPLS network within
an 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. Since this document only
addresses IP/MPLS networks, any reference to Inter-AS
TE in this document refers only to IP/MPLS networks and
is not intended to address IP-only TE requirements.
TE LSP: MPLS Traffic Engineering Label Switched Path 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 Label Switched Path (LSP), Head-end Label TE Label Switched Path (LSP), Head-end Label
Switching Router (LSR) and Tail-end LSR reside in 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
skipping to change at page 5, line 58 skipping to change at page 6, line 5
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. MPLS Inter-AS TE requirements.............. September 2004
MPLS Inter-AS TE requirements June 2004 Inter-AS TE Segment: A portion of the Inter-AS TE path.
Inter-AS DS-TE: Diffserv-aware Inter-AS TE. 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.
skipping to change at page 7, line 5 skipping to change at page 7, line 5
inter-packet delay variation, loss rate, etc. inter-packet delay variation, loss rate, etc.
Many SPs have partial or full deployment of Diffserv implementations Many SPs have partial or full deployment of Diffserv implementations
in their networks today, either across the entire network or in their networks today, either across the entire network or
minimally 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 Quality of Service (QOS) bounds are In situations where strict Quality of Service (QOS) bounds are
required, admission control inside the backbone of a network is in required, admission control inside the backbone of a network is in
some cases required in addition to current Diffserv mechanisms. some cases required in addition to current Diffserv mechanisms.
MPLS Inter-AS TE requirements June 2004 MPLS Inter-AS TE requirements September 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 such as maximum one-way transit delay, may be guaranteed by
providing 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.
skipping to change at page 7, line 46 skipping to change at page 7, line 46
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 elaborate 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. Nondeterministic factors such
as un-coordinated routing and network changes, as well as sub- as uncoordinated routing and network changes, as well as sub-
optimum traffic conditions would potentially lead to a complex set optimum traffic conditions would potentially lead to a complex set
of 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 MPLS Inter-AS TE requirements September 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
reqiure 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 achieved within an AS. as packet loss and service availability, as achieved within an AS.
As a consequence, fast convergence in a stable fashion upon As a consequence, fast convergence in a stable fashion upon
link/SRLG/node failures becomes a strong requirement. This is link/SRLG/node failures becomes a strong requirement. This is
clearly difficult to achieve with current inter-domain techniques, clearly difficult to achieve with current inter-domain techniques,
especially in cases of link/SRLG failures between ASBRs or ASBR node especially in cases of link/SRLG failures between ASBRs 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
where resource optimization, QOS guarantees and fast recovery where resource optimization, bandwidth 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
skipping to change at page 9, line 47 skipping to change at page 9, line 47
----- ----- ----- -----
<=================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. are not discussed further.
If either SP1∆s or SP2∆s network is not a Diffserv-aware network, If either SP1's or SP2's network is not a Diffserv-aware network,
the scenario would still apply to provide bandwidth guarantees. the scenario would still apply to provide 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 MPLS Inter-AS TE requirements September 2004
It is worth mentioning that these remote aggregation routers It is worth mentioning that these remote aggregation routers
co-located in another SP's network are unlikely to host SP1's IGP co-located in another SP's network are unlikely to host SP1's IGP
and BGP routing planes and will more likely maintain their own AS or and BGP routing planes and will more likely maintain their own AS or
be part of the SP1's AS. In this case, such TE tunnels may cross be part of the SP1's AS. In this case, such TE tunnels may cross
several ASes, but the Head-end and Tail-end LSRs of TE tunnel may several ASes, but the Head-end and Tail-end LSRs of TE tunnel may
have the same AS number, as shown in the diagram above. have the same AS number, as shown in the 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 may also choose Instead of co-locating a PE router in SP2's PoP, SP1 may also choose
to aggregate customer VPN sites onto a SP2's PE router where inter- to aggregate customer VPN sites onto a SP2's PE router where inter-
AS TE tunnels can be built and signaled through SP2's MPLS network AS TE tunnels can be built and signaled through SP2's MPLS network
between the SP2 PoP (to which SP1a customer CEs are directly between the SP2 PoP (to which SP1 a customer CEs are directly
connected) and SP1's ASBR or PE routers inside SP2's network. This connected) and SP1's ASBR or PE routers inside SP2's network. This
allows SP1's customers connected to SP2 PE router to receive a allows SP1's customers connected to SP2 PE router to receive a
guaranteed bandwidth service up to the TE LSP tail-end router guaranteed bandwidth service up to the TE LSP tail-end 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 SP1s CE's local-loop access circuits on virtual trunk aggregating SP1's CE's local-loop access circuits on
SP2's MPLS network over which the bandwidth can be guaranteed to the SP2's MPLS network over which the bandwidth can be guaranteed to the
TE LSP tail-end router located in SP1's network, as shown in the 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 |
skipping to change at page 11, line 5 skipping to change at page 11, line 5
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 ASx+ +------SP2 AS2---+ +--SP1 AS1-----+ +SP1 Customer ASx+ +------SP2 AS2---+ +--SP1 AS1-----+
MPLS Inter-AS TE requirements June 2004 MPLS Inter-AS TE requirements September 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 the In this scenario as illustrated below, customers require the
establishment of MPLS TE tunnel from CE1 to CE2 end-to-end across establishment of MPLS TE tunnel from CE1 to CE2 end-to-end across
several SPs∆ networks. One application example would be the several SPs∆ networks.
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 ASx+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASy+ +Cust ASx+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASy+
skipping to change at page 12, line 5 skipping to change at page 12, line 5
In addition, where both CE1 and CE2 reside in the same AS, they will 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 if there is a greater 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
have few deployments, unless some mechanisms such as hierarchical have few deployments, unless some mechanisms such as hierarchical
intra-AS TE-LSPs are used to reduce the number of signaling states. intra-AS TE-LSPs are used to reduce the number of signaling states.
MPLS Inter-AS TE requirements June 2004 MPLS Inter-AS TE requirements Septmber 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
skipping to change at page 12, line 36 skipping to change at page 12, line 36
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, it 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 can 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 those with sparsely connected networks, have continents, as well as those with sparsely connected networks, have
designed their multi-AS routing policies 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 as a whole, rather than
a network which may consist of many ASes, this could be realized via partially. For a network which may consist of many ASes, this could
the establishment of inter-AS TE LSPs as shown in the diagragm be realized via the establishment of inter-AS TE LSPs as shown in
below: the diagragm below:
MPLS Inter-AS TE requirements June 2004 MPLS Inter-AS TE requirements September 2004
<===================Inter-AS MPLS Tunnel=============> <===================Inter-AS MPLS Tunnel=============>
-------- -------- -------- -------- -------- --------
| |_______________| |____________| | | |_______________| |____________| |
| SP1 |_______________| SP1 |____________| SP1 | | SP1 |_______________| SP1 |____________| SP1 |
| AS1 |_______________| AS2 |____________| AS3 | | AS1 |_______________| AS2 |____________| AS3 |
| | | | | | | | | | | |
-------- -------- -------- -------- -------- --------
|| || || ||
|| --------- || || --------- ||
skipping to change at page 13, line 34 skipping to change at page 13, line 34
<===================Inter-AS MPLS DS-TE Tunnel=============> <===================Inter-AS MPLS DS-TE Tunnel=============>
---- ----- ----- ----- ----- ---- ---- ----- ----- ----- ----- ----
| PE |__| P |___|ASBR |___Inter-AS___|ASBR |___|P |___|PE | | PE |__| P |___|ASBR |___Inter-AS___|ASBR |___|P |___|PE |
| RTR| | RTR | | RTR | Link | RTR | |RTR | |RTR | | RTR| | RTR | | RTR | Link | RTR | |RTR | |RTR |
---- ----- ----- ----- ----- ---- ---- ----- ----- ----- ----- ----
+------------SP1 AS1---------+ +------------SP1 AS2------+ +------------SP1 AS1---------+ +------------SP1 AS2------+
For example , the inter-AS MPLS DS-TE LSP shown in the diagram above For example , the inter-AS MPLS DS-TE LSP shown in the diagram above
could be used to transport a set of L2 Pseudo Wires or VoIP traffic could be used to transport a set of L2 Pseudo Wires or VoIP traffic
with corresponding QoS requirement. with corresponding bandwidth requirement.
Furthermore, fast recovery in case of ASBR-ASBR link failure or ASBR Furthermore, fast recovery in case of ASBR-ASBR link failure or ASBR
node failure is a strong requirement for such services. node failure is a strong requirement for such services.
4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport 4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport
Scenario V presents another possible deployment case. SP1 with AS1 Scenario V presents another possible deployment case. SP1 with AS1
wants to link a regional network to its core backbone by building an wants to link a regional network to its core backbone by building an
inter-AS MPLS TE tunnel over one or multiple transit ASes belonging inter-AS MPLS TE tunnel over one or multiple transit ASes belonging
to SP2, SP3, etc. as shown in the following diagram: to SP2, SP3, etc. as shown in the following diagram:
skipping to change at page 14, line 5 skipping to change at page 14, line 5
[ ---- ---- ] [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] [ ---- ---- ]
[ ] [ ] [ ] [ ] [ ] [ ]
<================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 regional network of SP1. By the same token, the AS number for SP1's 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 MPLS Inter-AS TE requirements September 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 15, line 5 skipping to change at page 15, line 5
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 the provisioning of a TE LSP at The proposed solution SHOULD allow the provisioning of a TE LSP at
the Head/Tail end with end-to-end Resource Reservation Protocol the Head/Tail end with end-to-end Resource Reservation Protocol
(RSVP) signaling (eventually with loose paths) traversing across the (RSVP) signaling (eventually with loose paths) traversing across the
interconnected ASBRs, without further provisioning required along interconnected ASBRs, without further provisioning required along
the transit path. the transit path.
MPLS Inter-AS TE requirements June 2004 MPLS Inter-AS TE requirements September 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 ASes, ASBRs and
Inter-AS links.
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 when explicitly select or auto-discover the following elements when
signaling the inter-AS TE LSP path: signaling the inter-AS TE LSP path:
- a set of AS numbers as loose HoPs and/or - a set of AS numbers as loose HoPs and/or
- a set of LSRs including ASBRs - a set of LSRs including ASBRs
It should also specify the above elements in the Explicit Route It should also specify the above elements in the Explicit Route
Object (ERO) and record them in the Record Route Object (RRO) of the Object (ERO) and record them in the Record Route Object (RRO) of the
skipping to change at page 15, line 58 skipping to change at page 16, line 5
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 optimality (or sub-optimality) since the path may allow for reduced optimality (or sub-optimality) since the path may
not remain 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:
MPLS Inter-AS TE requirements September 2004
(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.
skipping to change at page 16, line 45 skipping to change at page 16, line 48
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-optimization 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 pairs 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 SHOULD interoperate with current intra-AS
TE fast re-route mechanism from [TE-FRR]. MPLS 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 MPLS Inter-AS TE requirements September 2004
5.1.7. DS-TE Support 5.1.7. DS-TE Support
The proposed inter-AS MPLS TE solution SHOULD 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].
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 to the solution 4.1 of [DS-TE] SHOULD also be faithfully applied to the solution
development development
5.1.8. Scalability and Hierarchical LSP Support 5.1.8. Scalability and Hierarchical LSP Support
The proposed solution(s) MUST have a minimum impact on 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.
skipping to change at page 18, line 5 skipping to change at page 18, line 5
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.
The proposed solution SHOULD also provide the ability to "announce" The proposed solution SHOULD also provide the ability to "announce"
the inter-AS MPLS TE tunnels as a link into the IGPs (ISIS or OSPF) the inter-AS MPLS TE tunnels as a link into the IGPs (ISIS or OSPF)
with the link's cost associated with it. By doing so, PE routers with the link's cost associated with it. By doing so, PE routers
that do not participate in the inter-AS TE path computation can take that do not participate in the inter-AS TE path computation can take
into account such links in its IGP-based SPF computation. into account such links in its IGP-based SPF computation.
MPLS Inter-AS TE requirements June 2004 MPLS Inter-AS TE requirements September 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 Management Information Base (MIB) is required for use An inter-AS TE Management Information Base (MIB) is required for use
with network management protocols by SPs to manage and configure with network management protocols by SPs to manage and configure
inter-AS traffic engineering tunnels. This new MIB SHOULD extend inter-AS traffic engineering tunnels. This new MIB SHOULD extend
(and not reinvent) the existing MIBs to accommodate this new (and not reinvent) the existing MIBs to accommodate this new
functionality. functionality.
skipping to change at page 19, line 5 skipping to change at page 19, line 5
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 MPLS Inter-AS TE requirements September 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
skipping to change at page 19, line 41 skipping to change at page 19, line 41
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 impact on The deployment of inter-AS MPLS TE SHOULD NOT impact existing BGP-
existing BGP-based traffic engineering or MPLS TE mechanisms, but based traffic engineering or MPLS TE mechanisms, but allow for a
allow for a smooth migration or co-existence. smooth migration or co-existence.
5.1.14. Performance 5.1.14. Performance
The solution SHOULD be evaluated taking into account various The solution SHOULD be evaluated taking into account various
performance criteria: performance criteria:
- Degree of path optimality of the inter-AS TE LSP path - Degree of path optimality of the inter-AS TE LSP path
- TE LSP setup time - TE LSP setup time
- Failure and restoration time - Failure and restoration time
- Impact and scalability of the control plane due to added - Impact and scalability of the control plane due to added
overheads, etc. overheads, etc.
- Impact and scalability of the data/forwarding plane due to - Impact and scalability of the data/forwarding plane due to
added overheads, etc. added overheads, etc.
MPLS Inter-AS TE requirements June 2004 MPLS Inter-AS TE requirements September 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 those that 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
skipping to change at page 21, line 5 skipping to change at page 21, line 5
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.
MPLS Inter-AS TE requirements June 2004 MPLS Inter-AS TE requirements September 2004
It is worth noting that such a policy control mechanism may also be 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 but exactly how 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 SHOULD 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 Head-End tunnel
ending IP address, originating AS#, neighbor AS#, neighbor ASBR ending IP address, originating AS#, neighbor AS#, neighbor ASBR
interface IP address, etc. interface IP address, etc.
skipping to change at page 22, line 5 skipping to change at page 22, line 5
incoming inter-AS TE signaling requests due to a lack of resources incoming inter-AS TE signaling requests due to a lack of resources
for a particular TE-Class, non-compliant preemption, or upon mutual for a particular TE-Class, non-compliant preemption, or upon mutual
agreements. The following lists parameters that can potentially be agreements. The following lists parameters 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 MPLS Inter-AS TE requirements September 2004
Similarly, 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
skipping to change at page 22, line 35 skipping to change at page 22, line 35
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 authenticate (such as using RSVP INTEGRITY SHOULD have a means to authenticate (such as using RSVP INTEGRITY
Object), allow 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.
7. Acknowledgement 7. Acknowledgements
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, Yakov Rekhter and Bert Wijnen
suggestions and helpful comments during the discussions of this for their suggestions and helpful comments during the discussions of
draft. this draft.
8. 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 MPLS Inter-AS TE requirements September 2004
9. 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
[RFC-2119], S. Bradner, "Key words for use in RFCs to Indicate [RFC-2119], S. Bradner, "Key words for use in RFCs to Indicate
skipping to change at page 24, line 5 skipping to change at page 24, line 5
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-05.txt>, MPLS", Internet Draft <draft-ietf-mpls-lsp-ping-05.txt>,
August 2004, (Work in Progress) August 2004, (Work in Progress)
MPLS Inter-AS TE requirements June 2004 MPLS Inter-AS TE requirements September 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
of Diff-Serv-aware MPLS Traffic Engineering", draft-ietf-tewg-diff
-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-05.txt, November 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 (TE) Extensions to [OSPF-TE] Katz, Yeung, "Traffic Engineering (TE) Extensions to
OSPF Version 2", RFC 2370, September 2003. OSPF Version 2", RFC 2370, September 2003.
skipping to change at page 25, line 5 skipping to change at page 25, line 5
[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 Ayyangar, "Inter-AS MPLS Traffic [INTER-AS-TE], Vasseur and Ayyangar, "Inter-AS MPLS Traffic
Engineering", draft-vasseur-ccamp-inter-area-as-te-00.txt, Engineering", draft-vasseur-ccamp-inter-area-as-te-00.txt,
August, 2004 (work 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-01.txt", June 2004 (work in progress). -route-01.txt", June 2004 (work in progress).
MPLS Inter-AS TE requirements June 2004 MPLS Inter-AS TE requirements September 2004
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on
others, and derivative works that comment on or otherwise explain it an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
or assist in its implementation may be prepared, copied, published REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
and distributed, in whole or in part, without restriction of any INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
kind, provided that the above copyright notice and this paragraph IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
are included on all such copies and derivative works. However, this THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process MUST be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be 12. Intellectual Property
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an The IETF takes no position regarding the validity or scope of any
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Intellectual Property Rights or other rights that might be claimed
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING to pertain to the implementation or use of the technology described
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION in this document or the extent to which any license under such
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF rights might or might not be available; nor does it represent that
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
MPLS Inter-AS TE requirements June 2004 Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
13. Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
MPLS Inter-AS TE requirements September 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 separate from - Establishing a scalable exterior routing plane separate from
The 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
 End of changes. 

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