One document matched: draft-boyle-tewg-interarea-reqts-01.txt
Differences from draft-boyle-tewg-interarea-reqts-00.txt
IETF Internet Draft Jim Boyle, PDNETS
Document: draft-boyle-tewg-interarea-reqts-01.txt December 2003
Requirements for support of Inter-Area
MPLS Traffic Engineering
Status of this Memo
This document is an Internet-Draft and is subject to 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract:
Traffic engineering using MPLS within a single IGP area has become
quite prevalent in networks today. This gives a network operator
several advantages, including better traffic measurement
capabilities, faster restoration times, and of course the ability
to better manage congestion points within their network. However,
the current uses have been limited to one IGP area. OSPF based
networks usually do traffic engineering only in their backbone
area, and many ISIS networks still operate at a single level. It
would be useful to be able to extend these capabilities across
hierarchical areas within a single IGP, as well as to be able to
extend across AS boundaries if it is found to be useful and
possible. This document first considers current applications of
MPLS traffic engineering (TE), and then it addresses how these
might be used (or precluded) across IGP areas. For the purposes
of this document, IGP areas refers both to OSPF areas and ISIS
multi-level hierarchies. Requirements for Inter-AS TE can be
found in [INTER-AS-TE].
Please direct comments on this document to te-wg@ops.ietf.org
Boyle 1
Requirements for Inter-Area TE December 2003
Table of Contents
1.... Current uses of MPLS Traffic Engineering
1.1.. Fundamental functionalities
1.1.1 MPLS LSPs used for Tunneling
1.2.. MPLS TE and routing
1.3.. Intra-area Protection
1.4.. Diffserv and TE
2.... General Requirements
3.... Inter-area requirements
3.1.. Inter-Area Path Selection
3.2.. Inter-area MPLS TE and routing
3.3.. Inter-area MPLS TE and Protection
3.4.. Diffserv and Inter-area MPLS TE
4.... Security Considerations
5.... Acknowledgments
6.... References
7.... Author's Address
1. Current uses of MPLS Traffic Engineering
1.1 Fundamental functionalities
There are a number of primitives that are specified [RSVP-LSP]
[RSVP-OSPF] and useful in MPLS TE. Some are itemized here and
revisited when discussing how they might be needed or useful for
inter-area MPLS TE.
a) bandwidth specification - allows the sender to specify how much
bandwidth is required for an MPLS LSP. This is done in the
Tspec.
b) priorities - allows prioritization of access to link bandwidth.
Priorities for setup and hold may be specified, though it is a
common practice to set these to be equal, when specified.
c) ERO - This allows the source to specify the route an LSP should
take. The specification is often a strict route determined by
the source during path selection, however the protocol allows
for loose hops that an LSP should be routed toward hop-by-hop.
d) RRO - A sender can request that the route an LSP takes is
confirmed during the reservation process by inserting a record
route object. The semantics of this are the same as the ERO.
e) protection requested - Different protection techniques are
possible, and the ability to use these is controlled by the
source of the LSP [PROTECTION].
Boyle 2
Requirements for Inter-Area TE December 2003
f) resource affinities - Links can be assigned to administrative
groups and these can be taken into account when selecting a
path. The administrative constraints of an LSP are also
signaled in the session object of the LSP.
Also, different reservation styles can be used, including
shared-explicit which allows for make-before-break functionality
during bandwidth and path changes on an LSP. The source is able to
specify that shared-explicit is requested in the session object of
the LSP.
The fact that all traffic for the LSP is consolidated into one
tunnel makes measurement of macroscopic flows much easier than with
traditional IP routing. This is also an advantage network
operators find in using MPLS TE.
1.1.1 MPLS LSPs used for Tunneling
In addition to the carriage of plain, globally routable IPv4
traffic, MPLS is often used to carry VPN traffic between ports of a
network. This may be a customer's private IPv4, ATM, Frame Relay
or Ethernet traffic. The two endpoints agree on what is in the
tunnel via configuration or additional signaling [RFC2547]
[MARTINI]. This is one of the strongest current drivers for new
deployments of MPLS. It is also one of the strongest drivers for
the need to push MPLS TE across area boundaries, as connectivity is
required between network edges.
1.2 MPLS TE and routing
At its simplest, MPLS TE allows for the connection between two
routers and the tunneling of traffic between them. This might be
done for the purposes of measurement, transport of VPN traffic, or
to provide a quicker restoration of traffic flow during different
failure scenarios. In this mode, the only traffic introduced onto
the tunnel is traffic for the destination. For instance, in the
following topology if there is an LSP from M1-to-N2, only traffic
going through M1 with N2 as its final destination would end up on
the LSP.
M3--M1--------------N1
\/ | / \
/\ | / \
M4--M2----------N2-----N3
Boyle 3
Requirements for Inter-Area TE December 2003
Alternate approaches modify the IGP's shortest path selection
algorithm. In this case, if the IGP's shortest paths from M1 are
as follows:
M3--M1--------------N1
/ | \
/ | \
M4 M2----------N2 N3
Then an LSP from M1-to-N2 might create a shortcut such that the
path M1-to-N2 plus the cost of the link from N2 to N3 might be
better than M1-N1-N3 path, so traffic hitting M1 and going to N3
would end up the LSP M1-to-N2. Another implementation might only
use the LSP for IGP destinations that naturally fall beyond the LSP
destination on the shortest path tree. In the above example,
M1-to-N2 would not be used for N3, however an LSP from M1-to-N1
would include traffic to N3.
Another common approach is to treat these LSPs as forwarding
adjacencies which are included in the LSP source's IGP
advertisement [FA-LSP]. In this case, traffic from other nodes can
be drawn toward a node with an LSP. For example, if the IGP
shortest path tree from M4's perspective is the following:
M3--M1--------------N1
/
/
M4--M2----------N2-----N3
If the LSP M1-to-N2 is advertised back into the IGP with the right
cost, this might modify M4's tree to be as follows:
M3--M1--------------N1
/ \________
/ \
M4--M2 N2-----N3
These are all useful ways to incorporate MPLS into routing with
intra-area LSPs.
In summary, MPLS LSPs are used in intra-area TE in the following ways.
1) When traffic goes through the source and is to the destination
of the LSP
2) When traffic goes through the source and is to the destination
of the LSP or somewhere beyond this destination from an IGP SPF
perspective.
3) The LSP is introduced into the IGP to become part of the path
Boyle 4
Requirements for Inter-Area TE December 2003
consideration for all nodes with visibility into the
advertisement.
1.3 Intra-area Protection
MPLS allows for a variety of approaches to speed up traffic
restoration when there is a failure within a network (especially
link-based failures). Common approaches include having two LSPs (a
working and protect) on separate paths, as well as using MPLS
signaling to setup more advanced protection schemes. [PROTECTION]
outlines that LSPs may be protected in several approaches. For
each LSP, a detour LSP may be routed toward the destination but
avoiding the next node (and link). These detours may merge back
into the main LSP. Alternatively, an LSP can be established for a
given link and if there is a failure of that link, all LSPs that
were active on the failed link are switched into the backup LSP.
These are both approaches that have found use in today's MPLS
networks.
1.4 Diffserv and TE
The MPLS label allows for a CoS value to be used within the "Exp"
bits, and this can be used to affect the proper queuing for the
packet. This is termed a label-inferred diffserv LSP (L-LSP) in
[DIFFSERV-LSP]. An explicit object can also be used to specify the
diffserv class of traffic that the LSP is limited to, and that can
be used to treat the LSP accordingly. Other approaches are being
developed to allow more intimacy with diffserv and route selection,
this is termed Diffserv TE, and is specified in [DIFF-TE]. One
thing to note about Diffserv TE, besides its pre-emergent state at
this time, is that many of the semantics are abstract and inferred
by configuration. For instance, Class-Type 0, 1 and 2 are often
correlated to Best Effort, Assured Forwarding and Expedited
Forwarding, however that is only from convention and the protocol
allows much more flexibility to achieve the requirements of the
network operator.
2. General Requirements
As outlined in section 1, there are many uses of MPLS TE today,
though it is mostly constrained to a single IGP area. Some of the
information available in the routing domain of a single area is so
condensed when an area boundary is crossed that some of the
functionality could be sharply curtailed. For example, the absence
of edge to edge link state topology information makes complete
explicit route discovery impossible. However, it might still be
useful, especially for transporting of VPN traffic from edge to
edge of a network (for inter-area). Other current TE uses may be
more difficult to achieve inter-area due to the lack of ability to
integrate an MPLS LSP into an inter-area routing scheme. For
Boyle 5
Requirements for Inter-Area TE December 2003
instance, interconnection of a hosting center to a significant
peering router in another area may be useful for traffic
quantification, explicit route usage, or interaction with EBGP
route selection. However this may have to be done from edge router
to edge router. It might be impossible to introduce an LSP that
originates in one area into the routing such that traffic to
another area is drawn towards it. Currently, this sort of topology
manipulation is possible within a single area.
It might be possible to achieve limited results and this document
attempts to specify some constraints that might be useful
guidelines.
There are several reasons that network operators choose to break up
their network into different areas. These often include
scalability and containment of routing information. The latter can
help isolate most of a network from receiving and processing
updates that are of no consequence to its routing decisions. In
fact, whole routers can be taken down in an area without any router
outside of that area being aware. Scalability and containment of
routing information should not be compromised to allow inter-area
traffic engineering. In fact, to the extent possible, information
propagation for path-selection should continue to be localized.
Additionally, The base specification of MPLS TE is architecturally
structured and relatively devoid of excessive state propagation in
terms of routing or signaling. Its strength in extensibility can
also be seen as an Achilles heel, as there is really no limit to
what is possible with extensions. It is paramount to maintain
architectural vision and discretion when adapting it for use for
inter-area and inter-as TE. Additional information carried within
an area, or propagated outside of an area (via routing or
signaling) should neither be excessive, patchwork, nor
non-relevant.
For these reasons, the solution should stress scalability and
generality over piece-meal point application extensions or overly
comprehensive approaches that deliver more than may be necessary at
this time.
3. Inter-area requirements
All of the features outlined in section 1 can be assumed to have
the same meaning and semantics in different areas of a multi-area
IGP.
For instance, an affinity of "international" (0x1) in one area can
be assumed to be "international" in a different area. Most of the
primitives used for intra-area path selection are propagated in the
session object of an RSVP LSP.
Boyle 6
Requirements for Inter-Area TE December 2003
Therefore, all of the functionalities outlined in section 1.1 are
possible and necessary for support in inter-area MPLS TE.
3.1 Inter-Area Path Selection
Obviously some functions such as a full route selection for an ERO
will not be possible across area boundaries. For this reason, and
since the most necessary primitives for route selection are
propagated within an LSPs Path message, an approach of ERO route
expansion is suggested as the best approach for inter-area LSP
establishment. An alternate approach of propagation of sufficient
topology information to make a complete path determination is not
recommended due to the additional information required as well as
the incongruence of this approach with the overall containment
provided by the network hierarchy. The alignment of these is
mentioned as a goal in section 2.
In overview, the requirements below call for what may be called a
crankback method which employs head end direction for regional
optimization.
A source should specify a strict ERO to an egress point of its area
with the next hop being at a minimum the destination for the LSP.
The area border router will expand this ERO to the destination (or
its border router if the destination is more than one area away
from the source). When insufficient topology exist at a route
expansion at a border router, a Path Error message will be sent to
the source, who may attempt to establish the LSP through another
border router. Similarly, when the source is more than one area
away from the destination, the destination's border router may send
back a Path Error. Ideally, the source's border router would try
another border router into the destination's area, however with
current protocol, the Path Error will propagate to the source. The
source now needs to know if it should try again at the border
router of the source's area. This is the challenge of inter-area
traffic engineered LSP establishment
A solution is needed which elegantly and efficiently allows for the
LSP to be routed through the best pair of border routers. As these
may change over time, there is a need to show how border-router
optimization is handled.
Additionally, more optimal routes may become available within an
area. To the extent possible, optimization of the LSP onto these
routes should be possible, potentially without impacting state in
other areas. The head-end of the LSP should be able to have
control on the candidacy of an LSP for optimization in a remote
area.
Boyle 7
Requirements for Inter-Area TE December 2003
3.2 Inter-area MPLS TE and routing
Clearly an inter-area LSP can be used to carry traffic that is
destined for the destination of the LSP. (item (1) at the end of
section 1.2).
Much information may also be present which allows other traffic to
be included in the LSP. Area border routers propagate information
for more than their directly attached interfaces. In OSPF, network
summary LSAs are sent throughout the network by ABRs (and external
networks are propagated by ASBRs). This information allows the LSP
also to be used to reach networks beyond an LSP to a border router
or an ASBR (item (2) at the end of section 1.2).
However, it may be difficult to allow the existence of an LSP (or
two from source to destination and vice-versa) to attract traffic
to an LSP's source. The only way that might work would be to
mirror existing network summary and external advertisements.
However since these can flood throughout a network, they could have
a severe impact on IGP database size. Incorporation of LSPs back
into routing across areas is not currently required and is not
recommended outside of experimental investigation. (item 3 at the
end of section 1.2)
3.3 Inter-area MPLS TE and Protection
Facility protection of a single link is necessarily intra-area and
not applicable to inter-area discussions.
Per-path protection is necessary and can hopefully use the same
path establishment mechanisms (along with necessary REROUTE and
DETOUR objects) to achieve the same restoration levels as are
achieved within an area.
Since the complete ERO may not be present, there may not be
sufficient information to initially calculate a valid detour for
all cases. However, a minimization of protocol modifications and
state propagation may still be desired, even if it came at the
expense of delayed detour establishment. For instance, one
approach might be to wait for an LSP's RRO to help craft a detour
which explicitly merges back into the main LSP quickly after the
area boundary. Or an approach might be to simply try a detour
through the next most reasonable ABR. The LSP will likely merge
back in naturally, however there can be some topologies where the
backup ABR can not expand the path without avoiding one of the
nodes listed in the DETOUR object.
3.4 Diffserv and Inter-area MPLS TE
Just as session specific parameters such as affinities are assumed
Boyle 8
Requirements for Inter-Area TE December 2003
to be consistent within one IGP, the same can be said for diffserv
support on an LSP. COS mappings on L-LSPs are expected to be
consistent, and E-LSPs are explicitly interpreted by definition.
Diffserv TE should be directly translatable at border-routers, as
the class-type of an LSP is explicit for class-types greater than 0
and not-existent in the path message for class-type 0.
4. Security Considerations
None.
5. Acknowledgments
Thanks to Craig Pierantozzi, Laura Cunningham and Jerry Ash, whose
feedback and editorial review have helped refine this document.
6. References
[DIFF-TE] draft-ietf-tewg-diff-te-proto-05.txt
[DIFFSERV-LSP] RFC3270
[FA-LSP] draft-ietf-mpls-lsp-hierarchy-08.txt
[INTER-AS-TE] draft-ietf-tewg-interas-mpls-te-req-02.txt
[MARTINI] draft-martini-l2circuit-trans-mpls-11.txt
[PROTECTION] draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt
[RFC2547] RFC2547
[RSVP-LSP] RFC3209
[RSVP-OSPF] RFC3630
7. Author's Address
Jim Boyle
Email: jboyle@pdnets.com
| PAFTECH AB 2003-2026 | 2026-04-23 17:56:21 |