draft-ietf-ospf-mlinks-02.txt   draft-ietf-ospf-mlinks-03.txt 
Network Working Group P. Murphy Network Working Group P. Murphy
Internet Draft US Geological Survey Internet Draft US Geological Survey
Expiration Date: August 2001 February 2001 Expiration Date: August 2002 February 2002
File name: draft-ietf-ospf-mlinks-02.txt File name: draft-ietf-ospf-mlinks-03.txt
Unnumbered OSPF Multiple Area Links OSPF Multiple Area Links
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working 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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Unnumbered OSPF Multiple Area Links ...... 2 2.1 Requirement for OSPF Multiple Area Links ................. 2
2.2 Proposed Solution ........................................ 3 2.2 Proposed Solution ........................................ 3
2.2.1 Secondary Adjacencies .................................... 4 2.2.1 Secondary Adjacencies .................................... 4
2.2.2 Secondary Neighbor Discovery ............................. 4 2.2.2 Secondary Neighbor Discovery ............................. 4
2.2.3 Advertising Secondary Links .............................. 5 2.2.3 Advertising Secondary Links .............................. 5
2.3 Application .............................................. 5 2.3 Application .............................................. 5
3.0 Secondary Interfaces ..................................... 5 3.0 Secondary Interfaces ..................................... 5
3.1 The SecondaryAreas Interface parameter ................... 5 3.1 The SecondaryAreas Interface parameter ................... 5
3.2 The Secondary Interface Data Structure ................... 6 3.2 The Secondary Interface Data Structure ................... 6
3.3 The Secondary Interface State Machine .................... 6 3.3 The Secondary Interface State Machine .................... 6
3.4 OSPF Protocol Packet Processing .......................... 7 3.4 OSPF Protocol Packet Processing .......................... 7
3.5 Designated Router Selection and Function ................. 7 3.5 Designated Router Election and Function .................. 7
4.0 Synchronizing Secondary Areas Using Mlink Type-9 LSAs .... 8 4.0 Synchronizing Secondary Areas Using Mlink Type 9 LSAs .... 8
5.0 Secondary Neighbors ...................................... 9 5.0 Secondary Neighbors ...................................... 8
5.1 The Secondary Neighbor Data Structure .................... 9 5.1 The Secondary Neighbor Data Structure .................... 8
5.2 The Secondary Neighbor State Machine ..................... 10 5.2 The Secondary Neighbor State Machine ..................... 9
5.3 Events Triggered by the Primary Neighbor State Machine.... 11 5.3 Receiving Mlink Type 9 Neighbor Discover LSAs ............ 10
5.4 Receiving Hello Packets .................................. 11 5.4 Receiving Secondary Hello Packets ........................ 11
5.5 Receiving Mlink Type-9 Neighbor Discover LSAs ............ 12 6.0 Advertising Secondary Adjacencies ........................ 11
6.0 Advertising Secondary Adjacencies ........................ 13 7.0 The Shortest Path First Calculation ...................... 11
7.0 The Shortest Path First Calculation ...................... 14 8.0 Flushing Secondary Adjacencies ........................... 12
8.0 Flushing Secondary Adjacencies ........................... 14 9.0 Security Considerations .................................. 12
9.0 Security Considerations .................................. 15 10.0 Acknowledgments .......................................... 12
10.0 Acknowledgments .......................................... 15 11.0 References ............................................... 12
11.0 References ............................................... 15 12.0 Authors' Addresses ....................................... 12
12.0 Authors' Addresses ....................................... 15 Appendix A: Router-LSAs ........................................ 13
Appendix A: Router-LSAs ........................................ 16 Appendix B: Mlink Type 9 Neighbor Discover LSAs ................ 17
Appendix B: Mlink Type-9 Neighbor Discover LSAs ................ 20 Appendix C: Configuration Parameters ........................... 19
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 OSPF interface and which allows multiple areas to share the same OSPF link. One area is
links. One area is always configured as an interface's primary area. always configured as the link's primary area. The link's remaining
The interface's remaining areas are termed secondary and view it as areas are termed secondary. Two border routers adjacent across the
unnumbered. Two border routers adjacent across the same secondary same secondary area may forward the area's intra-area traffic across
area may forward the area's intra-area traffic across its secondary the link. This option applies to standard areas, stub areas, and
links. This option applies to standard areas, stub areas, and NSSAs. NSSAs. It works over any OSPF interface. Routers with this option
It works over any OSPF interface. Routers with this option
configured are backward compatible with routers running the standard configured are backward compatible with routers running the standard
OSPF Version 2 compliant implementation as defined in RFC 2328. OSPF Version 2 compliant implementation as defined in RFC 2328.
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 Unnumbered OSPF Multiple Area Links 2.1 Requirement for OSPF Multiple Area Links
Large corporate networks in today's modern Internet have tremendous Large corporate networks in today's modern Internet have tremendous
human and equipment resources coupled with sizable budget invested in 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 take 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. advantage of the backbone's faster and more reliable network links.
Performance over a T1 link can pale by comparison to performance over Performance over a T1 link can pale by comparison to performance over
a DS3 or OC3 backbone link. Large corporate networks have sizable a DS3 or OC3 backbone link. Large corporate networks have sizable
backbone routing tables and routinely use stub areas and NSSAs. Under backbone routing tables and routinely use stub areas and NSSAs. Under
the current OSPF specification intra-area routes are always preferred the current OSPF specification intra-area routes are always preferred
skipping to change at page 3, line 22 skipping to change at page 3, line 22
see the summary LSA of N1, but still cannot take advantage of it due see the summary LSA of N1, but still cannot take advantage of 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 inside NSSA 1. A common practice is to use multiple B0 visible inside NSSA 1. A common practice is to use multiple
interface subnets. However this is not an option when the path 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 between A0 and B0 is unnumbered or when one desires that the NSSA 1
path between A0 and B0 be unnumbered. Moreover when configuring path between A0 and B0 be unnumbered. Moreover when configuring
multiple interface subnets over multi-access networks, inverse-arp multiple interface subnets over multi-access networks, inverse-arp
limitations come into play and additional layer 2 PVCs may be limitations come into play and additional layer 2 PVCs may be
required imposing potential resource and budgetary ramifications. The required, imposing potential resource and budgetary ramifications.
existing tools for the multiple area usage of the same physical link The existing tools for the multiple area usage of the same physical
are awkward to configure, implementation dependent, unnecessarily link are awkward to configure, implementation dependent,
complex and unwieldy to maintain. These tools also burden the unnecessarily complex and unwieldy to maintain. If, in the above
physical link with the simultaneous database exchange of multiple example, the link between A0 and B0 were part of NSSA 1, path
OSPF interfaces during adjacency formation. preference would be optimal as the DS3 path would be intra-area for
NSSA 1.
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
The Unnumbered OSPF Multiple Area Links option lets multiple areas The OSPF Multiple Area Links option is a simpler tool for configuring
use the same link between two border routers for intra-area traffic. multiple area links, requiring just a simple list of the areas
Traffic may originate from inside each of the configured areas, as sharing an OSPF link. Once configured it lets multiple areas use the
every router in the configured areas sees the link as part of its same link between two border routers for each area's intra-area
link state topology. Routers with configured unnumbered OSPF multiple traffic. Traffic may originate from inside each of the configured
area links must be in Area 0, although the connection to Area 0 may areas, as every router in the configured areas sees the link as part
be an unnumbered OSPF multiple area link. 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 The current OSPF specification only allows one area per OSPF
interface. Thus, should an Area L dual-home to Area 0 via two border 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 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 or router<->network link, the adjacent link over Area K is not seen
inside Area L, even though the two border routers exist physically inside Area L, even though the two border routers exist physically
adjacent within Area L. This, coupled with intra-area route adjacent within Area L. This, coupled with intra-area route
preference, prevents Area L from utilizing Area K's adjacent path. preference, prevents Area L from utilizing Area K's adjacent path.
2.2.1 Secondary Adjacencies 2.2.1 Secondary Adjacencies
The softening of this restriction is facilitated by the addition of a The softening of this restriction is facilitated by the addition of a
new interface configuration parameter called SecondaryAreas. This new interface configuration parameter called SecondaryAreas. This
parameter specifies a list of additional areas in which an OSPF parameter specifies a list of additional areas which share the OSPF
interface also belongs (See Appendix C). The areas listed in this link (See Appendix C). The areas listed in this parameter are called
parameter are called the interface's secondary areas, as opposed to the interface's secondary areas, as opposed to the interface's
the interface's configured area, hereafter called the primary area. A configured area, hereafter called the primary area. A separate
separate interface data structure is generated for each of the interface data structure is generated for each of the secondary
secondary areas. For each secondary area listed in the SecondaryAreas areas. For each secondary area listed in the SecondaryAreas parameter
parameter a router can form OSPF adjacencies with the primary area's a router can form OSPF adjacencies across the interface's directly
neighboring routers across the interface's directly attached network attached network or router link. These adjacencies are called
or router link. These adjacencies are called secondary adjacencies. secondary adjacencies.
Secondary adjacencies are formed after the primary area's link state Secondary adjacencies are formed after the primary area's link state
data base exchange has synchronized matching secondary areas with any data base exchange has synchronized matching secondary areas through
of its primary neighbors (See Section 4.0). Link state database the flooding path with the link's other directly connected routers.
exchange occurs across a secondary adjacency along with normal (See Section 4.0). Link state database exchange occurs across a
flooding. Note that a secondary adjacency for area 0 may not be secondary adjacency along with normal flooding. Note that a secondary
configured over an interface which is linked to a transit area for a adjacency for area 0 may not be configured for an interface which is
configured virtual link. linked to a transit area for a configured virtual link (See Section
3.4).
2.2.2 Secondary Neighbor Discovery 2.2.2 Secondary Neighbor Discovery
A Type-9 opaque LSA is used to form secondary adjacencies over a A Type 9 opaque LSA is used to form secondary adjacencies over a
primary link with adjacent opaque capable border routers. Until an primary link with adjacent opaque capable border routers. Until an
opaque type is assigned for this option experimental opaque type 224 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. 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 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 secondary areas because the flooding scope of this opaque LSA needs
to be restricted to routers which are directly attached to a common 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 network or router link. A separate mlink Type 9 LSA is originated for
each of the primary interface's secondary areas. Included in a each of the primary interface's secondary areas. If required,
secondary area's mlink Type-9 LSA is the secondary area's configured included in a secondary area's mlink Type 9 LSA is the secondary
optional capabilities, its authentication parameters, plus, if area's configured Designated Router priority. Mlink Type 9 LSAs are
required, its configured Designated Router priority. Mlink Type-9 propagated during the exchange/update of the primary area's link
LSAs are propagated during the exchange/update of the primary area's state data base (LSDB) with its adjacent primary neighbors.
link state data base (LSDB) with its adjacent primary neighbors.
If a router A receives an mlink Type-9 LSA for area L originating 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, 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 then router A may form a secondary adjacency in area L with router B.
provided the LSA's optional capabilities and authentication See Section 5.2 for details about secondary neighbor adjacency
parameters match those configured for the secondary area in the formation. LSDB exchange and update across a secondary adjacency
SecondaryAreas parameter. See Section 5.2 for details about secondary proceed as defined in [OSPF] Sections 10 and 13.
neighbor adjacency formation. LSDB exchange and update across a
secondary adjacency proceed as defined in [OSPF] Sections 10 and 13.
2.2.3 Advertising Secondary Links 2.2.3 Advertising Secondary Links
Secondary adjacencies are advertised as point-to-point or point-to- Secondary adjacencies are advertised as point-to-point links. Any
multipoint links. Any intervening transit network always belongs to intervening transit network or stub network assigned to the primary
the interface's primary area. Moreover, there is no network LSA for a interface always belongs to the interface's primary area. There is no
secondary adjacency's intervening transit network in the secondary network LSA for this intervening transit network in any of the
area. Hence all secondary adjacencies must be advertised in a interface's secondary areas. All secondary adjacencies must be
router's router-LSA with unnumbered point-to-point type. advertised in a router-LSA with point-to-point type.
During the Dykstra shortest path first (SPF) calculation the LSAs for During the Dykstra shortest path first (SPF) calculation the LSAs for
secondary adjacencies look like unnumbered point-to-point links. A secondary adjacencies look like point-to-point links. A border router
Border router never includes in a secondary area's SPF tree any never includes in a secondary area's SPF tree any network across
network across which one of its secondary adjacencies span. This which one of its secondary adjacencies span. This ensures
ensures synchronization of the SPF tree amongst the secondary area's synchronization of the SPF tree amongst the secondary area's routers.
routers. However border routers may use the IP addresses of However, since border routers share the link's addressing, they may
neighboring routers for determining a destination's next hop across a use the IP addresses of their secondary neighbors for determining a
secondary link over a point-to-multipoint or transit network. destination's next hop across a secondary link over a point-to-
multipoint or transit network.
2.3 Application 2.3 Application
Consider now the example mentioned in Section 2.1 and assume NSSA 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. Since the routers A0, A1, B0, and B1 possess NSSA 1's router-LSAs 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 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 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 Dykstra calculation now includes this DS3 link with a cost of 1. Thus
the path between A0 and M1 is the more preferred path the preferred path between A0 and M1 is
A0<->B0<->B1<->M1 A0<->B0<->B1<->M1
and the path between A1 and N1 is the more preferred path and the preferred path between A1 and N1
A1<->A0<->B0<->N1 A1<->A0<->B0<->N1
3.0 Secondary Interfaces 3.0 Secondary Interfaces
3.1 The SecondaryAreas Interface Parameter 3.1 The SecondaryAreas Interface Parameter
A new configuration parameter called SecondaryAreas has been added to A new configuration parameter called SecondaryAreas has been added to
the OSPF interface data structure (See Appendix C). The the OSPF interface data structure (See Appendix C). The
SecondaryAreas interface parameter lists a set of areas which may SecondaryAreas interface parameter lists a set of areas which may
form unnumbered secondary adjacencies across the interface. If the form secondary adjacencies across the interface. If the
SecondaryAreas interface parameter has a null list, then no secondary SecondaryAreas interface parameter has a null list, then no secondary
areas are configured for this interface and no secondary adjacencies areas are configured for this interface and no secondary adjacencies
can be formed over the interface. For each secondary area listed in can be formed over the interface.
the SecondaryAreas interface parameter the interface cost,
authentication parameters, and Designated Router priority are also Each area listed in the SecondaryAreas interface parameter should
configurable. The SecondaryAreas' interface costs and the Designated have a secondary interface data structure. With the exception of Area
Router priorities default to the values assigned to the primary ID all of secondary interface parameters which are usually
interface. Note that if a virtual link is configured across a transit configurable, such as interface cost, authentication parameters and
area which is linked to an interface, then Area 0 may not be Designated Router priority, default to the values assigned to the
configured in the interface's SecondaryAreas parameter. 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 3.2 The Secondary Interface Data Structure
An OSPF interface data structure should be built for each of an OSPF An OSPF interface data structure should be built for each of an OSPF
interface's secondary areas. These interface data structures are interface's secondary areas. These interface data structures are
called secondary interface data structures and are bound to the called secondary interface data structures and are loosely bound to
primary interface. The configured primary area of an OSPF interface the primary interface. The configured primary area of an OSPF
generates its primary interface data structure. Recall [OSPF] interface generates its primary interface data structure. A point-
Sections 8.2 and 10.5 imply that a point-to-point layer 2 link to-point layer 2 link between two routers may have only one OSPF
between two routers may have only one OSPF interface per area. interface per area (See [OSPF] Sections 8.2 and 10.5). Additional
Additional areas may be added as secondary areas, but they must not areas may be added as secondary areas, but they must not duplicate
duplicate areas already configured for the layer 2 link. areas already configured for the layer 2 link. A secondary
interface's list of neighboring routers is generated by examining the
A secondary interface's list of neighboring routers is generated by primary interface's received mlink Type 9 LSAs as defined in Section
examining the primary interface's received mlink Type-9 LSAs as 4.0 below.
defined in Section 4.0 below. Before a neighboring router may be
added to the secondary interface's list of neighboring routers it
must also occur in the primary interface's list of neighboring
routers.
Secondary interfaces copy their interface type from the primary With the exception of broadcast networks, secondary interfaces copy
interface's data structure and still compute a Designated Router and their interface type from the primary interface's data structure. If
a Backup Designated Router over broadcast and NBMA networks. This the primary interface's network has broadcast type then the secondary
promotes efficient flooding across a primary interface's transit interface's network has NBMA type. Secondary interfaces with NBMA
network. However, these network links are always advertised as type still compute a Designated Router and a Backup Designated
unnumbered router<->router links and behave exactly like point-to- Router. This promotes efficient flooding across the interface's
multipoint interfaces. As such a secondary link's Designated Router transit network. Note that secondary adjacencies are always
does not originate a type-2 network LSA into the secondary area for advertised as router links even when their network type is NBMA. As
the primary interface's transit network. 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 3.3 The Secondary Interface State Machine
The interface states of a secondary interface are the same as the The interface states of a secondary interface are the same as the
interface states of a primary interface. However in some cases state interface states of a primary interface. Secondary neighbors exchange
transitions are triggered by the primary interface's state machine. Hello packets, called secondary Hello packets, just like primary
The InterfaceUp event is redefined for secondary links: neighbors. The processing of received secondary Hellos is practically
unchanged (See Section 5.5). The InterfaceUp event for a secondary
InterfaceUp interfaces is generated by its corresponding primary interface when
the primary interface transitions to either Point-to-point, DR Other,
This event is triggered by the primary interface when it DR, or Backup state. In addition to those actions described in [OSPF]
transitions to either Point-to-point, DR Other, DR, or Backup Section 9.3, when the InterfaceUp event is generated for secondary
state. Its effect on the secondary interface's state is similar to interfaces, the neighbor Start event is generated for each existing
the effect the InterfaceUp event has on the primary interface's secondary neighbor.
state with one exception. The periodic sending of Hello packets is
suppressed for a secondary interface. If the primary interface
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.
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.
The events BackupSeen and NeighborChange for a secondary interface
are triggered during the processing of the primary interface's
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).
The events InterfaceDown, LoopInd, UnloopInd, and Wait Timer are The remainder of the interface state machine is virtually unchanged
unchanged for secondary interfaces. Note that since the secondary for secondary interfaces. Those protocols which generate the events
interface's InterfaceUp event occurs only after the primary interface InterfaceDown, LoopInd, UnloopInd for the primary interface should
has transitioned to DR other, DR or Backup state, a secondary generate the same events for all of the primary interface's
interface's Wait Timer will never start before the primary corresponding secondary interfaces. The NeighborChange and BackupSeen
interface's Wait Timer has fired. 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 3.4 OSPF Protocol Packet processing
Since secondary interfaces are unnumbered interfaces, OSPF protocol Since a secondary interface shares the ip address of its
packet processing needs a minor adjustment. For point-to-point corresponding primary interface, OSPF protocol packet processing
networks there are no changes. For broadcast, NBMA, and point-to- needs a minor adjustment. For broadcast, NBMA, and point-to-
multipoint links, the packet's IP source address is required to be on 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 the same network as the receiving OSPF primary interface. This can be
verified by comparing the packet's IP source address to the primary verified by comparing the packet's IP source address to the primary
interface's source address, after masking both addresses with the interface's source address, after masking both addresses with the
interface mask (See [OSPF] Section 8.2). 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 Selection and Function 3.5 Designated Router Election and Function
The election of the Designated Router and the Backup Designated The election of the Designated Router and the Backup Designated
router for a secondary link over a broadcast or NBMA network proceeds router for a secondary link over a secondary NBMA network proceeds as
as described in [OSPF] Section 9.4. Eligibility is determined from described in [OSPF] Section 9.4. Eligibility is determined from the
the Designated Router priorities defined in the SecondaryAreas Designated Router priorities configured for each secondary area as
parameter and the received mlink Type-9 LSAs, as well as its well as the priorities defined in received secondary Hellos from
neighbors' views of the Designated Router and the Backup Designated secondary neighbors. Note that the Designated Router for a secondary
Router for the secondary link, which is also found in the received link does not originate a network-LSA (Type-2) into its secondary
mlink Type-9 LSAs. Any change in the calculating router's Designated area for the secondary NBMA network over which the secondary link
Router or Backup Designated Router for a secondary link will result bridges. All secondary links are advertised as point-to-point links
in the reorigination of the corresponding secondary area's mlink (see Section 6.0). The only function of a secondary link's Designated
Type-9 LSA. Router is flooding optimization.
Note that the Designated Router for a secondary link does not
originate a network-LSA (Type-2) into its secondary area for the
broadcast or NBMA network over which the secondary link bridges. All
secondary links remain unnumbered point-to-point or point-to-
multipoint (see Section 6.0). The only function of a secondary link's
Designated Router is flooding optimization.
4.0 Synchronizing Secondary Areas using Mlink Type-9 LSAs 4.0 Synchronizing Secondary Areas using Mlink Type 9 LSAs
Mlink Type-9 LSAs are used to discover and maintain secondary Mlink Type 9 LSAs are used to discover and start secondary neighbor
neighbor relationships and to elect the Designated Router and Backup relationships. If the primary interface is of broadcast or NBMA type
Designated Router for multi-access secondary adjacencies. If the then all of its candidate Designated Routers must be opaque capable,
primary interface is of broadcast or NBMA type then all of its even if these routers have no secondary areas configured for their
candidate Designated Routers must be opaque capable, even if these link to the broadcast or NBMA network. Otherwise mlink Type 9 LSAs
routers have no secondary areas configured for their link to the may not propagate to all potential routers capable of forming
broadcast or NBMA network. Otherwise mlink Type-9 LSAs may not secondary adjacencies over the network. Note that these candidate
propagate to all potential routers capable of forming secondary Designated Routers do not have to support OSPF Multiple Area Links,
adjacencies over the network. Note that these candidate Designated but they do have to be opaque capable in order to flood mlink Type 9
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 LSAs to their adjacent primary neighbors who may or may not support
unnumbered OSPF multiple area links. OSPF Multiple Area Links.
The format of the mlink Type-9 LSA is detailed in Appendix B. Any The format of the mlink Type 9 LSA is detailed in Appendix B. Any
router which has an interface with a non-empty SecondaryAreas router which has an interface with a non-empty SecondaryAreas
interface parameter must originate an mlink Type-9 LSA for each interface parameter must originate across the primary interface an
configured secondary area. If an interface's SecondaryAreas parameter mlink Type 9 LSA for each configured secondary area. If an
is null, then no mlink Type-9 LSAs should be advertised. A secondary interface's SecondaryAreas parameter is null, then no mlink Type 9
area's mlink Type-9 LSA minimally lists as opaque information the LSAs will be advertised. A secondary area's mlink Type 9 LSA
area's secondary area ID, its optional capabilities, its minimally lists as opaque information the secondary link's Area ID,
authentication parameters, and, if required, its Designated Router plus, if available, its IP address and, if required, its Designated
priority. Router priority. A new mlink Type 9 LSA is reoriginated following
expiration of its LSRefreshInterval or when changes occur in the
In addition, to ensure proper secondary neighbor state transition, a secondary link's router priority. Mlink Type 9 LSAs are only flooded
secondary area's mlink Type-9 LSA also lists as opaque information at the routers fully adjacent primary neighbors. If a secondary area
those primary neighbors from which an mlink Type-9 LSA has been is removed from a primary interface's configured secondary areas, its
received for this area with matching optional capabilities and locally originated mlink Type 9 LSA should be flushed.
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.
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.
The mlink Type-9 LSA of each of the primary interface's secondary 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 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, Area ID will normally produce unique Opaque IDs. When it doesn't,
alter the least significant bits until uniqueness is achieved. alter the least significant bits until uniqueness is achieved.
5.0 Secondary Neighbors 5.0 Secondary Neighbors
An OSPF router converses with its secondary neighbors. Each separate An OSPF router converses with its secondary neighbors. Each separate
conversation is described by a "secondary neighbor data structure". conversation is described by a "secondary neighbor data structure".
Conversations between secondary neighbors are bound to the secondary Conversations between secondary neighbors are bound to the secondary
interface and identified by both the Area ID and either the router's interface and identified by both the Area ID and either the router's
OSPF Router ID or its Neighbor IP address (see below). Unless OSPF Router ID or its Neighbor IP address (see Section 3.4). Unless
discussed below details for the creation and maintenance of secondary discussed below details for the creation and maintenance of secondary
neighbors and secondary adjacencies are the same as discussed in neighbors and secondary adjacencies are the same as discussed in
[OSPF] Sections 9 and 10. [OSPF] Sections 10.
5.1 The Secondary Neighbor Data Structure 5.1 The Secondary Neighbor Data Structure
The neighbor data structure for secondary adjacencies is identical to The neighbor data structure for secondary adjacencies is identical to
the neighbor data structure for standard OSPF adjacencies. Secondary the neighbor data structure for standard OSPF adjacencies. Secondary
neighbors are discovered by comparing the contents of the primary neighbors are discovered by comparing the Area IDs of the primary
interface's received mlink Type-9 LSAs with its configured list of interface's received mlink Type 9 LSAs with the secondary areas
secondary areas and then comparing the secondary areas' configured listed in the interface's SecondaryAreas parameter. For point-to-
optional capabilities (see Section 5.5) with those listed for them in multipoint and transit networks, the originator of the mlink Type 9
the neighboring router's mlink Type-9 LSAs. A separate neighbor data LSA should be on the same network as the receiving interface. This
structure is built for each matching secondary area. 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
The Inactivity Timer used for a primary neighbor data structure is addresses with the interface mask. For point-to-point and point-to-
synchronized with the Inactivity Timer for all of its configured multipoint secondary network types, a separate neighbor data
secondary neighbor data structures. The secondary link's Designated structure is always built for each new secondary neighbor discovered
Router and the Backup Designated Router, as viewed by a secondary by a received mlink Type 9 LSA. Since the mlink Type 9 LSA of an NBMA
neighbor, are specified as opaque information stored in the secondary link includes the neighbor's Designated Router priority,
neighbor's corresponding mlink Type-9 LSA and received over the its separate secondary neighbor data structure is built only when
primary interface. Also included are the neighbor's Designated Router either the local router or the originating router of the mlink Type 9
priority for the secondary link, its optional capabilities, and a LSA is DR eligible (see Section 5.4). The Neighbor ID and the
list of secondary neighbors it sees over the secondary link. Neighbor IP address of the secondary neighbor's data structure are
copied from the Advertising Router field and IP Address fields of the
The secondary Neighbor ID and Neighbor IP address are copied from the mlink Type 9 LSA.
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 5.2 The Secondary Neighbor State Machine
While secondary neighbor states are identical to OSPF's neighbor While secondary neighbor states are identical to OSPF's neighbor
states, there are some important distinctions in their actions and states, there are a few important distinctions in their actions and
the events which trigger them. Every router which is a secondary the events which trigger them. When a primary interface receives an
neighbor for a secondary interface is also a primary neighbor for its new mlink Type 9 LSA from a primary neighbor, the LSA's content may
primary interface. The two neighbor data structures are loosely bound create a new secondary neighbor, destroy an existing secondary
together so that events which happen to the primary neighbor may neighbor or modify the state of an existing secondary neighbor. For
trigger events for the secondary neighbor. 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).
A secondary neighbor's Init, 1-way, and 2-way state transitions are If an mlink Type 9 LSA ages out, the KillNbr event is executed for
controlled by the reception across the primary interface of Hello the corresponding secondary neighbor, and the LSA should be flushed.
Packets and mlink Type-9 LSAs (See Sections 5.4 and 5.5). The If the state of the neighbor is 2-way or higher, the local router
combination of the two eliminates the requirement for the periodic should send a Hello packet to the secondary neighbor which omits it
sending of Hello Packets for each secondary interface. When a primary from the neighbor list (See Section 5.5). The conditions which cause
neighbor state machine receives a new mlink Type-9 LSA from a primary the execution of the KillNbr and LLDown events for primary neighbors
neighbor via link state update, or confirms the status of an existing should trigger the same events for any of their corresponding
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. 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 Since the formation of secondary neighbors is linked with the
database exchange and the link state update of the mlink Type-9 LSAs database exchange and the link state update of the mlink Type 9 LSAs
received from their loosely bound primary neighbors, the timing of received across the primary link, the timing of this exchange effects
this exchange effects when a secondary neighbor transitions to when a secondary neighbor transitions to ExStart state. The mlink
ExStart state. The mlink Type-9 LSA of a secondary Area 0 should be Type 9 LSA of a secondary Area 0 should be listed at the top of the
listed at the top of the database summary list. The mlink type-9 LSAs database summary list. The mlink Type 9 LSAs of non-backbone
of non-backbone secondary areas should be listed at the bottom of the secondary areas should be listed at the bottom of the database
database summary list. These tools mitigate the effect of the summary list. These tools mitigate the effect of the database
database exchange by non-backbone secondary areas on the primary exchange by non-backbone secondary areas on the primary neighbor
neighbor state machine as it transitions to Full state, while at the state machine as it transitions to Full state, while at the same time
same time allowing an Area 0 secondary neighbor state machine to letting an Area 0 secondary neighbor state machine proceed to Full
proceed to Full state roughly in parallel with the primary neighbor state roughly in parallel with the primary neighbor state machine.
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 5.3 Receiving Mlink Type 9 Neighbor Discovery LSAs
This section explains the detailed processing of a received mlink This section explains the detailed processing of a received mlink
type-9 LSA. When an mlink Type-9 LSA is acknowledged during a primary Type 9 LSA. Note that any mlink Type 9 LSAs received across a
neighbor's database exchange or received via link state update, its secondary interface are simply ignored. Thus two neighbors which
Secondary Area ID is checked against those listed in the primary don't agree on the primary area will never form either primary or
interface's SecondaryAreas parameter. If it is not listed processing secondary adjacencies.
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 When an mlink Type 9 LSA is acknowledged during a primary neighbor's
is examined. If the router itself appears in this list, then the database exchange or received via link state update, its Secondary
corresponding secondary neighbor state machine for this neighbor Area ID is checked against those listed in the primary interface's
should be executed with the event 2-WayReceived. Otherwise, the SecondaryAreas parameter. If it is not listed processing of this LSA
secondary neighbor state machine should be executed with the event stops. If it is listed, for point-to-multipoint and transit networks
1-WayReceived, and the processing of the LSA stops. 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.
o Next, if a change in the neighbor's Secondary Router Priority Next check for the existence of a secondary neighbor in the current
field in the LSA was noted, the corresponding secondary interface list of secondary neighbors contained in the corresponding secondary
state machine is scheduled with the event NeighborChange. 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
data structure and the newly received mlink Type 9 LSA) then execute
a Start event for the newly created secondary neighbor.
o If the neighbor is both declaring itself to be the Designated 5.4 Receiving Secondary Hello Packets
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 The processing of Secondary Hello Packets proceeds as described in
Designated Router in the LSA (LSA's Backup Designated Router field [OSPF] Section 10.5 with just a few exceptions. If a Secondary Hello
= Neighbor IP address) and the corresponding secondary interface Packet is received from a non-existent secondary neighbor the
is in state Waiting, then schedule the secondary interface state processing of the Hello Packet stops and the packet is dropped.
machine with the event BackupSeen. Otherwise, if the neighbor is Secondary neighbor data structures are created by the processing of
declaring itself to be the Backup Designated Router in the LSA and received mlink Type 9 LSAs (See Section 5.4). If a Secondary Hello
it had not previously, or the neighbor is not declaring itself Packet is received with a router priority which does not match that
Backup Designated Router where it had previously, the secondary of the mlink Type 9 LSA which created the secondary neighbor, a 1-
interface state machine is scheduled with the event WayReceived event should be executed.
NeighborChange.
6.0 Advertising Secondary Adjacencies 6.0 Advertising Secondary Adjacencies
Border routers advertise their secondary adjacencies in their A Border router advertises its secondary adjacencies in the router-
router-LSAs as unnumbered point-to-point links even though they may LSAs of its configured secondary areas as point-to-point links even
be numbered point-to-point links, point-to-multipoint links, or though they may be secondary NBMA links. Any stub or transit networks
broadcast or NBMA network links in the OSPF interface's primary area. shared by the primary link with its secondary links are never
This allows their interconnecting networks to retain a single area advertised in the router-LSAs of its secondary areas. This allows
identity. As unnumbered point-to-point links, all secondary these stub and transit networks to retain a single area identity.
adjacencies have link type 1. The building of the router-LSA, as Noting that a secondary interface does share the IP address of its
described in [OSPF] Section 12.4.1, is virtually unchanged. corresponding primary interface, when adding the secondary link to
the router LSA [OSPF] Section 12.4.1.1 is reduced to simply
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 If a neighboring router has formed a secondary adjacency then add
a type 1 (point-to-point) link for this adjacency. Its Link ID 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 should be set to the Router ID of the neighboring router. If the
primary interface is numbered, the Link Data should specify the corresponding primary interface is numbered, the Link Data should
primary interface's IP address. For unnumbered point-to-point specify the primary interface's IP address. If the primary
networks, the Link Data field should specify the interface's MIB- interface is unnumbered, the Link Data field should specify the
II [MIB] ifIndex value. The cost should be set to the secondary interface's MIB-II [MIB] ifIndex value. The cost should be set to
area's cost specified in the primary interface's SecondaryAreas the configured output cost of the corresponding secondary
parameter. interface.
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 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 point-to-point links there is no change required in the Shortest
Shortest Path First (SPF) calculation, except on those border routers Path First (SPF) calculation, except on those border routers where
where they are configured. Border routers do not include in a they are configured. Border routers do not include in a secondary
secondary area's SPF tree any network which one of its secondary area's SPF tree any network which one of its secondary adjacencies
adjacencies transit. This ensures synchronization of the SPF tree transit. This ensures synchronization of the SPF tree amongst the
amongst the secondary area's routers. However border routers do use secondary area's other routers. However border routers do use the IP
the IP addresses stored in their secondary neighbors' router-LSAs for addresses stored in their secondary neighbors' router-LSAs for
determining a destination's next hop across a secondary link when the determining a destination's next hop across a secondary link when the
associated interface connects to a point-to-multipoint or transit associated interface connects to a point-to-multipoint or transit
network. In this case the outgoing interface is derived directly from network. In this case the outgoing interface is derived directly from
the destination router's next hop IP address. the destination router's next hop IP address.
8.0 Flushing Secondary Adjacencies 8.0 Flushing Secondary Adjacencies
Secondary adjacencies are flushed from the link state database of a Secondary adjacencies are flushed from the link state database of a
secondary area when their neighbor states transition down from Full secondary area when their neighbors transition down from Full state,
status, just as with normal OSPF adjacencies. A new router-LSA is just as with normal OSPF adjacencies. A new router-LSA is built for
built for the secondary area and flooded out all of the secondary the secondary area and flooded out all of the secondary area's
area's primary and secondary interfaces. Finally the SPF calculation primary and secondary interfaces. Finally the SPF calculation is
is performed to reflect the new link state topology. performed to reflect the new link state topology.
9.0 Security Considerations 9.0 Security Considerations
Security issues are not discussed in this memo. Security issues are not discussed in this memo.
10.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. In addition, comments from the following individual are also Moy. Most notably, Acee Lindem, Redback Networks, provided
acknowledged: outstanding input which substantially simplified this document from
its previous incarnations.
Acee Lindem IBM
11.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.
skipping to change at page 15, line 38 skipping to change at page 12, line 49
Inc., April 1998. Inc., April 1998.
12.0 Author's Address 12.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@usgs.gov EMail: pmurphy@noc.usgs.net
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
The router-LSA describes the state and cost of the router's links (i.e., router-LSA. The router-LSA describes the state and cost of the
interfaces) to the area. All of the router's links to an area, including router's links (i.e., interfaces) to the area. All of the router's
secondary links, must be described in a single router-LSA. For details links to an area, including secondary links, must be described in a
concerning the construction of router-LSAs see this document's Section 6.0 single router-LSA. For details concerning the construction of
and [OSPF] Section 12.4.1. router-LSAs see this document's Section 6.0 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 17, line 24 skipping to change at page 14, line 24
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 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 as well as a separate entry for each fully adjacent area including a separate entry for each fully adjacent
secondary neighbor across a broadcast or NBMA network link. secondary neighbor, regardless of its secondary link's network
Secondary interfaces to broadcast and NBMA networks are type.
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.
Type Type
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. Secondary
router links are always type 1 point-to-point even when they
have secondary NBMA network type.
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. Its Identifies the object that this router link connects to. Its
value depends on the link's Type. When connecting to an object value depends on the link's Type. When connecting to an object
that 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 are always type 1 point-to-point State ID. This provides the key for looking up the
regardless of the type of their matching primary link. This neighboring LSA in the link state database during the routing
provides the key for looking up the neighboring LSA in the table calculation. See [OSPF] Section 12.2 for more details.
link state database during the routing table calculation. See
[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. Recall a secondary router link (Type 1) shares the IP
point-to-point links, they do evaluate Link Data as if they address of its corresponding primary interface, if it exists.
were numbered whenever their interface has an IP address Otherwise it is an unnumbered point-to-point connection. See
associated with its primary area. See Section 6.0 of this Section 6.0 of this document and [OSPF] Section 16.1.1 for
document and [OSPF] Section 16.1.1 for more details. 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 do not 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. For secondary links the The cost of using this router link. For secondary links the
cost is specified in the primary interface's SecondaryAreas cost is specified in the secondary interface data structure.
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-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 Type-9 Neighbor Discovery LSAs Appendix B. Mlink Type 9 Neighbor Discovery LSAs
Mlink Type-9 LSAs are used directly by OSPF to distribute lists of Mlink Type 9 LSAs are used directly by OSPF to distribute lists of
candidate secondary areas among neighboring routers. Mlink Type-9 candidate secondary areas among neighboring routers. Mlink Type 9
LSAs are flooded across the primary interface. The flooding scope of LSAs are flooded across the primary interface. The flooding scope of
mlink Type-9 LSAs is link-local, which means mlink Type-9 LSAs are an mlink Type 9 LSAs is link-local, which means mlink Type 9 LSAs are
never forwarded beyond the local (sub)network or router link. never flooded beyond the local (sub)network or router link.
Sections 4.0 and 5.5 of this document describe the purpose of these Sections 4.0 and 5.3 of this document describe the purpose of these
mlink Type-9 LSAs 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 | 9 | | 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 | | Secondary Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sec AuType | Sec Options | Sec Rtr Pri | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sec Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sec Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary neighbor | | Sec Rtr Pri | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Syntax of the mlink Type-9 LSA's Link-State ID 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 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 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 Opaque ID (the remaining 24 bits). The mlink Type 9 LSA of each
of the primary interface's secondary areas must have a unique of the primary interface's secondary areas must have a unique
opaque ID. The last 24 bits of the Secondary Area ID will normally opaque ID. The last 24 bits of the Secondary Area ID will normally
produce unique Opaque IDs. When it doesn't, alter the least produce unique Opaque IDs. When it doesn't, alter the least
significant bits until uniqueness is achieved. significant bits until uniqueness is achieved.
Options Options
The optional capabilities supported by this router for the The optional capabilities supported by this router for the
primary area, as documented in [OSPF] Section A.2. primary area, as documented in [OSPF] Section A.2.
Secondary Area ID Secondary Area ID
The area ID of the area across which a neighboring router may The area ID of the area across which a neighboring router may
form a secondary adjacency. form a secondary adjacency.
Sec AuType IP Address
Identifies the authentication procedure to be used. The IP Address of the secondary area's corresponding primary
Authentication is discussed in [OSPF] Appendix D of the interface. If the primary interface has unnumbered point-to-
specification. Consult [OSPF] Appendix D for a list of the point type, then IP Address should be set to 0.
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 Sec Rtr Pri
This router's Designated Router priority for a secondary link This router's Designated Router priority for a secondary link
across a transit network. This parameter is used during the across a transit network. This parameter is used during the
secondary links (Backup) Designated Router election. If set to secondary links (Backup) Designated Router election. If set to
0, the router will be ineligible to become the (Backup) 0, the router will be ineligible to become the (Backup)
Designated Router for this secondary link. 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 interface configuration parameter called this document defines a new interface configuration parameter called
SecondaryAreas which supports unnumbered OSPF multiple area links. SecondaryAreas which supports OSPF Multiple Area Links. The
The SecondaryAreas parameter's default setting is null. 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 SecondaryAreas parameter in a secondary interface data structure is
always null. always null.
For each secondary area listed in an interface's SecondaryAreas
parameter, the secondary link's interface cost, authentication
parameters and Designated Router priority must be configurable. If
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/