draft-ietf-tewg-interas-mpls-te-req-01.txt   draft-ietf-tewg-interas-mpls-te-req-02.txt 
IETF Internet Draft Raymond Zhang, Editor IETF Internet Draft Raymond Zhang, Editor
Internet Engineering Task Force Infonet Services Corporation Internet Engineering Task Force Infonet Services Corporation
Document: JP Vasseur, Co-Editor Document: JP Vasseur, Co-Editor
draft-ietf-tewg-interas-mpls-te-req-01.txt CISCO Systems, Inc draft-ietf-tewg-interas-mpls-te-req-02.txt CISCO Systems, Inc
October 2003 November 2003
Expires: April 2004 Expires: May 2004
MPLS Inter-AS Traffic Engineering requirements MPLS Inter-AS Traffic Engineering requirements
draft-ietf-tewg-interas-mpls-te-req-01.txt draft-ietf-tewg-interas-mpls-te-req-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are Working all provisions of Section 10 of RFC2026. Internet-Drafts are Working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 2, line 43 skipping to change at page 2, line 43
4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport..13 4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport..13
5. Detailed Requirements for Inter-AS MPLS Traffic Engnineering......14 5. Detailed Requirements for Inter-AS MPLS Traffic Engnineering......14
5.1. Requirements within one SP Administrative Domain................14 5.1. Requirements within one SP Administrative Domain................14
5.1.1. Inter-AS MPLS TE Operations and Interoperability..............14 5.1.1. Inter-AS MPLS TE Operations and Interoperability..............14
5.1.2. Protocol Signaling and Path Computations......................15 5.1.2. Protocol Signaling and Path Computations......................15
5.1.3. Optimality....................................................15 5.1.3. Optimality....................................................15
5.1.4. Support of diversely routed inter-AS TE LSP...................16 5.1.4. Support of diversely routed inter-AS TE LSP...................16
5.1.5. Re-optimization...............................................16 5.1.5. Re-optimization...............................................16
5.1.6. Fast Recovery support using MPLS TE Fast Reroute..............16 5.1.6. Fast Recovery support using MPLS TE Fast Reroute..............16
5.1.7. DS-TE Support.................................................17 5.1.7. DS-TE Support.................................................17
5.1.8. Hierarchical LSP Support and Forwarding Adjacency (FA)........17 5.1.8. Hierarchical LSP Support......................................17
5.1.9. Mapping of traffic onto Multiple 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..................................17 5.1.10. Inter-AS MPLS TE Management..................................17
5.1.10.1. Inter-AS MPLS TE MIB Requirements..........................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.1.10.2. Inter-AS MPLS TE Fault Management Requirements.............18
5.2. Requirements for Inter-AS MPLS TE across Multiple SP 5.2. Requirements for Inter-AS MPLS TE across Multiple SP
Administrative Domains..........................................19 Administrative Domains..........................................19
5.2.1. Confidentiality...............................................19 5.2.1. Confidentiality...............................................19
5.2.2. Policy Control................................................20 5.2.2. Policy Control................................................20
5.2.2.1. Inter-AS TE Agreement Enforcement Polices...................20 5.2.2.1. Inter-AS TE Agreement Enforcement Polices...................20
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....................................21 5.2.2.3 Inter-AS Traffic Policing....................................21
skipping to change at page 8, line 11 skipping to change at page 8, line 11
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.
3.2.3. Fast Recovery across ASes 3.2.3. Fast Recovery across ASes
When extending services such as VoIP across ASes, customers often When extending services such as VoIP across ASes, customers often
demands SPs to maintain the same level of performance targets such demands SPs to maintain the same level of performance targets such
as packet loss and service availability as ones that can be achieved as packet loss and service availability as ones that can be achieved
within an AS. As a consequence, fast convergence in a stable within an AS. As a consequence, fast convergence in a stable
fashion upon link/SRLG/node failures becomes a strong requirement.
fashion upon link/SRLG/node failure becomes a strong requirement, This is clearly difficult to achieve with current inter-domain
clearly difficult to achieve with current inter-domain techniques, techniques, especially in cases of link/SRLG failures between ASBRs
especially in cases of link/SRLG failures between ASBRs or ASBR node or ASBR node failures.
failures.
3.3. Inter-AS Traffic Engineering Requirements Statement 3.3. Inter-AS Traffic Engineering Requirements Statement
Just as in the applicable case of deploying MPLS TE in a SP's Just as in the applicable case of deploying MPLS TE in a SP's
network, an inter-AS TE method in addition to BGP-based traffic network, an inter-AS TE method in addition to BGP-based traffic
engineering capabilities needs to be deployed across inter-AS links engineering capabilities needs to be deployed across inter-AS links
over where resource optimization, QOS guarantees and fast recovery over where resource optimization, QOS guarantees and fast recovery
are required. are required.
This is especially critical in a Diffserv-enabled, multi-class This is especially critical in a Diffserv-enabled, multi-class
skipping to change at page 8, line 38 skipping to change at page 8, line 37
across different ASes. across different ASes.
The approach of extending current intra-AS MPLS TE capabilities The approach of extending current intra-AS MPLS TE capabilities
[TE-RSVP] across inter-AS links for IP/MPLS networks is considered [TE-RSVP] across inter-AS links for IP/MPLS networks is considered
here because of already available implementations and operational here because of already available implementations and operational
experiences. experiences.
Please note that the inter-AS traffic engineering over an IP-only Please note that the inter-AS traffic engineering over an IP-only
network is for future consideration since there is no sufficient network is for future consideration since there is no sufficient
interest for similar requirements to those of IP/MPLS networks interest for similar requirements to those of IP/MPLS networks
at this time. at this time. More specifically, this document only covers the
inter-AS TE requirements for packet based IP/MPLS networks.
4. Application Scenarios 4. Application Scenarios
The following sections present a few application scenarios over The following sections present a few application scenarios over
IP/MPLS networks where requirements cannot be addressed with current IP/MPLS networks where requirements cannot be addressed with current
intra-AS MPLS TE mechanism and give rise to considerations for intra-AS MPLS TE mechanism and give rise to considerations for
inter-AS MPLS traffic engineering requirements. inter-AS MPLS traffic engineering requirements.
Although not explicitly noted in the following discussions, fast Although not explicitly noted in the following discussions, fast
recovery of traffic path(s) crossing multiple ASes in a stable recovery of traffic path(s) crossing multiple ASes in a stable
fashion is particularly important in case of link/SRLG/node failure fashion is particularly important in case of link/SRLG/node failures
at AS boundaries for all application scenarios presented here. at AS boundaries for all application scenarios presented here.
4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees 4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees
4.1.1 Scenario I - Extended or Virtual PoP (VPoP) 4.1.1 Scenario I - Extended or Virtual PoP (VPoP)
A global service provider (SP1), for example would like to expand A global service provider (SP1), for example would like to expand
its reach in a region where a regional service provider's (SP2) its reach in a region where a regional service provider's (SP2)
network has already established an extended coverage in its PoP network has already established an extended coverage in its PoP
density. density.
skipping to change at page 10, line 20 skipping to change at page 10, line 20
LSRs of TE tunnel may have the same AS number, as shown in the LSRs of TE tunnel may have the same AS number, as shown in the
diagram above. diagram above.
4.1.2. Scenario II - Extended or Virtual Trunk 4.1.2. Scenario II - Extended or Virtual Trunk
Instead of co-locating a PE router in SP2's PoP, SP1, for example Instead of co-locating a PE router in SP2's PoP, SP1, for example
may also choose to aggregate customer VPN sites onto a SP2's PE 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 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 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 are directly connected) and SP1's ASBR or PE routers inside SP2's
network. This allows SP1s customers connected to SP2 PE router to network. This allows SP1s customers connected to SP2 PE router to
receive a guaranteed bandwidth service up to the TE LSP tail-end receive a guaranteed bandwidth service up to the TE LSP tail-end
router located in SP1's network. router located in SP1's network.
In this scenario, there could be two applicable cases: In this scenario, there could be two applicable cases:
Case 1 - the inter-AS MPLS TE tunnel functions as an extended or Case 1 - the inter-AS MPLS TE tunnel functions as an extended or
virtual trunk aggregating SP1 CE's local-loop access circuits on virtual trunk aggregating SP1 CE's local-loop access circuits on
SP2's MPLS network over which the bandwidth can be guaranteed to the SP2's MPLS network over which the bandwidth can be guaranteed to the
TE LSP tail-end router located in SP1s network, as shown in the TE LSP tail-end router located in SP1s network, as shown in the
diagram below: diagram below:
<====Inter-AS MPLS TE Tunnel====> <====Inter-AS MPLS TE Tunnel====>
or or
< ===Inter-AS MPLS TE Tunnel===============> < ===Inter-AS MPLS TE Tunnel===============>
---- ----- ----- ----- ----- ---- ----- ----- ----- -----
| CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 | | CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE | | | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- ----- ---- ----- ----- ----- -----
skipping to change at page 11, line 13 skipping to change at page 11, line 13
+SP1 Customer AS3+ +------SP2 AS2---+ +--SP1 AS1-----+ +SP1 Customer AS3+ +------SP2 AS2---+ +--SP1 AS1-----+
In case 2 above, SP2 may elect to establish an aggregating or In case 2 above, SP2 may elect to establish an aggregating or
hierarchical intra-AS MPLS TE tunnel between the transiting P or PE hierarchical intra-AS MPLS TE tunnel between the transiting P or PE
router and SP2's ASBR router just to reduce the number of tunnel router and SP2's ASBR router just to reduce the number of tunnel
states signaled from the SP2 PE to where SP1's CEs are connected. states signaled from the SP2 PE to where SP1's CEs are connected.
4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE 4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE
In this scenario as illustrated below, customers require to In this scenario as illustrated below, customers require to
establish MPLS TE tunnel from CE1 to CE2 end-to-end across several establish MPLS TE tunnel from CE1 to CE2 end-to-end across several
SP's networks. One application example would be guaranteed SP's networks. One application example would be the guaranteed
bandwidth for services such as voice- or video-over-IP services. bandwidth for voice- or video-over-IP services.
<======================Inter-AS MPLS TE Tunnel==================> <======================Inter-AS MPLS TE Tunnel==================>
--- ----- ----- ----- ----- --- --- ----- ----- ----- ----- ---
|CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2| |CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2|
| | | PE | | RTR | Link | RTR | | PE | | | | | | PE | | RTR | Link | RTR | | PE | | |
--- ----- ----- ----- ----- --- --- ----- ----- ----- ----- ---
+Cust AS1+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASx+ +Cust AS1+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASx+
skipping to change at page 13, line 31 skipping to change at page 13, line 31
illustrated in the diagram below with an inter-AS DS-TE LSP: illustrated in the diagram below with an inter-AS DS-TE LSP:
<===================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 used to transport a set of L2 Pseudo Wires or VoIP could be used to transport a set of L2 Pseudo Wires or VoIP traffic
traffic with corresponding QoS requirement. with corresponding QoS 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 15, line 14 skipping to change at page 15, line 14
5.1.2. Protocol Signaling and Path Computations 5.1.2. Protocol Signaling and Path Computations
One can conceive that an inter-AS MPLS TE tunnel path signaled One can conceive that an inter-AS MPLS TE tunnel path signaled
across inter-AS links consists of a sequence of intra-AS segments. across inter-AS links consists of a sequence of intra-AS segments.
The proposed solution SHOULD provide the ability to either The proposed solution SHOULD provide the ability to either
explicitly select or auto-discover the following elements explicitly select or auto-discover the following elements
when signaling the inter-AS TE LSP path: when signaling the inter-AS TE LSP path:
- a set of AS numbers as loop HoPs - a set of AS numbers as loose HoPs
- a set of ASBR LSRs - a set of ASBR LSRs
and to specify the above elements in the ERO and record them in the 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 RRO of the Resv message just to keep track of the set of ASes or
ASBRs traversed by the inter-As TE LSP. ASBRs traversed by the inter-As TE LSP.
For example, one may provide a manual description of all or some of 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 hops (loose routing) the TE LSP must traverse, allowing to keep
the information related to the intra-AS resources confidential while the information related to the intra-AS resources confidential while
still leaving intra-AS routing decisions to local operators. The still leaving intra-AS routing decisions to local operators. The
skipping to change at page 16, line 51 skipping to change at page 16, line 51
re-signaled again (via make before break) if and only if a more re-signaled again (via make before break) if and only if a more
optimal path exists. optimal path exists.
Furthermore the solution SHOULD provide the ability of manually Furthermore the solution SHOULD provide the ability of manually
rejecting re-optimization at AS boundaries. rejecting re-optimization at AS boundaries.
5.1.6. Fast Recovery support using MPLS TE Fast Reroute 5.1.6. Fast Recovery support using MPLS TE Fast Reroute
There are in general two or more inter-AS links between multiple There are in general two or more inter-AS links between multiple
pair of ASBRs for redundancy. The topological density between ASes pair of ASBRs for redundancy. The topological density between ASes
in a multi-AS SP network is generally much higher. In the event of in a SP network with multi-ASes is generally much higher. In the
inter-AS link failure, rapid local protection SHOULD also be made event of an inter-AS link failure, rapid local protection SHOULD
available and interoperate with current intra-AS MPLS TE fast also be made available and interoperate with current intra-AS MPLS
re-route mechanism from [TE-FRR]. TE fast re-route mechanism from [TE-FRR].
Moreover, the traffic routed onto an inter-AS TE tunnel SHOULD also The traffic routed onto an inter-AS TE tunnel SHOULD also be fast
be fast protected against any node failure, should the node be protected against any node failure where the node could be internal
internal to an AS or at the AS boundary. to an AS or at the AS boundary.
5.1.7. DS-TE Support 5.1.7. DS-TE Support
The proposed inter-AS MPLS TE solution SHOULD also satisfy core The proposed inter-AS MPLS TE solution SHOULD also satisfy core
requirements documented in [DS-TE] and interoperate seamlessly with requirements documented in [DS-TE] and interoperate seamlessly with
current intra-AS MPLS DS-TE mechanism [DSTE-PROT]. current intra-AS MPLS DS-TE mechanism [DSTE-PROT].
It is worth pointing out that the compatibility clause in section It is worth pointing out that the compatibility clause in section
4.1 of [DS-TE] SHOULD also be faithfully applied in the development 4.1 of [DS-TE] SHOULD also be faithfully applied in the development
of the solutions. of the solutions.
5.1.8. Hierarchical LSP Support and Forwarding Adjacency (FA) 5.1.8. Hierarchical LSP Support
It is conceivable that there would potentially be scalability issues It is conceivable that there would potentially be scalability issues
as the number of required inter-AS MPLS TE tunnels increases. In 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 order to reduce the number of tunnel states to be maintained by each
transiting PoP, the proposed solution SHOULD allow TE LSP transiting PoP, the proposed solution SHOULD allow TE LSP
aggregation such that individual tunnels can be carried onto one or aggregation such that individual tunnels can be carried onto one or
more aggregating LSP. One such mechanism, for example is described more aggregating LSP(s). One such mechanism, for example is
in [MPLS-LSPHIE]. described in [MPLS-LSPHIE].
5.1.9. Mapping of traffic onto Multiple Inter-AS MPLS TE Tunnels 5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels
There SHOULD be several possibilities to map a particular traffic There SHOULD be several possibilities to map a particular traffic
to a particular destination onto a specific inter-AS TE LSP. to a particular destination onto a specific inter-AS TE LSP.
For example, static routing could be used if IP destination For example, static routing could be used if IP destination
addresses are known. Another example is to utilize static routing addresses are known. Another example is to utilize static routing
using recursive BGP route resolution. using recursive BGP route resolution.
In cases where inter-AS MPLS TE tunnels are terminated at P routers 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 in a PoP where there could also be multiple PE routers, the proposed
skipping to change at page 17, line 52 skipping to change at page 17, line 52
the link's cost associated with it. By doing so, PE routers that do 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 not participate in the inter-AS TE path computation can take into
account such links in its IGP-based SPF computation. account such links in its IGP-based SPF computation.
5.1.10. Inter-AS MPLS TE Management 5.1.10. Inter-AS MPLS TE Management
5.1.10.1. Inter-AS MPLS TE MIB Requirements 5.1.10.1. Inter-AS MPLS TE MIB Requirements
An inter-AS TE MIB is required for use with network management An inter-AS TE MIB is required for use with network management
protocols by SPs to manage and configure inter-AS traffic protocols by SPs to manage and configure inter-AS traffic
engineering tunnels. This new MIB must extend (and not reinvent) engineering tunnels. This new MIB MUST extend (and not reinvent)
the existing MIBs to accommodate this new functionality. the existing MIBs to accommodate this new functionality.
An inter-AS TE MIB should include features, for example: An inter-AS TE MIB should include features, for example:
- the setup of inter-AS TE tunnels with associated constraints - the setup of inter-AS TE tunnels with associated constraints
(e.g. resources) (e.g. resources)
- the collection of traffic and performance statistics not only - the collection of traffic and performance statistics not only
at the tunnel Headend, but any other points of the TE tunnel. at the tunnel Headend, but any other points of the TE tunnel.
- the inclusion of both IPv4/v6 + AS# or AS# subobjects in the - the inclusion of both IPv4/v6 + AS# or AS# subobjects in the
ERO in the path message, e.g: ERO in the path message, e.g:
skipping to change at page 20, line 7 skipping to change at page 20, line 7
computed path is not provided by AS2. computed path is not provided by AS2.
In addition, the management requirements discussed in section 5.1.10 In addition, the management requirements discussed in section 5.1.10
above, when used across different SP admin domains, SHOULD include above, when used across different SP admin domains, SHOULD include
similar confidentiality requirements discussed here in terms of similar confidentiality requirements discussed here in terms of
"hiding" intermediate hops or interface address and/ or labels in "hiding" intermediate hops or interface address and/ or labels in
the transiting or peering SPs. the transiting or peering SPs.
5.2.2. Policy Control 5.2.2. Policy Control
In some cases, some policy control might be necessary at the AS In some cases, policy control might be necessary at the AS
boundaries, namely ingress policy controls enabling SPs to enforce boundaries, namely ingress policy controls enabling SPs to enforce
the inter-AS policies per interconnect agreements or modify some the inter-AS policies per interconnect agreements or modify some
requested parameters conveyed by incoming inter-AS MPLS TE signaling requested parameters conveyed by incoming inter-AS MPLS TE signaling
requests. requests.
It is worth noting that such policy control mechanism may also be It is worth noting that such policy control mechanism may also be
used between ASes within a SP. used between ASes within a SP.
This section only discusses the elements that may be used to form a This section only discusses the elements that may be used to form a
set of ingress control policies. However, how exactly SPs establish set of ingress control policies. However, how exactly SPs establish
skipping to change at line 1311 skipping to change at line 1311
etc.) etc.)
In addition, to achieve some degrees of granularity, SPs may choose 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 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 of inter-AS links for ingress traffic destined to certain PoPs or
regions within SP's network from another AS by tagging certain sets regions within SP's network from another AS by tagging certain sets
of routes with a specific attribute when announcing to another AS. of routes with a specific attribute when announcing to another AS.
This of course goes under the assumption that the other AS permits This of course goes under the assumption that the other AS permits
automated egress policy by matching the predefined attribute from automated egress policy by matching the predefined attribute from
incoming routes. incoming routes.
<x-flowed>
</x-flowed>
 End of changes. 

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