[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
Network Working Group                                          P. Murphy
Internet Draft                                      US Geological Survey
Expiration Date: February 2000                               August 2000
File name: draft-ietf-ospf-mlinks-01.txt


                  Unnumbered OSPF Multiple Area Links

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

























Murphy                                                          [Page i]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


Table Of Contents

   1.0   Abstract .................................................  1
   2.0   Overview .................................................  2
   2.1   Requirement for Unnumbered OSPF Multiple Area Links ......  2
   2.2   Proposed Solution ........................................  3
   2.2.1 Secondary Adjacencies ....................................  4
   2.2.2 Secondary Neighbor Discovery .............................  4
   2.2.3 Advertising Secondary Links ..............................  5
   2.3   Application ..............................................  5
   3.0   Secondary Interfaces .....................................  5
   3.1   The SecondaryAreas Interface parameter ...................  5
   3.2   The Secondary Interface Data Structure ...................  6
   3.3   The Secondary Interface State Machine ....................  6
   3.4   OSPF Protocol Packet Processing ..........................  7
   3.5   Designated Router Selection and Function .................  7
   4.0   Synchronizing Secondary Areas Using Mlink Type-9 LSAs ....  8
   5.0   Secondary Neighbors ......................................  9
   5.1   The Secondary Neighbor Data Structure ....................  9
   5.2   The Secondary Neighbor State Machine ..................... 10
   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

   This memo describes an option to the OSPF Version 2 specification
   which allows multiple areas to share the same OSPF interface and
   links. One area is always configured as an interface's primary area.
   The interface's remaining areas are termed secondary and view it as
   unnumbered. Two border routers adjacent across the same secondary
   area may forward the area's intra-area traffic across its secondary
   links. This option applies to standard areas, stub areas, and NSSAs.
   It works over any OSPF interface.  Routers with this option
   configured are backward compatible with routers running the standard
   OSPF Version 2 compliant implementation as defined in RFC 2328.

   Please send comments to ospf@discuss.microsoft.com.



Murphy                                                          [Page 1]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


2.0 Overview

2.1 Requirement for Unnumbered OSPF Multiple Area Links

   Large corporate networks in today's modern Internet have tremendous
   human and equipment resources coupled with sizable budget invested in
   their backbone infrastructure. Their regional networks are normally
   not so fortunate and must multi-home to the backbone in order to take
   advantage of the backbone's faster and more reliable network links.
   Performance over a T1 link can pale by comparison to performance over
   a DS3 or OC3 backbone link.  Large corporate networks have sizable
   backbone routing tables and routinely use stub areas and NSSAs. Under
   the current OSPF specification intra-area routes are always preferred
   over inter-area routes even when the traffic is sourced from and
   destined to the same non-backbone OSPF area.

   Consider the following typical OSPF example:

              A0-----------Area 0 link------------B0-------N1
              |              DS3 (1)               |  (2)
              |                                    |
              |NSSA 1 link              NSSA 1 link|
              |  T1 (28)                  T1 (28)  |
              |                                    |
              |                                    |
              A1-----------NSSA 1 link------------B1-------M1
                            512k (56)                 (2)

   where A0 and B0 are border routers attached to NSSA 1. A1 and B1 are
   internal routers in NSSA 1. N1 and M1 are standard ethernet networks
   in NSSA 1 which are directly attached to B0 and B1 respectively. The
   cost of each link is shown in parentheses. All OSPF costs are
   symmetric. Under the current OSPF specification the preferred path
   between A0 and M1 is

                   A0<->A1<->B1<->M1

   with an OSPF cost of 86, even though there exists a more preferred
   path through B0 namely

                   A0<->B0<->B1<->M1

   with an OSPF cost of 31.

   In addition the NSSA 1 OSPF preferred path between A1 and N1 is

                A1<->B1<->B0<->N1,




Murphy                                                          [Page 2]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


   with an OSPF cost of 86, even though there exists a more preferred
   path through the link between A0 and B0, namely

                A1<->A0<->B0<->N1

   with an OSPF cost of 31. Under the current OSPF specification NSSA
   1's router A1 does not even see this path to N1 since it has no
   knowledge of Area 0's topology. A0, on the other hand, would at lease
   see the summary LSA of N1, but still cannot take advantage of it due
   to OSPF intra-area path preference.

   What is needed is a tool which makes the Area 0 link between A0 and
   B0 visible inside NSSA 1. A common practice is to use multiple
   interface subnets. However this is not an option when the path
   between A0 and B0 is unnumbered or when one desires that the NSSA 1
   path between A0 and B0 be unnumbered. Moreover when configuring
   multiple interface subnets over multi-access networks, inverse-arp
   limitations come into play and additional layer 2 PVCs may be
   required imposing potential resource and budgetary ramifications. The
   existing tools for the multiple area usage of the same physical link
   are awkward to configure, implementation dependent, unnecessarily
   complex and unwieldy to maintain. 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

   The Unnumbered OSPF Multiple Area Links option lets multiple areas
   use the same link between two border routers for intra-area traffic.
   Traffic may originate from inside each of the configured areas, as
   every router in the configured areas sees the link as part of its
   link state topology. Routers with configured unnumbered OSPF multiple
   area links must be in Area 0, although the connection to Area 0 may
   be an unnumbered OSPF multiple area link.

   The current OSPF specification only allows one area per OSPF
   interface.  Thus, should an Area L dual-home to Area 0 via two border
   routers which are adjacent over another Area K's router<->router link
   or router<->network link, the adjacent link over Area K is not seen
   inside Area L, even though the two border routers exist physically



Murphy                                                          [Page 3]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


   adjacent within Area L. This, coupled with intra-area route
   preference, prevents Area L from utilizing Area K's adjacent path.

2.2.1 Secondary Adjacencies

   The softening of this restriction is facilitated by the addition of a
   new interface configuration parameter called SecondaryAreas. This
   parameter specifies a list of additional areas in which an OSPF
   interface also belongs (See Appendix C). The areas listed in this
   parameter are called the interface's secondary areas, as opposed to
   the interface's configured area, hereafter called the primary area. A
   separate interface data structure is generated for each of the
   secondary areas. For each secondary area listed in the SecondaryAreas
   parameter a router can form OSPF adjacencies with the primary area's
   neighboring routers across the interface's directly attached network
   or router link. These adjacencies are called secondary adjacencies.

   Secondary adjacencies are formed after the primary area's link state
   data base exchange has synchronized matching secondary areas 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.2.2 Secondary Neighbor Discovery

   A Type-9 opaque LSA is used to form secondary adjacencies over a
   primary link with adjacent opaque capable border routers. Until an
   opaque type is assigned for this option experimental opaque type 224
   will be used. The option's LSA is referred to as an mlink Type-9 LSA.
   A Type-9 LSA is used for the exchange/update of an interface's
   secondary areas because the flooding scope of this opaque LSA needs
   to be restricted to routers which are directly attached to a common
   network or router link. A separate mlink Type-9 LSA is originated for
   each of the primary interface's secondary areas. 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 a router A receives an mlink Type-9 LSA for area L originating
   from a router B during the exchange/update of primary area K's LSDB,
   then router A may form a secondary adjacency in area L with router B
   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



Murphy                                                          [Page 4]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


   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

   Secondary adjacencies are advertised as point-to-point or point-to-
   multipoint links. Any intervening transit network always belongs to
   the interface's primary area. Moreover, there is no network LSA for a
   secondary adjacency's intervening transit network in the secondary
   area.  Hence all secondary adjacencies must be advertised in a
   router's router-LSA with unnumbered point-to-point type.

   During the Dykstra shortest path first (SPF) calculation the LSAs for
   secondary adjacencies look like unnumbered point-to-point links. A
   Border router never includes in a secondary area's SPF tree any
   network across which one of its secondary adjacencies span. This
   ensures synchronization of the SPF tree amongst the secondary area's
   routers. However border routers may use the IP addresses of
   neighboring routers for determining a destination's next hop across a
   secondary link over a point-to-multipoint or transit network.

2.3 Application

   Consider now the example mentioned in Section 2.1 and assume NSSA 1
   is configured as a secondary area over the Area 0 link between A0 and
   B0. Since the routers A0, A1, B0, and B1 possess NSSA 1's router-LSAs
   originating from A0 and B0 which define a secondary link between A0
   and B0 in NSSA 1, the NSSA 1 intra-area SPF tree computed by the
   Dykstra calculation now includes this DS3 link with a cost of 1. Thus
   the path between A0 and M1 is the more preferred path

                A0<->B0<->B1<->M1

   and the path between A1 and N1 is the more preferred path

                A1<->A0<->B0<->N1

3.0 Secondary Interfaces

3.1 The SecondaryAreas Interface Parameter

   A new configuration parameter called SecondaryAreas has been added to
   the OSPF interface data structure (See Appendix C). The
   SecondaryAreas interface parameter lists a set of areas which may
   form 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



Murphy                                                          [Page 5]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


   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.2 The Secondary Interface Data Structure

   An OSPF interface data structure should be built for each of an OSPF
   interface's secondary areas. These interface data structures are
   called secondary interface data structures and are 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 secondary interface's list of neighboring routers is generated by
   examining the primary interface's received mlink Type-9 LSAs as
   defined in Section 4.0 below. 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
   interface's data structure and still compute a Designated Router and
   a Backup Designated Router over broadcast and NBMA networks. This
   promotes efficient flooding across a primary interface's transit
   network. However, these network links are always advertised as
   unnumbered router<->router links and behave exactly like point-to-
   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.3 The Secondary Interface State Machine

   The interface states of a secondary interface are the same as the
   interface states of a primary interface. However in some cases state
   transitions are triggered by the primary interface's state machine.
   The InterfaceUp event is redefined for secondary links:

   InterfaceUp

      This event is triggered by the primary interface when it
      transitions to either Point-to-point, DR Other, DR, or Backup



Murphy                                                          [Page 6]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


      state. Its effect on the secondary interface's state is similar to
      the effect the InterfaceUp event has on the primary interface's
      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
   unchanged for secondary interfaces. Note 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.

3.4 OSPF Protocol Packet processing

   Since secondary interfaces are unnumbered interfaces, OSPF protocol
   packet processing needs a minor adjustment. For point-to-point
   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).

3.5 Designated Router Selection and Function

   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



Murphy                                                          [Page 7]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


   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.

   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

   Mlink Type-9 LSAs are used to discover and maintain secondary
   neighbor relationships and to elect the Designated Router and Backup
   Designated Router for multi-access secondary adjacencies. If the
   primary interface is of broadcast or NBMA type then all of its
   candidate Designated Routers must be opaque capable, even if these
   routers have no secondary areas configured for their link to the
   broadcast or NBMA network. Otherwise mlink Type-9 LSAs may not
   propagate to all potential routers capable of forming secondary
   adjacencies over the network. Note that these candidate Designated
   Routers do not have to support 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.

   The format of the mlink Type-9 LSA is detailed in Appendix B. Any
   router which has an interface with a non-empty SecondaryAreas
   interface parameter must originate an mlink Type-9 LSA for each
   configured secondary area. If an interface's SecondaryAreas parameter
   is null, then no mlink Type-9 LSAs should be advertised. A secondary
   area's mlink Type-9 LSA minimally lists as opaque information the
   area's secondary area ID, its optional capabilities, its
   authentication parameters, and, if required, its Designated Router
   priority.

   In addition, to ensure proper secondary neighbor state transition, a
   secondary area's mlink Type-9 LSA also lists as opaque information
   those primary neighbors from which an mlink Type-9 LSA has been
   received for this area with matching optional capabilities and
   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



Murphy                                                          [Page 8]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


   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
   areas must have a unique opaque ID. The last 24 bits of the Secondary
   Area ID will normally produce unique Opaque IDs. When it doesn't,
   alter the least significant bits until uniqueness is achieved.

5.0 Secondary Neighbors

   An OSPF router converses with its secondary neighbors. Each separate
   conversation is described by a "secondary neighbor data structure".
   Conversations between secondary neighbors are bound to the secondary
   interface and identified by both the Area ID and either the router's
   OSPF Router ID or its Neighbor IP address (see 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.



Murphy                                                          [Page 9]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


   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



Murphy                                                         [Page 10]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


   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



Murphy                                                         [Page 11]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


      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



Murphy                                                         [Page 12]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


   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.




Murphy                                                         [Page 13]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


   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
   as unnumbered point-to-point links there is no change required in the
   Shortest Path First (SPF) calculation, except on those border routers
   where they are configured. Border routers do not include in a
   secondary area's SPF tree any network which one of its secondary
   adjacencies transit. This ensures synchronization of the SPF tree
   amongst the secondary area's routers.  However border routers do use
   the IP addresses stored in their secondary neighbors' router-LSAs for
   determining a destination's next hop across a secondary link when the
   associated interface connects to a point-to-multipoint or transit
   network. In this case the outgoing interface is derived directly from
   the destination router's next hop IP address.

8.0 Flushing Secondary Adjacencies

   Secondary adjacencies are flushed from the link state database of a
   secondary area when their 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.







Murphy                                                         [Page 14]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


9.0 Security Considerations

   Security issues are not discussed in this memo.

10.0 Acknowledgments

   This document was produced by the OSPF Working Group, chaired by John
   Moy.  In addition, comments from the following individual are also
   acknowledged:

   Acee Lindem        IBM

11.0 References

   [MIB]   McCloghrie, K., and M. Rose, "Management Information Base for
           network management of TCP/IP-based internets: MIB-II", STD
           17, RFC 1213, Hughes LAN Systems, Performance Systems
           International, March 1991.

   [OPAQ]  Coltun, Rob, "The OSPF Opaque LSA Option", FORE Systems,
           August 1998.

   [OSPF]  Moy, J., "OSPF Version 2", RFC 2328, Ascend Communications,
           Inc., April 1998.

12.0 Author's Address

   Pat Murphy
   US Geological Survey
   345 Middlefield Road, Mail Stop 870
   Menlo Park, California 94560

   Phone: (650)329-4044
   EMail: pmurphy@usgs.gov

















Murphy                                                         [Page 15]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


Appendix A. Router-LSAs

   Router-LSAs are Type 1 LSAs. Each router in an area originates a router-LSA.
   The router-LSA describes the state and cost of the router's links (i.e.,
   interfaces) to the area. All of the router's links to an area, including
   secondary links, must be described in a single router-LSA. For details
   concerning the construction of router-LSAs see this document's Section 6.0
   and [OSPF] Section 12.4.1.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |     Options   |       1       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    0    |V|E|B|        0      |            # links            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Link ID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Link Data                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     # TOS     |            metric             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      TOS      |        0      |          TOS  metric          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Link ID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Link Data                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |

   In router-LSAs, the Link State ID field is set to the router's OSPF
   Router ID. Router-LSAs are flooded throughout a single area only.

      bit V
          When set, the router is an endpoint of one or more fully
          adjacent virtual links having the described area as its
          transit area (V is for virtual link endpoint).




Murphy                                                         [Page 16]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


      bit E
          When set, the router is an AS boundary router (E is for
          external).

      bit B
          When set, the router is an area border router (B is for
          border).

      bit W
          When set, the router is a wild-card multicast receiver (W is
          for wild).

      bit Nt
          When set, the router is a NSSA border router which translates
          type-7 LSAs into type-5 LSAs (Nt is for NSSA translation).

      # links
          The number of router links described in this LSA. This must be
          the total collection of router links (i.e., interfaces) to the
          area 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.,
   interface). Each router link is typed (see the below Type field). The
   Type field indicates the kind of link being described. It may be a
   link to a transit network, to another router or to a stub network.
   The values of all the other fields describing a router link depend on
   the link's Type. For example, each link has an associated 32-bit Link
   Data field. For links to stub networks this field specifies the
   network's IP address mask. For other link types the Link Data field
   specifies the router interface's IP address.


      Type
          A quick description of the router link for one of the
          following. Note that host routes are classified as links to
          stub networks with network mask of 0xffffffff.


                 Type   Description
                 __________________________________________________
                 1      Point-to-point connection to another router
                 2      Connection to a transit network
                 3      Connection to a stub network
                 4      Virtual link




Murphy                                                         [Page 17]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


      Link ID
          Identifies the object that this router link connects to. Its
          value depends on the link's Type. When connecting to an object
          that also originates an LSA (i.e., another router or a transit
          network) the Link ID is equal to the neighboring LSA's Link
          State ID. Secondary links are always type 1 point-to-point
          regardless of the type of their matching primary link. This
          provides the key for looking up the neighboring LSA in the
          link state database during the routing table calculation. See
          [OSPF] Section 12.2 for more details.

                 Type   Link ID
                 ______________________________________
                 1      Neighboring router's Router ID
                 2      IP address of Designated Router
                 3      IP network/subnet number
                 4      Neighboring router's Router ID

      Link Data
          Value again depends on the link's Type field. For connections
          to stub networks, Link Data specifies the network's IP address
          mask. For unnumbered point-to-point connections, it specifies
          the interface's MIB-II [MIB] ifIndex value. For the other link
          types it specifies the router interface's IP address. This
          latter piece of information is needed during the routing table
          build process, when calculating the IP address of the next
          hop.  Although secondary links are considered unnumbered
          point-to-point links, they do evaluate Link Data as if they
          were numbered whenever their interface has an IP address
          associated with its primary area. See Section 6.0 of this
          document and [OSPF] Section 16.1.1 for more details.

      # TOS
          The number of different TOS metrics given for this link, not
          counting the required link metric (referred to as the TOS 0
          metric in [1583]). For example, if no additional TOS metrics
          are given, this field is set to 0.  Secondary Areas do not use
          TOS.

      metric
          The cost of using this router link. For secondary links the
          cost is specified in the primary interface's SecondaryAreas
          parameter.


   Additional TOS-specific information may also be included, for
   backward compatibility with previous versions of the OSPF
   specification ([1583]).  Within each link, and for each desired TOS,



Murphy                                                         [Page 18]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


   TOS-specific link information may be encoded as follows:

      TOS
          IP Type of Service that this metric refers to. The encoding of
          TOS in OSPF LSAs is described in [1583] Section 12.3.

      TOS metric
          TOS-specific metric information.











































Murphy                                                         [Page 19]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


Appendix B. Mlink Type-9 Neighbor Discovery LSAs

   Mlink Type-9 LSAs are used directly by OSPF to distribute lists of
   candidate secondary areas among neighboring routers. Mlink Type-9
   LSAs are flooded across the primary interface. The flooding scope of
   mlink Type-9 LSAs is link-local, which means mlink Type-9 LSAs are
   never forwarded beyond the local (sub)network or router link.

   Sections 4.0 and 5.5 of this document describe the purpose of these
   mlink Type-9 LSAs in more detail.

       0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |    Options    |       9       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Opaque Type   |               Opaque ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Advertising Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      LS Sequence Number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Secondary Area ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Sec AuType           |  Sec Options  |  Sec Rtr Pri  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Sec Authentication                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Sec Authentication                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Designated Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Backup Designated Router                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Secondary neighbor                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |

   Syntax of the mlink Type-9 LSA's Link-State ID

      The link-state ID of an mlink Type-9 LSA is divided into an Opaque
      Type field (the first 8 bits), which has value mlink, and the
      Opaque ID (the remaining 24 bits).  The mlink Type-9 LSA of each
      of the primary interface's secondary areas must have a unique
      opaque ID. The last 24 bits of the Secondary Area ID will normally
      produce unique Opaque IDs. When it doesn't, alter the least



Murphy                                                         [Page 20]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


      significant bits until uniqueness is achieved.

      Options
         The optional capabilities supported by this router for the
         primary area, as documented in [OSPF] Section A.2.

      Secondary Area ID
         The area ID of the area across which a neighboring router may
         form a secondary adjacency.

      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



Murphy                                                         [Page 21]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


         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.












































Murphy                                                         [Page 22]


Internet Draft    Unnumbered OSPF Multiple Area Links        August 2000


Appendix C. Interface Data Structure

   Chapter 9 in the OSPF specification documents the interface data
   structure and the data items which are included in it. Section 3.1 of
   this document defines a new interface configuration parameter called
   SecondaryAreas which supports unnumbered OSPF multiple area links.
   The SecondaryAreas parameter's default setting is null. The
   SecondaryAreas parameter in a secondary interface data structure is
   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.

































Murphy                                                         [Page 23]