Internet Draft
MPLS Working group S. Dharanikota
Internet Traffic Engineering Working Group Nayna Networks
Internet Draft
Document: S. Venkatachalam
draft-dharanikota-interarea-mpls-te-ext-01.txt Alcatel USA
Category: Expiration
T. Nadeau
Cisco Systems, Inc.
OSPF, IS-IS, RSVP, CR-LDP extensions to support
inter-area traffic engineering using MPLS TE
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 except that the right to produce
derivative works is not granted.
This document is an Internet-Draft and is NOT offered in accordance
with Section 10 of RFC2026, and the author does not provide the IETF
with any rights other than to publish as an Internet-Draft
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.
1. Abstract
In this draft, we propose the extensions required to the routing
protocols, signaling protocols, and the MIB to support the idea of
inter-area LSPs. A companion document [INTER_AREA_REQ] provides the
architectural requirements for such a concept. This document also
provides the signaling extensions to support the crankback as defined
in the architecture document [INTER_AREA-REQ].
2. Notation and Conventions used in this document
ABR Area Border Router
ASBR Autonomous System Border Router
CR-LDP Constraint Based Routing LDP
CSPF Constraint-based Shortest Path First
ER Explicit Route
ERO Explicit Route Object
IACO Inter Area Criteria Object
IACUO Inter Area Criteria Used Object
IGP Interior Gateway Protocol
ISIS Intermediate System to Intermediate System
ISP Internet Service Provider
LDP Label Distribution Protocol
LER Label Edge Router
LSA Link State Attribute
LSR Label Switch Router
LSP Label Switched Path
MIB Management Information Base
MPLS Multi Protocol Label Switching
OSPF Open Shortest Path First
PDU Protocol Data Unit
PLRO Primary LSP Route Object
PRO Path Route Object
PV Path Vector
RSVP Resource Reservation Protocol
TBD To Be Defined
TE Traffic Engineering
TLV Type Length Value
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 RFC2119 [RFC2119].
3. Introduction
Current work in the MPLS traffic engineering group (such as
[TE_FRAMEWORK], [QOS_CONST]) focuses only on the intra-area LSP setup
issues. In this work we propose an architecture to extend the traffic
engineering capability across IGP areas and recommend relevant
modifications to the routing protocols, the signaling protocols and
the MIBs.
The ISPÆs networks are divided into Autonomous Systems (ASs), where
each AS is divided into Interior Gateway Protocol (IGP) areas to allow
the hiding and aggregating of routing information. Although this
concept of hierarchical routing by an IGP makes sense from the routing
perspective, it is a bottleneck for traffic engineering - as it hides
the path taken by a packet to destinations in the other routing areas.
Hence, from the Traffic Engineering (TE) perspective, requirements
such as path selection and crankback need different architectural
additions to the existing IGPs and signaling protocols for inter-area
Label Switched Path (LSP) setup.
Traffic engineering practice currently involves the setup and use of
LSPs as dedicated bandwidth pipes between two end points. LSPs can be
setup across several routers, either through the use of manually
specified routes, or routes that are computed. The routes can be
computed offline through the use of a dedicated tool, or through the
use of online constraint based routing using an IGP [IGP_REQ,
RSVP_EXT].
The offline tool will be centralized, and has the advantage of being
able to consider the traffic pattern history over a large period of
time, and hence will be efficient in optimizing the resources over
time, not just the particular instant when the request is received.
The offline traffic engineering tool, if also used for LSP setup in
addition to routing, may be able to optimize the resources across
LSPs. This would include mechanisms to tear down LSP segments and
reroute them when better resources become available or new requests
arrive.
The online constraint based routing model [IGP_REQ] requires (1) a
constraint based routing process implemented on certain Label Switched
Routers (LSRs) that serve as Label Edge Routers (LERs) to the LSPs,
and (2) a set of mechanisms to flood out and maintain the TE
characteristics of the topology.
From [TOOL_VS_RP] discussion, it is clear that traffic engineering can
be implemented with the help of tools and routing protocol extensions,
as initiated by [IGP_REQ]. Although there has been some work in the
area of realizing some of the issues such as TE crankback [CRANKBACK]
and DiffServ realizations [QOS_CONST], [QOS_TE_EXT], no work has been
performed that directly related to the inter-area extensions and a
framework for such in the TE working group.
In our solution, we propose to send across IGP areas, the summary
routes containing criteria-based route attributes, which will be used
at the Autonomous System Border Routers (ASBRs) in their TE path
computation. Since an off-line TE tool cannot compute the complete
explicit path from ASBR to ASBR unless it knows the complete routing
table of the AS, we expect to have loose path specification, which can
be translated into explicit path in-steps at the intermediate Area
Border Routers (ABRs). The solutions we are providing in this draft
are applicable to the destination networks inside the AS or outside
the AS. For the sake of simplicity we consider the customer networks
inside an autonomous system.
The companion document [INTER_AREA_REQ] presents the architectural
requirements for such a solution. In this document, the extensions to
provide such a solution of criteria-based inter-area routing are
separated into routing protocol extensions, signaling protocol
extensions and configuration extensions. In section 4, we present the
OSPF and IS-IS extensions. The signaling extensions for RSVP and CR-
LDP are presented in section 5. The configuration extensions for such
architectural changes are presented in section 6. Security
considerations, references and acknowledgements follow in sections 7,
8, and 9 respectively.
4. Routing protocol extensions
4.1 Intra-area requirements
OSPF or ISIS implementation SHOULD support the [INTRA_TE],
[ISIS_INTRA_TE] extensions to advertise and distribute the TE
information of the interfaces of the area. In addition, [QOS_TE_EXT]
may be supported to flood the bandwidth per class type of each
interface.
[INTRA_TE], [ISIS_INTRA_TE] defines the following TE attributes:
- Traffic engineering metric
- Maximum bandwidth
- Maximum reservable bandwidth
- Unreserved bandwidth
- Resource class/color
[QOS_TE_EXT] defines the unreserved bandwidth for different class
types.
Not all of the TE attributes specified in [INTRA_TE], [ISIS_INTRA_TE]
and [QOS_TE_EXT] need to be supported - in fact a subset may be chosen
that reflects the traffic engineering condition of the network and
does not impose a burden on the storage and flooding of the TE
information.
Specific to OSPF:
When a request for the setup of a constraint based LSP within the area
is received, a CSPF computation will be performed on the TE resources
of the area (as specified by the intra-area TE-LSAs) to determine the
best path that satisfies the constraints. The constraints on the LSP
can be one or more of the TE attributes flooded by OSPF in the intra-
area TE LSA.
Specific to ISIS:
When a request for the setup of a constraint based LSP within the area
is received, a CSPF computation will be performed on the TE resources
of the area (as specified by the intra-area TE-LSAs) to determine the
best path that satisfies the constraints of the LSP. The constraints
on the LSP can be one or more of the TE attributes flooded by ISIS in
the L1 extended IS reachability TE sub-TLVs.
4.2 Inter-area requirements
The route computation process uses the inter-area TE summary
information.
- to determine if a path to the inter-area destination that
satisfies the constraints does exist, and
- to determine the ABR to reach the next area.
TE attribute summarization is similar to the route summarization that
is already a part of OSPF or ISIS. The TE attributes can be summarized
through the use of a dijkstra based algorithm as described in section.
The value of the TE summary attribute to a destination advertised by
an ABR represents the TE resources of the best path available from the
ABR to that destination based on that TE attribute alone.
A separate route calculation is necessary to determine the summary
value for each TE attribute that needs to be summarized. Since these
route calculations are based on the intra-area TE attribute values,
the set of TE attributes to be summarized should be a subset of the
set of TE attributes supported inside the areas.
In the general case of TE attribute summarization, any number of TE
attributes such as bandwidth, delay to a destination can be
summarized. However, since a large number of TE attributes to be
summarized will result in an increase in processing required, the
number of TE attributes to be summarized should be kept small.
Specific to OSPF:
The summarized TE attributes will be distributed inside the areas by
the use of a new link state message (called TE summary LSA) as defined
in [INTER_TE_OSPF]. The definitions for the various TE attributes in
the TE summary LSA are also described in [INTER_TE_OSPF]. In addition
to those TE attributes, the following three TLVs are proposed to be
added in the TE summary LSA.
Specific to ISIS:
The summarized TE attributes will be distributed inside the areas by
extending the IP reachability TLV in the L1 and L2 link state PDU to
include TE sub-TLVs as described below.
4.3 Requirements for OSPF
4.3.1 Unreserved Bandwidth for CT1 to CT3
The unreserved bandwidth for class-types 1, 2 and 3 [QOS_CONST] to the
destination are each individually described in a TLV. The units is
bytes/second and the representation is IEEE floating point. The TLV
types are 7, 8, and 9, respectively and the length is 32 octets each.
4.4. Requirements for ISIS
4.4.1 Traffic Engineering Extensions to the IP Reachability TLV
This draft extends the IP Reachability TLV in the L1 and L2 link state
PDUs to allow the representation of TE information in the form of TE
sub-TLVs. Each TE sub-TLV in the IP Reachability TLV carries the type
and value of a traffic engineering attribute to the remote
destination.
An L2 link state PDU containing the IP reachability TLV with the TE
extensions will be originated by an L1/L2 router and flooded
throughout the L2 domain. This PDU will contain IP reachability TLV
with the TE sub-TLVs for each reachable address in the connected
areas. The value for each TE attribute will have been computed through
the use of a dijkstra based algorithm as detailed in the next section.
(This is the 'up' part of the redistribution as detailed in
[ISIS_TE]).
An L1 link state PDU containing the IP reachability TLV with the TE
extensions will be originated by an L1/L2 router and flooded
throughout its connected areas. This PDU will contain IP reachability
TLV with the TE sub-TLVs for each reachable address in a remote area.
(This is the 'down' part of the redistribution as detailed in
[ISIS_TE]).
4.4.2 Format of the IP reachability TLV with TE Sub-TLVs
The extended IP reachability TLV as described in [ISIS_TE] with TYPE =
135 is further extended with the addition of the TE sub-TLVs
describing the traffic engineering attributes to the destination
network.
Hence the IP reachability TLV has a structure as described in
[ISIS_TE], followed by zero or more TE sub-TLVs, each of which is of
the form:
No. of Octets
+---------------------------+
| CODE | 1
+---------------------------+
| LENGTH | 1
+---------------------------+
| VALUE | LENGTH
+---------------------------+
4.4.3 The Traffic Engineering Sub-TLVs
The following traffic engineering attributes are defined:
Sub-TLV type Length (octets) Name
3 4 Resource Class/Color
9 4 Maximum Bandwidth
10 4 Reservable Bandwidth
11 32 Unreserved Bandwidth
18 3 TE Default Metric
TBD 4 Delay
TBD 32 Unreserved Bandwidth for CT1
TBD 32 Unreserved Bandwidth for CT2
TBD 32 Unreserved Bandwidth for CT3
Most of these traffic engineering attributes have sizes and types the
same as in [ISIS_TE]. Note that new traffic engineering attributes and
sub-TLVs to represent them may be defined in the future. The TE
attributes are described below.
4.4.3.1 Resource Class/Color
The resource class or color of the destination network is a
combination of the colors for the various paths to the network. The
sub-TLV type of the resource class/color attribute is 3, and the
length is 4 octets.
4.4.3.2 Maximum Bandwidth
The maximum bandwidth to the destination is described in bytes/second
as an IEEE floating point number. The sub-TLV type is 9, and the
length is 4 octets.
4.4.3.3 Reservable Bandwidth
The reservable bandwidth to the destination is described in
bytes/second as an IEEE floating point number. The sub-TLV type is 10,
and the length is 4 octets.
4.4.3.4 Unreserved Bandwidth
The unreserved bandwidth to the destination is described in
bytes/second as an IEEE floating point number. The sub-TLV type is 11,
and the length is 4 octets.
4.4.3.5 Traffic Engineering Metric
The traffic engineering metric represents the traffic engineering cost
of reaching the destination network from the advertising L2 router.
The sub-TLV type is 18, and the length of this attribute is 3 octets.
4.4.3.6 Delay
The delay attribute is the delay cost to reach the destination network
in milliseconds, represented as an unsigned (4-byte) long integer. The
TLV-type is TBD, and the length is 4 octets.
4.4.3.7 Unreserved Bandwidth for CT1 to CT3
The unreserved bandwidth for class-types 1, 2 and 3 [QOS_CONST] to the
destination are each individually described in a sub-TLV. The units is
bytes/second and the representation is IEEE floating point. The sub-
TLV types are TBD, and the length is 4 octets.
4.5 Summarization of Traffic Engineering Attributes
The traffic engineering metric is an additive metric similar to the
OSPF/ISIS metrics, but need not be the same. The traffic engineering
and metric advertised by the router for the given summary destination
will have been computed in a manner similar to the dijkstra
computation for the OSPF/ISIS metric.
The delay is an additive metric. The value of the delay attribute for
a summary destination will have been determined through a dijkstra
computation based on the delay.
The maximum bandwidth to the summary destination is the largest of all
path-capacities, each associated with a possible path to the
destination. The path-capacity is the smallest link capacity of all
the links in the path. Hence, the maximum bandwidth is the maximum
amount of traffic that can be sent to that destination, when there is
no other traffic on the links.
The unreserved bandwidth to the summary destination is the largest of
all path-unreserved bandwidths, each associated with a possible path
to the destination. The path-unreserved bandwidth is the smallest
unreserved bandwidth of all the links in the path. Hence, the
unreserved bandwidth is the maximum amount of traffic that can
currently be sent to that destination, the other traffic on the links
being steady. The unreserved bandwidth for Class-Types 1, 2, and 3
[QOS_CONST] will be computed similarly.
The value of the color attribute to the summary destination is some
combination of the path-colors, each associated with a possible path
to the destination. The path-color is a combination of the colors of
the links in the path. This combination can be a "logical and" of the
colors, or a concatenation.
5. Signaling Extensions
The signaling protocol requirements for the setup of the inter-area
LSP are (as mentioned in [INTE_AREA_REQ]):
1. Signaling SHOULD be extended to carry the criteria based
elements, such as: Primary criteria (Attribute 1, ..., Attribute N);
Secondary criteria (Attribute 1, ..., Attribute N).
2. Signaling SHOULD trigger IGP computation for the explicit route
in an area at the transit ABRs. If the path, which satisfies the primary
criteria, is not available then it should trigger for the IGP computation
of the path for the secondary criteria.
3. It MAY inform the initiating node about the change the criteria
for the path set up in the intermediate path. This deliberate
notification can also be derived when the actual setup is completed.
4. The intermediate ABRs SHOULD know the difference between the
primary and the backup LSPs. This enables the signaling component to
distinguish between the paths taken by the primary LSP during the
computation of the backup LSP.
5. The same mechanisms used for the primary LSP setup SHOULD be used
for the backup LSP setup also.
6. Crankback in an area SHOULD always be performed from the starting
ABR of that LSP section. If the path is not available send the
information one area back and try to perform the computation.
5.1 RSVP extensions
In this section we describe extensions to RSVP for the support of
Inter-Area LSP setup as described in [INTER_AREA_REQ]. These
extensions are in addition to the extensions to RSVP as defined in
[RSVP_EXT] and includes attributes from [QOS_TE_EXT] [TE_FRAMEWORK] as
sub-objects.
Three new objects are introduced as follows:
- object (from now on is also abbreviated as
IACO) introduced to carry the primary and the secondary criteria in the
PATH message.
- object (from now on is also
abbreviated as IACUO) is introduced in the RESV message to capture the
route taken by the primary or the secondary PATH message.
- object (from now on abbreviated as PLRO) to
carry the path followed by the primary LSP in the PATH message.
In the following sections we also demonstrate different uses of ERO
(EXPLICIT ROUTE OBJECT) and RRO (RECORD ROUTE OBJECT) from the
[RSVP_EXT] draft. Note that constraint-related objects such as
as mentioned in [QOS_TE_EXT] can be sub-objects in the
IACO. The following table illustrates the objects discussed that are
relevant for this draft.
Object type Message Importance
--------------------------------------------------------------------
Path Mandatory
Resv Mandatory
Path Mandatory
Path Optional
Path Optional
Path Optional
Path, Resv Optional but recommended
5.1.1 PATH and RESV message format changes
The format of the Path message is changed as follows:
::=
[]
[]
[]
[] (For Primary Criteria)
[][]
[]
[] (For Secondary Criteria)
[][]
[]
[]
[ ... ]
[]
::= []
[]
[]
The format of the Resv message is changed as follows:
::=
[ ]
[] []
[...]