IETF Internet Draft                               Raymond Zhang, Editor
Internet Engineering Task Force            Infonet Services Corporation
Document:                                         JP Vasseur, Co-Editor
draft-ietf-tewg-interas-mpls-te-req-01.txt           CISCO Systems, Inc
October 2003
Expires: April 2004



            MPLS Inter-AS Traffic Engineering requirements
                draft-ietf-tewg-interas-mpls-te-req-01.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet-Drafts are Working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document discusses requirements for the support of inter-AS
   MPLS Traffic Engineering (MPLS TE).  The main objective of this
   document is to present a set of requirements which would result in a
   set of general guidelines in the definition, selection and
   specification development for any technical solution(s) meeting
   these requirements.

Summary for Sub-IP related Internet Drafts

   RELATED DOCUMENTS:
   None

   WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
   TEWG

   WHY IS IT TARGETED AT THIS WG(s)
   It is stated in the charter that documenting SP requirements in this
   area are one of the work items to be undertaken by TEWG.

   JUSTIFICATION
   The TEWG charter further states that "The working group may also
   consider the problems of traffic engineering across autonomous
   systems boundaries."


Zhang, Vasseur, et. al.                                        [Page 1]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003


   This draft discusses the requirements for a traffic engineering
   mechanism across autonomous systems boundaries that would also be
   interoperable with current intra-AS traffic engineering mechanisms.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119.

Table of Contents

1. Introduction.......................................................3
2. Contributing Authors...............................................4
3. Definitions and Requirements Statement.............................5
3.1. Definitions......................................................5
3.2. Objectives and Requirements of Inter-AS Traffic Engineering......6
3.2.1. Inter-AS Bandwidth Guarantees..................................6
3.2.2. Inter-AS Resource Optimization.................................7
3.2.3. Fast Recovery across ASes......................................8
3.3. Inter-AS Traffic Engineering Requirements Statement..............8
4. Application Scenarios..............................................8
4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees....8
4.1.1. Scenario I - Extended or Virtual PoP...........................9
4.1.2. Scenario II - Extended or Virtual Trunk.......................10
4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE......11
4.2. Application Scenarios Requiring Inter-AS Resource Optimization..12
4.2.1. Scenario IV - TE across multi-AS within a Single SP
       Administrative Domain.........................................12
4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport..13
5. Detailed Requirements for Inter-AS MPLS Traffic Engnineering......14
5.1. Requirements within one SP Administrative Domain................14
5.1.1. Inter-AS MPLS TE Operations and Interoperability..............14
5.1.2. Protocol Signaling and Path Computations......................15
5.1.3. Optimality....................................................15
5.1.4. Support of diversely routed inter-AS TE LSP...................16
5.1.5. Re-optimization...............................................16
5.1.6. Fast Recovery support using MPLS TE Fast Reroute..............16
5.1.7. DS-TE Support.................................................17
5.1.8. Hierarchical LSP Support and Forwarding Adjacency (FA)........17
5.1.9. Mapping of traffic onto Multiple Inter-AS MPLS TE Tunnels.....17
5.1.10. Inter-AS MPLS TE Management..................................17
5.1.10.1. Inter-AS MPLS TE MIB Requirements..........................17
5.1.10.2. Inter-AS MPLS TE Fault Management Requirements.............18
5.2. Requirements for Inter-AS MPLS TE across Multiple SP
     Administrative Domains..........................................19
5.2.1. Confidentiality...............................................19
5.2.2. Policy Control................................................20
5.2.2.1. Inter-AS TE Agreement Enforcement Polices...................20
5.2.2.2. Inter-AS TE Rewrite Policies................................21
5.2.2.3 Inter-AS Traffic Policing....................................21

Zhang, Vasseur, et. al.                                        [Page 2]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

6. Evaluation Criteria...............................................21
6.1. Detailed Requirement Satisfactions..............................21
6.2. Scalability and Extensibility...................................21
6.3. Complexity and Risks............................................22
6.4. Performance.....................................................22
6.5. Backward Compatibility..........................................22
7. Security Considerations...........................................22
8. Acknowledgement...................................................21
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
            Engineering..............................................26


1. Introduction

   The MPLS Traffic Engineering mechanism documented in [TE-RSVP] may
   be deployed by Service Providers to achieve some of the most
   important objectives of network traffic engineering as described in
   [TE-OVW].  These objectives are summarized as listed below:

      - Supporting end-to-end services requiring QoS guarantees
      - Performing network resource optimization
      - Providing fast recovery

   However, this traffic engineering mechanism can only be used within
   an Autonomous System (AS).

   This document discusses requirements for an inter-AS MPLS Traffic
   Engineering mechanism that may be used to achieve the same set of
   objectives across AS boundaries within or beyond SPs'administrative
   domains.

   The document will also present a set of application scenarios where
   the inter-AS traffic engineering mechanism may be required.

   These application scenarios will also be used to further facilitate
   the discussions for a list of detailed requirements for such an
   inter-AS Traffic Engineering mechanism along with the evaluation
   criteria for any technical solution(s) meeting these requirements.

   Please note that there are other means of traffic engineering
   including IGP metrics based (for use within an AS) and BGP attribute
   based (for use across ASes; see Appendix A) traffic engineering
   mechanisms.  However, these means offer coarser control of traffic
   paths, and do not readily offer bandwidth guarantees or fast
   restoration, and therefore will not be discussed further in this
   document.




Zhang, Vasseur, et. al.                                        [Page 3]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

2. Contributing Authors

   This document was the collective work of several. The text and
   content of this document was contributed by the editors and the
   co-authors listed below (The contact information for the editors
   appears in section 9, and is not repeated below.):

   Kenji Kumaki
   KDDI Corporation
   Garden Air Tower
   Iidabashi, Chiyoda-ku,
   Tokyo 102-8460,
   JAPAN
   E-mail : ke-kumaki@kddi.com

   Paul Mabey
   Qwest Communications
   950 17th Street,
   Denver, CO 80202
   USA
   Email: pmabey@qwest.com

   Nadim Constantine
   Infonet Services Corporation
   2160 E. Grand Ave.
   El Segundo, CA 90025
   USA
   Email: nadim_constantine@infonet.com

   Pierre Merckx
   EQUANT
   1041 route des Dolines - BP 347
   06906 SOPHIA ANTIPOLIS Cedex
   FRANCE
   Email: pierre.merckx@equant.com

   Ting Wo Chung
   Bell Canada
   181 Bay Street, Suite 350
   Toronto, Ontario, Canada, M5J 2T3
   Email: ting_wo.chung@bell.ca

   Jean-Louis Le Roux
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   E-mail: jeanlouis.leroux@francetelecom.com






Zhang, Vasseur, et. al.                                        [Page 4]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

   Yonghwan Kim
   SBC Laboratories, Inc.
   4698 Willow Road
   Pleasanton, CA 94588
   USA
   Email: Yonghwan_Kim@labs.sbc.com

3. Definitions and Requirements Statement

3.1. Definitions

   The following provides a list of abbreviations or acronyms
   specifically pertaining to this document:

   SP: Service Providers including regional or global providers

   SP Administrative Domain: a single SP administration over a network
                             or networks that may consist of one AS or
                             multiple ASes.

   IP-only networks: SP's network where IP routing protocols such as
                     IGP/ BGP are activated

   IP/MPLS networks: SP's network where MPLS switching capabilities and
                     signaling controls (e.g. ones described in
                     [MPLS-ARCH]) are activated in addition to IP
                     routing protocols.

   Intra-AS TE: A generic definition for traffic engineering mechanisms
                operating over IP-only and/ or IP/MPLS network within an
                AS.

   Inter-AS TE: A generic definition for traffic engineering mechanisms
                operating over IP-only and/ or IP/MPLS network across
                one or multiple ASes.

   TE LSP: MPLS Traffic Engineering Label Switched Path

   Intra-AS MPLS TE: An MPLS Traffic Engineering mechanism where its
                     TE LSPs Head-end LSR and Tail-end LSR reside in
                     the same AS for traffic engineering purposes.

   Inter-AS MPLS TE: An MPLS Traffic Engineering mechanism where its
                     TE LSPs Head-end LSR and Tail-end LSR do not
                     reside within the same AS or both Head-end LSR and
                     Tail-end LSR are in the same AS but the TE LSP
                     transiting path may be across different ASes

   ASBR Routers: Border routers used to connect to another AS of a
                 different or the same Service Provider via one or more
                 links inter-connecting between ASes.



Zhang, Vasseur, et. al.                                        [Page 5]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

   Inter-AS TE Path: An TE path traversing multiple ASes and ASBRs,
                     e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2...
                     ASBRn-ASn.

   Inter-AS TE Segment: A portion of the Inter-AS TE path.

   PCS: Path Computation Server (e.g. an LSR or an off-line tool)

   PCC: Path Computation Client (e.g. an LSR)

   CE: Customer Edge Equipment

   PE: Provider Edge Equipment that has direct connections to CEs.

   P: Provider Equipment that has backbone trunk connections only.

   VRF: Virtual Private Network (VPN) Routing and Forwarding Instance.

   PoP: Point of presence or a node in SP's network.

   SRLG: A set of links may constitute a 'shared risk link group'
         (SRLG) if they share a resource whose failure may affect all
         links in the set as defined in [GMPLS-ROUT].

   Please note that the terms of CE, PE and P used throughout this
   document are generic in their definitions.  In particular, whenever
   such acronyms are used, it does not necessarily mean that CE is
   connected to a PE in a VRF environment described in such IETF drafts
   as [BGP-MPLSVPN].

3.2. Objectives and Requirements of Inter-AS Traffic Engineering

   As mentioned in section 1 above, some SPs have requirements for
   achieving the same set of traffic engineering objectives as
   presented in [TE-OVW] across AS boundaries.

   This section examines these requirements in each of the key
   corresponding areas: 1) Inter-AS bandwidth guarantees; 2)
   Inter-AS Resource Optimization and 3) Fast Recovery across ASes,
   i.e. Recovery of Inter-AS Links/SRLG and ASBR Nodes.

3.2.1. Inter-AS Bandwidth Guarantees

   The DiffServ IETF working group has defined a set of mechanisms
   described in [DIFF_ARCH], [DIFF_AF] and [DIFF_EF] or [MPLS-Diff]
   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
   can be expressed in terms of maximum one-way transit delay,
   inter-packet delay variation, loss rate, etc.

   Many SPs have some or full deployment of Diffserv implementations in
   their networks today, either across the entire network or at the
   least, on the edge of the network across CE-PE links.

Zhang, Vasseur, et. al.                                        [Page 6]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

   In situations where strict QOS bounds are required, admission
   control inside the backbone of a network is in some cases required
   in addition to current Diffserv mechanisms.

   When the propagation delay can be bounded, the performance targets,
   such as maximum one-way transit delay may be guaranteed by providing
   bandwidth guarantees along the Diffserv-enabled path.

   One typical example of this requirement is to provide bandwidth
   guarantees over an end-to-end path for VoIP traffic classified as EF
   (Expedited Forwarding [DIFF_EF]) class in a Diffserv-enabled
   network.  When the EF path is extended across multiple ASes,
   inter-AS bandwidth guarantee is then required.

   Another case for inter-AS bandwidth guarantee is the requirement for
   guaranteeing a certain amount of transit bandwidth across one or
   multiple ASes.

   Several application scenarios are presented to further illustrate
   this requirement in section 4 below.

3.2.2. Inter-AS Resource Optimization

   In Service Provider (SP) networks, the BGP protocol [BGP] is
   deployed to exchange routing information between ASes.  The inter-AS
   capabilities of BGP may also be employed for traffic engineering
   purposes across the AS boundaries.  Appendix A provides a
   brief description of the current BGP-based inter-AS traffic
   engineering practices.

   SPs have managed to survive with this coarse set of BGP-based
   traffic engineering facilities across inter-AS links in a largely
   best effort environment.  Certainly in many cases ample bandwidth
   within SP's network and across inter-AS links reduces the need for
   more elaborated inter-AS TE policies.

   However, in the case where a SP network is deployed over multiple
   ASes, for example, as the number of inter-AS links grows, the
   complexity of the inter-AS policies and the difficulty in inter-AS
   TE path optimization increase to a level such that it may soon
   become unmanageable.

   Another example is where inter-AS links are established between
   different SP administrative domains. Un-deterministic factors such
   as un-coordinated routing and network changes as well as sub-optimum
   traffic conditions would potentially lead to a complex set of
   Inter-AS traffic engineering policies where current traffic
   engineering mechanisms would probably not scale well.

   In these situations where resource optimization is required and/ or
   specific routing requirements arise, the BGP-based inter-AS
   facilities will need to be complemented by a more granular inter-AS
   traffic engineering mechanism.

Zhang, Vasseur, et. al.                                        [Page 7]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

3.2.3. Fast Recovery across ASes

   When extending services such as VoIP across ASes, customers often
   demands SPs to maintain the same level of performance targets such
   as packet loss and service availability as ones that can be achieved
   within an AS.  As a consequence, fast convergence in a stable

   fashion upon link/SRLG/node failure becomes a strong requirement,
   clearly difficult to achieve with current inter-domain techniques,
   especially in cases of link/SRLG failures between ASBRs or ASBR node
   failures.

3.3. Inter-AS Traffic Engineering Requirements Statement

   Just as in the applicable case of deploying MPLS TE in a SP's
   network, an inter-AS TE method in addition to BGP-based traffic
   engineering capabilities needs to be deployed across inter-AS links
   over where resource optimization, QOS guarantees and fast recovery
   are required.

   This is especially critical in a Diffserv-enabled, multi-class
   environment described in [PSTE] where statistical performance
   targets must be maintained consistently over the entire path
   across different ASes.

   The approach of extending current intra-AS MPLS TE capabilities
   [TE-RSVP] across inter-AS links for IP/MPLS networks is considered
   here because of already available implementations and operational
   experiences.

   Please note that the inter-AS traffic engineering over an IP-only
   network is for future consideration since there is no sufficient
   interest for similar requirements to those of IP/MPLS networks
   at this time.

4. Application Scenarios

   The following sections present a few application scenarios over
   IP/MPLS networks where requirements cannot be addressed with current
   intra-AS MPLS TE mechanism and give rise to considerations for
   inter-AS MPLS traffic engineering requirements.

   Although not explicitly noted in the following discussions, fast
   recovery of traffic path(s) crossing multiple ASes in a stable
   fashion is particularly important in case of link/SRLG/node failure
   at AS boundaries for all application scenarios presented here.

4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees






Zhang, Vasseur, et. al.                                        [Page 8]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

4.1.1 Scenario I - Extended or Virtual PoP (VPoP)

   A global service provider (SP1), for example would like to expand
   its reach in a region where a regional service provider's (SP2)
   network has already established an extended coverage in its PoP
   density.

   In this scenario, the SP1 may establish interconnections with SP2 in
   one or multiple points in that region.  It may then use SP2's
   network as an extended transport by co-locating aggregation routers
   in some SP2's PoPs that are in the regions where SP1 has a larger
   number of customer sites.



   In order to ensure bandwidth capacity provided by SP2 and achieve
   some degrees of transparency to SP2's network changes in terms of
   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
   SP1's PE routers co-locating in SP2's PoPs, as illustrated in the
   diagram below:

    <===========Inter-AS MPLS TE Tunnel===========>
                           -----                -----
                  ________|ASBR |___Inter-AS___|ASBR |________
                 |        | RTR |     Link     | RTR |        |
    ----       -----       -----                -----       -----
   |SP1 |_____| SP2 |                                      | SP1 |
   |VPoP|     |P/PE |                                      |P/PE |
    ----       -----       -----                -----       -----
                 |________|ASBR |___Inter-AS___|ASBR |________|
                          | RTR |     Link     | RTR |
                           -----                -----
    <=================Inter-AS MPLS TE Tunnel=================>
   +-SP1 AS1-+ +-------SP2 AS2-----+          +------SP1 AS1------+

   In situations where end-to-end Diffserv paths must be maintained,
   both SP's networks may need to provision Diffserv PHB at each hop
   supporting a set of traffic classes with compatible performance
   targets.  The subsequent issues regarding Service Level Agreement
   (SLA) boundaries, reporting and measuring system inter-operability
   and support demarcations are beyond the scope of this document and
   will therefore not be discussed here.

   Note also that either the SP1 or SP2 network may not be a
   Diffserv-aware network.  The scenario would still apply to provide
   bandwidth guarantees.

   The SP2, on the other hand, can similarly choose to expand its reach
   beyond its servicing region over SP1's network via inter-AS MPLS
   TE paths.



Zhang, Vasseur, et. al.                                        [Page 9]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

   It is worth mentioning that these remote aggregation routers
   co-located in other SP's network will unlikely participate in
   hosting SP's IGP and BGP routing planes and will most likely
   maintain its own AS or be part of the SP1's AS.  In this case, such
   TE tunnels may cross several ASes, but the Head-end and Tail-end
   LSRs of TE tunnel may have the same AS number, as shown in the
   diagram above.

4.1.2. Scenario II - Extended or Virtual Trunk

   Instead of co-locating a PE router in SP2's PoP, SP1, for example
   may also choose to aggregate customer VPN sites onto a SP2's PE
   router where inter-AS TE tunnels can be built and signaled through
   SP2's MPLS network between the SP2 PoP (to which SP1 customer CEs
   are directly 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 guaranteed bandwidth service up to the TE LSP tail-end
   router located in SP1's network.

   In this scenario, there could be two applicable cases:

   Case 1 - the inter-AS MPLS TE tunnel functions as an extended or
   virtual trunk aggregating SP1 CE's local-loop access circuits on
   SP2's MPLS network over which the bandwidth can be guaranteed to the
   TE LSP tail-end router located in SP1’s network, as shown in the
   diagram below:

                        <====Inter-AS MPLS TE Tunnel====>
                                       or
                        < ===Inter-AS MPLS TE Tunnel===============>

    ----               -----     -----                -----     -----
   | CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1  |
   |    |     Loop    | PE  |   | RTR |     Link     | RTR |   |PE   |
    ----               -----     -----                -----     -----

   +SP1 Customer AS3+ +-----SP2 AS2---+              +-SP1 AS1-------+

   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
   to the SP1's ASBR or PE:

      <==============Inter-AS MPLS TE Tunnel==============>
                               or
      <==============Inter-AS MPLS TE Tunnel========================>

    ----                -----       -----              -----     -----
   | CE |____Local_____| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1  |
   |    |    Loop      | PE  |   | RTR |     Link     | RTR |   |PE   |
    ----                -----     -----                -----     -----

   +SP1 Customer AS3+ +------SP2 AS2---+               +--SP1 AS1-----+


Zhang, Vasseur, et. al.                                       [Page 10]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

   In case 2 above, SP2 may elect to establish an aggregating or
   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
   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

   In this scenario as illustrated below, customers require to
   establish MPLS TE tunnel from CE1 to CE2 end-to-end across several
   SP's networks.  One application example would be guaranteed
   bandwidth for services such as voice- or video-over-IP services.

    <======================Inter-AS MPLS TE Tunnel==================>

    ---       -----     -----              -----      -----       ---
   |CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2|
   |   |     | PE  |   | RTR |    Link    | RTR |    | PE  |     |   |
    ---       -----     -----              -----      -----       ---

   +Cust AS1+ +---SP2 AS-----+        +-------SP1 AS-------+ +Cust ASx+





   The diagram below illustrates another example where CE1 and CE2 are
   customers of SP1 with eBGP peering relationships established across
   the CE-PE links.  A inter-AS MPLS TE tunnel may then be established
   from CE1 in AS1 to CE2 which may belong to the same AS or different
   AS than that of CE1 across SP1's network in AS2.

    <===============Inter-AS MPLS TE Tunnel=====================>

    ---        -----       ----      ----      -----           ---
   |CE1|______| SP1 |_____|SP1 |____|SP1 |____| SP1 |_________|CE2|
   |   |      | PE1 |     |P1  |    |P2  |    | PE2 |         |   |
    ---        -----       ----      ----      -----           ---

   +-Cust AS1-+ +-------------SP1 AS2----------------+ +-Cust ASx-+

   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
   the SP1's network.

   In addition, where both CE1 and CE2 residing in the same AS, they
   likely share the same private AS number.

   Scenario III however, will not scale well should there be a larger
   number of inter-AS TE MPLS tunnels in some degrees of partial mesh
   or full mesh.  Therefore, it is expected that this scenario will
   not have a large number of deployments, unless some mechanisms such
   as hierarchical intra-AS TE-LSPs are used to reduce the number of
   signaling states

Zhang, Vasseur, et. al.                                       [Page 11]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

4.2. Application Scenarios Requiring Inter-AS Resource Optimization

   The scenarios presented in this section mainly deal with inter-AS
   resource optimization.

4.2.1. Scenario IV - TE across multi-AS within a Single SP
       Administrative Domain

   As mentioned in [TE-APP], SPs have generally admitted that the
   current MPLS TE mechanism provides a great deal of tactical and
   strategic values in areas of traffic path optimization [TE-RSVP] and
   rapid local repair capabilities [TE-FRR] via a set of on-line or
   off-line constraint-based searching algorithms.

   From a service provider's perspective, another way of stating the
   objectives of traffic engineering is to be able to deliver more
   customer traffic with already available capacity in the network
   without violating performance targets, and/ or to provide better QOS
   services via an improved network utilization, operating more likely
   below congestion thresholds.

   It is worth noting that situations where resource provisioning is
   not an issue, e.g. low density in inter-AS connectivity or ample
   inter-AS capacity may not require more scalable and granular TE
   facilities beyond BGP routing policies since such policies could be
   rather simple and because inter-AS resource optimization is not an
   absolute requirement.


   However many SPs, especially those with networks across multiple
   continents as well as sparsely connected, have designed their
   multi-AS routing policies, for example, along or within the
   continental or sub-continental boundaries where the number of ASes
   can range from a very few to dozens.  Generally, inter-continent or
   sub-continent capacity is very expensive.  Some Service Providers
   have multiple ASes in the same country and would like to optimize
   resources over their inter-region links.  This would demand a
   more scalable degree of resource optimization, which warrants the
   consideration of extending current intra-AS MPLS TE capabilities
   across inter-AS links.

   In addition, one may only realize higher efficiency in conducting
   traffic optimization and path protection/ restoration planning when
   coordinating all network resources (not partially) as a whole.  For
   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
   below:







Zhang, Vasseur, et. al.                                       [Page 12]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

       <===================Inter-AS MPLS Tunnel=============>
     --------                 --------              --------
    |        |_______________|        |____________|        |
    |  SP1   |_______________|  SP1   |____________|  SP1   |
    |  AS1   |_______________|  AS2   |____________|  AS3   |
    |        |               |        |            |        |
     --------                 --------              --------
        ||                                             ||
        ||                   ---------                 ||
        ||___________________|  SP1   |________________||
        |____________________|  AS4   |_________________|
                             |        |
                             ---------
   The motivation for inter-AS MPLS TE is even more prominent in a
   Diffserv-enabled network over which statistical performance targets
   are to be maintained from any point to any point of the network as
   illustrated in the diagram below with an inter-AS DS-TE LSP:

     <===================Inter-AS MPLS DS-TE Tunnel=============>
    ----    -----     -----                -----     -----     ----
   | PE |__| P   |___|ASBR |___Inter-AS___|ASBR |___|P    |___|PE  |
   | RTR|  | RTR |   | RTR |     Link     | RTR |   |RTR  |   |RTR |
    ----    -----     -----                -----     -----     ----
   +------------SP1 AS1---------+        +------------SP1 AS2------+

   For example , the inter-AS MPLS DS-TE LSP shown in the diagram above
   could be used used to transport a set of L2 Pseudo Wires or VoIP
   traffic with corresponding QoS requirement.

   Furthermore, fast recovery in case of ASBR-ASBR link failure or ASBR
   node failure is a strong requirement for such services.

4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport

   Scenario V presents another possible deployment case.  SP1 with AS1
   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
   to SP2, SP3, etc. as shown in the following diagram:

                <===========Inter-AS MPLS TE Tunnel=======>
   [               ]          [             ]          [              ]
   [  ----    ---- ]          [ ----   ---- ]          [ ----    ---- ]
   [ |P/PE|__|ASBR|]_Inter-AS_[|ASBR|.|ASBR|]_Inter-AS_[|ASBR|  |P/PE|]
   [ |RTR |  |RTR |]   Link   [|RTR | |RTR |]   Link   [|RTR |  |RTR |]
   [  ----    ---- ]          [ ----   ---- ]          [ ----    ---- ]
   [               ]          [             ]          [              ]
       <================Inter-AS MPLS TE Tunnel=====================>
   +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
   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 ASx may be the same as or different from AS1.

Zhang, Vasseur, et. al.                                       [Page 13]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

   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
   introduce routing complexities:

                <===========Inter-AS MPLS TE Tunnel=======>
   +----------------------------SP1 AS1-----------------------------+
   [                                                                ]
   [  ----    ----                                     ----    ---- ]
   [ |P/PE|__|ASBR|__________Primary Intera-AS________|P   |  |PE  |]
   [ |RTR |  |RTR |                Link               |RTR |  |RTR |]
   [  ----    ----                                     ----    ---- ]
   [           |                                        |           ]
   [          ----                                     ----         ]
   [         |ASBR|                                   |ASBR|        ]
   [         |RTR |                                   |RTR |        ]
   [          ----                                     ----         ]
               ^ |                                      | ^
               | |                                      | |
               | |            [              ]          | |
               | |            [ ----    ---- ]          | |
               | |__ Inter-AS_[|ASBR|..|ASBR|]_Inter-AS_| |
               |       Link   [|RTR |  |RTR |]   Link     |
               |              [ ----    ---- ]            |
               |              [              ]            |
               |                                          |
               +======Backup Inter-AS MPLS TE Tunnel======+
                 +Transit SP2 AS2,SP3 AS3,etc....SPi ASi+

5. Detailed Requirements for Inter-AS MPLS Traffic Engnineering

   This section discusses detailed requirements for inter-AS MPLS TE in
   two principal areas: 1) requirements for inter-AS MPLS TE in the
   same SP administrative domain and 2) requirements for inter-AS MPLS
   TE across different SP administrative domains.

5.1. Requirements within one SP Administrative Domain

   This section presents detailed requirements for inter-AS MPLS TE
   within the same SP administrative domain.

5.1.1. Inter-AS MPLS TE Operations and Interoperability

   The inter-AS MPLS TE solution SHOULD be consistent with requirements
   discussed in [TE-REQ] and the derived solution MUST be such that
   it will interoperate seamlessly with current intra-AS MPLS TE
   mechanism and inherit its capability sets from [TE-RSVP].

   The proposed solution MUST allow to provision at the Head/Tail end
   with end-to-end RSVP signaling (eventually with loose paths)
   traversing across the interconnected ASBRs, without further
   provisioning required along the transit path.



Zhang, Vasseur, et. al.                                       [Page 14]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

5.1.2. Protocol Signaling and Path Computations

   One can conceive that an inter-AS MPLS TE tunnel path signaled
   across inter-AS links consists of a sequence of intra-AS segments.

   The proposed solution SHOULD provide the ability to either
   explicitly select or auto-discover the following elements
   when signaling the inter-AS TE LSP path:

      - a set of AS numbers as loop HoPs
      - a set of ASBR LSRs

   and to specify the above elements in the ERO and record them in the
   RRO of the Resv message just to keep track of the set of ASes or
   ASBRs traversed by the inter-As TE LSP.

   For example, one may provide a manual description of all or some of
   the hops (loose routing) the TE LSP must traverse, allowing to keep
   the information related to the intra-AS resources confidential while
   still leaving intra-AS routing decisions to local operators.  The
   solution may allow the Head-end LSR to compute the TE LSP
   path up to the next entry point in the next hop AS.

   In the case of establishing inter-AS TE LSP traversing multiple ASes
   within the same SP networks, the solution SHOULD also allow the
   Headend LSR to explicitly specify the hops across anyone of
   the transiting ASes and the TE tunnel headhend SHOULD also check
   the explicit segment to make sure that the constrainsts are met.

   In another example, an automated way of setting up the TE LSP
   without any static configuration on the Head-End LSR. In that case,
   it might require a discovery mechanism of some PCS using IGP
   extensions (as defined in [OSPF-TE-CAP], for example), as well as
   some signaling protocol extension to request the computation of an
   inter-AS TE LSP to a PCS(s) such as one defined in [PATH-COMP].

   In addition, The proposed solution SHOULD also provide the ability
   to specify and signal that certain loose or explicit nodes and
   resources to be explicitly excluded in the inter-AS TE LSP path
   establishment, such as one defined in [EXCLUDE-ROUTE] for instance.

5.1.3 Optimality

   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
   follow an optimal path.

   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
   the case of an inter-AS path across several ASes having completely
   different IGP metric policies, the notion of minimal path might
   require IGP metric normalization, for example.


Zhang, Vasseur, et. al.                                       [Page 15]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

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
   LSPs between a pair of LSRs, when:

     (1) A single TE LSP satisfying the required set of constraints
         cannot be found, in which case it may require load splitting.

     (2) Multiple TE paths may be required to limit the impact of a
         network element failure to a portion of the traffic.  As an
         example, two VoIP gateways may load balance the traffic among
         a set of inter-AS TE LSPs.

     (3) Path protection (e.g. 1:1 or 1:N) as discussed in
         [MPLS-Recov].

   In the examples above, being able to set up diversely routed TE LSPs
   becomes a requirement for inter-AS TE.

   The solution SHOULD be able to set up a set of link/SRLG/Node
   diversely routed inter-AS TE LSPs.

5.1.5.  Re-optimization

   Once an inter-AS TE LSP has been established and should there be any
   resource or other changes inside anyone of transiting ASes, the
   solution MUST be able to re-optimize the LSP accordingly and
   non-disruptively, either upon expiration of a configurable timer or
   triggered by a network event or a manual request at the TE tunnel
   Head-end.

   The solution SHOULD support the ability for intermediate nodes to
   signal the respective Head-End LSRs of the existence of a more
   optimal path.

   The solution SHOULD also be such that an inter-AS TE LSP is
   re-signaled again (via make before break) if and only if a more
   optimal path exists.

   Furthermore the solution SHOULD provide the ability of manually
   rejecting re-optimization at AS boundaries.

5.1.6. Fast Recovery support using MPLS TE Fast Reroute

   There are in general two or more inter-AS links between multiple
   pair of ASBRs for redundancy.  The topological density between ASes
   in a multi-AS SP network is generally much higher.  In the event of
   inter-AS link failure, rapid local protection SHOULD also be made
   available and interoperate with current intra-AS MPLS TE fast
   re-route mechanism from [TE-FRR].




Zhang, Vasseur, et. al.                                       [Page 16]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

   Moreover, the traffic routed onto an inter-AS TE tunnel SHOULD also
   be fast protected against any node failure, should the node be
   internal to an AS or at the AS boundary.

5.1.7. DS-TE Support

   The proposed inter-AS MPLS TE solution SHOULD also satisfy core
   requirements documented in [DS-TE] and interoperate seamlessly with
   current intra-AS MPLS DS-TE mechanism [DSTE-PROT].

   It is worth pointing out that the compatibility clause in section
   4.1 of [DS-TE] SHOULD also be faithfully applied in the development
   of the solutions.

5.1.8. Hierarchical LSP Support and Forwarding Adjacency (FA)

   It is conceivable that there would potentially be scalability 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 each
   transiting PoP, the proposed solution SHOULD allow TE LSP
   aggregation such that individual tunnels can be carried onto one or
   more aggregating LSP.  One such mechanism, for example is described
   in [MPLS-LSPHIE].

5.1.9. Mapping of traffic onto Multiple Inter-AS MPLS TE Tunnels

   There SHOULD be several possibilities to map a particular traffic
   to a particular destination onto a specific inter-AS TE LSP.

   For example, static routing could be used if IP destination
   addresses are known.  Another example is to utilize static routing
   using recursive BGP route resolution.

   In cases where inter-AS MPLS TE tunnels are terminated at P routers
   in a PoP where there could also be multiple PE routers, the proposed
   solution SHOULD provide the ability whereby to "announce" 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 that do
   not participate in the inter-AS TE path computation can take into
   account such links in its IGP-based SPF computation.

5.1.10. Inter-AS MPLS TE Management

5.1.10.1. Inter-AS MPLS TE MIB Requirements

   An inter-AS TE MIB is required for use with network management
   protocols by SPs to manage and configure inter-AS traffic
   engineering tunnels.  This new MIB must extend (and not reinvent)
   the existing MIBs to accommodate this new functionality.





Zhang, Vasseur, et. al.                                       [Page 17]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

   An inter-AS TE MIB should include features, for example:
      - the setup of inter-AS TE tunnels with associated constraints
        (e.g. resources)
      - the collection of traffic and performance statistics not only
        at the tunnel Headend, but any other points of the TE tunnel.
      - the inclusion of both IPv4/v6 + AS# or AS# subobjects in the
        ERO in the path message, e.g:

        EXPLICIT_ROUTE class object:
        address1 (loose IPv4 Prefix, /AS1)
        address2 (loose IPv4 Prefix, /AS1)
        AS2      (AS number)
        address3 (loose IPv4 prefix, /AS3)
        address4 (loose IPv4 prefix, /AS3) - destination

        or

        address1 (loose IPv4 Prefix, /AS1)
        address2 (loose IPv4 Prefix, /AS1)
        address3 (loose IPv4 Prefix, /AS2)
        address4 (loose IPv4 Prefix, /AS2)
        address5 (loose IPv4 prefix, /AS3)
        address6 (loose IPv4 prefix, /AS3) - destination

      - Similarly, the inclusion of the RRO object in the resv. message
        recording subojects such as interface IPv4/v6 address (if not
        hidden), AS number, a label, a node-id (when required), etc.
      - inter-AS specific attributes as discussed in section 5 of this
        document including, for example inter-AS MPLS TE tunnel
        accounting records across each AS segment.

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
   plane failures.  But tools for fault detection over LSPs haven't
   been widely developed so far.  SPs today manually troubleshoot such
   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
   plane in order to determine where the faults come from.

   The proposed solution SHOULD be able to interoperate with fault
   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
   IGP areas (OSPF) or levels(IS-IS) within the transiting ASes with
   working return paths.

   For example, [LSPPING] is being considered as a failure detection
   mechanism over the data plane against the control plane and could
   be used to troubleshoot intra-AS TE LSPs.  Such facilities, if
   adopted, SHOULD then be extended to inter-AS TE paths.




Zhang, Vasseur, et. al.                                       [Page 18]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

   The above example, however depicts one such mechanism that does
   require a working return path such that diagnostic test packets can
   return via an alternate data plane, such as a global IPv4 path in
   the event that the LSP is broken.

   [MPLS-TTL] presents how TTL may be processed across a hierarchical
   MPLS networks and such a facility as this SHOULD also be extended
   to inter-AS TE links.

5.2. Requirements for Inter-AS MPLS TE across Multiple SP
     Administrative Domains.

   The requirements for inter-AS MPLS TE across multiple SP admin
   domains SHOULD include all requirements discussed in section 5.1
   above in addition to what are presented in this section here.

   Please note that the SP with multi-AS networks may choose not to
   turn on the features discussed in the following two sections when
   building TE tunnels across ASes in its own domain.

5.2.1. Confidentiality

   Since an inter-AS TE LSP may span multiple ASes belonging to
   different SPs, the solution MIGHT allow to "hide" the set of hops
   used by the TE LSP within an AS as illustrated in the following
   example:

   [   ASBR1-----ASBR2   ]
   [       ]     [       ]
   [  A    ]     [   B   ]
   [  AS1  ]     [   AS2 ]
   [  SP1  ]-----[   SP2 ]
   [       ]     [       ]

   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
   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
   B that complies with the set of constraints traverses ASBR2 without
   a detailed knowledge of the lists of the hops used within AS2.

   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)
   could use this information to compute an optimal path, even if the
   computed path is not provided by AS2.

   In addition, the management requirements discussed in section 5.1.10
   above, when used across different SP admin domains, SHOULD include
   similar confidentiality requirements discussed here in terms of
   "hiding" intermediate hops or interface address and/ or labels in
   the transiting or peering SPs.



Zhang, Vasseur, et. al.                                       [Page 19]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

5.2.2. Policy Control

   In some cases, some policy control might be necessary at the AS
   boundaries, namely ingress policy controls enabling SPs to enforce
   the inter-AS policies per interconnect agreements or modify some
   requested parameters conveyed by incoming inter-AS MPLS TE signaling
   requests.

   It is worth noting that such policy control mechanism may also be
   used between ASes within a SP.

   This section only discusses the elements that may be used to form a
   set of ingress control policies.  However, how exactly SPs establish
   bilateral or multilateral agreements upon which the control policies
   can be built are beyond the scope of this document.

5.2.2.1. Inter-AS TE Agreement Enforcement Polices

   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
   boundaries:

      - RSVP-TE session attributes: affinities and preemption
        priorities
      - Per AS or SP bandwidth admission control to ensure that RSVP-TE
        messages do not request for bandwidth resources over their
        allocation.
      - Request origins which can be represented by HE tunnel ending IP
        address, originating AS#, neighbor AS#, neighbor ASBR interface
        IP address, etc.
      - DS-TE TE-Class <Class-Type, Preemption>.
      - FRR attribute: local protection desired bit, node protection
        desired bit and bandwidth protection desired bit carried in the
        SESSION
      - ATTRIBUTE or the FAST-REROUTE objects in the RSVP Path message
        as defined in [TE-FRR].
      - Optimization allowed or not.

   In some cases, a TE policy server could also be used for the
   enforcement of inter-AS TE policies.  This requirement could allow
   SPs to make the inter-AS TE policies scale better.

   The signaling of a non policy compliant request MUST trigger the
   generation of a RSVP Path Error message by the policy enforcing
   node towards the Head-end LSR, indicating the cause. The
   Head-end LSR SHOULD take appropriate actions, such as re-route, upon
   receipt of such a message.







Zhang, Vasseur, et. al.                                       [Page 20]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

5.2.2.2. Inter-AS TE Rewrite Policies

   In some situations, SPs may need to rewrite some attributes of the
   incoming inter-AS TE signaling requests due to for example, a lack
   of resources for a particular TE-Class, non compliant preemption,
   upon mutual agreements.  The following lists a set of parameters
   that can potentially be rewritten at the AS boundaries:

      - RSVP-TE session attributes: affinities and preemption
        priorities
      - DS-TE TE-Class <Class-Type, Preemption>.
      - ERO expansion requests

   Simimarly, the re-writing node MUST generate a RSVP Path Error
   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 inter-AS TE LSP.

5.2.2.3 Inter-AS Traffic Policing

   The proposed solution SHOULD also provide a set of policing
   mechanisms which could be configured on the inter-AS links,
   to ensure that traffic routed through the tunnel does not exceed
   the bandwidth negotiated during LSP signaling.

   For example, an ingress policer could be configured to enforce
   the traffic contract on the mutually agreed resource requirements
   of the established inter-AS TE LSP (i.e. RSVP bandwidth) on the
   interface to which the inter-AS link is connected.



6. Evaluation Criteria

   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.

6.2. Scalability and Extensibility

   The proposed solution(s) MUST have minimum impact on the network
   scalability from both intra and inter-AS perspectives.



Zhang, Vasseur, et. al.                                       [Page 21]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

   This requirement applies to both of the following:

      - IGP (impact in terms of IGP flooding, SPF, etc.).
      - BGP (impact in terms of additional information carried within
        BGP, number of routes, flaps, overload events, etc.).
      - RSVP TE (message rate, number of retained states, ,etc.).

   In addition, the solution(s) MUST allow extensions as both inter-AS
   MPLS TE and current intra-AS MPLS TE specifications evolve.

6.3. Complexity and Risks

   The proposed solution (s) SHOULD not introduce unnecessary
   complexity to the current operating network to such a degree that it
   would affect the stability and diminish the benefits of deploying
   such solution over SP networks.

6.4. 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

   Other criteria might be added as this draft will evolve.

6.5. Backward Compatibility

   The deployment of inter-AS MPLS TE SHOULD not have impact on
   existing BGP-based traffic engineering or MPLS TE mechanisms to
   allow for a smooth migration or co-existence.

7. Security Considerations

   The proposed solution(s) MUST address security issues across
   multiple SP administrative domains.  Although inter-AS MPLS TE is
   not expected to add specific security extensions beyond those of
   current intra-AS TE, greater considerations MUST be given in terms
   of how to establish a trusted model across AS boundaries.  SPs
   SHOULD have a means to authenticating, such as using RSVP INTEGRITY
   object, allowing and possibly denying inter-AS signaling requests
   and SHOULD be protected from DoS attacks.

8. Acknowledgement

   We would like to thank Yuichi Ikejiri, David Allan, Kurt Erik
   Lindqvist, Dave McDysan, Christian Jacquenet, Kireeti Kompella,
   Ed Kern, Jim Boyle and Thomas Nadeauor for their suggestions and
   helpful comments during the discussions of this draft.



Zhang, Vasseur, et. al.                                       [Page 22]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

9. Editor's Addresses

   Raymond Zhang
   Infonet Services Corporation
   2160 E. Grand Ave.
   El Segundo, CA 90025
   USA
   Email: raymond_zhang@infonet.com

   JP Vasseur
   CISCO Systems, Inc.
   300 Beaver Brook Road
   Boxborough , MA - 01719
   USA
   Email: jpv@cisco.com

10. Normative References

   [TE-REQ], Awduche et. al., "Requirements for Traffic Engineering
   over MPLS", RFC2702, September 1999.

   [TE-RSVP], Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP
   Tunnels", RFC 3209, December 2001

   [GMPLS-ROUT], Kompella, et. al., "RGeneralized Multi-Protocol Label
   Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
   Engineering (RSVP-TE) Extensions, RFC 3473, January 2003.


   [BGP], Rekhter, et. al., "A Border Gateway Protocol 4 (BGP-4)",
   RFC 1771, March 1995

   [LSPPING], Kompella, et.. al.," Detecting Data Plane Liveliness in
   MPLS", Internet Draft <draft-ietf-mpls-lsp-ping-03.txt>, June 2003,
   (Work in Progress)

   [MPLS-TTL], Agarwal, et. al., "Time to Live (TTL) Processing in MPLS
   Networks", RFC 3443, January, 2003

   [DS-TE], Le Faucheur, et. al., ''Requirements for support of
   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-05.txt, September, 2003 (Work in Progress).

   [TE-FRR], Pan, et. al., "Fast Reroute Techniques in RSVP-TE",
   draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, June 2003
   (Work in Progress).

   [ISIS-TE], Smit, Li, "IS-IS extensions for Traffic Engineering",
   draft-ietf-isis-traffic-05.txt, August, 2003 (Work in Progress).


Zhang, Vasseur, et. al.                                       [Page 23]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

   [OSPF-TE] Katz, Yeung, "Traffic Engineering Extensions to OSPF",
   draft-ietf-ospf-ospfv3-traffic-01.txt, June, 2001
   (Work in Progress).

   [PATH-COMP], Vasseur, et. al., ''RSVP Path computation request and
   reply messages'', draft-vasseur-mpls-computation-rsvp-03.txt, June
   2002. (Work in Progress)

   [OSPF-TE-CAP], Vasseur, Psenak. "OSPF TE TLV capabilities",
   draft-vasseur-mpls-ospf-te-cap-00.txt, October 2002.
   (Work in Progress)

   [MPLS-LSPHIE] Kompella, Rekhter, "LSP Hierarchy with Generalized
   MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt , March 2002.
   (work in progress)

   [MPLS-Recov], Sharma V., et al, "Framework for Multi-Protocol Label
   Switching (MPLS)-based Recovery", RFC 3469, Feb, 2003

   [BGP-Label], Rekhter and Rosen, "Carrying Label Information in
   BGP-4", RFC 3107, May 2001

   [INTER-AS-TE], Vasseur and Zhang, "Inter-AS MPLS Traffic
   Engineering", draft-vasseur-inter-as-te-01.txt, June, 2003 (work
   in progress).

   [EXCLUDE-ROUTE], Farrel, et. al., "draft-ietf-ccamp-rsvp-te-exclude
   -route-00.txt", June 2003 (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



Zhang, Vasseur, et. al.                                       [Page 24]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

   [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.

12. Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   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
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


















Zhang, Vasseur, et. al.                                       [Page 25]


Internet Draft     draft-ietf-tewg-interas-mpls-te-req-01.txt  Oct 2003

Appendix A. Brief Description of BGP based Inter-AS Traffic
            Engineering

   In today's Service Provider (SP) network, BGP is deployed to meet
   two different sets of requirements:

      - Establishing a scalable exterior routing plane separating from
        data forwarding plane within SP's administrative domain
      - Exchanging network reachability information with different BGP
        autonomous systems (ASes) that could belong to a different SP
        or simply, a different AS within a SP network.

   Over connections across the AS boundaries, traffic engineering may
   also be accomplished via a set of BGP capabilities by appropriately
   enforcing BGP-based inter-AS routing policies.  The current
   BGP-based inter-AS traffic engineering practices may be summarized
   as follows:

      - "Closest exit" routing where egress traffic from one SP to
        another follows the path defined by the lowest IGP or intra-AS
        MPLS TE tunnel metrics of the BGP next-HOP of exterior routes
        learned from other AS over the inter-AS links
      - "BGP path attribute" based routing selection mechanism where
        the egress traffic path is determined by interconnect (peering
        or transit) policies based upon one or a combination of BGP
        path attributes, like AS_PATH, MULTI_EXIT_DISC (MED), and
        Local_Pref.

   SPs have often faced a number of un-deterministic factors in their
   practices of inter-AS traffic engineering employing the methods
   mentioned above:

      - Sub-optimum traffic distribution across inter-AS links
      - Un-deterministic traffic condition changes due to uncoordinated
        IGP routing policies or topology changes within other AS and
        uncoordinated BGP routing policy changes (MED or as-prepend,
        etc.)

   In addition, to achieve some degrees of granularity, SPs may choose
   to enforce BGP inter-AS policies that are specific to one or a set
   of inter-AS links for ingress traffic destined to certain PoPs or
   regions within SP's network from another AS by tagging certain sets
   of routes with a specific attribute when announcing to another AS.
   This of course goes under the assumption that the other AS permits
   automated egress policy by matching the predefined attribute from
   incoming routes.








Zhang, Vasseur, et. al.                                       [Page 26]