MPLS, Internet Traffic Engineering Sudheer Dharanikota
Internet Draft Senthil K. Venkatachalam
Category: Standards Track Alcatel USA
September 2000
OSPF, IS-IS, RSVP, CR-LDP Extensions to Support
Inter-Area Traffic Engineering Using MPLS TE
<draft-dharanikota-interarea-mpls-te-ext-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [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.
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_FWK] 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_FWK].
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 1]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
2. Notations 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.
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 2]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
The ISP's networks are divided into Autonomous Systems (ASs), where
each AS is divided into 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 TE perspective, requirements such as path
selection and crankback need different architectural additions to
the existing IGPs and signaling protocols for inter-area LSP setup.
Traffic engineering practice currently involves the setup and use of
Label Switched Paths (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 LSRs that
serve as 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 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 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.
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 3]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
The requirements of criteria-based inter-area routing are separated
into routing protocol requirements, signaling protocol requirements
and configuration requirements. 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 requirements for such
architectural changes are presented in section 6. Security
considerations, references and acknowledgements follow in sections
7, 8, and 9.
4. Routing protocol extensions
4.1 Intra-area requirements
OSPF or ISIS implementation SHOULD support the [OSPF_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.
[OSPF_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 [OSPF_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.
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 4]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
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 4.3. 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.
4.2.1 Requirements for 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 [OSPF_INTER_TE]. The definitions for the various TE
attributes in the TE summary LSA are also described in
[OSPF_INTER_TE]. In addition to those TE attributes, the following
three TLVs are proposed to be added in the TE summary LSA.
4.2.1.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
are 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.
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 5]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
4.2.2 Requirements for 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
[ISIS_ISO], [ISIS_IETF] to include TE sub-TLVs as described below.
4.2.2.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_INTRA_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_INTRA_TE]).
4.2.2.2 Format of the IP reachability TLV with TE Sub-TLVs
The extended IP reachability TLV as described in [ISIS_INTRA_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_INTRA_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
+---------------------------+
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 6]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
4.2.2.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_INTRA_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.2.2.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.2.2.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.2.2.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.2.2.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.
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 7]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
4.2.2.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.2.2.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.2.2.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.3 Inter-Area 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
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.
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 8]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
5. Signaling requirements
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_FWK]. 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:
- <INTER AREA CRITERIA> object (from now on is also abbreviated
as IACO) introduced to carry the primary and the secondary
criteria in the PATH message.
- <INTER AREA CRITERIA USED> 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.
- <PRIMARY LSP ROUTE> object (from now on abbreviated as PLRO) to
carry the path followed by the primary LSP in the PATH message.
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 9]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
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
<CLASSTYPE> 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
--------------------------------------------------------------------
<INTER AREA CRITERIA> Path Mandatory
<INTER AREA CRITERIA USED> Resv Mandatory
<PRIAMRY LSP ROUTE> Path Mandatory
<DIFFSERV><CLASSTYPE> Path Optional
<TE CONSTRAINTS> Path Optional
<EXPLICIT ROUTE> Path Optional
<RECORD ROUTE> Path, Resv Optional but
Recommended
5.1.1 PATH and RESV message format changes
The format of the Path message is changed as follows:
<Path Message> ::=
<Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[<EXPLICIT_ROUTE>]
<LABEL_REQUEST>
[<SESSION_ATTRIBUTE>]
[<INTER AREA CRITERIA>] (For Primary Criteria)
[<DIFFSERV>][<CLASSTYPE>]
[<TE CONSTRAINTS>]
[<INTER AREA CRITERIA>] (For Secondary Criteria)
[<DIFFSERV>][<CLASSTYPE>]
[<TE CONSTRAINTS>]
[<PRIMARY LSP ROUTE>]
[<POLICY_DATA> ... ]
[<sender descriptor>]
<sender descriptor> ::= <SENDER_TEMPLATE> [<SENDER_TSPEC>]
[<ADSPEC>]
[<RECORD_ROUTE>]
The format of the Resv message is changed as follows:
<Resv Message> ::=
<Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[<RESV_CONFIRM>] [<SCOPE>]
[<POLICY_DATA>...]
<STYLE> <flow descriptor list>
[<RECORD ROUTE>]
[<INTER AREA CRITERIA USED>]
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 10]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
5.1.2 Handling of the new objects
The following are the message formats for the new objects that are
introduced in this document.
INTER AREA CRITERIA Object (IACO):
+------------------------------------------------------------------+
| Length (12 bits) | C-Number = TBD | C-Type = 0 for Primary |
| | (8 bits) | (8 bits) 1 for Secondary|
+------------------------------------------------------------------+
| Attribute 1 - For example <DIFFSERV> <CLASSTYPE> and/or |
| <TE CONSTRAINTS> |
+------------------------------------------------------------------+
| .... |
| |
| Till Attribute N |
| |
+------------------------------------------------------------------+
C-Number:
To be defined by IANA
C-Type:
0 for the Primary Criteria
1 for the Secondary Criteria
Attribute:
Constraints from the traffic engineering related drafts.
INTER AREA CRITERIA USED Object (IACUO):
+------------------------------------------------------------------+
| Length | C-Number = TBD | C-Type = 0 for Primary |
| | (8 bits) | (8 bits) 1 for Secondary|
+------------------------------------------------------------------+
C-Number:
To be defined by IANA
C-Type:
0 for the Primary Criteria
1 for the Secondary Criteria
2 for none
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 11]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
PRIMARY LSP ROUTE Object (PLRO):
+------------------------------------------------------------------+
| Length = N*4 or 16 | C-Number = TBD | C-Type = 0 for IPV4 |
| | (8 bits) | (8 bits)1 for IPV6 |
| | | 2 for unavailable|
+------------------------------------------------------------------+
| IP Address 1 (V4 or V6) |
+------------------------------------------------------------------+
| .... |
| |
+------------------------------------------------------------------+
| IP Address N (V4 or V6) |
+------------------------------------------------------------------+
C-Number:
To be defined by IANA
C-Type:
0 for the IPV4 address
1 for the IPV6 address
2 for the unavailability of the objects.
The IACO can be used very effectively in conjunction with the ERO
and RRO objects. It is possible that the ERO and RRO options are
enabled to specify a preferred path and to know the path taken by
the LSP respectively.
The following list of cases we will illustrate the handling of the
IACO, IACUO, and PLRO objects in conjunction with the ERO and RRO
objects.
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 12]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
Case 1: IACO + ERO with strict route option: Here we can have
two situations in one case the primary fails and the other
in which both the primary and the secondary fail. The
following explain the operation:
i. Primary fails: Since the path is strict route a PATHErr
message will be sent to crankback to the nearest ABR in
the path with error code for "Primary Criteria Failed".
The ABR should attempt to setup the LSP with secondary
criteria.
ii. Primary and secondary fails: When both the primary and
the secondary fails the source of the LSP setup is
informed with the help of a PATHErr message with the
error code "Primary and Secondary Criteria Failed".
Case 2: IACO + ERO with loose source route option: Here also we
have the same situation as above except for the choice of
different path when either the primary or the secondary
fails. Also when both the primary and the secondary fail we
have to go only one previous ABR hop to recomputed the path
till the source is reached.
Case 3: IACUO with and without RRO: In the case of no RRO in
the RESV message the LSP initiating node (Ingress LER) will
not know the path taken by the primary LSP and hence backup
LSP may have overlapping LSP sections with the primary.
Where as when the RRO object is used, above problem can be
avoided, with the use of PLRO.
Case 4: With and without PLRO: When PLRO is present we can
avoid overlapping segments between the primary and the
backup LSPs.
5.1.3 Error conditions
The following are the error conditions
1 Primary Criteria Failed
2 Secondary Criteria Failed
3 Primary and Secondary Criteria Failed
4 Unknown Criteria
5 Unknown Object
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 13]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
5.2 CR-LDP extensions
In this section we describe extensions to CR-LDP for the support of
Inter-Area LSP setup as described in [INTER_AREA_FWK]. These
extensions are in addition to the extensions to CR-LDP as defined in
[CR_LDP] and includes the attributes from [QOS_TE_EXT],
[TE_FRAMEWORK] as sub-objects.
Three new objects are introduced as follows:
- <INTER AREA CRITERIA TLV> (from now on is also abbreviated as
IACO) introduced to carry the primary and the secondary
criteria in the Label Request message.
- <INTER AREA CRITERIA USED TLV> (from now on is also abbreviated
as IACUO) is introduced in the Label Mapping message to capture
the route taken by the primary or the secondary Label Request
message.
- <PRIMARY LSP ROUTE TLV> (from now on abbreviated as PLRO) to
carry the path followed by the primary LSP in the Label Request
message.
Note that constraint-related TLVs such as <CLASSTYPE> as mentioned
in [QOS_TE_EXT] can be sub-TLVs in the IACO. The following table
illustrates the objects discussed that are relevant for this draft.
Object type Message Importance
--------------------------------------------------------------------
<INTER AREA CRITERIA TLV> Label Request Mandatory
<INTER AREA CRITERIA USED TLV> Label Mapping Mandatory
<PRIAMRY LSP ROUTE TLV> Label Request Mandatory
<DIFFSERV TLV><CLASSTYPE TLV> Label Request Optional
<TE CONSTRAINTS TLV> Label Request Optional
<EXPLICIT ROUTE TLV> Label Request Optional
<PATH VECTOR TLV> Label Request/Mapping Optional (Recommended)
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 14]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
5.2.1 Label Request and Label Mapping messages Encoding
The encoding for the CR-LDP Label Request message is extended as
follows, to optionally include the Inter Area Criteria TLV (which
contains the Primary and Secondary Criteria TLVs) and Primary LSP
Route TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-LSP TLV (CR-LDP Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH VECTOR TLV (Optional but Recommended) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INTER AREA CRITERIA TLV (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRIAMRY LSP ROUTE TLV (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other CR-LDP TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding for the CR-LDP Label Mapping Message is extended as
follows, to optionally include the Inter Area Criteria Used TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Request Message ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSPID TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INTER AREA CRITERIA USED (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 15]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
5.2.2 Handling of the new objects
The following are the message formats for the new objects that are
introduced in this document.
The INTER AREA CRITERIA TLV has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| IACO TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRIMARY CRITERIA sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SECONDARY CRITERIA sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV has both the primary and the secondary criteria sub-TLVs.
Notice that the U and F bits are set to `0' to abort the connection
setup in case any LSP does not know how to use these mechanisms.
The PRIMARY/SECONDARY CRITERIA sub-TLV format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|PRIMARY/SECONDARY CRITERIA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DiffServ TLV (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class Type TLV (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Engineering TLV (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub TLV carries either the Primary or the Secondary criteria.
Each of these criteria has a list of constraints as exemplified in
the above message format. Also note that the U and F flags are set
to `0'.
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 16]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
The INTER AREA CRITERIA USED TLV has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| IACUO TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Used |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Inter Area Criteria Used TLV has a Criteria Used field "Used",
which will be set to:
0 for primary criteria,
1 for secondary criteria and
15 for none
PRIMARY LSP ROUTE TLV format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|PRIMARY LSP ROUTE TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4/ IPV6 HOP 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4/ IPV6 HOP N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV contains the path taken by the Primary LSP. It can have
IPV4 or IPV6 address hops taken by this path.
The IACO can be used very effectively in conjunction with the
Explicit Route (ER) TLV and Path Vector (PV) TLV. It is possible
that the ER TLV and PV TLV options are enabled to specify preferred
path and to know the path taken by the LSP respectively.
The following list of cases we will illustrate the handling of the
IACO, IACUO, and PLRO TLVs in conjunction with the ER TLV and PR
TLV.
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 17]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
Case 1: IACO + ER TLV with strict route option: Here we can
have two situations in one case the primary fails and the
other in which both the primary and the secondary fail. The
following explain the operation:
i. Primary fails: Since the path is strict route a LDP
Notification message will be sent to crankback to the
nearest ABR in the path with error code for "Primary
Criteria Failed". The ABR should attempt to setup the
LSP with secondary criteria.
ii. Primary and secondary fails: When both the primary and
the secondary fails the source of the LSP setup is
informed with the help of a LDP Notification message
with the error code "Primary and Secondary Criteria
Failed".
Case 2: IACO + ER TLV with loose source route option: Here also
we have the same situation as above except for the choice of
different path when either the primary or the secondary
fails. Also when both the primary and the secondary fail we
have to go only one previous ABR hop to recomputed the path
till the source is reached.
Case 3: IACUO with and without PV TLV: In the case of no PV TLV
in the LDP Mapping message the LSP initiating node (Ingress
LER) will not know the path taken by the primary LSP and
hence backup LSP may have overlapping LSP sections with the
primary. Where as when the PV TLV is used, above problem can
be avoided, with the use of PLRO.
Case 4: With and without PLRO: When PLRO is present we can
avoid overlapping segments between the primary and the
secondary LSPs.
5.2.3 Status codes for the inter-area LSP setup
In the procedures described above, certain errors must be reported.
The following values are defined for the Status Code field of the
Status Code E Status Data
Primary Criteria Failed 0 TBD
Secondary Criteria Failed 0 TBD
Primary and Secondary Criteria Failed 0 TBD
Unknown Criteria 0 TBD
Unknown TLV 0 TBD
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 18]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
6. MIB requirements (TBD)
The configuration requirements for such architecture can be divided
into:
- Routing configuration, such as criteria filtering, criteria-
constraint mapping, route filtering for criteria summarization
etc.
- LSP Setup configuration, such as primary criteria and backup
criteria etc.
- Signaling configuration, such as the criteria change in the
intermediate segment notification, crankback in-progress
notification required etc.
These configuration information will be further elaborated in the
later versions of this draft.
7. Security Considerations (TBD)
8. References
[RFC2026] S. Bradner, "The Internet Standards Process Revision 3,"
BCP 9, RFC 2026.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC2119.
[IGP_REQ] T. Li, G. Swallow, D. Awduche, "IGP Requirements for
Traffic Engineering with MPLS," <draft-li-mpls-igp-00.txt>
[CRANKBACK] A. Iwata, N. Fujita, G. Ash, "Crankback Routing
Extensions for CR-LDP," <draft-fujita-mpls-crldp-crankback-01.txt>
[TOOL_VS_RP] "Internet Traffic Engineering working group mailing
list discussion on centralized tool based TE versus constraint-based
routing protocol extensions," ftp://ftpext.eng.uu.net/tewg
[QOS_CONST] F. Le Faucheur et al., "Requirements for support of
DiffServ-aware MPLS Traffic Engineering," <draft-lefaucheur-diff-te-
reqts-00.txt>
[QOS_TE_EXT] F. Le Faucheus et al., "Extensions to IS-IS, OSPF, RSVP
and CR-LDP for support of DiffServ-aware MPLS Traffic Engineering,"
<draft-lefaucheur-diff-te-ext-00.txt>
[OSPF_INTRA_TE] D. Katz, D. Yeung, "Traffic Engineering Extensions to
OSPF," <draft-katz-yeung-ospf-traffic-01.txt>
[INTER_AREA_FWK] S. Venkatachalam, S. Dharanikota, "A frame work for
the LSP setup across IGP areas for MPLS traffic engineering,"
<draft-venkatachalam-interarea-mpls-te-00.txt>
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 19]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000
[TE_FRAMEWORK] D. O. Awduche, et al., "A Framework for internet
Traffic Engineering," <draft-ietf-tewg-framework-02.txt>
[RSVP_EXT] D. Awduche et al., "Extensions to RSVP for LSP Tunnels,"
<draft-ietf-mpls-rsvp-lsp-tunnel-04.txt>
[OSPF_INTER_TE] S. Venkatachalam, and B. Abarbanel, "OSPF Extensions
to Support Inter-Area Traffic Engineering," <draft-venkatachalam-
ospf-traffic-00.txt >
[CR-LDP] B. Jamoussi et al., "Constraint-Based LSP Setup using LDP,"
<draft-ietf-mpls-cr-ldp-03.txt>
[ISIS_ISO] "Intermediate System to Intermediate System Intra-Domain
Routeing Exchange Protocol for use in Conjunction with the Protocol
for Providing the Connectionless-mode Network Service (ISO 8473),"
ISO DP 10589, February 1990.
[ISIS_IETF] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments," RFC 1195.
[ISIS_INTRA_TE] H. Smit, and T. Li, "IS-IS Extensions for Traffic
Engineering," <draft-ietf-isis-traffic-01.txt>
9. Author's Addresses
Sudheer Dharanikota
Alcatel USA
45195 Business Court, Suite 400
Dulles, VA 20166
Phone: (703)654-8631
Email: Sudheer.Dharanikota@usa.alcatel.com
Senthil Venkatachalam
Alcatel USA
45195 Business Court, Suite 400
Dulles, VA 20166
Phone: (703)654-8635
Email: Senthil.Venkatachalam@usa.alcatel.com
S. Dharanikota, S. Venkatachalam Expires March 2001 [Page 20]
Internet Draft draft-dharanikota-interarea-mpls-te-ext-00.txt Sept. 2000