Internet DRAFT - draft-cheng-ccamp-ospf-multiarea-te-extensions
draft-cheng-ccamp-ospf-multiarea-te-extensions
CCAMP Working Group D. Cheng (Polaris Networks)
Internet Draft
Expiration Date: September 2002
OSPF Extensions to Support Multi-Area Traffic Engineering
draft-cheng-ccamp-ospf-multiarea-te-extensions-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. 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 OSPF Routing Enhancements ................................... 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 .......................................... 4
4.0 Scope and Mechanisms for Advertising......................... 5
4.1 Option 1: AS-Wide Advertising ............................... 5
4.2 Option 2: Per-Area and On-Demand Advertising ................ 5
4.3 Option 3: Per-LSR and On-Demand Advertising ................. 6
5.0 Security Considerations ..................................... 6
6.0 Acknowledgements ............................................ 6
7.0 References .................................................. 6
8.0 Author's Address ........................................... 6
[Page 1]
1.0 Introduction
This document specifies additional traffic engineering parameters
and their formats that could be used to support constraint-based
routing for GMPLS LSP 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]. However, in OSPF networks with multiple areas, it
is sometimes desirable to obtain traffic parameters from other areas
so that the head-end LSR in one area may be able to select an
optimized path toward the tail-end LSR across OSPF area boundary.
There are a number of practical ways to perform routing across OSPF
area boundary in GMPLS networks as documented in the [MULTI-AREA].
The extensions as proposed in this document may be used in support
some of the scenarios as described in that document.
This document proposed the following TLVs as extensions to GMPLS-OSPF:
1) Top level TLV - Address TLV, type 3
2) Sub-TLV - Area Sub-TLV, type 17
3) Sub-TLV - Address Sub-TLV, type 18
4) Sub-TLV - Peer ABR Sub-TLV, type 19
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.
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. 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.
Second, the topology of the inter-connectivity of the ABRs in the
OSPF domain, or a subset of such, along with the traffic parameters,
needs to be made known to the head-end LSR. Note this
inter-connectivity is in abstract context.
[Page 2]
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 OSPF Routing Enhancements
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 Sub-TLV
The Area 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 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) | 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 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) | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[Page 3]
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 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) | 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)
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 Address TLV is advertised by an ABR.
3.3.1 Peer-ABR 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.
[Page 4]
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) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer ABR Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.0 Advertising Scope and Related Mechanisms
There always exists a tradeoff between the amount of the routing
information that needs to be passed around and the degree of routing
optimization. In order to be flexible enough to meet different
routing requirements in MPLS/GMPLS networks, this document does not
limit to a single scope and mechanism for the advertising of the
additional routing information as described in the Section 3. The
following sections describe some of the practices in distributing
the additional routing information, but does not preclude others.
4.1 Option 1: AS-Wide Advertising
The ABR always advertises the routing information belong to each of
the areas that it attached as described in the Section 3.0
unconditionally using type-11 opaque LSA throughout the entire OSPF
domain where the ABR belongs to.
With this option, all routers in the same OSPF domain have to store
and maintain the additional routing information, but any router can
use these information to calculate LSPs that across multiple OSPF
areas with better optimization.
4.2 Option 2: Per-Area and On-Demand Advertising
In this scenario, the ABR only advertises the additional routing
information that belong to a non-backbone area unconditionally to
the backbone area using type-10 opaque LSA. If any non-backbone
area wishes to have the additional routing information as described
in the Section 3.0, one or more ABRs in that area will then
re-advertise the information that is available in the backbone
area into 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 5]
4.3 Option 3: Per-LSR and On-Demand Advertising
This scenario is similar to the one as described in the Section 4.2,
except that the on-demand advertising is based on individual LSRs
that actually wishe to obtain and maintain the additional routing
information.
To accomplish the per-LSR based advertising on-demand, a special
communication channel is required between the head-end LSR and an
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.3) was taken from Yakov Rekhter and is
appreaciated.
7.0 References
[MULTI-AREA] "Multi-area MPLS Traffic Engineering",
draft-kompella-mpls-multiarea-te-02.txt, work in Progress.
[OSPF-TE] "Traffic Engineering Extensions to OSPF",
draft-katz-yeung-ospf-traffic-04.txt, work in Progress
[GMPLS-Routing] "Routing Extensions in Support of
Generalized MPLS", draft-ietf-ccamp-gmpls-routing-01.txt,
work in progress.
[GMPLS-OSPF] "OSPF Extensions in Support of Generalized MPLS",
draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
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 6]
