OSPF W. Lu
Internet-Draft Ericsson
Intended status: Standards Track July 9, 2011
Expires: January 10, 2012
OSPF TE Extension for Area IDs
draft-lu-ospf-area-tlv-01
Abstract
For multi-area path computation, it is desirable to have knowledge of
area boundaries and the corresponding border routers which are
capable of processing inter-area TE traffic. This memo defines a TLV
to the OSPF TE extensions to meet such need.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 10, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Lu Expires January 10, 2012 [Page 1]
Internet-Draft OSPF TE Extension for Area IDs July 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Current Solutions . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Global TED . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2. Stitch . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.3. Crankback . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4. Distributed Path Computation . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.4. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Exit Area . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. TE-ABR . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. The importance of ABR whereabouts . . . . . . . . . . . . 6
3.2. Topic not Yet Addressed . . . . . . . . . . . . . . . . . 6
3.3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Scope of the proposal . . . . . . . . . . . . . . . . . . . . 7
5. Area ID TLV . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. TLV Origination Point . . . . . . . . . . . . . . . . . . 8
5.2. TLV encoding . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Use-Case 1 . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1.1. Crankback approach . . . . . . . . . . . . . . . . . . 10
6.1.2. BRPC approach . . . . . . . . . . . . . . . . . . . . 10
6.2. Use-Case 2 . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Lu Expires January 10, 2012 [Page 2]
Internet-Draft OSPF TE Extension for Area IDs July 2011
1. Introduction
1.1. Background
Traffic Engineering (TE) based networks are widely used by network
operators. The provision and setup mechanisms work fine in a single
IGP area thanks to the well defined TE extensions to the
corresponding protocols, namely RSVP-TE [RFC3209], OSPF-TE [RFC3630],
and ISIS-TE [RFC3784]. From the single area TE database, LSPs can be
derived to meet various TE constraints using some Path Computation
Element (PCE) methods such as CSPF.
The mechanisms however cannot be applied directly to multi-area
networks, for which the path computation is one of the key
applications of the PCE-based architecture [RFC4655].
It is highly desirable to compute inter-area shortest paths that
satisfy some bandwidth constraints or any other constraints, with
little manual intervention, as is possible within a single IGP area.
1.2. Current Solutions
Listed below are a few existing inter-area path computation
mechanisms. As can be seen the ABR whereabouts are indispensable in
computing inter-area LSPs.
1.2.1. Global TED
A single TE database that contains all TE information of each and
every area/domain is called the global TED. This certainly makes it
easy to compute shortest path LSPs that meet all constraint
requirements. The drawbacks nevertheless are apparent:
a. IGP hierarchy enables improved IGP scalability by dividing the
IGP domain into areas and limiting the flooding scope of topology
information to within area boundaries. The global TED goes
against this principle.
b. Even if one is willing to compromise this principle, the LSPs
created upon this global TED would lack of area information which
may be required for enforcing path selection policies.
1.2.2. Stitch
This method uses per-area path computation based on ERO expansion on
the head-end LSR and on ABRs. ABRs can be selected through either:
Lu Expires January 10, 2012 [Page 3]
Internet-Draft OSPF TE Extension for Area IDs July 2011
a. Static configuration of ABRs as loose hops at the head-end LSR;
b. Dynamic ABR selection - Proprietary, knowledge of ABRs may be
aquired through non-standard protocol modification.
1.2.3. Crankback
Crankback method defined in [RFC4920] allows an LSP to be constructed
to beyond the area scope provided some intermediate nodes, i.e.
ABRs, are known. Crankback can probe the ABRs one after another till
a viable path is found if it exists.
Note that this method does not allow computing an optimal path but
just a feasible path. It may also have some non-negligible setup
delay. These issues nevertheless are beyond the scope of this
document.
1.2.4. Distributed Path Computation
PCE architecture document [RFC4655] outlines a distributed PCE
architecture. The idea is that various PCEs which have partial
information of the topologies work together to conclude the best
paths that meet the computation constraint requirements.
Individual PCEs may not have any visibility beyond the areas they are
servicing. For inter-area path computation purpose, the knowledge of
ABRs are essential for the neighboring PCEs to find out the overall
best path over the combined areas.
BRPC as defined in [RFC5441] provides one of such methods. OSPF-CAP
[RFC5088] on the other hand defines methods to make known distributed
PCEs using OSPF capability TLVs.
Note that although [RFC5088] contains PCE-DOMAIN sub-TLV for OSPF
Area ID, it however cannot be used for identifying area border LSRs.
It is for locating PCEs, not LSRs.
1.3. Requirements Language
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 RFC 2119 [RFC2119].
1.4. Acronyms
Lu Expires January 10, 2012 [Page 4]
Internet-Draft OSPF TE Extension for Area IDs July 2011
ABR - Area Border Router
BRPC - Backward-Recursive Path Computation
CSPF - Constrained Shortest Path First
IGP - Interior Gateway Protocol
LSA - Link State Advertisement
LSDB - Link-State DataBase
LSP - Label Switched Path
LSR - Label Switching Router
OSPF - Open Shortest Path First
PCC - Path Computation Client
PCE - Path Computation Element
TE - Traffic Engineering
TED - Traffic Engineering Database
TLV - Type Length Value
VSPT - Virtual Shortest Path Tree
2. Definitions
The following definitions are under the context where TE is enabled.
2.1. Exit Area
A neighboring OSPF area to which an inter-area path can possibly be
extended is called Exit Area.
The ABR which connects the current area to an Exit Area is called
exit ABR.
2.2. TE-ABR
An exit ABR is also referred to as TE-ABR.
Lu Expires January 10, 2012 [Page 5]
Internet-Draft OSPF TE Extension for Area IDs July 2011
3. Motivation
3.1. The importance of ABR whereabouts
All solutions listed in Section 1.2, except the global TED approach,
have to use the knowledge of exit ABRs to accomplish their inter-area
path computation tasks.
Some methods require manual configuration which is costly and error
prone. Others may have to use proprietary means to acquire the
information.
It is desirable to have the exit ABR information available and make
it conveniently accessible to the relevant PCEs without adding lot of
complexity to the protocols nor too much burden to the participating
routers.
3.2. Topic not Yet Addressed
Apart from the manual provision, currently the exit ABR information
is difficult to acquire. The reasons are:
1. OSPF TE Database (TED) does not contain information on exit ABRs;
2. CSPF operates on the TED and is therefore limited to the
information the latter provides. Unless the critical information
of the exit ABRs becomes available, the CSPF cannot operate
optimally by seeing beyond the area scope.
3. One may argue that CSPF can dig into OSPF's other repositories,
such as LSDB, to find out the ABR whereabouts. This is not
advisable because it negates the purpose of keeping TED opque and
independent from the normal OSPF operation. This is also
technically difficult because usually CSPF and OSPF are two
different processes that they may not be running in the same
nodes.
4. Even if one is willing for CSPF to intrude into OSPF space, and
use the ABR bit (B bit) information for locating border routers,
these ABRs are not necessarily the exit ABRs. In other words,
even if CSPF learns which routers sit on area borders, it is
still unable to ascentain whether the ABRs are supporting TE on
the other side of the borders. OSPF's hierarchical design limits
the topology sharing to within area boundaries.
5. And even if one is willing to jump across this limit and somehow
manages to aquire the ABRs' TE ability onto other areas, there is
still the need for one more key information, the Area IDs.
Lu Expires January 10, 2012 [Page 6]
Internet-Draft OSPF TE Extension for Area IDs July 2011
6. The Area IDs are critical to the distributed PCE architecture.
They are essential in enforcing path computation area sequences
and PCE policies. They are also useful for consolidating path
computation jobs. Section 6.2 provides an example of ABR
consolidation.
7. It is important to understand that the proposed TLV also implies
TE capabilities. In other words the TLV signifies that the
advertising router is not only an ABR, but also an LSR capable of
handling TE traffic. Unless tied with TE knowledge, methods of
discovering of ABRs will not be useful in locating TE-ABRs, i.e.
the LSRs that can transit TE traffic across areas.
8. At last, since the TLV is TE based, it should be defined in the
OSPF TE extensions and maintained similarly with its
counterparts, Router Address TLV and Link TLV.
3.3. Benefits
The benefits of having an OSPF Area ID TLV are listed below:
1. It fits into OSPF TE architecture, preserves the protocol's
hierarchy, and adds little burden to the OSPF process;
2. It automates the TE-ABR discovery, and eliminates the need of
manual provisioning;
3. Very often an LSR is also a PCE. If this LSR is also an ABR, it
can compute a two-area LSP effortlessly. The PCC only needs to
send the request to one TE-ABR (if there are multiple TE-ABRs
sharing the same border), provided it has knowledge of the TE-ABR
whereabouts.
4. Scope of the proposal
This document describes solutions for inter-area path computation and
does not address inter-domain scenarios.
It is also specific to OSPF as an IGP protocol, though the concepts
apply to ISIS which are to be defined in a separate document.
5. Area ID TLV
[RFC3630] section 2.4 defines two TLVs. This memo adds a third TLV
called the Area ID TLV.
Lu Expires January 10, 2012 [Page 7]
Internet-Draft OSPF TE Extension for Area IDs July 2011
5.1. TLV Origination Point
The Area ID TLV is originated and maintained by TE-ABR routers. The
TLV is encoded in an OSPF TE LSA which is an area-opaque LSA, and
handled the same way as the TE-LINK TLV and TE-ROUTER-ADDRESS TLV.
This TLV is flooded throughout and within the originating area.
----------------- ---------
| || |
| ABR1 |
| Area0 || Area1 |
| ABR2 |
| | =========
| || |
| || Area2 |
| || |
====ABR4========ABR3========
| || |
| Area4 || Area3 |
| || |
----------------- ---------
Figure 1: TLV Origination
In Figure 1 for example, it is assumed all ABRs and areas are TE
enabled. For ABR1 and ABR2, since they sit between Area0 and Area1,
both will originate an Area ID TLV concerning Area1 and flood it into
Area0, and vice versa. Likewise, ABR3 will originate a TLV covering
Area2, Area3, and Area4, and flood it into Area0, and so on for
Area2, Area3 and Area4.
Lu Expires January 10, 2012 [Page 8]
Internet-Draft OSPF TE Extension for Area IDs July 2011
5.2. TLV encoding
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Len | Area-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area-ID (Cont) | Another Area-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Another Area-ID (Cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| More Area-IDs |
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: TLV Format
Type The Area ID TLV consists of a 1-octet type value which will be
allocated by the IANA (suggested value 3).
Len 1-octet unsigned integer value 4xN to represent N exit areas,
not including the originating area.
Value The value fields contains one or more Area IDs. Each Area ID
is a four-octet OSPF Area ID associated with an exit area for
which the ABR has TE enabled. An ABR may connect to multiple
areas. Therefore it may generate 1 TLV with N IDs, where N is
the total number of exit areas, not including the originating
area. Since the Len field is of 1-octet, this TLV can hold
upto 63 IDs. For non-ABR routers this Area-ID TLV SHOULD not
occur.
5.3. Example
Consider Figure 1 again. Router ABR3 connects to four areas Area0,
Area2, Area3, and Area4. Assuming all ABRs and areas are TE enabled
except Area4 which is not TE-enabled. ABR3 originates and floods
following Area-ID TLVs as shown in Figure 3, assuming type is 3.
Lu Expires January 10, 2012 [Page 9]
Internet-Draft OSPF TE Extension for Area IDs July 2011
==========================================
|To |Type| Len|Area-IDs ...|
------------------------------------------
|Area0 | 3| 8|0 0 0 2|0 0 0 3|
|Area2 | 3| 8|0 0 0 0|0 0 0 3|
|Area3 | 3| 8|0 0 0 0|0 0 0 2|
|Area4 | None |
==========================================
Figure 3: Sample TLV
6. Applications
6.1. Use-Case 1
---------- --------- ----------
| || || |
| ABR1 ABR3 |
| H || T || |
| ABR2 || |
| Area1 || Area0 || Area2 |
| || || |
---------- --------- ----------
Figure 4: Use-Case 1
The topology is shown in Figure 4. The headend "H" is in Area1. The
tailend "T" is in Area0. LSRs are running OSPF-TE and RSVP-TE.
6.1.1. Crankback approach
The crankback method requires a list of ABRs for tryout. The list
usually has to be provisioned manually.
With the proposed Area-ID TLVs, the ABR information is made available
through the OSPF TE database. Therefore "H" learns the ABR list
dynamically from its OSPF TED, which is ABR1 and ABR2. "H" starts
the crankback procedure with "ABR1" from which it reaches "T". The
LSP thus is established successfully, though not necessarily optimal.
6.1.2. BRPC approach
With the method defined in [RFC5441], the VSPT has to be first built
from "T" in Area0. Given that the area sequence is Area0->Area1, the
initial VSPT has the candidate exit ABRs ABR1, ABR2, and ABR3.
Lu Expires January 10, 2012 [Page 10]
Internet-Draft OSPF TE Extension for Area IDs July 2011
Now with the proposed OSPF Area ID TLVs the PCE of Area0 knows that
ABR3 connects Area2, not Area1, therefore ABR3 is not considered as
an exit ABR.
Subsequently the PCE of Area1 takes the VSPT passed by the PCE of
Area0 as input and concludes the end-to-end path computation.
6.2. Use-Case 2
Very often an LSR is also a PCE. In that case, the Area ID TLVs can
make the path computation job more efficient.
----------- -----------
| || |
| ABR1 Area1 |
| H || |
| ABR2 T |
| Area0 || |
| ABR3 |
| | -----------
| || |
| ABR4 Area2 |
| || |
----------- -----------
Figure 5: Use-Case 2
As shown in Figure 5, if the headend "H" knows that the tailend "T",
or some intermediate node to reach, is in Area1, it sends a PCReq to
one of the ABRs that connect to Area1. The draft proposal makes the
ABR list conveniently available, which is [ABR1, ABR2, ABR3]. Note
that ABR4 is not listed since it is not an exit ABR to Area1.
Assuming by some local policy ABR1 is chosen. Since ABR1 sits across
Area0 and Area1, it has visibility to TEDs of both areas. ABR1 which
is also a PCE performs the path computation job in the same way as an
intra-area path computation.
Note that the resulting path, if existent, does not necessarily go
through ABR1. It can be for example H->ABR3->T.
Note also that the ABR selection is a local decision. One can use
some criteria, for example the highest te-router-id, to select the
ABR. However, the candidate ABRs have to share the common border
such as the one between Area0 and Area1. This can be achieved by
grouping ABRs according to their exit Area IDs in the proposed OSPF
Area ID TLVs.
Lu Expires January 10, 2012 [Page 11]
Internet-Draft OSPF TE Extension for Area IDs July 2011
7. Acknowledgements
The author would like to thank Sriganesh Kini, Meral Shirazipour, and
Dimitri Papadimitriou for their reviews and comments.
8. IANA Considerations
This document defines the following TLV to the OSPF TE Extensions
under TE LSA:
+-------------------+-------------+---------------+
| Type | Name | Source |
+-------------------+-------------+---------------+
| TBD (recommend 3) | Area ID TLV | This document |
+-------------------+-------------+---------------+
9. Security Considerations
There are no specific security considerations within the scope of
this document.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
10.2. Informative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for
Lu Expires January 10, 2012 [Page 12]
Internet-Draft OSPF TE Extension for Area IDs July 2011
Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4674] Le Roux, J., "Requirements for Path Computation Element
(PCE) Discovery", RFC 4674, October 2006.
[RFC4920] Farrel, A., Satyanarayana, A., Iwata, A., Fujita, N., and
G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS
RSVP-TE", RFC 4920, July 2007.
[RFC4927] Le Roux, J., "Path Computation Element Communication
Protocol (PCECP) Specific Requirements for Inter-Area MPLS
and GMPLS Traffic Engineering", RFC 4927, June 2007.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008.
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
Backward-Recursive PCE-Based Computation (BRPC) Procedure
to Compute Shortest Constrained Inter-Domain Traffic
Engineering Label Switched Paths", RFC 5441, April 2009.
Author's Address
Wenhu Lu
Ericsson
300 Holger Way
San Jose, California 95134
USA
Phone: 408 750-5436
Email: wenhu.lu@ericsson.com
Lu Expires January 10, 2012 [Page 13]