---- ----- ----- ----- -----
| CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- -----
+SP1 Customer ASx+ +-----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 ASx+ +------SP2 AS2---+ +--SP1 AS1-----+
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 the
establishment of MPLS TE tunnel from CE1 to CE2 end-to-end across
several SPs’ networks.
<======================Inter-AS MPLS TE Tunnel==================>
--- ----- ----- ----- ----- ---
|CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2|
| | | PE | | RTR | Link | RTR | | PE | | |
--- ----- ----- ----- ----- ---
+Cust ASx+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASy+
The diagram below illustrates another example where CE1 and CE2 are
customers of SP1 with external BGP (eBGP) peering relationships
established across the CE-PE links. An inter-AS MPLS TE tunnel may
then be established from CE1 in ASx to CE2, which may belong to the
same AS or a 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 ASx-+ +-------------SP1 AS2----------------+ +-Cust ASy-+
The above example shows that SP1’s network has a single AS.
Obviously, there may be multiple ASes between CE1 and CE2, as well as
in the SP1’s network.
In addition, where both CE1 and CE2 reside in the same AS, they will
likely share the same private AS number.
However, Scenario III will not scale well if there is a greater
number of inter-AS TE MPLS tunnels in some degrees of partial mesh or
full mesh. Therefore, it is expected that this scenario will have
few deployments, unless some mechanisms such as hierarchical intra-AS
TE-LSPs are used to reduce the number of signaling states.
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 value 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 path computation algorithms.
From a service provider’s perspective, another way of stating the
objectives of traffic engineering is to utilize available capacity in
the network for delivering customer traffic without violating
performance targets, and/or to provide better QoS services via an
improved network utilization, more likely operating 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), it may not require more scalable and granular TE
facilities beyond BGP routing policies. This is because such
policies can 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 those with sparsely connected networks, have
designed their multi-AS routing policies 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 as a whole, rather than partially.
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 diagram
below:
<===================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 to transport a set of L2 Pseudo Wires or VoIP traffic
with corresponding bandwidth 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.
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 Engineering
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 the current intra-AS MPLS TE
mechanism and inherit its capability sets from [TE-RSVP].
The proposed solution SHOULD allow the provisioning of a TE LSP at
the Head/Tail-end with end-to-end Resource Reservation Protocol
(RSVP) signaling (eventually with loose paths) traversing across the
interconnected ASBRs, without further provisioning required along the
transit path.
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 ASes, ASBRs, and inter-AS
links.
The proposed solution SHOULD provide the ability either to select
explicitly or to auto-discover the following elements when signaling
the inter-AS TE LSP path:
- a set of AS numbers as loose hops and/or
- a set of LSRs including ASBRs
It should also specify the above elements in the Explicit Route
Object (ERO) and record them in the Record Route Object (RRO) of the
Resv message just to keep track of the set of ASes or ASBRs traversed
by the inter-AS TE LSP.
In the case of establishing inter-AS TE LSP traversing multiple ASes
within the same SP networks, the solution SHOULD also allow the
Head-end LSR to explicitly specify the hops across any one of the
transiting ASes and the TE tunnel Head-end SHOULD also check the
explicit segment to make sure that the constraints are met.
In addition, the proposed solution SHOULD provide the ability to
specify and signal that certain loose or explicit nodes (e.g., AS
numbers, etc.) and resources are to be explicitly excluded in the
inter-AS TE LSP path establishment, such as one defined in
[EXCLUDE-ROUTE].
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
follows 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.
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 allow
for reduced optimality (or sub-optimality) since the path may not
remain optimal for the lifetime of the LSP.
5.1.4. Support of Diversely Routed Inter-AS TE LSP
Setting up multiple inter-AS TE LSPs between a pair of LSRs might be
desirable when:
(1) a single TE LSP satisfying the required set of constraints
cannot be found, in which case it may require load sharing;
(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 the ASes, the solution
MUST be able to re-optimize the LSP accordingly and non-disruptively,
either upon expiration of a configurable timer or upon being
triggered by a network event or a manual request at the TE tunnel
Head-End.
The solution 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 of the ASes.
In the case of an identical set of traversed paths, the solution
SHOULD provide an option for the Head-End LSRs to control whether
re-optimization will occur because there could exist a more optimal
path in one of the transit ASes along the inter-AS TE LSP path.
Furthermore, the solution MUST provide the ability to reject 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
pairs of ASBRs for redundancy. The topological density between ASes
in a SP network with multi-ASes is generally much higher. In the
event of an inter-AS link failure, rapid local protection SHOULD also
be made available and SHOULD interoperate with the current intra-AS
MPLS TE fast re-route mechanism from [TE-FRR].
The traffic routed onto an inter-AS TE tunnel SHOULD also be fast
protected against any node failure where the node could be internal
to an AS or at the AS boundary.
5.1.7. DS-TE Support
The proposed inter-AS MPLS TE solution SHOULD satisfy core
requirements documented in [DS-TE].
It is worth pointing out that the compatibility clause in section 4.1
of [DS-TE] SHOULD also be faithfully applied to the solution
development.
5.1.8. Scalability and Hierarchical LSP Support
The proposed solution(s) MUST have a minimum impact on network
scalability from both intra- and inter-AS perspectives.
This requirement applies to all of the following:
- IGP (impact in terms of IGP flooding, path computation, etc.)
- BGP (impact in terms of additional information carried within
BGP, number of routes, flaps, overload events, etc.)
- RSVP TE (impact in terms of message rate, number of retained
states, etc.)
It is also 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(s). One such mechanism, for example, is
described in [MPLS-LSPHIE].
5.1.9. Mapping of Traffic onto Inter-AS MPLS TE Tunnels
There SHOULD be several possibilities to map 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.
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)
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 Management Information Base (MIB) is required for use
with network management protocols by SPs to manage and configure
inter-AS traffic engineering tunnels. This new MIB SHOULD extend
(and not reinvent) the existing MIBs to accommodate this new
functionality.
An inter-AS TE MIB should have features that include:
- 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 head-end, 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 sub-objects 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, an 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.
However, the above example 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 hierarchical MPLS
networks, and such a facility as this SHOULD also be extended to