Network Working Group P. Murphy
Internet Draft US Geological Survey
Expiration Date: August 2002 February 2002
File name: draft-ietf-ospf-mlinks-03.txt
OSPF Multiple Area Links
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."
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.
Murphy [Page i]
Internet Draft OSPF Multiple Area Links February 2002
Table Of Contents
1.0 Abstract ................................................. 1
2.0 Overview ................................................. 2
2.1 Requirement for OSPF Multiple Area Links ................. 2
2.2 Proposed Solution ........................................ 3
2.2.1 Secondary Adjacencies .................................... 4
2.2.2 Secondary Neighbor Discovery ............................. 4
2.2.3 Advertising Secondary Links .............................. 5
2.3 Application .............................................. 5
3.0 Secondary Interfaces ..................................... 5
3.1 The SecondaryAreas Interface parameter ................... 5
3.2 The Secondary Interface Data Structure ................... 6
3.3 The Secondary Interface State Machine .................... 6
3.4 OSPF Protocol Packet Processing .......................... 7
3.5 Designated Router Election and Function .................. 7
4.0 Synchronizing Secondary Areas Using Mlink Type 9 LSAs .... 8
5.0 Secondary Neighbors ...................................... 8
5.1 The Secondary Neighbor Data Structure .................... 8
5.2 The Secondary Neighbor State Machine ..................... 9
5.3 Receiving Mlink Type 9 Neighbor Discover LSAs ............ 10
5.4 Receiving Secondary Hello Packets ........................ 11
6.0 Advertising Secondary Adjacencies ........................ 11
7.0 The Shortest Path First Calculation ...................... 11
8.0 Flushing Secondary Adjacencies ........................... 12
9.0 Security Considerations .................................. 12
10.0 Acknowledgments .......................................... 12
11.0 References ............................................... 12
12.0 Authors' Addresses ....................................... 12
Appendix A: Router-LSAs ........................................ 13
Appendix B: Mlink Type 9 Neighbor Discover LSAs ................ 17
Appendix C: Configuration Parameters ........................... 19
1.0 Abstract
This memo describes an option to the OSPF Version 2 specification
which allows multiple areas to share the same OSPF link. One area is
always configured as the link's primary area. The link's remaining
areas are termed secondary. Two border routers adjacent across the
same secondary area may forward the area's intra-area traffic across
the link. This option applies to standard areas, stub areas, and
NSSAs. It works over any OSPF interface. Routers with this option
configured are backward compatible with routers running the standard
OSPF Version 2 compliant implementation as defined in RFC 2328.
Please send comments to ospf@discuss.microsoft.com.
Murphy [Page 1]
Internet Draft OSPF Multiple Area Links February 2002
2.0 Overview
2.1 Requirement for OSPF Multiple Area Links
Large corporate networks in today's modern Internet have tremendous
human and equipment resources coupled with sizable budget invested in
their backbone infrastructure. Their regional networks are normally
not so fortunate and must multi-home to the backbone in order to take
advantage of the backbone's faster and more reliable network links.
Performance over a T1 link can pale by comparison to performance over
a DS3 or OC3 backbone link. Large corporate networks have sizable
backbone routing tables and routinely use stub areas and NSSAs. Under
the current OSPF specification intra-area routes are always preferred
over inter-area routes even when the traffic is sourced from and
destined to the same non-backbone OSPF area.
Consider the following typical OSPF example:
A0-----------Area 0 link------------B0-------N1
| DS3 (1) | (2)
| |
|NSSA 1 link NSSA 1 link|
| T1 (28) T1 (28) |
| |
| |
A1-----------NSSA 1 link------------B1-------M1
512k (56) (2)
where A0 and B0 are border routers attached to NSSA 1. A1 and B1 are
internal routers in NSSA 1. N1 and M1 are standard ethernet networks
in NSSA 1 which are directly attached to B0 and B1 respectively. The
cost of each link is shown in parentheses. All OSPF costs are
symmetric. Under the current OSPF specification the preferred path
between A0 and M1 is
A0<->A1<->B1<->M1
with an OSPF cost of 86, even though there exists a more preferred
path through B0 namely
A0<->B0<->B1<->M1
with an OSPF cost of 31.
In addition the NSSA 1 OSPF preferred path between A1 and N1 is
A1<->B1<->B0<->N1,
Murphy [Page 2]
Internet Draft OSPF Multiple Area Links February 2002
with an OSPF cost of 86, even though there exists a more preferred
path through the link between A0 and B0, namely
A1<->A0<->B0<->N1
with an OSPF cost of 31. Under the current OSPF specification NSSA
1's router A1 does not even see this path to N1 since it has no
knowledge of Area 0's topology. A0, on the other hand, would at lease
see the summary LSA of N1, but still cannot take advantage of it due
to OSPF intra-area path preference.
What is needed is a tool which makes the Area 0 link between A0 and
B0 visible inside NSSA 1. A common practice is to use multiple
interface subnets. However this is not an option when the path
between A0 and B0 is unnumbered or when one desires that the NSSA 1
path between A0 and B0 be unnumbered. Moreover when configuring
multiple interface subnets over multi-access networks, inverse-arp
limitations come into play and additional layer 2 PVCs may be
required, imposing potential resource and budgetary ramifications.
The existing tools for the multiple area usage of the same physical
link are awkward to configure, implementation dependent,
unnecessarily complex and unwieldy to maintain. If, in the above
example, the link between A0 and B0 were part of NSSA 1, path
preference would be optimal as the DS3 path would be intra-area for
NSSA 1.
2.2 Proposed Solution
The OSPF Multiple Area Links option is a simpler tool for configuring
multiple area links, requiring just a simple list of the areas
sharing an OSPF link. Once configured it lets multiple areas use the
same link between two border routers for each area's intra-area
traffic. Traffic may originate from inside each of the configured
areas, as every router in the configured areas sees the link as part
of its link state topology. Routers with configured OSPF Multiple
Area Links must be in Area 0, although the connection to Area 0 may
be one of the areas listed as sharing the link.
The current OSPF specification only allows one area per OSPF
interface. Thus, should an Area L dual-home to Area 0 via two border
routers which are adjacent over another Area K's router<->router link
or router<->network link, the adjacent link over Area K is not seen
inside Area L, even though the two border routers exist physically
adjacent within Area L. This, coupled with intra-area route
preference, prevents Area L from utilizing Area K's adjacent path.
Murphy [Page 3]
Internet Draft OSPF Multiple Area Links February 2002
2.2.1 Secondary Adjacencies
The softening of this restriction is facilitated by the addition of a
new interface configuration parameter called SecondaryAreas. This
parameter specifies a list of additional areas which share the OSPF
link (See Appendix C). The areas listed in this parameter are called
the interface's secondary areas, as opposed to the interface's
configured area, hereafter called the primary area. A separate
interface data structure is generated for each of the secondary
areas. For each secondary area listed in the SecondaryAreas parameter
a router can form OSPF adjacencies across the interface's directly
attached network or router link. These adjacencies are called
secondary adjacencies.
Secondary adjacencies are formed after the primary area's link state
data base exchange has synchronized matching secondary areas through
the flooding path with the link's other directly connected routers.
(See Section 4.0). Link state database exchange occurs across a
secondary adjacency along with normal flooding. Note that a secondary
adjacency for area 0 may not be configured for an interface which is
linked to a transit area for a configured virtual link (See Section
3.4).
2.2.2 Secondary Neighbor Discovery
A Type 9 opaque LSA is used to form secondary adjacencies over a
primary link with adjacent opaque capable border routers. Until an
opaque type is assigned for this option, experimental opaque type 224
will be used. The option's LSA is referred to as an mlink Type 9 LSA.
A Type 9 LSA is used for the exchange/update of an interface's
secondary areas because the flooding scope of this opaque LSA needs
to be restricted to routers which are directly attached to a common
network or router link. A separate mlink Type 9 LSA is originated for
each of the primary interface's secondary areas. If required,
included in a secondary area's mlink Type 9 LSA is the secondary
area's configured Designated Router priority. Mlink Type 9 LSAs are
propagated during the exchange/update of the primary area's link
state data base (LSDB) with its adjacent primary neighbors.
If a router A receives an mlink Type 9 LSA for area L originating
from a router B during the exchange/update of primary area K's LSDB,
then router A may form a secondary adjacency in area L with router B.
See Section 5.2 for details about secondary neighbor adjacency
formation. LSDB exchange and update across a secondary adjacency
proceed as defined in [OSPF] Sections 10 and 13.
Murphy [Page 4]
Internet Draft OSPF Multiple Area Links February 2002
2.2.3 Advertising Secondary Links
Secondary adjacencies are advertised as point-to-point links. Any
intervening transit network or stub network assigned to the primary
interface always belongs to the interface's primary area. There is no
network LSA for this intervening transit network in any of the
interface's secondary areas. All secondary adjacencies must be
advertised in a router-LSA with point-to-point type.
During the Dykstra shortest path first (SPF) calculation the LSAs for
secondary adjacencies look like point-to-point links. A border router
never includes in a secondary area's SPF tree any network across
which one of its secondary adjacencies span. This ensures
synchronization of the SPF tree amongst the secondary area's routers.
However, since border routers share the link's addressing, they may
use the IP addresses of their secondary neighbors for determining a
destination's next hop across a secondary link over a point-to-
multipoint or transit network.
2.3 Application
Consider now the example mentioned in Section 2.1 and assume NSSA 1
is configured as a secondary area over the Area 0 link between A0 and
B0. Since the routers A0, A1, B0, and B1 possess NSSA 1's router-LSAs
originating from A0 and B0 which define a secondary link between A0
and B0 in NSSA 1, the NSSA 1 intra-area SPF tree computed by the
Dykstra calculation now includes this DS3 link with a cost of 1. Thus
the preferred path between A0 and M1 is
A0<->B0<->B1<->M1
and the preferred path between A1 and N1
A1<->A0<->B0<->N1
3.0 Secondary Interfaces
3.1 The SecondaryAreas Interface Parameter
A new configuration parameter called SecondaryAreas has been added to
the OSPF interface data structure (See Appendix C). The
SecondaryAreas interface parameter lists a set of areas which may
form secondary adjacencies across the interface. If the
SecondaryAreas interface parameter has a null list, then no secondary
areas are configured for this interface and no secondary adjacencies
can be formed over the interface.
Each area listed in the SecondaryAreas interface parameter should
Murphy [Page 5]
Internet Draft OSPF Multiple Area Links February 2002
have a secondary interface data structure. With the exception of Area
ID all of secondary interface parameters which are usually
configurable, such as interface cost, authentication parameters and
Designated Router priority, default to the values assigned to the
primary interface. Furthermore, except for the Area ID, IP interface
address and mask, all configurable interface parameters should be
separately configurable for each secondary interface. Note that if a
virtual link is configured across a transit area which is linked to
an interface, then Area 0 may not be configured in the interface's
SecondaryAreas parameter.
3.2 The Secondary Interface Data Structure
An OSPF interface data structure should be built for each of an OSPF
interface's secondary areas. These interface data structures are
called secondary interface data structures and are loosely bound to
the primary interface. The configured primary area of an OSPF
interface generates its primary interface data structure. A point-
to-point layer 2 link between two routers may have only one OSPF
interface per area (See [OSPF] Sections 8.2 and 10.5). Additional
areas may be added as secondary areas, but they must not duplicate
areas already configured for the layer 2 link. A secondary
interface's list of neighboring routers is generated by examining the
primary interface's received mlink Type 9 LSAs as defined in Section
4.0 below.
With the exception of broadcast networks, secondary interfaces copy
their interface type from the primary interface's data structure. If
the primary interface's network has broadcast type then the secondary
interface's network has NBMA type. Secondary interfaces with NBMA
type still compute a Designated Router and a Backup Designated
Router. This promotes efficient flooding across the interface's
transit network. Note that secondary adjacencies are always
advertised as router links even when their network type is NBMA. As
such the Designated Router of a secondary NBMA link does not
originate a type-2 network LSA into the secondary area for the
primary interface's transit network.
3.3 The Secondary Interface State Machine
The interface states of a secondary interface are the same as the
interface states of a primary interface. Secondary neighbors exchange
Hello packets, called secondary Hello packets, just like primary
neighbors. The processing of received secondary Hellos is practically
unchanged (See Section 5.5). The InterfaceUp event for a secondary
interfaces is generated by its corresponding primary interface when
the primary interface transitions to either Point-to-point, DR Other,
DR, or Backup state. In addition to those actions described in [OSPF]
Murphy [Page 6]
Internet Draft OSPF Multiple Area Links February 2002
Section 9.3, when the InterfaceUp event is generated for secondary
interfaces, the neighbor Start event is generated for each existing
secondary neighbor.
The remainder of the interface state machine is virtually unchanged
for secondary interfaces. Those protocols which generate the events
InterfaceDown, LoopInd, UnloopInd for the primary interface should
generate the same events for all of the primary interface's
corresponding secondary interfaces. The NeighborChange and BackupSeen
events are generated through the orderly processing of secondary
Hello packets received across the secondary interface as described in
[OSPF] Section 10.5 and augmented in Section 5.4. It is notable that
since the secondary interface's InterfaceUp event occurs only after
the primary interface has transitioned to DR other, DR or Backup
state, a secondary interface's Wait Timer will never start before the
primary interface's Wait Timer has fired. This produces a more
orderly ascension to Full state for secondary NBMA adjacencies.
3.4 OSPF Protocol Packet processing
Since a secondary interface shares the ip address of its
corresponding primary interface, OSPF protocol packet processing
needs a minor adjustment. For broadcast, NBMA, and point-to-
multipoint links, the packet's IP source address is required to be on
the same network as the receiving OSPF primary interface. This can be
verified by comparing the packet's IP source address to the primary
interface's source address, after masking both addresses with the
interface mask (See [OSPF] Section 8.2). The Area Id is used to
distinguish the primary interface from its configured secondary
interfaces. Any router with a configured virtual link cannot
configure Area 0 in the SecondaryAreas parameters of any interface
belonging to the link's transit area. Otherwise the virtual link
would not be distinguishable from an Area 0 secondary link.
3.5 Designated Router Election and Function
The election of the Designated Router and the Backup Designated
router for a secondary link over a secondary NBMA network proceeds as
described in [OSPF] Section 9.4. Eligibility is determined from the
Designated Router priorities configured for each secondary area as
well as the priorities defined in received secondary Hellos from
secondary neighbors. Note that the Designated Router for a secondary
link does not originate a network-LSA (Type-2) into its secondary
area for the secondary NBMA network over which the secondary link
bridges. All secondary links are advertised as point-to-point links
(see Section 6.0). The only function of a secondary link's Designated
Router is flooding optimization.
Murphy [Page 7]
Internet Draft OSPF Multiple Area Links February 2002
4.0 Synchronizing Secondary Areas using Mlink Type 9 LSAs
Mlink Type 9 LSAs are used to discover and start secondary neighbor
relationships. If the primary interface is of broadcast or NBMA type
then all of its candidate Designated Routers must be opaque capable,
even if these routers have no secondary areas configured for their
link to the broadcast or NBMA network. Otherwise mlink Type 9 LSAs
may not propagate to all potential routers capable of forming
secondary adjacencies over the network. Note that these candidate
Designated Routers do not have to support OSPF Multiple Area Links,
but they do have to be opaque capable in order to flood mlink Type 9
LSAs to their adjacent primary neighbors who may or may not support
OSPF Multiple Area Links.
The format of the mlink Type 9 LSA is detailed in Appendix B. Any
router which has an interface with a non-empty SecondaryAreas
interface parameter must originate across the primary interface an
mlink Type 9 LSA for each configured secondary area. If an
interface's SecondaryAreas parameter is null, then no mlink Type 9
LSAs will be advertised. A secondary area's mlink Type 9 LSA
minimally lists as opaque information the secondary link's Area ID,
plus, if available, its IP address and, if required, its Designated
Router priority. A new mlink Type 9 LSA is reoriginated following
expiration of its LSRefreshInterval or when changes occur in the
secondary link's router priority. Mlink Type 9 LSAs are only flooded
at the routers fully adjacent primary neighbors. If a secondary area
is removed from a primary interface's configured secondary areas, its
locally originated mlink Type 9 LSA should be flushed.
The mlink Type 9 LSA of each of the primary interface's secondary
areas must have a unique opaque ID. The last 24 bits of the Secondary
Area ID will normally produce unique Opaque IDs. When it doesn't,
alter the least significant bits until uniqueness is achieved.
5.0 Secondary Neighbors
An OSPF router converses with its secondary neighbors. Each separate
conversation is described by a "secondary neighbor data structure".
Conversations between secondary neighbors are bound to the secondary
interface and identified by both the Area ID and either the router's
OSPF Router ID or its Neighbor IP address (see Section 3.4). Unless
discussed below details for the creation and maintenance of secondary
neighbors and secondary adjacencies are the same as discussed in
[OSPF] Sections 10.
5.1 The Secondary Neighbor Data Structure
The neighbor data structure for secondary adjacencies is identical to
Murphy [Page 8]
Internet Draft OSPF Multiple Area Links February 2002
the neighbor data structure for standard OSPF adjacencies. Secondary
neighbors are discovered by comparing the Area IDs of the primary
interface's received mlink Type 9 LSAs with the secondary areas
listed in the interface's SecondaryAreas parameter. For point-to-
multipoint and transit networks, the originator of the mlink Type 9
LSA should be on the same network as the receiving interface. This
can be verified by comparing the mlink Type 9 LSA's IP address field
with the IP address of the primary interface, after masking both
addresses with the interface mask. For point-to-point and point-to-
multipoint secondary network types, a separate neighbor data
structure is always built for each new secondary neighbor discovered
by a received mlink Type 9 LSA. Since the mlink Type 9 LSA of an NBMA
secondary link includes the neighbor's Designated Router priority,
its separate secondary neighbor data structure is built only when
either the local router or the originating router of the mlink Type 9
LSA is DR eligible (see Section 5.4). The Neighbor ID and the
Neighbor IP address of the secondary neighbor's data structure are
copied from the Advertising Router field and IP Address fields of the
mlink Type 9 LSA.
5.2 The Secondary Neighbor State Machine
While secondary neighbor states are identical to OSPF's neighbor
states, there are a few important distinctions in their actions and
the events which trigger them. When a primary interface receives an
new mlink Type 9 LSA from a primary neighbor, the LSA's content may
create a new secondary neighbor, destroy an existing secondary
neighbor or modify the state of an existing secondary neighbor. For
point-to-point and point-to-multipoint secondary network types, a new
secondary neighbor is always established. For NBMA secondary network
types, the decision whether or not to create a new secondary neighbor
depends on whether either the local router or the originating router
are DR eligible (See Section 5.3). A router must clear its own mlink
Type 9 LSAs from the database summary list of a primary neighbor
during database exchange to ensure that its corresponding secondary
neighbor relationships transition out of Down state. A secondary
neighbor state machine always passes through Attempt state, even for
point-to-point and point-to-multipoint secondary interface network
types (See Section 5.3 and 5.4).
If an mlink Type 9 LSA ages out, the KillNbr event is executed for
the corresponding secondary neighbor, and the LSA should be flushed.
If the state of the neighbor is 2-way or higher, the local router
should send a Hello packet to the secondary neighbor which omits it
from the neighbor list (See Section 5.5). The conditions which cause
the execution of the KillNbr and LLDown events for primary neighbors
should trigger the same events for any of their corresponding
secondary neighbors.
Murphy [Page 9]
Internet Draft OSPF Multiple Area Links February 2002
Since the formation of secondary neighbors is linked with the
database exchange and the link state update of the mlink Type 9 LSAs
received across the primary link, the timing of this exchange effects
when a secondary neighbor transitions to ExStart state. The mlink
Type 9 LSA of a secondary Area 0 should be listed at the top of the
database summary list. The mlink Type 9 LSAs of non-backbone
secondary areas should be listed at the bottom of the database
summary list. These tools mitigate the effect of the database
exchange by non-backbone secondary areas on the primary neighbor
state machine as it transitions to Full state, while at the same time
letting an Area 0 secondary neighbor state machine proceed to Full
state roughly in parallel with the primary neighbor state machine.
5.3 Receiving Mlink Type 9 Neighbor Discovery LSAs
This section explains the detailed processing of a received mlink
Type 9 LSA. Note that any mlink Type 9 LSAs received across a
secondary interface are simply ignored. Thus two neighbors which
don't agree on the primary area will never form either primary or
secondary adjacencies.
When an mlink Type 9 LSA is acknowledged during a primary neighbor's
database exchange or received via link state update, its Secondary
Area ID is checked against those listed in the primary interface's
SecondaryAreas parameter. If it is not listed processing of this LSA
stops. If it is listed, for point-to-multipoint and transit networks
the originator of the mlink Type 9 LSA should be on the same network
as the receiving interface. This can be verified by comparing the
mlink Type 9 LSA's IP address field with the IP address of the
primary interface, after masking both addresses with the interface
mask. If a match does not occur processing of this LSA stops.
Next check for the existence of a secondary neighbor in the current
list of secondary neighbors contained in the corresponding secondary
interface data structure. If a matching secondary neighbor data
structure cannot be found, (i.e. this is the first time the secondary
neighbor has been detected), and if the secondary network type is
either point-to-point or point-to-multipoint or the secondary network
type is NBMA and either the local router or the originating router is
DR eligible across the secondary NBMA, then create a secondary
neighbor data structure for the neighbor described in the mlink Type
9. The Neighbor ID and the Neighbor IP address of the secondary
neighbor data structure are copied from the Advertising Router and IP
Address fields of the mlink Type 9 LSA. The initial state of the
newly created secondary neighbor is set to Down. If the secondary
network type is point-to-point or point-to-multipoint, or the
secondary network type is NBMA and both the local router and the
originating router are DR eligible (as defined the secondary neighbor
Murphy [Page 10]
Internet Draft OSPF Multiple Area Links February 2002
data structure and the newly received mlink Type 9 LSA) then execute
a Start event for the newly created secondary neighbor.
5.4 Receiving Secondary Hello Packets
The processing of Secondary Hello Packets proceeds as described in
[OSPF] Section 10.5 with just a few exceptions. If a Secondary Hello
Packet is received from a non-existent secondary neighbor the
processing of the Hello Packet stops and the packet is dropped.
Secondary neighbor data structures are created by the processing of
received mlink Type 9 LSAs (See Section 5.4). If a Secondary Hello
Packet is received with a router priority which does not match that
of the mlink Type 9 LSA which created the secondary neighbor, a 1-
WayReceived event should be executed.
6.0 Advertising Secondary Adjacencies
A Border router advertises its secondary adjacencies in the router-
LSAs of its configured secondary areas as point-to-point links even
though they may be secondary NBMA links. Any stub or transit networks
shared by the primary link with its secondary links are never
advertised in the router-LSAs of its secondary areas. This allows
these stub and transit networks to retain a single area identity.
Noting that a secondary interface does share the IP address of its
corresponding primary interface, when adding the secondary link to
the router LSA [OSPF] Section 12.4.1.1 is reduced to simply
If a neighboring router has formed a secondary adjacency then add
a type 1 (point-to-point) link for this adjacency. Its Link ID
should be set to the Router ID of the neighboring router. If the
corresponding primary interface is numbered, the Link Data should
specify the primary interface's IP address. If the primary
interface is unnumbered, the Link Data field should specify the
interface's MIB-II [MIB] ifIndex value. The cost should be set to
the configured output cost of the corresponding secondary
interface.
7.0 The Shortest Path First Calculation
Since secondary links appear in the link state data base of an area
as point-to-point links there is no change required in the Shortest
Path First (SPF) calculation, except on those border routers where
they are configured. Border routers do not include in a secondary
area's SPF tree any network which one of its secondary adjacencies
transit. This ensures synchronization of the SPF tree amongst the
secondary area's other routers. However border routers do use the IP
addresses stored in their secondary neighbors' router-LSAs for
determining a destination's next hop across a secondary link when the
Murphy [Page 11]
Internet Draft OSPF Multiple Area Links February 2002
associated interface connects to a point-to-multipoint or transit
network. In this case the outgoing interface is derived directly from
the destination router's next hop IP address.
8.0 Flushing Secondary Adjacencies
Secondary adjacencies are flushed from the link state database of a
secondary area when their neighbors transition down from Full state,
just as with normal OSPF adjacencies. A new router-LSA is built for
the secondary area and flooded out all of the secondary area's
primary and secondary interfaces. Finally the SPF calculation is
performed to reflect the new link state topology.
9.0 Security Considerations
Security issues are not discussed in this memo.
10.0 Acknowledgments
This document was produced by the OSPF Working Group, chaired by John
Moy. Most notably, Acee Lindem, Redback Networks, provided
outstanding input which substantially simplified this document from
its previous incarnations.
11.0 References
[MIB] McCloghrie, K., and M. Rose, "Management Information Base for
network management of TCP/IP-based internets: MIB-II", STD
17, RFC 1213, Hughes LAN Systems, Performance Systems
International, March 1991.
[OPAQ] Coltun, Rob, "The OSPF Opaque LSA Option", FORE Systems,
August 1998.
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, Ascend Communications,
Inc., April 1998.
12.0 Author's Address
Pat Murphy
US Geological Survey
345 Middlefield Road, Mail Stop 870
Menlo Park, California 94560
Phone: (650)329-4044
EMail: pmurphy@noc.usgs.net
Murphy [Page 12]
Internet Draft OSPF Multiple Area Links February 2002
Router-LSAs are Type 1 LSAs. Each router in an area originates a
router-LSA. The router-LSA describes the state and cost of the
router's links (i.e., interfaces) to the area. All of the router's
links to an area, including secondary links, must be described in a
single router-LSA. For details concerning the construction of
router-LSAs see this document's Section 6.0 and [OSPF] Section
12.4.1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
In router-LSAs, the Link State ID field is set to the router's OSPF
Router ID. Router-LSAs are flooded throughout a single area only.
bit V
When set, the router is an endpoint of one or more fully
adjacent virtual links having the described area as its
transit area (V is for virtual link endpoint).
Murphy [Page 13]
Internet Draft OSPF Multiple Area Links February 2002
bit E
When set, the router is an AS boundary router (E is for
external).
bit B
When set, the router is an area border router (B is for
border).
bit W
When set, the router is a wild-card multicast receiver (W is
for wild).
bit Nt
When set, the router is a NSSA border router which translates
type-7 LSAs into type-5 LSAs (Nt is for NSSA translation).
# links
The number of router links described in this LSA. This must be
the total collection of router links (i.e., interfaces) to the
area including a separate entry for each fully adjacent
secondary neighbor, regardless of its secondary link's network
type.
The following fields are used to describe each router link (i.e.,
interface). Each router link is typed (see the below Type field). The
Type field indicates the kind of link being described. It may be a
link to a transit network, to another router or to a stub network.
The values of all the other fields describing a router link depend on
the link's Type. For example, each link has an associated 32-bit Link
Data field. For links to stub networks this field specifies the
network's IP address mask. For other link types the Link Data field
specifies the router interface's IP address.
Type
A quick description of the router link for one of the
following. Note that host routes are classified as links to
stub networks with network mask of 0xffffffff. Secondary
router links are always type 1 point-to-point even when they
have secondary NBMA network type.
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual link
Murphy [Page 14]
Internet Draft OSPF Multiple Area Links February 2002
Link ID
Identifies the object that this router link connects to. Its
value depends on the link's Type. When connecting to an object
that also originates an LSA (i.e., another router or a transit
network) the Link ID is equal to the neighboring LSA's Link
State ID. This provides the key for looking up the
neighboring LSA in the link state database during the routing
table calculation. See [OSPF] Section 12.2 for more details.
Type Link ID
______________________________________
1 Neighboring router's Router ID
2 IP address of Designated Router
3 IP network/subnet number
4 Neighboring router's Router ID
Link Data
Value again depends on the link's Type field. For connections
to stub networks, Link Data specifies the network's IP address
mask. For unnumbered point-to-point connections, it specifies
the interface's MIB-II [MIB] ifIndex value. For the other link
types it specifies the router interface's IP address. This
latter piece of information is needed during the routing table
build process, when calculating the IP address of the next
hop. Recall a secondary router link (Type 1) shares the IP
address of its corresponding primary interface, if it exists.
Otherwise it is an unnumbered point-to-point connection. See
Section 6.0 of this document and [OSPF] Section 16.1.1 for
more details.
# TOS
The number of different TOS metrics given for this link, not
counting the required link metric (referred to as the TOS 0
metric in [1583]). For example, if no additional TOS metrics
are given, this field is set to 0. Secondary Areas do not use
TOS.
metric
The cost of using this router link. For secondary links the
cost is specified in the secondary interface data structure.
Additional TOS-specific information may also be included, for
backward compatibility with previous versions of the OSPF
specification ([1583]). Within each link, and for each desired TOS,
TOS-specific link information may be encoded as follows:
Murphy [Page 15]
Internet Draft OSPF Multiple Area Links February 2002
TOS
IP Type of Service that this metric refers to. The encoding of
TOS in OSPF LSAs is described in [1583] Section 12.3.
TOS metric
TOS-specific metric information.
Murphy [Page 16]
Internet Draft OSPF Multiple Area Links February 2002
Appendix B. Mlink Type 9 Neighbor Discovery LSAs
Mlink Type 9 LSAs are used directly by OSPF to distribute lists of
candidate secondary areas among neighboring routers. Mlink Type 9
LSAs are flooded across the primary interface. The flooding scope of
an mlink Type 9 LSAs is link-local, which means mlink Type 9 LSAs are
never flooded beyond the local (sub)network or router link.
Sections 4.0 and 5.3 of this document describe the purpose of these
mlink Type 9 LSAs in more detail.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sec Rtr Pri | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Syntax of the mlink Type 9 LSA's Link-State ID
The link-state ID of an mlink Type 9 LSA is divided into an Opaque
Type field (the first 8 bits), which has value mlink, and the
Opaque ID (the remaining 24 bits). The mlink Type 9 LSA of each
of the primary interface's secondary areas must have a unique
opaque ID. The last 24 bits of the Secondary Area ID will normally
produce unique Opaque IDs. When it doesn't, alter the least
significant bits until uniqueness is achieved.
Options
The optional capabilities supported by this router for the
primary area, as documented in [OSPF] Section A.2.
Secondary Area ID
The area ID of the area across which a neighboring router may
form a secondary adjacency.
Murphy [Page 17]
Internet Draft OSPF Multiple Area Links February 2002
IP Address
The IP Address of the secondary area's corresponding primary
interface. If the primary interface has unnumbered point-to-
point type, then IP Address should be set to 0.
Sec Rtr Pri
This router's Designated Router priority for a secondary link
across a transit network. This parameter is used during the
secondary links (Backup) Designated Router election. If set to
0, the router will be ineligible to become the (Backup)
Designated Router for this secondary link.
Murphy [Page 18]
Internet Draft OSPF Multiple Area Links February 2002
Appendix C. Interface Data Structure
Chapter 9 in the OSPF specification documents the interface data
structure and the data items which are included in it. Section 3.1 of
this document defines a new interface configuration parameter called
SecondaryAreas which supports OSPF Multiple Area Links. The
SecondaryAreas interface parameter lists a set of areas which may
form secondary adjacencies across the interface. The SecondaryAreas
parameter's default setting is null. If a virtual link is configured
across a transit area linked to an interface, then Area 0 may not be
configured in the interface's SecondaryAreas parameter.
Each area listed in the SecondaryAreas interface parameter should
have a secondary interface data structure. With the exception of Area
ID all of secondary interface parameters which are usually
configurable, such as interface cost, authentication parameters and
Designated Router priority, default to the values assigned to the
primary interface. Furthermore, except for the Area ID, IP interface
address and mask, all configurable interface parameters should be
separately configurable for each secondary interface. The
SecondaryAreas parameter in a secondary interface data structure is
always null.
Murphy [Page 19]
