draft-ietf-ospf-mlinks-00.txt   draft-ietf-ospf-mlinks-01.txt 
Network Working Group P. Murphy Network Working Group P. Murphy
Internet Draft US Geological Survey Internet Draft US Geological Survey
Expiration Date: December 1998 July 1998 Expiration Date: February 2000 August 2000
File name: draft-ietf-ospf-mlinks-00.txt File name: draft-ietf-ospf-mlinks-01.txt
OSPF Multiple Area Links Unnumbered OSPF Multiple Area Links
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working 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, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
"1id- abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or The list of Internet-Draft Shadow Directories can be accessed at
ftp.isi.edu (US West Coast). http://www.ietf.org/shadow.html.
Table Of Contents Table Of Contents
1.0 Abstract ................................................. 1 1.0 Abstract ................................................. 1
2.0 Overview ................................................. 2 2.0 Overview ................................................. 2
2.1 Requirement for OSPF Multiple Area Links ................. 2 2.1 Requirement for Unnumbered OSPF Multiple Area Links ...... 2
2.2 Proposed Solution ........................................ 3 2.2 Proposed Solution ........................................ 3
3.0 Implementation Details ................................... 6 2.2.1 Secondary Adjacencies .................................... 4
3.1 SecondaryAreas Interface parameter ....................... 6 2.2.2 Secondary Neighbor Discovery ............................. 4
3.2 Advertising Secondary Areas .............................. 6 2.2.3 Advertising Secondary Links .............................. 5
3.3 Forming Secondary Adjacencies ............................ 7 2.3 Application .............................................. 5
3.4 Advertising Secondary Adjacencies ........................ 7 3.0 Secondary Interfaces ..................................... 5
3.5 Secondary Area Link State Data Base Exchange and Update .. 8 3.1 The SecondaryAreas Interface parameter ................... 5
3.6 The Shortest Path First Calculation ...................... 9 3.2 The Secondary Interface Data Structure ................... 6
3.7 Flushing Secondary Adjacencies ........................... 9 3.3 The Secondary Interface State Machine .................... 6
4.0 Acknowledgments .......................................... 10 3.4 OSPF Protocol Packet Processing .......................... 7
5.0 References ............................................... 10 3.5 Designated Router Selection and Function ................. 7
6.0 Security Considerations .................................. 10 4.0 Synchronizing Secondary Areas Using Mlink Type-9 LSAs .... 8
7.0 Authors' Addresses ....................................... 10 5.0 Secondary Neighbors ...................................... 9
Appendix A: Router LSAs ...................................... 11 5.1 The Secondary Neighbor Data Structure .................... 9
Appendix B: mlink Opaque LSAs ................................ 13 5.2 The Secondary Neighbor State Machine ..................... 10
Appendix C: Configuration Parameters ......................... 14 5.3 Events Triggered by the Primary Neighbor State Machine.... 11
5.4 Receiving Hello Packets .................................. 11
5.5 Receiving Mlink Type-9 Neighbor Discover LSAs ............ 12
6.0 Advertising Secondary Adjacencies ........................ 13
7.0 The Shortest Path First Calculation ...................... 14
8.0 Flushing Secondary Adjacencies ........................... 14
9.0 Security Considerations .................................. 15
10.0 Acknowledgments .......................................... 15
11.0 References ............................................... 15
12.0 Authors' Addresses ....................................... 15
Appendix A: Router-LSAs ........................................ 16
Appendix B: Mlink Type-9 Neighbor Discover LSAs ................ 20
Appendix C: Configuration Parameters ........................... 23
1.0 Abstract 1.0 Abstract
This memo describes an option to the OSPF Version 2 specification This memo describes an option to the OSPF Version 2 specification
which allows multiple areas to share the same link. This option adds which allows multiple areas to share the same OSPF interface and
no additional link state flooding over shared links other than the links. One area is always configured as an interface's primary area.
normal link state database exchange and update originating from the The interface's remaining areas are termed secondary and view it as
link's configured primary area. The option applies to standard areas, unnumbered. Two border routers adjacent across the same secondary
stub areas, and NSSAreas. It eliminates the excess Area 0 link state area may forward the area's intra-area traffic across its secondary
baggage that accompanies the use of virtual links as currently links. This option applies to standard areas, stub areas, and NSSAs.
practiced when configuring similar transits for standard OSPF areas. It works over any OSPF interface. Routers with this option
Routers with this option configured are backward compatible with configured are backward compatible with routers running the standard
routers running the standard OSPF Version 2 compliant implementation OSPF Version 2 compliant implementation as defined in RFC 2328.
as defined in RFC 2328, and can be restricted to a subset of the OSPF
routing domain. This option is applied only on OSPF border routers.
Implementation of OSPF multiple area links requires a modification to
the OSPF interface data structure which allows each interface of a
border router to be connected to multiple areas. One area is always
configured as the interface's primary area. Any additional areas
which are configured for an interface are called the interface's
secondary areas. Two adjacent border routers with mutually shared
secondary areas may transit a secondary area's intra-area traffic
over the adjacency. A typical application is a stub area or NSSArea
which is dual homed to the Area 0 backbone and loosely joined by an
internal slow speed link. If there exists a high speed Area 0 link
between two of the stub area's border routers, this option allows the
stub area's intra-area traffic to route across this high speed area 0
link. The current specification forces traffic to prefer the intra-
area path over the slow speed link.
Another not so common application makes Area 0 the secondary area
over a local high speed LAN link with the primary area a local stub
or NSSArea. Here Area 0 is not primary due to topological
limitations which restrict its applicability. E.g. the local LAN link
could be a campus backbone with dozens of routers on it, all part of
the same NSSArea.
Please send comments to ospf@discuss.microsoft.com. Please send comments to ospf@discuss.microsoft.com.
2.0 Overview 2.0 Overview
2.1 Requirement for OSPF Multiple Area Links 2.1 Requirement for Unnumbered OSPF Multiple Area Links
Large corporate networks in todays modern Internet invest tremendous Large corporate networks in today's modern Internet have tremendous
human and equipment resources, coupled with sizable budget, into human and equipment resources coupled with sizable budget invested in
their backbone infrastructure. Their regional networks are normally their backbone infrastructure. Their regional networks are normally
not so fortunate, and must multi-home to the backbone in order to not so fortunate and must multi-home to the backbone in order to take
take advantage of the backbone's high speed and high reliability advantage of the backbone's faster and more reliable network links.
network links. Performance over a T1 link can pale by comparison to Performance over a T1 link can pale by comparison to performance over
performance over a DS3 or OC3 backbone link. Indeed, even a high a DS3 or OC3 backbone link. Large corporate networks have sizable
speed 100 megabit LAN link can carry an order of magnitude more backbone routing tables and routinely use stub areas and NSSAs. Under
traffic than a standard 10 megabit link. Large corporate networks the current OSPF specification intra-area routes are always preferred
have sizable backbone routing tables and routinely use stub areas and over inter-area routes even when the traffic is sourced from and
NSSAreas. Under the current OSPF specification intra-area routes are destined to the same non-backbone OSPF area.
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: Consider the following typical OSPF example:
A0-----------Area 0 link------------B0-------N1 A0-----------Area 0 link------------B0-------N1
| DS3 | | DS3 (1) | (2)
| | | |
|NSSArea 1 link NSSArea 1 link| |NSSA 1 link NSSA 1 link|
| T1 T1 | | T1 (28) T1 (28) |
| | | |
| | | |
A1---------NSSArea 1 link-----------B1-------M1 A1-----------NSSA 1 link------------B1-------M1
T1 512k (56) (2)
where A0 and B0 are border routers attached to NSSArea 1. A1 and B1 where A0 and B0 are border routers attached to NSSA 1. A1 and B1 are
are internal routers in NSSArea 1. N1 and M1 are standard ethernet internal routers in NSSA 1. N1 and M1 are standard ethernet networks
networks in NSSArea 1 directly attached to B0 and B1 respectively. in NSSA 1 which are directly attached to B0 and B1 respectively. The
Assume all T1 links have an OSPF cost of 28 in both directions, N1 cost of each link is shown in parentheses. All OSPF costs are
and M1 are attached with interface costs 2. The DS3 link has an OSPF symmetric. Under the current OSPF specification the preferred path
cost of 1. All costs are symmetric. Under the current OSPF between A0 and M1 is
specification the preferred path between A0 and M1 is
A0<->A1<->B1<->M1 A0<->A1<->B1<->M1
with OSPF cost 58, even though there exists a more preferred path with an OSPF cost of 86, even though there exists a more preferred
through B0 namely path through B0 namely
A0<->B0<->B1<->M1 A0<->B0<->B1<->M1
with OSPF cost 31. Indeed the DS3 link between A0 and B0 has the with an OSPF cost of 31.
potential of making the performance between A0 and B1 approach that
of a single T1.
Consider also the NSSArea 1 OSPF preferred path between A1 and N1, In addition the NSSA 1 OSPF preferred path between A1 and N1 is
A1<->B1<->B0<->N1, A1<->B1<->B0<->N1,
with an OSPF cost of 86, even though there exists a more preferred
with cost 58. Again there exists a more preferred path through the path through the link between A0 and B0, namely
link between A0 and B0, namely
A1<->A0<->B0<->N1 A1<->A0<->B0<->N1
with cost 31. This link also has the potential of performing at with an OSPF cost of 31. Under the current OSPF specification NSSA
single hop T1 speeds. Under the current OSPF specification NSSArea
1's router A1 does not even see this path to N1 since it has no 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 knowledge of Area 0's topology. A0, on the other hand, would at lease
lease see the summary LSA of N1, but still cannot take advantage of see the summary LSA of N1, but still cannot take advantage of it due
it due to OSPF intra-area path preference. to OSPF intra-area path preference.
What is needed is a tool which makes the Area 0 link between A0 and What is needed is a tool which makes the Area 0 link between A0 and
B0 visible in NSSArea 1. Virtual links are not an option since B0 visible inside NSSA 1. A common practice is to use multiple
virtual links don't work over NSSAreas. If the link between A0 and B0 interface subnets. However this is not an option when the path
were part of NSSArea 1, path preference would be optimal as the DS3 between A0 and B0 is unnumbered or when one desires that the NSSA 1
path would be intra-area for NSSArea 1. This cannot be the non- path between A0 and B0 be unnumbered. Moreover when configuring
backbone equivalent of an Area 0 virtual link. Excessive use of such multiple interface subnets over multi-access networks, inverse-arp
a feature would negate the purpose of the Area 0 backbone. 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. These tools also burden the
physical link with the simultaneous database exchange of multiple
OSPF interfaces during adjacency formation.
The Unnumbered 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. Furthermore it prioritizes database
exchange, giving preference to the primary area and Area 0 over other
non-backbone secondary areas. 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 2.2 Proposed Solution
OSPF multiple area links provide the capability of allowing multiple The Unnumbered OSPF Multiple Area Links option lets multiple areas
areas to use the same link/path between two border routers for use the same link between two border routers for intra-area traffic.
intra-area traffic. Traffic may originate from inside each of the Traffic may originate from inside each of the configured areas, as
configured areas, as every router in the configured areas sees the every router in the configured areas sees the link as part of its
link/path as part of its link state topology. Only areas which are link state topology. Routers with configured unnumbered OSPF multiple
dual homed to Area 0 may take advantage of this option, since any area links must be in Area 0, although the connection to Area 0 may
router with multiple directly attached areas must be in Area 0 and it be an unnumbered OSPF multiple area link.
takes at least two such border routers to create a multiple area
link.
The current OSPF specification only allows one area per interface. The current OSPF specification only allows one area per OSPF
Thus, should an Area L dual-home to two Area 0 border routers which interface. Thus, should an Area L dual-home to Area 0 via two border
are adjacent over another Area K's router<->router link or router<- routers which are adjacent over another Area K's router<->router link
>network link, the adjacent link over Area K is not seen inside Area or router<->network link, the adjacent link over Area K is not seen
L, even though the two border routers exist physically adjacent inside Area L, even though the two border routers exist physically
within Area L. This coupled with intra-area route preference prevents adjacent within Area L. This, coupled with intra-area route
Area L from utilizing Area K's adjacent link. preference, prevents Area L from utilizing Area K's adjacent path.
The softening of this restriction is facilitated by the addition of a 2.2.1 Secondary Adjacencies
new parameter to the interface data structure called SecondaryAreas.
The SecondaryAreas interface parameter is a self-defining structure
containing a list of Area Ids for additional areas in which the
interface also belongs, along with their associated OSPF costs. The
areas listed in this parameter are called the interface's secondary
areas, as opposed to the interface's configured Area ID, hereafter
called the primary area. For each secondary area listed in the
SecondaryAreas parameter there is a list of neighboring Router Ids
which have formed adjacencies for the secondary area across the
interface's directly attached network or router link. These
adjacencies are called secondary adjacencies. Secondary adjacencies
are formed during the primary area's link state data base exchange
and update as defined in Sections 3.2 and 3.3.
A type 9 Opaque LSA is used to exchange/update the interface's The softening of this restriction is facilitated by the addition of a
secondary areas with adjacent Opaque capable border routers. Until an new interface configuration parameter called SecondaryAreas. This
opaque type is assigned for this option, it will be simply referred parameter specifies a list of additional areas in which an OSPF
to as an mlink type 9 opaque LSA. A type 9 opaque LSA is used because interface also belongs (See Appendix C). The areas listed in this
the flooding scope of the mlink type 9 opaque LSA needs to be parameter are called the interface's secondary areas, as opposed to
restricted to those routers directly attached to a common network or the interface's configured area, hereafter called the primary area. A
router link. Each router will list its configured secondary addresses separate interface data structure is generated for each of the
as defined by the interface's SecondaryAreas parameter in its mlink secondary areas. For each secondary area listed in the SecondaryAreas
type 9 opaque LSA. The mlink type 9 opaque LSA is propagated during parameter a router can form OSPF adjacencies with the primary area's
the primary area's link state data base exchange and update with its neighboring routers across the interface's directly attached network
fully adjacent neighbors. If a router A receives an mlink type 9 or router link. These adjacencies are called secondary adjacencies.
opaque LSA from an adjacent router B during primary area K's link
state data base exchange, then router A and B form a secondary
adjacency in area L if and only if
1) Area L is listed in the interface's SecondaryArea parameter. Secondary adjacencies are formed after the primary area's link state
data base exchange has synchronized matching secondary areas with any
of its primary neighbors (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 over an interface which is linked to a transit area for a
configured virtual link.
2) Area L is listed in router B's received mlink type 9 opaque 2.2.2 Secondary Neighbor Discovery
LSA.
3) Router A contains a type 1 (router) LSA from router B in Area A Type-9 opaque LSA is used to form secondary adjacencies over a
L's link state data base. 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. Included in a
secondary area's mlink Type-9 LSA is the secondary area's configured
optional capabilities, its authentication parameters, plus, if
required, its 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 routers A and B form a secondary adjacency then the router ID of If a router A receives an mlink Type-9 LSA for area L originating
router B is added to Area L's list of secondary adjacencies for the from a router B during the exchange/update of primary area K's LSDB,
interface. then router A may form a secondary adjacency in area L with router B
provided the LSA's optional capabilities and authentication
parameters match those configured for the secondary area in the
SecondaryAreas parameter. 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.
Secondary adjacencies are either point-to-point or point-to- 2.2.3 Advertising Secondary Links
multipoint. Any intervening transit networks always belong to the
interface's primary area. There is no network LSA for a secondary
adjacency's intervening transit network in the secondary area. Hence
all secondary adjacencies for Area L must be advertised in router A's
type 1 (router) LSA with unnumbered point-to-point type.
During the Dykstra SPF calculation the LSAs for secondary adjacencies Secondary adjacencies are advertised as point-to-point or point-to-
look like unnumbered point-to-point links, except on border routers multipoint links. Any intervening transit network always belongs to
where they originate. A Border router never includes in a secondary the interface's primary area. Moreover, there is no network LSA for a
area's SPF tree any network across which one of its secondary secondary adjacency's intervening transit network in the secondary
adjacencies span. This ensures synchronization of the SPF tree area. Hence all secondary adjacencies must be advertised in a
amongst the secondary area's routers. However border routers do use router's router-LSA with unnumbered point-to-point type.
the IP addresses stored in neighboring border router LSAs for
determining link paths across a multi-access secondary adjacency.
There is no secondary link state data base exchange or update over During the Dykstra shortest path first (SPF) calculation the LSAs for
secondary adjacencies. Instead, these adjacencies rely on the secondary adjacencies look like unnumbered point-to-point links. A
secondary area's base topology (minus the secondary links) for Border router never includes in a secondary area's SPF tree any
flooding link state information regarding an area's secondary network across which one of its secondary adjacencies span. This
adjacencies. The reasons for not attempting a secondary link state ensures synchronization of the SPF tree amongst the secondary area's
data base exchange/update are two fold. First, the goal of this routers. However border routers may use the IP addresses of
document is to establish a transit for multiple areas over a single neighboring routers for determining a destination's next hop across a
link without imposing the additional traffic load caused by passing secondary link over a point-to-multipoint or transit network.
the secondary area's link state database over that link. Second the
added complexity of synchronizing multiple secondary area link state
databases over the link is unnecessary when the primary area is the
Area 0 backbone. Should the secondary area partition, traffic between
the two parts of the partitioned secondary area would still use the
secondary adjacent link via OSPF inter-area routing.
It is true that routing between the different parts of a secondary 2.3 Application
area partitioned by a defunct secondary adjacency over an Area 0 link
would be based on the inter-area route computation results from
processing summary links. Summary-range aggregation may over simplify
routing between the different parts of a partitioned area. However
this is no different that what exists under the current OSPF base
standards. Furthermore, the proper partitioning of a secondary area's
assigned address space not only allows the summary-range aggregates
to effect proper routing during topological failures, but it also
promotes more cost effective and efficient routing even when
secondary areas are whole.
Consider now the example mentioned in Section 2.3 and assume Area 1 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 is configured as a secondary area over the Area 0 link between A0 and
B0. The NSSArea 1 intra-area shortest path first tree computed by the B0. Since the routers A0, A1, B0, and B1 possess NSSA 1's router-LSAs
Dykstra calculation now includes the DS3 link between A0 and B0 with originating from A0 and B0 which define a secondary link between A0
a cost of 1. Given that all four routers possess link state and B0 in NSSA 1, the NSSA 1 intra-area SPF tree computed by the
advertisements for the link between A0 and B0 in NSSArea 1, the path Dykstra calculation now includes this DS3 link with a cost of 1. Thus
between A0 and M1 is now the path between A0 and M1 is the more preferred path
A0<->B0<->B1<->M1 A0<->B0<->B1<->M1
and the path between A1 and N1 is and the path between A1 and N1 is the more preferred path
A1<->A0<->B0<->N1 A1<->A0<->B0<->N1
Furthermore, should the link between A1 and B1 fail terminating the 3.0 Secondary Interfaces
NSSArea 1's secondary adjacency between A0 and B0, the path between
A0 and M1 would still be
A0<->B0<->B1<->M1, 3.1 The SecondaryAreas Interface Parameter
as the summary LSA for M1 originating from B0 forms an inter-area A new configuration parameter called SecondaryAreas has been added to
path to M1. the OSPF interface data structure (See Appendix C). The
SecondaryAreas interface parameter lists a set of areas which may
form unnumbered 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. For each secondary area listed in
the SecondaryAreas interface parameter the interface cost,
authentication parameters, and Designated Router priority are also
configurable. The SecondaryAreas' interface costs and the Designated
Router priorities default to the values assigned to the primary
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.0 Implementation Details 3.2 The Secondary Interface Data Structure
3.1 SecondaryAreas Interface parameter 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 bound to the
primary interface. The configured primary area of an OSPF interface
generates its primary interface data structure. Recall [OSPF]
Sections 8.2 and 10.5 imply that a point-to-point layer 2 link
between two routers may have only one OSPF interface per area.
Additional areas may be added as secondary areas, but they must not
duplicate areas already configured for the layer 2 link.
A new parameter called SecondaryAreas is added to the OSPF interface A secondary interface's list of neighboring routers is generated by
data structure. Implementations must support the manual configuration examining the primary interface's received mlink Type-9 LSAs as
of this parameter. The SecondaryAreas interface parameter lists the defined in Section 4.0 below. Before a neighboring router may be
set of Areas which can form secondary adjacencies over the interface, added to the secondary interface's list of neighboring routers it
complete with their secondary area interface costs. By default a must also occur in the primary interface's list of neighboring
secondary area's interface cost is set to the value of the routers.
interface's primary area cost. Only those Areas listed in the
SecondaryAreas interface parameter are candidate areas for the
interface's secondary adjacencies. 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.
For each secondary area listed in the SecondaryAreas interface Secondary interfaces copy their interface type from the primary
parameter, there is a list of Router Ids which have formed secondary interface's data structure and still compute a Designated Router and
adjacencies to the router over the interface. These Routers Ids a Backup Designated Router over broadcast and NBMA networks. This
should also be listed in the interface's list of neighboring routers. promotes efficient flooding across a primary interface's transit
If the list of Router Ids is null, then the interface has no network. However, these network links are always advertised as
secondary adjacencies for this secondary area. This list is unnumbered router<->router links and behave exactly like point-to-
populated as defined in Section 3.3 below. multipoint interfaces. As such a secondary link's Designated Router
does not originate a type-2 network LSA into the secondary area for
the primary interface's transit network.
3.2 Advertising Secondary Areas 3.3 The Secondary Interface State Machine
All routers which support secondary areas must also be opaque The interface states of a secondary interface are the same as the
capable. If the interface is of broadcast type, then all candidate interface states of a primary interface. However in some cases state
designated routers must be opaque capable, even if they have no transitions are triggered by the primary interface's state machine.
secondary areas configured for the interface which connects to the The InterfaceUp event is redefined for secondary links:
broadcast transit network. Otherwise type 9 opaque LSAs, which are
used by this option, will not propagate to all potential routers
capable of forming secondary adjacencies over the broadcast transit
network. Note that candidate designated routers do not have to
support OSPF multiple area links, but they do have to be opaque
capable in order to flood the type 9 opaque LSA to their adjacent
neighbors who may or may not support OSPF multiple area links.
Any router which has an interface with a non-empty SecondaryAreas InterfaceUp
interface parameter must advertise a type 9 opaque LSA with opaque
type mlink to the interface's fully adjacent neighbors. The mlink
type 9 opaque LSA contains the Area Ids listed in the interface's
SecondaryAreas parameter as Opaque Information. See Appendix B for
details. If an interface's SecondaryAreas parameter is null, then the
mlink type 9 opaque LSA should not be advertised.
By default, the mlink opaque type sets it opaque ID to the last 24 This event is triggered by the primary interface when it
bits of the interface's IP address, if it has one. In the case of transitions to either Point-to-point, DR Other, DR, or Backup
unnumbered point-to-point connections, the mlink opaque ID is set to state. Its effect on the secondary interface's state is similar to
the last 24 bits of the interface's MIB-II [MIB] ifIndex value. All the effect the InterfaceUp event has on the primary interface's
implementations should also support the manual configuration of an state with one exception. The periodic sending of Hello packets is
interface's mlink opaque ID in the rare instance this default schema suppressed for a secondary interface. If the primary interface
results in duplication. network is a physical point-to-point or point-to-multipoint
network, then the secondary interface transitions to Point-to-
point state. Else if the router is not eligible to become the
Designated Router, the interface state transitions to DR Other.
3.3 Forming Secondary Adjacencies Otherwise the attached primary network is a broadcast or NBMA
network and the router is eligible to become a Designated Router
for the secondary area. In this case, an attempt is made to
discover the attached network's Designated Router for the
secondary area. The interface state is set to Waiting and the
single shot Wait Timer is started.
Two border routers A and B in area L may form a secondary adjacency The events BackupSeen and NeighborChange for a secondary interface
across an interface, whose primary area is K, under the following are triggered during the processing of the primary interface's
conditions: received mlink Type-9 LSAs in very much the same way these events are
triggered for a standard OSPF interface during the processing of
received Hello Packets (See Section 5.5).
(a) Routers A and B are fully adjacent across the interface's The events InterfaceDown, LoopInd, UnloopInd, and Wait Timer are
primary area K or they share a common area K full adjacency unchanged for secondary interfaces. Note that since the secondary
with the interface's designated router. 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.
(b) Routers A and B see router LSAs (type-1) for each other in 3.4 OSPF Protocol Packet processing
Area L's link state data base.
(c) Routers A and B have exchanged/updated mlink type 9 opaque Since secondary interfaces are unnumbered interfaces, OSPF protocol
LSAs across the interface both of which contain Area L as a packet processing needs a minor adjustment. For point-to-point
candidate secondary area. networks there are no changes. 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).
When all three conditions are met, a secondary adjacency is formed 3.5 Designated Router Selection and Function
between routers A and B across the interface's primary area. There is
no particular ordering of events. Either (a), (b), or (c) can trigger
the event which forms the secondary adjacency, provided the other two
conditions have already been met.
3.4 Advertising Secondary Adjacencies The election of the Designated Router and the Backup Designated
router for a secondary link over a broadcast or NBMA network proceeds
as described in [OSPF] Section 9.4. Eligibility is determined from
the Designated Router priorities defined in the SecondaryAreas
parameter and the received mlink Type-9 LSAs, as well as its
neighbors' views of the Designated Router and the Backup Designated
Router for the secondary link, which is also found in the received
mlink Type-9 LSAs. Any change in the calculating router's Designated
Router or Backup Designated Router for a secondary link will result
in the reorigination of the corresponding secondary area's mlink
Type-9 LSA.
Border routers advertise their secondary adjacencies in their router Note that the Designated Router for a secondary link does not
LSAs as unnumbered point-to-point links even though they may be originate a network-LSA (Type-2) into its secondary area for the
numbered point-to-point links, point-to-multipoint links, or transit broadcast or NBMA network over which the secondary link bridges. All
network links in their associated interface's primary area. This secondary links remain unnumbered point-to-point or point-to-
allows their interconnecting networks to retain a single area multipoint (see Section 6.0). The only function of a secondary link's
identity, thus avoiding the inevitable problems which would occur Designated Router is flooding optimization.
with duplicate summary links advertisements and aggregation. It also
makes configuration and deployment seamless.
As unnumbered point-to-point links, all secondary adjacencies have 4.0 Synchronizing Secondary Areas using Mlink Type-9 LSAs
link type 1. The building of the router LSA is described in [OSPF]
Section 12.4.1. For the purpose of building the router LSA, an
interface belongs to both its primary area and its secondary areas.
With this in mind, no change is required to [OSPF] Section 12.4.1.
Even though secondary adjacencies are considered unnumbered point- Mlink Type-9 LSAs are used to discover and maintain secondary
to-point links, for the purpose of defining Link Data in the type 1 neighbor relationships and to elect the Designated Router and Backup
(router) LSA (see Appendix A) we allow them to use the interface's IP Designated Router for multi-access secondary adjacencies. If the
address. For secondary adjacencies [OSPF] Section 12.4.1.1 is reduced primary interface is of broadcast or NBMA type then all of its
to simply 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 unnumbered 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
unnumbered OSPF multiple area links.
If a neighboring router has formed a secondary adjacency then add The format of the mlink Type-9 LSA is detailed in Appendix B. Any
a Type 1 link (point-to-point). The Link ID should be set to the router which has an interface with a non-empty SecondaryAreas
Router ID of the neighboring router. If the interface is numbered, interface parameter must originate an mlink Type-9 LSA for each
the Link Data should specify the IP interface address. For configured secondary area. If an interface's SecondaryAreas parameter
unnumbered point-to-point networks, the Link Data field should is null, then no mlink Type-9 LSAs should be advertised. A secondary
specify the interface's MIB-II [MIB] ifIndex value. The cost area's mlink Type-9 LSA minimally lists as opaque information the
should be set to the secondary area's cost of the point-to-point area's secondary area ID, its optional capabilities, its
interface as defined in the interface's SecondaryAreas parameter. authentication parameters, and, if required, its Designated Router
priority.
By not adding the type 3 links noted in [OSPF] Section 12.4.1. In addition, to ensure proper secondary neighbor state transition, a
secondary adjacencies retain the look and feel of an unnumbered secondary area's mlink Type-9 LSA also lists as opaque information
point-to-point links to the remaining routers in the secondary area, those primary neighbors from which an mlink Type-9 LSA has been
even though they may configure their link data with the interface's received for this area with matching optional capabilities and
IP address. authentication parameters (See Section 5.5). Any change in this list
will result in the reorigination of a new instance of the secondary
area's mlink Type-9 LSA. Also for broadcast and NBMA networks the
mlink Type-9 LSA lists the router's current choice for the area's
Designated Router and Backup Designated Router. A value of 0.0.0.0 in
these fields means that one has not yet been selected.
3.5 Secondary Area Link State Data Base Exchange and Update Unlike Hello Packets, a new instance of a secondary area's mlink
Type-9 LSA is only originated when the LSA's opaque information
content has changed or when the LSRefreshInterval has expired. The
LSA's content may change during the processing of received Hellos and
received mlink Type-9 LSAs, or when an mlink Type-9 LSA ages out or
when the primary interface parameters of a secondary area are
reconfigured. A new mlink Type-9 LSA is reoriginated following
expiration of its LSRefreshInterval or when changes occur in its
secondary area's interface cost, authentication parameters, router
priority, Designated Router, Backup Designated Router, or the area's
list of secondary neighbors at state greater than Init. Like other
LSAs, the reorigination of a mlink Type-9 LSA is subject to the
MinLSInterval. New mlink Type-9 LSAs are built from the list of
configured secondary areas plus their corresponding secondary
interface state machines and secondary neighbor state machines. 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.
There is no link state data base exchange or update across a The mlink Type-9 LSA of each of the primary interface's secondary
secondary adjacency. Only the interface's primary area synchronizes areas must have a unique opaque ID. The last 24 bits of the Secondary
its link state data base with the interface's neighboring routers. Area ID will normally produce unique Opaque IDs. When it doesn't,
Instead, secondary areas rely on their base topology (i.e. the alter the least significant bits until uniqueness is achieved.
topology without the secondary links), for complete flooding and
synchronization of the link state data base throughout the secondary
area. If the primary area is the area 0 backbone this is not a
problem, since the routing table entries generated by the secondary
areas summary links will forward packets when a secondary area's base
topology partitions in such a way that its secondary adjacencies are
dropped.
If the primary area is non-zero, then a simple IP over IP tunnel may 5.0 Secondary Neighbors
be configured for the secondary across the physical link. This tunnel
will perform link state data base synchronization for the secondary
area across the interface. The IP tunnel is not part of this
specification, but clearly it is advantageous to any OSPF multiple
area links implementation if tunneling of IP over IP is supported.
Note that if the tunnel is suitably configured with a high OSPF cost,
it would never be used for forwarding packets other than those
required for link state data base exchange and update. Moreover the
tunnel will always exist as long as the secondary adjacency's
physical link is active.
3.6 The Shortest Path First Calculation 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 below). Unless
discussed below details for the creation and maintenance of secondary
neighbors and secondary adjacencies are the same as discussed in
[OSPF] Sections 9 and 10.
5.1 The Secondary Neighbor Data Structure
The neighbor data structure for secondary adjacencies is identical to
the neighbor data structure for standard OSPF adjacencies. Secondary
neighbors are discovered by comparing the contents of the primary
interface's received mlink Type-9 LSAs with its configured list of
secondary areas and then comparing the secondary areas' configured
optional capabilities (see Section 5.5) with those listed for them in
the neighboring router's mlink Type-9 LSAs. A separate neighbor data
structure is built for each matching secondary area.
The Inactivity Timer used for a primary neighbor data structure is
synchronized with the Inactivity Timer for all of its configured
secondary neighbor data structures. The secondary link's Designated
Router and the Backup Designated Router, as viewed by a secondary
neighbor, are specified as opaque information stored in the
neighbor's corresponding mlink Type-9 LSA and received over the
primary interface. Also included are the neighbor's Designated Router
priority for the secondary link, its optional capabilities, and a
list of secondary neighbors it sees over the secondary link.
The secondary Neighbor ID and Neighbor IP address are copied from the
corresponding primary area neighbor data structure. The OSPF optional
capabilities which are supported by the neighboring router for the
secondary area are learned from opaque information stored in the
neighbor's mlink Type-9 LSA for this area and must match the local
router's optional capabilities configured for the secondary area.
5.2 The Secondary Neighbor State Machine
While secondary neighbor states are identical to OSPF's neighbor
states, there are some important distinctions in their actions and
the events which trigger them. Every router which is a secondary
neighbor for a secondary interface is also a primary neighbor for its
primary interface. The two neighbor data structures are loosely bound
together so that events which happen to the primary neighbor may
trigger events for the secondary neighbor.
A secondary neighbor's Init, 1-way, and 2-way state transitions are
controlled by the reception across the primary interface of Hello
Packets and mlink Type-9 LSAs (See Sections 5.4 and 5.5). The
combination of the two eliminates the requirement for the periodic
sending of Hello Packets for each secondary interface. When a primary
neighbor state machine receives a new mlink Type-9 LSA from a primary
neighbor via link state update, or confirms the status of an existing
one during database exchange, the LSA's content may create a new
secondary neighbor or effect the state of an existing secondary
neighbor. A router must clear its own mlink Type-9 LSAs from the
database summary list during database exchange with its primary
neighbors to enable its secondary neighbors to transition past Init
state. Any existing mlink Type-9 LSAs previously received from other
primary neighbors must be cleared from the database summary list
during a primary neighbor's database exchange before their content
can create new secondary neighbors or change the state of existing
secondary neighbors.
If an mlink Type-9 LSA of a primary neighbor ages out, the KillNbr
event is executed for the primary neighbor's corresponding secondary
adjacency, and the LSA should be flushed. A newly received mlink
Type-9 LSA from a primary neighbor may effect the creation of a new
secondary adjacency for the neighbor. It may also cause the
corresponding secondary neighbor to drop to 2-Way state or lower or
be destroyed altogether. (See Section 5.5)
A secondary neighbor state machine never enters Attempt state for a
NBMA secondary interface. Instead it relies solely on its
corresponding primary neighbor state machine to start communications
over an NBMA. Hence there is no Start event for a secondary neighbor
state machine (See Section 5.4).
5.3 Events Triggered by the Primary Neighbor State Machine
When a primary neighbor state machine transitions down to ExStart due
to either a SeqNumberMismatch or BadLSReq event, it triggers a 1-
WayReceived Event for any secondary neighbors at state 2-way or
greater.
The events KillNbr, LLDown, and Inactivity Timer of a primary
neighbor state machine simultaneously trigger the same events for its
loosely bound secondary neighbor state machines.
Since the formation of secondary neighbors is linked with the
database exchange and the link state update of the mlink Type-9 LSAs
received from their loosely bound primary neighbors, 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 allowing an Area 0 secondary neighbor state machine to
proceed to Full state roughly in parallel with the primary neighbor
state machine.
5.4 Receiving Hello Packets
If a Hello Packet is received from one of the interface's existing
primary neighbors which has loosely bound secondary neighbors then
the corresponding secondary neighbor state machines are executed in
line as follows:
o Each Hello Packet causes each of the neighbor's existing secondary
neighbor state machines at state greater than Down to be executed
with the event HelloReceived.
o Then the list of neighbors contained in the Hello Packet is
examined. If the router itself does not appear in this list, then
each of the neighbor's existing secondary neighbor state machines
at state greater than Init should be executed with the event 1-
WayReceived.
Hello packets do not cause secondary neighbor structures to be
created and do not effect the election of Designated Routers and
Backup Designated Routers by the secondary interface state machines.
That is triggered by the processing of the primary interface's
received mlink Type-9 LSAs. All primary neighbors are considered
secondary neighbors for each configured secondary area. They
transition from Down to Init state with their corresponding primary
neighbors and freeze at Init state until the creation of their
secondary neighbor data structures is triggered when the primary
interface receives their mlink Type-9 LSAs. (See Section 5.5)
5.5 Receiving Mlink Type-9 Neighbor Discovery LSAs
This section explains the detailed processing of a received mlink
type-9 LSA. 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 and its optional capabilities or
authentication parameters no longer match those stored in the
SecondaryAreas parameter, then execute a KillNbr event for any
existing corresponding secondary neighbor state machine belonging to
this neighbor and terminate processing of this LSA.
Else check for the existence of a secondary neighbor state machine
for the Secondary Area ID that corresponds to the originating primary
neighbor. If one does not exist, create one. Initialize its state to
Init and copy the Neighbor ID, the Inactivity Timer, and the Neighbor
IP address from the corresponding primary neighbor state machine.
When the received mlink Type-9 LSA originated from a primary neighbor
over a broadcast, point-to-multipoint or NBMA network set the
corresponding secondary neighbor data structure's Router Priority
field, Neighbor's Designated Router field, and the Neighbor's Backup
Designated Router field from the corresponding fields in the LSA's
opaque data. Changes in these fields should be noted for possible use
in the steps below.
Now the rest of the mlink Type-9 LSA is examined generating events to
be given to the corresponding secondary neighbor and secondary
interface state machines. These state machines are specified either
to be executed or scheduled (see [OSPF] Section 4.4). For example, by
specifying below that the secondary neighbor state machine be
executed in line, several neighbor state transitions may be effected
by a single received mlink Type-9 LSA:
o The list of secondary neighbors contained in the LSA's opaque data
is examined. If the router itself appears in this list, then the
corresponding secondary neighbor state machine for this neighbor
should be executed with the event 2-WayReceived. Otherwise, the
secondary neighbor state machine should be executed with the event
1-WayReceived, and the processing of the LSA stops.
o Next, if a change in the neighbor's Secondary Router Priority
field in the LSA was noted, the corresponding secondary interface
state machine is scheduled with the event NeighborChange.
o If the neighbor is both declaring itself to be the Designated
Router in the LSA (LSA's Designated Router field = Neighbor IP
address), and the Backup Designated Router field in the LSA's
opaque information is equal to 0.0.0.0, and the corresponding
secondary interface is in state Waiting, then schedule the
secondary interface state machine with the event BackupSeen.
Otherwise, if the neighbor is declaring itself to be the
Designated Router in the LSA and it had not previously, or the
secondary neighbor is not declaring itself Designated Router in
the LSA where it had previously, then schedule the secondary
interface state machine with the event NeighborChange.
o If the secondary neighbor is declaring itself to be the Backup
Designated Router in the LSA (LSA's Backup Designated Router field
= Neighbor IP address) and the corresponding secondary interface
is in state Waiting, then schedule the secondary interface state
machine with the event BackupSeen. Otherwise, if the neighbor is
declaring itself to be the Backup Designated Router in the LSA and
it had not previously, or the neighbor is not declaring itself
Backup Designated Router where it had previously, the secondary
interface state machine is scheduled with the event
NeighborChange.
6.0 Advertising Secondary Adjacencies
Border routers advertise their secondary adjacencies in their
router-LSAs as unnumbered point-to-point links even though they may
be numbered point-to-point links, point-to-multipoint links, or
broadcast or NBMA network links in the OSPF interface's primary area.
This allows their interconnecting networks to retain a single area
identity. As unnumbered point-to-point links, all secondary
adjacencies have link type 1. The building of the router-LSA, as
described in [OSPF] Section 12.4.1, is virtually unchanged.
Even though secondary adjacencies are considered unnumbered point-
to-point links, for the purpose of defining Link Data in the router-
LSA (see Appendix A) they use the primary interface's IP address. For
secondary adjacencies [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
primary interface is numbered, the Link Data should specify the
primary interface's IP address. For unnumbered point-to-point
networks, the Link Data field should specify the interface's MIB-
II [MIB] ifIndex value. The cost should be set to the secondary
area's cost specified in the primary interface's SecondaryAreas
parameter.
By not adding the host route type 3 links noted in [OSPF] Section
12.4.1, secondary adjacencies retain the look and feel of unnumbered
point-to-point links to the remaining routers in the secondary area,
even though they may configure their link data with the primary
interface's IP address.
7.0 The Shortest Path First Calculation
Since secondary links appear in the link state data base of an area Since secondary links appear in the link state data base of an area
as unnumbered point-to-point links there is no change required in the as unnumbered point-to-point links there is no change required in the
Shortest Path First (SPF) calculation, except on those border routers Shortest Path First (SPF) calculation, except on those border routers
where they are configured. Border routers do not include in a where they are configured. Border routers do not include in a
secondary area's SPF tree any network which one of its secondary secondary area's SPF tree any network which one of its secondary
adjacencies transit. This ensures synchronization of the SPF tree adjacencies transit. This ensures synchronization of the SPF tree
amongst the secondary area's routers. However border routers do use amongst the secondary area's routers. However border routers do use
the IP addresses stored in their secondary neighbors' type-1 (router) the IP addresses stored in their secondary neighbors' router-LSAs for
LSAs for determining the destination next hop across a secondary determining a destination's next hop across a secondary link when the
adjacency when the associated interface connects the destination associated interface connects to a point-to-multipoint or transit
router via a point-to-multipoint link or transit network link. In network. In this case the outgoing interface is derived directly from
this case the outgoing interface is derived directly from the the destination router's next hop IP address.
destination router's next hop IP address.
3.7 Flushing Secondary Adjacencies
The dropping and flushing of secondary adjacencies from the link
state database of a secondary area is triggered by any of the
following events:
The secondary area is manually purged from the interface's
SecondaryAreas parameter.
An adjacent router looses its primary area adjacency. Note that
over a multi-access network termination happens when a neighboring
router ceases to be listed in the Designated Router's list of
neighbors.
The secondary area is no longer listed in the adjacent router's 8.0 Flushing Secondary Adjacencies
mlink type 9 opaque LSA.
The adjacent router's mlink type 9 opaque LSA is flushed from the Secondary adjacencies are flushed from the link state database of a
primary area or exceeds MAXAge. secondary area when their neighbor states transition down from Full
status, 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.
The adjacent router's type 1 (router) LSA is flushed from the 9.0 Security Considerations
secondary area or exceeds MAXAge. In other words, the secondary
area has partitioned with the two formerly adjacent routers now in
separate parts.
When any of these events occur the interface's SecondaryAreas Security issues are not discussed in this memo.
parameter is updated to purge the adjacency. A new router LSA is
built for the secondary area and flooded out those interfaces for
which the secondary area is primary. The SPF calculation is done to
reflect the new link state topology.
4.0 Acknowledgments 10.0 Acknowledgments
This document was produced by the OSPF Working Group, chaired by John This document was produced by the OSPF Working Group, chaired by John
Moy. Moy. In addition, comments from the following individual are also
In addition, the comments of the following individuals are also
acknowledged: acknowledged:
Derek Yeung Cisco Systems Acee Lindem IBM
Rob Colton Fore Systems
5.0 References 11.0 References
[MIB] McCloghrie, K., and M. Rose, "Management Information Base for [MIB] McCloghrie, K., and M. Rose, "Management Information Base for
network management of TCP/IP-based internets: MIB-II", STD network management of TCP/IP-based internets: MIB-II", STD
17, RFC 1213, Hughes LAN Systems, Performance Systems 17, RFC 1213, Hughes LAN Systems, Performance Systems
International, March 1991. International, March 1991.
[OPAQ] Coltun, Rob, "The OSPF Opaque LSA Option", FORE Systems, [OPAQ] Coltun, Rob, "The OSPF Opaque LSA Option", FORE Systems,
August 1998. August 1998.
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, Ascend Communications, [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Ascend Communications,
Inc., April 1998. Inc., April 1998.
[1583] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 12.0 Author's Address
1994.
6.0 Security Considerations
Security issues are not discussed in this memo.
7.0 Author's Address
Pat Murphy Pat Murphy
US Geological Survey US Geological Survey
345 Middlefield Road, Mail Stop 870 345 Middlefield Road, Mail Stop 870
Menlo Park, California 94560 Menlo Park, California 94560
Phone: (650)329-4044 Phone: (650)329-4044
EMail: pmurphy@noc.doi.net EMail: pmurphy@usgs.gov
Appendix A. Router-LSAs Appendix A. Router-LSAs
Router-LSAs are Type 1 LSAs. Each router in an area originates a router-LSA. 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., 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, including secondary interfaces) to the area. All of the router's links to an area, including
links, to an area must be described in a single router-LSA. For details secondary links, must be described in a single router-LSA. For details
concerning the construction of router-LSAs, see this document's Section 3.6 concerning the construction of router-LSAs see this document's Section 6.0
and [OSPF] Section 12.4.1. and [OSPF] Section 12.4.1.
0 1 2 3 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 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 | | LS age | Options | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID | | Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
skipping to change at page 12, line 50 skipping to change at page 16, line 50
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data | | Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
In router-LSAs, the Link State ID field is set to the router's OSPF 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. Router ID. Router-LSAs are flooded throughout a single area only.
bit V bit V
When set, the router is an endpoint of one or more fully When set, the router is an endpoint of one or more fully
adjacent virtual links having the described area as Transit adjacent virtual links having the described area as its
area (V is for virtual link endpoint). transit area (V is for virtual link endpoint).
bit E bit E
When set, the router is an AS boundary router (E is for When set, the router is an AS boundary router (E is for
external). external).
bit B bit B
When set, the router is an area border router (B is for When set, the router is an area border router (B is for
border). border).
bit W bit W
When set, the router is a wild-card multicast receiver (W is When set, the router is a wild-card multicast receiver (W is
for for wild). for wild).
bit Nt bit Nt
When set, the router is a NSSA border router which translates When set, the router is a NSSA border router which translates
type-7 LSAs into type-5 LSAs (Nt is for NSSA translation). type-7 LSAs into type-5 LSAs (Nt is for NSSA translation).
# links # links
The number of router links described in this LSA. This must be The number of router links described in this LSA. This must be
the total collection of router links (i.e., interfaces) to the the total collection of router links (i.e., interfaces) to the
area. area as well as a separate entry for each fully adjacent
secondary neighbor across a broadcast or NBMA network link.
Secondary interfaces to broadcast and NBMA networks are
considered point-to-multipoint networks.
The following fields are used to describe each router link (i.e., The following fields are used to describe each router link (i.e.,
interface). Each router link is typed (see the below Type field). The 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 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. 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 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 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 Data field. For links to stub networks this field specifies the
network's IP address mask. For other link types the Link Data field network's IP address mask. For other link types the Link Data field
specifies the router interface's IP address. specifies the router interface's IP address.
skipping to change at page 13, line 47 skipping to change at page 18, line 4
A quick description of the router link for one of the A quick description of the router link for one of the
following. Note that host routes are classified as links to following. Note that host routes are classified as links to
stub networks with network mask of 0xffffffff. stub networks with network mask of 0xffffffff.
Type Description Type Description
__________________________________________________ __________________________________________________
1 Point-to-point connection to another router 1 Point-to-point connection to another router
2 Connection to a transit network 2 Connection to a transit network
3 Connection to a stub network 3 Connection to a stub network
4 Virtual link 4 Virtual link
Link ID Link ID
Identifies the object that this router link connects to. Value Identifies the object that this router link connects to. Its
depends on the link's Type. When connecting to an object that value depends on the link's Type. When connecting to an object
also originates an LSA (i.e., another router or a transit that also originates an LSA (i.e., another router or a transit
network) the Link ID is equal to the neighboring LSA's Link network) the Link ID is equal to the neighboring LSA's Link
State ID. Secondary links area are always type 1 point-to- State ID. Secondary links are always type 1 point-to-point
point regardless of the type of their associated primary area. regardless of the type of their matching primary link. This
This provides the key for looking up the neighboring LSA in provides the key for looking up the neighboring LSA in the
the link state database during the routing table calculation. link state database during the routing table calculation. See
See [OSPF] Section 12.2 for more details. [OSPF] Section 12.2 for more details.
Type Link ID Type Link ID
______________________________________ ______________________________________
1 Neighboring router's Router ID 1 Neighboring router's Router ID
2 IP address of Designated Router 2 IP address of Designated Router
3 IP network/subnet number 3 IP network/subnet number
4 Neighboring router's Router ID 4 Neighboring router's Router ID
Link Data Link Data
Value again depends on the link's Type field. For connections Value again depends on the link's Type field. For connections
to stub networks, Link Data specifies the network's IP address to stub networks, Link Data specifies the network's IP address
mask. For unnumbered point-to-point connections, it specifies mask. For unnumbered point-to-point connections, it specifies
the interface's MIB-II [MIB] ifIndex value. For the other link the interface's MIB-II [MIB] ifIndex value. For the other link
types it specifies the router interface's IP address. This types it specifies the router interface's IP address. This
latter piece of information is needed during the routing table latter piece of information is needed during the routing table
build process, when calculating the IP address of the next build process, when calculating the IP address of the next
hop. Although secondary links are considered unnumbered hop. Although secondary links are considered unnumbered
point-to-point links, they do evaluate Link Data as if they point-to-point links, they do evaluate Link Data as if they
were numbered whenever their interface has an IP address were numbered whenever their interface has an IP address
associated with its primary area. See Section 3.6 of this associated with its primary area. See Section 6.0 of this
document and [OSPF] Section 16.1.1 for more details. document and [OSPF] Section 16.1.1 for more details.
# TOS # TOS
The number of different TOS metrics given for this link, not The number of different TOS metrics given for this link, not
counting the required link metric (referred to as the TOS 0 counting the required link metric (referred to as the TOS 0
metric in [1583]). For example, if no additional TOS metrics metric in [1583]). For example, if no additional TOS metrics
are given, this field is set to 0. Secondary Areas may use are given, this field is set to 0. Secondary Areas do not use
TOS. TOS.
metric metric
The cost of using this router link. The cost of using this router link. For secondary links the
cost is specified in the primary interface's SecondaryAreas
parameter.
Additional TOS-specific information may also be included, for Additional TOS-specific information may also be included, for
backward compatibility with previous versions of the OSPF backward compatibility with previous versions of the OSPF
specification ([1583]). Within each link, and for each desired TOS, specification ([1583]). Within each link, and for each desired TOS,
TOS TOS-specific link information may be encoded as follows: TOS-specific link information may be encoded as follows:
TOS TOS
IP Type of Service that this metric refers to. The encoding of IP Type of Service that this metric refers to. The encoding of
TOS in OSPF LSAs is described in [1583] Section 12.3. TOS in OSPF LSAs is described in [1583] Section 12.3.
TOS metric TOS metric
TOS-specific metric information. TOS-specific metric information.
Appendix B. mlink Opaque LSA Appendix B. Mlink Type-9 Neighbor Discovery LSAs
The mlink Opaque LSA is used directly by OSPF to distribute list of Mlink Type-9 LSAs are used directly by OSPF to distribute lists of
candidate secondary areas among neighboring routers. The flooding candidate secondary areas among neighboring routers. Mlink Type-9
scope of the mlink type 9 Opaque LSA is link-local, which means mlink LSAs are flooded across the primary interface. The flooding scope of
LSAs are never forwarded beyond the local (sub)network. mlink Type-9 LSAs is link-local, which means mlink Type-9 LSAs are
never forwarded beyond the local (sub)network or router link.
Section 3.3 of this document describes the purpose of the mlink Sections 4.0 and 5.5 of this document describe the purpose of these
Opaque LSA in more detail. mlink Type-9 LSAs in more detail.
0 1 2 3 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 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 | Link State | | LS age | Options | 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID | | Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number | | LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length | | LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Area ID 1 | | Secondary Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | Sec AuType | Sec Options | Sec Rtr Pri |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Area ID n | | Sec Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sec Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Syntax Of The Opaque LSA's Link-State ID Syntax of the mlink Type-9 LSA's Link-State ID
The link-state ID of the mlink Opaque LSA is divided into an The link-state ID of an mlink Type-9 LSA is divided into an Opaque
Opaque Type field (the first 8 bits), which has value mlink, and Type field (the first 8 bits), which has value mlink, and the
the Opaque ID (the remaining 24 bits). The mlink Opaque ID is set Opaque ID (the remaining 24 bits). The mlink Type-9 LSA of each
to the last 24 bits of the interface's primary area IP address, if of the primary interface's secondary areas must have a unique
it has one. In the case of unnumbered point-to-point connections, opaque ID. The last 24 bits of the Secondary Area ID will normally
the mlink opaque ID is set to the last 24 bits of the interface's produce unique Opaque IDs. When it doesn't, alter the least
MIB-II [MIB] ifIndex value. All implementations should also significant bits until uniqueness is achieved.
support the manual configuration of an interface's mlink opaque ID
in the rare instance this default schema results in duplication. 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.
Sec AuType
Identifies the authentication procedure to be used.
Authentication is discussed in [OSPF] Appendix D of the
specification. Consult [OSPF] Appendix D for a list of the
currently defined authentication types.
Sec Authentication
A 64-bit field for use by the authentication scheme. See [OSPF]
Appendix D for details.
Neighbors Cnt
This 16 bit field describes the number of secondary neighbors
listed for the Secondary Area ID. If there are no secondary
neighbors listed, then Neighbor Cnt should be set to 0.
Sec Options
The optional capabilities supported by this router for this
secondary area, as documented in [OSPF] Section A.2.
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.
Designated Router
The identity of the Designated Router for a secondary link, in
the view of the originating router. The Designated Router is
identified here by the IP address across the primary link. Its
value is set to 0.0.0.0 if there is no Designated Router for
the secondary link.
Backup Designated Router
The identity of the Backup Designated Router for a secondary
link, in the view of the originating router. The Backup
Designated Router is identified here by its IP address across
the primary link. Its value is set to 0.0.0.0 if there is no
Backup Designated Router for the secondary link.
Secondary Neighbor
The Router IDs of each router from whom valid mlink Type-9 LSAs
have been received across the primary link for the secondary
area with matching optional capabilities and authentication
parameters.
Appendix C. Interface Data Structure Appendix C. Interface Data Structure
Chapter 9 in the OSPF specification documents the interface data Chapter 9 in the OSPF specification documents the interface data
structure and the data items which are included in it. Section 3.1 of structure and the data items which are included in it. Section 3.1 of
this document defines a new configuration parameter called this document defines a new interface configuration parameter called
SecondaryAreas which is to be included in support of OSPF multiple SecondaryAreas which supports unnumbered OSPF multiple area links.
area links. Sections 3.2 and 3.4 describe the application of the The SecondaryAreas parameter's default setting is null. The
parameter. SecondaryAreas parameter in a secondary interface data structure is
always null.
In addition, for each secondary area listed in an interface's For each secondary area listed in an interface's SecondaryAreas
SecondaryAreas parameter, the interface data structure must maintain parameter, the secondary link's interface cost, authentication
a list of Router IDs which have formed secondary adjacencies for this parameters and Designated Router priority must be configurable. If
secondary area. the interface cost and Designated Router priority are not configured
they default to their corresponding values for the OSPF primary
interface. 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.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/