CCAMP Working Group Dean Cheng
Internet Draft Polaris Networks
Expires: August 2003 February 2003
OSPF Extensions to Support Multi-Area Traffic Engineering
draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
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."
To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html.
Abstract
The [MULTI-AREA] introduces a set of mechanisms that could be used
to construct LSPs that span multiple IS-IS/OSPF areas, where one
scenario is to allow the head-end LSR to compute the path all the
way to the ABR in the tail-end area. This document proposes some
new OSPF extensions that can be used in supporting that scenario,
i.e., by leaking some of the useful information from individual
areas to others, the constraint-based routing at the head-end LSR
of LSPs in OSPF networks with multiple areas can be optimized.
Table of Contents
1.0 Introduction .................................................. 2
2.0 Applicability ................................................. 2
3.0 TE Extensions to Multi-Area OSPF Routing ...................... 3
3.1 Area Sub-TLV .................................................. 3
3.2 Address TLV .................................................... 3
3.2.1 Address Sub-TLV .............................................. 4
3.3 Inter-ABR TE Link TLV .......................................... 4
3.3.1 Peer ABR Sub-TLV ............................................. 5
4.0 TE Advertisements and their Advertising Scope .................. 5
4.1 Option 1:Area TE LSA Advertised throughout a Single OSPF Domain . 5
4.2 Option 2:Area TE LSA Advertised per-Area and per-Configuration .. 6
4.2.3 TE Advertisements from OSPF Backbone to Non-Backbone Area ..... 6
4.2.3.1 Option 2-1: Per-Area and On-Demand Advertising .............. 6
4.2.3.2 Option 2-2: Per-LSR and On-Demand Advertising ............... 7
5.0 Security Considerations ........................................ 7
6.0 Acknowledgements ............................................... 7
[Page 1]
7.0 References ..................................................... 7
7.1 Formative References ........................................... 7
7.2 Informative References ......................................... 7
8.0 Author's Address .............................................. 7
1.0 Introduction
This document specifies additional traffic engineering parameters
and their formats that could be used to support constraint-based
routing for MPLS/GMPLS LSPs across multiple areas in OSPF networks.
Currently there already exist extensions to OSPF to support traffic
extensions in MPLS and GMPLS networks, as documented in [OSPF-TE]
and [GMPLS-OSPF]. In OSPF networks with multiple areas, only
reachability information may be exchanged between OSPF areas per
[OSPF]. There are a number of practical ways to perform routing
with traffic engineering across OSPF area boundary in MPLS/GMPLS
networks as documented in the [MULTI-AREA]. One desirable practice
is to obtain traffic engineering information from other areas
so that the head-end LSR in the source area may select an
optimized or "intelligent" path towards the tail-end LSR across
OSPF area boundaries.
In traditional OSPF networks, IP traffic across multiple areas is
generally sent to the ABRs based on the cross-area reachability
information advertised by the ABRs. This document proposes that for
MPLS/GMPLS LSPs across multiple OSPF areas with traffic engineering
requirements, the TE links as defined in the [OSPF-TE] and
[GMPLS-OSPF] may be constructed between ABRs within each area and
then advertised to other areas, along with other required
information, which can then be used in the constraint-based routing
in the path selection procedure at the head-end LSR.
This document proposed the following TLVs as extensions to OSPF-TE
and GMPLS-OSPF:
1) Top level TLV - Address TLV, type 3 (TBD)
2) Sub-TLV - Area Sub-TLV, type 17 (TBD)
3) Sub-TLV - Address Sub-TLV, type 18 (TBD)
4) Sub-TLV - Peer ABR Sub-TLV, type 19 (TBD)
2.0 Applicability
To establish and maintain MPLS/GMPLS LSPs that span multiple OSPF
areas, one may wish to let the head-end of a LSP to calculate an
optimal or near-optimal path from itself all the way to the entry
ABR of the destination area where the tail-end LSR resides. Note
the portion of the LSP that is outside of the source area where
the head-end LSR resides most likely contains loose hops. In
particular, it may be practical to let these loose hops be a list
of concatenation of ABRs in the same OSPF domain, i.e., exit ABR
of the source area, the entry and exist ABRs of the area that the
LSP needs to traverse, and finally the entry ABR of the destination
area. Note in such a scenario, the entry ABR of all the areas (except
[Page 2]
the source area) needs to expand the loose hops to strict hops using
the link-state based OSPF routing and traffic engineering database
within the associated area.
To support the routing calculation for LSPs that span multiple
OSPF areas at the head-end LSR, additional information in areas
other than the source area needs to be made known to the head-end
LSR or the source area. In this document, two pieces of additional
information are specified.
First, the destination area needs to be known by the head-end LSR.
Note currently in the OSPF networks, area information is not
included in the advertisements of reachable addresses/subnets,
using type-3 or type-5 LSA (refer to the [OSPF]).
Second, the topology of the inter-connectivity of the ABRs in the
OSPF domain, or a subset of such, along with the traffic parameters,
need to be made known to the head-end LSR. Note this
inter-connectivity is in abstract context.
With the two pieces of information, the head-end LSR may then find
and optimize the LSP from itself to the entry ABR of the destination
area.
3.0 TE Extensions to Multi-Area OSPF Routing
In this section we define some additional TE parameters that may be
used to support constraint-based routing in OSPF networks with
multiple areas. These TE parameters are carried using the format of
Type/Length/Value (TLV), which is consistent with those already
specified in the [OSPF-TE] and [GMPLS-OSPF].
3.1 Area ID Sub-TLV
The Area ID sub-TLV specifies the Area ID of an OSPF area where a set
of IP addresses and subnets included in an Address TLV (see the
Section 3.2) belong to, or an inter-ABR TE link belong to (see the
Section 3.3).
The format of the Area ID sub-TLV is as follows:
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 (17 - TBD) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2 Address TLV
The Address TLV specifies a set of reachable IP addresses or/and IP
subnets and the OSPF area that they belong to.
The Address TLV is a top-level TLV and contains a single Area ID
[Page 3]
sub-TLV and one or more Address sub-TLVs. Each Address sub-TLV
contains one or more IP addresses or/and IP subnets and the Area
sub-TLV specifies the Area ID of the OSPF area where these IP
addresses and subnets belong to.
The Address TLV is advertised by an ABR. Its format is as the follows:
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 (3 - TBD) | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.1 Address Sub-TLV
The Address sub-TLV specifies one or more IP addresses or subnets
that belong to an OSPF area as indicated by the Area ID sub-TLV.
The format of the Address sub-TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-type (18 - TBD) | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr_length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address or Subnet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address or Subnet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Addr_length specifies the length of the IPv4 address specified
in number of bits, and it applies to all IP addresses and subnets
included in the same Address sub-TLV.
3.3 Inter-ABR TE link TLV
The inter-ABR TE link TLV specifies a regular OSPF TE link as exactly
defined in the [GMPLS-OSPF] with two additional sub-TLVs as follows:
1) the Area sub-TLV (see the Section 3.1).
2) the peer-ABR sub-TLV (see the Section 3.3.1)
[Page 4]
For the inter-ABR TE link TLV, the above two sub-TLVs are mandatory.
An inter-ABR TE link describes a GMPLS TE link between two ABR in
the same OSPF area in abstract context.
The Inter-ABR TE link is advertised by an ABR.
3.3.1 Peer-ABR Router ID Sub-TLV
The peer ABR Router ID sub-TLV specifies the Router ID of the peer
end of the inter-ABR TE link. Note the local end is identified by
the advertising Router ID included in the LSA header. The two
Router IDs identify the two ABRs as two endpoint of the TE link and
the information contained in the Area sub-TLV specifies the area
where the TE link is in.
The format of the peer ABR Router ID sub-TLV is as follows:
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 (19 - TBD) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer ABR Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.0 TE Advertisements and their Advertising Scope
To allow the head-end LSR to compute a MPLS/GMPLS LSP across
multiple OSPF areas, traffic engineering information as described
in the Section 3.0 needs to be advertised and made known to the
head-end LSR, in addition to the classical routing information
per [OSPF]. The TE advertisements related to multiple areas are
as the following using the formats as described in the Section 3.0:
1) The OSPF Area ID of the IPv4 addresses and subnets that
are reachable through the advertising ABRs in their home
area.
2) The TE links between the ABRs within this area.
There always exists a tradeoff between the amount of the routing
information that needs to be passed around and the availability
of the routing information in other areas that may be used to
compute the path across the area boundary.
This document proposes a flexible mechanism to satisfy different
requirements and applications in MPLS/GMPLS networks as described
in the following.
4.1 Option 1:Area TE LSAs Advertised throughout a Single OSPF Domain
The TE advertisements as described in the Section 4.0 can always
be generated by ABRs in each of the OSPF areas including the backbone
and non-backbone areas with the LSA type as 11 (see [OSPF-OPAQUE]),
and as a result, these advertisements will be flooded throughout
the entire OSPF domain.
[Page 5]
The information contained in these advertisements can then be used
for computing LSPs that across OSPF area boundaries at the head-end
LSR.
4.2 Option 2:Area TE LSAs Advertised per-Area and per-Configuration
With this option, the backbone area always generates its area TE
LSAs; a non-backbone area may only generate its area TE LSAs if
configured to do so, and the area TE LSAs from a non-backbone area
is only advertised to the backbone area.
The collection of the area TE LSAs that maintained within the OSPF
backbone area may only be advertised to individual non-backbone
area or individual LSR if configured to do so.
4.2.1 TE Advertisements in the OSPF Backbone Area
The ABRs in the OSPF backbone area always adveritse the additional
opaque TE information as above. The type-10 opaque LSA is used
per [OSPF-OPAQUE].
After the advertising, the information may be adveritised to
non-backbone areas or individual LSRs subject to the configuration.
4.2.2 TE Advertisements from OSPF Non-Backbone to Backbone Area
The ABRs in a non-backbone area may choose to advertise or not to
advertise the additional opaque TE information to the backbone area.
If choose to advertise, the type-10 opaque LSA is used in the
backbone area per [OSPF-OPAQUE].
After the advertising, the information will be available in the
OSPF backbone area, and then they may be advertised to other
non-backbone areas or individual LSRs subject to the configuration.
4.2.3 TE Advertisements from OSPF Backbone to Non-Backbone Area
The collection of area TE advertisements as described in the
Section 4.2.1 and the Section 4.2.2 that are maintained in the
backbone area may be further advertised to other non-backbone areas
or individual LSRs with different options as described below.
4.2.3.1 Option 2-1:Per-Area and On-Demand Advertising
If any non-backbone area wishes to have the additional TE routing
information from other areas, one or more ABRs in that area can
re-advertise the information that is available in the backbone
area throughout that area. All these advertisements use type-10
opaque LSA.
The on-demand advertising may be triggered by a configuration
option from the network management system.
With this option, the additional routing information only needs to
be injected into individual areas that requesting for them.
[Page 6]
4.2.3.2 Option 2-2:Per-LSR and On-Demand Advertising
This scenario is similar to the one described in the Section 4.2.3.1,
except that the on-demand advertising is based on individual LSRs
that actually wishes to obtain and maintain the additional TE
routing information.
To accomplish the per-LSR based advertising on-demand, a special
communication channel is required between the LSR and an ABR in the
same area. A GRE tunnel may be used in this case. The type-9 opaque
LSA is used to carry the routing information.
5.0 Security Considerations
Security issues are not discussed in this document.
6.0 Acknowledgements
Suggestion of using GRE tunnels for obtaining additional routing
information (Section 4.2.3.2) was taken from Yakov Rekhter and is
appreaciated.
7.0 References
7.1 Normative References
123456789012345678901234567890123456789012345678901234567890123456789012
[OSPF] RFC 2328, "OSPF Version 2"
[OSPF-OPAQUE] RFC 2370, "The OSPF Opaque LSA Option"
[MULTI-AREA] "Multi-area MPLS Traffic Engineering", work in Progress.
[OSPF-TE] "Traffic Engineering Extensions to OSPF", work in Progress
[GMPLS-OSPF] "OSPF Extensions in Support of Generalized MPLS",
work in progress.
7.2 Informative References
[GMPLS-Routing] "Routing Extensions in Support of Generalized MPLS",
work in progress.
8.0 Authors' Addresses
Dean Cheng
Polaris Networks Inc.
6810 Santa Teresa Blvd.
San Jose, CA 95119
Phone: +1 408 284 8061
Email: dcheng@polarisnetworks.com
[Page 7]
