[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

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


                        OSPF Multiple Area Links

Status of this Memo

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

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

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

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

























Murphy                                                          [Page i]


Internet Draft          OSPF Multiple Area Links           February 2002


Table Of Contents

   1.0   Abstract .................................................  1
   2.0   Overview .................................................  2
   2.1   Requirement for OSPF Multiple Area Links .................  2
   2.2   Proposed Solution ........................................  3
   2.2.1 Secondary Adjacencies ....................................  4
   2.2.2 Secondary Neighbor Discovery .............................  4
   2.2.3 Advertising Secondary Links ..............................  5
   2.3   Application ..............................................  5
   3.0   Secondary Interfaces .....................................  5
   3.1   The SecondaryAreas Interface parameter ...................  5
   3.2   The Secondary Interface Data Structure ...................  6
   3.3   The Secondary Interface State Machine ....................  6
   3.4   OSPF Protocol Packet Processing ..........................  7
   3.5   Designated Router Election and Function ..................  7
   4.0   Synchronizing Secondary Areas Using Mlink Type 9 LSAs ....  8
   5.0   Secondary Neighbors ......................................  8
   5.1   The Secondary Neighbor Data Structure ....................  8
   5.2   The Secondary Neighbor State Machine .....................  9
   5.3   Receiving Mlink Type 9 Neighbor Discover LSAs ............ 10
   5.4   Receiving Secondary Hello Packets ........................ 11
   6.0   Advertising Secondary Adjacencies ........................ 11
   7.0   The Shortest Path First Calculation ...................... 11
   8.0   Flushing Secondary Adjacencies ........................... 12
   9.0   Security Considerations .................................. 12
   10.0  Acknowledgments .......................................... 12
   11.0  References ............................................... 12
   12.0  Authors' Addresses ....................................... 12
   Appendix A: Router-LSAs ........................................ 13
   Appendix B: Mlink Type 9 Neighbor Discover LSAs ................ 17
   Appendix C: Configuration Parameters ........................... 19

1.0 Abstract

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

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





Murphy                                                          [Page 1]


Internet Draft          OSPF Multiple Area Links           February 2002


2.0 Overview

2.1 Requirement for OSPF Multiple Area Links

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

   Consider the following typical OSPF example:

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

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

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

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

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

   with an OSPF cost of 31.

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

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




Murphy                                                          [Page 2]


Internet Draft          OSPF Multiple Area Links           February 2002


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

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

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

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

2.2 Proposed Solution

   The OSPF Multiple Area Links option is a simpler tool for configuring
   multiple area links, requiring just a simple list of the areas
   sharing an OSPF link. Once configured it lets multiple areas use the
   same link between two border routers for each area's intra-area
   traffic. Traffic may originate from inside each of the configured
   areas, as every router in the configured areas sees the link as part
   of its link state topology. Routers with configured OSPF Multiple
   Area Links must be in Area 0, although the connection to Area 0 may
   be one of the areas listed as sharing the link.

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






Murphy                                                          [Page 3]


Internet Draft          OSPF Multiple Area Links           February 2002


2.2.1 Secondary Adjacencies

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

   Secondary adjacencies are formed after the primary area's link state
   data base exchange has synchronized matching secondary areas through
   the flooding path with the link's other directly connected routers.
   (See Section 4.0).  Link state database exchange occurs across a
   secondary adjacency along with normal flooding. Note that a secondary
   adjacency for area 0 may not be configured for an interface which is
   linked to a transit area for a configured virtual link (See Section
   3.4).

2.2.2 Secondary Neighbor Discovery

   A Type 9 opaque LSA is used to form secondary adjacencies over a
   primary link with adjacent opaque capable border routers. Until an
   opaque type is assigned for this option, experimental opaque type 224
   will be used. The option's LSA is referred to as an mlink Type 9 LSA.
   A Type 9 LSA is used for the exchange/update of an interface's
   secondary areas because the flooding scope of this opaque LSA needs
   to be restricted to routers which are directly attached to a common
   network or router link. A separate mlink Type 9 LSA is originated for
   each of the primary interface's secondary areas. If required,
   included in a secondary area's mlink Type 9 LSA is the secondary
   area's configured Designated Router priority. Mlink Type 9 LSAs are
   propagated during the exchange/update of the primary area's link
   state data base (LSDB) with its adjacent primary neighbors.

   If a router A receives an mlink Type 9 LSA for area L originating
   from a router B during the exchange/update of primary area K's LSDB,
   then router A may form a secondary adjacency in area L with router B.
   See Section 5.2 for details about secondary neighbor adjacency
   formation. LSDB exchange and update across a secondary adjacency
   proceed as defined in [OSPF] Sections 10 and 13.






Murphy                                                          [Page 4]


Internet Draft          OSPF Multiple Area Links           February 2002


2.2.3 Advertising Secondary Links

   Secondary adjacencies are advertised as point-to-point links. Any
   intervening transit network or stub network assigned to the primary
   interface always belongs to the interface's primary area. There is no
   network LSA for this intervening transit network in any of the
   interface's secondary areas. All secondary adjacencies must be
   advertised in a router-LSA with point-to-point type.

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

2.3 Application

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

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

   and the preferred path between A1 and N1

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

3.0 Secondary Interfaces

3.1 The SecondaryAreas Interface Parameter

   A new configuration parameter called SecondaryAreas has been added to
   the OSPF interface data structure (See Appendix C). The
   SecondaryAreas interface parameter lists a set of areas which may
   form secondary adjacencies across the interface. If the
   SecondaryAreas interface parameter has a null list, then no secondary
   areas are configured for this interface and no secondary adjacencies
   can be formed over the interface.

   Each area listed in the SecondaryAreas interface parameter should



Murphy                                                          [Page 5]


Internet Draft          OSPF Multiple Area Links           February 2002


   have a secondary interface data structure. With the exception of Area
   ID all of secondary interface parameters which are usually
   configurable, such as interface cost, authentication parameters and
   Designated Router priority, default to the values assigned to the
   primary interface. Furthermore, except for the Area ID, IP interface
   address and mask, all configurable interface parameters should be
   separately configurable for each secondary interface.  Note that if a
   virtual link is configured across a transit area which is linked to
   an interface, then Area 0 may not be configured in the interface's
   SecondaryAreas parameter.

3.2 The Secondary Interface Data Structure

   An OSPF interface data structure should be built for each of an OSPF
   interface's secondary areas. These interface data structures are
   called secondary interface data structures and are loosely bound to
   the primary interface. The configured primary area of an OSPF
   interface generates its primary interface data structure. A point-
   to-point layer 2 link between two routers may have only one OSPF
   interface per area (See [OSPF] Sections 8.2 and 10.5). Additional
   areas may be added as secondary areas, but they must not duplicate
   areas already configured for the layer 2 link. A secondary
   interface's list of neighboring routers is generated by examining the
   primary interface's received mlink Type 9 LSAs as defined in Section
   4.0 below.

   With the exception of broadcast networks, secondary interfaces copy
   their interface type from the primary interface's data structure. If
   the primary interface's network has broadcast type then the secondary
   interface's network has NBMA type. Secondary interfaces with NBMA
   type still compute a Designated Router and a Backup Designated
   Router. This promotes efficient flooding across the interface's
   transit network. Note that secondary adjacencies are always
   advertised as router links even when their network type is NBMA. As
   such the Designated Router of a secondary NBMA link does not
   originate a type-2 network LSA into the secondary area for the
   primary interface's transit network.

3.3 The Secondary Interface State Machine

   The interface states of a secondary interface are the same as the
   interface states of a primary interface. Secondary neighbors exchange
   Hello packets, called secondary Hello packets, just like primary
   neighbors. The processing of received secondary Hellos is practically
   unchanged (See Section 5.5). The InterfaceUp event for a secondary
   interfaces is generated by its corresponding primary interface when
   the primary interface transitions to either Point-to-point, DR Other,
   DR, or Backup state. In addition to those actions described in [OSPF]



Murphy                                                          [Page 6]


Internet Draft          OSPF Multiple Area Links           February 2002


   Section 9.3, when the InterfaceUp event is generated for secondary
   interfaces, the neighbor Start event is generated for each existing
   secondary neighbor.

   The remainder of the interface state machine is virtually unchanged
   for secondary interfaces. Those protocols which generate the events
   InterfaceDown, LoopInd, UnloopInd for the primary interface should
   generate the same events for all of the primary interface's
   corresponding secondary interfaces. The NeighborChange and BackupSeen
   events are generated through the orderly processing of secondary
   Hello packets received across the secondary interface as described in
   [OSPF] Section 10.5 and augmented in Section 5.4. It is notable that
   since the secondary interface's InterfaceUp event occurs only after
   the primary interface has transitioned to DR other, DR or Backup
   state, a secondary interface's Wait Timer will never start before the
   primary interface's Wait Timer has fired. This produces a more
   orderly ascension to Full state for secondary NBMA adjacencies.

3.4 OSPF Protocol Packet processing

   Since a secondary interface shares the ip address of its
   corresponding primary interface, OSPF protocol packet processing
   needs a minor adjustment.  For broadcast, NBMA, and point-to-
   multipoint links, the packet's IP source address is required to be on
   the same network as the receiving OSPF primary interface. This can be
   verified by comparing the packet's IP source address to the primary
   interface's source address, after masking both addresses with the
   interface mask (See [OSPF] Section 8.2). The Area Id is used to
   distinguish the primary interface from its configured secondary
   interfaces.  Any router with a configured virtual link cannot
   configure Area 0 in the SecondaryAreas parameters of any interface
   belonging to the link's transit area. Otherwise the virtual link
   would not be distinguishable from an Area 0 secondary link.

3.5 Designated Router Election and Function

   The election of the Designated Router and the Backup Designated
   router for a secondary link over a secondary NBMA network proceeds as
   described in [OSPF] Section 9.4. Eligibility is determined from the
   Designated Router priorities configured for each secondary area as
   well as the priorities defined in received secondary Hellos from
   secondary neighbors. Note that the Designated Router for a secondary
   link does not originate a network-LSA (Type-2) into its secondary
   area for the secondary NBMA network over which the secondary link
   bridges. All secondary links are advertised as point-to-point links
   (see Section 6.0). The only function of a secondary link's Designated
   Router is flooding optimization.




Murphy                                                          [Page 7]


Internet Draft          OSPF Multiple Area Links           February 2002


4.0 Synchronizing Secondary Areas using Mlink Type 9 LSAs

   Mlink Type 9 LSAs are used to discover and start secondary neighbor
   relationships. If the primary interface is of broadcast or NBMA type
   then all of its candidate Designated Routers must be opaque capable,
   even if these routers have no secondary areas configured for their
   link to the broadcast or NBMA network. Otherwise mlink Type 9 LSAs
   may not propagate to all potential routers capable of forming
   secondary adjacencies over the network. Note that these candidate
   Designated Routers do not have to support OSPF Multiple Area Links,
   but they do have to be opaque capable in order to flood mlink Type 9
   LSAs to their adjacent primary neighbors who may or may not support
   OSPF Multiple Area Links.

   The format of the mlink Type 9 LSA is detailed in Appendix B. Any
   router which has an interface with a non-empty SecondaryAreas
   interface parameter must originate across the primary interface an
   mlink Type 9 LSA for each configured secondary area. If an
   interface's SecondaryAreas parameter is null, then no mlink Type 9
   LSAs will be advertised. A secondary area's mlink Type 9 LSA
   minimally lists as opaque information the secondary link's Area ID,
   plus, if available, its IP address and, if required, its Designated
   Router priority. A new mlink Type 9 LSA is reoriginated following
   expiration of its LSRefreshInterval or when changes occur in the
   secondary link's router priority. Mlink Type 9 LSAs are only flooded
   at the routers fully adjacent primary neighbors. If a secondary area
   is removed from a primary interface's configured secondary areas, its
   locally originated mlink Type 9 LSA should be flushed.

   The mlink Type 9 LSA of each of the primary interface's secondary
   areas must have a unique opaque ID. The last 24 bits of the Secondary
   Area ID will normally produce unique Opaque IDs. When it doesn't,
   alter the least significant bits until uniqueness is achieved.

5.0 Secondary Neighbors

   An OSPF router converses with its secondary neighbors. Each separate
   conversation is described by a "secondary neighbor data structure".
   Conversations between secondary neighbors are bound to the secondary
   interface and identified by both the Area ID and either the router's
   OSPF Router ID or its Neighbor IP address (see Section 3.4). Unless
   discussed below details for the creation and maintenance of secondary
   neighbors and secondary adjacencies are the same as discussed in
   [OSPF] Sections 10.

5.1 The Secondary Neighbor Data Structure

   The neighbor data structure for secondary adjacencies is identical to



Murphy                                                          [Page 8]


Internet Draft          OSPF Multiple Area Links           February 2002


   the neighbor data structure for standard OSPF adjacencies. Secondary
   neighbors are discovered by comparing the Area IDs of the primary
   interface's received mlink Type 9 LSAs with the secondary areas
   listed in the interface's SecondaryAreas parameter. For point-to-
   multipoint and transit networks, the originator of the mlink Type 9
   LSA should be on the same network as the receiving interface. This
   can be verified by comparing the mlink Type 9 LSA's IP address field
   with the IP address of the primary interface, after masking both
   addresses with the interface mask. For point-to-point and point-to-
   multipoint secondary network types, a separate neighbor data
   structure is always built for each new secondary neighbor discovered
   by a received mlink Type 9 LSA. Since the mlink Type 9 LSA of an NBMA
   secondary link includes the neighbor's Designated Router priority,
   its separate secondary neighbor data structure is built only when
   either the local router or the originating router of the mlink Type 9
   LSA is DR eligible (see Section 5.4). The Neighbor ID and the
   Neighbor IP address of the secondary neighbor's data structure are
   copied from the Advertising Router field and IP Address fields of the
   mlink Type 9 LSA.

5.2 The Secondary Neighbor State Machine

   While secondary neighbor states are identical to OSPF's neighbor
   states, there are a few important distinctions in their actions and
   the events which trigger them. When a primary interface receives an
   new mlink Type 9 LSA from a primary neighbor, the LSA's content may
   create a new secondary neighbor, destroy an existing secondary
   neighbor or modify the state of an existing secondary neighbor. For
   point-to-point and point-to-multipoint secondary network types, a new
   secondary neighbor is always established. For NBMA secondary network
   types, the decision whether or not to create a new secondary neighbor
   depends on whether either the local router or the originating router
   are DR eligible (See Section 5.3). A router must clear its own mlink
   Type 9 LSAs from the database summary list of a primary neighbor
   during database exchange to ensure that its corresponding secondary
   neighbor relationships transition out of Down state. A secondary
   neighbor state machine always passes through Attempt state, even for
   point-to-point and point-to-multipoint secondary interface network
   types (See Section 5.3 and 5.4).

   If an mlink Type 9 LSA ages out, the KillNbr event is executed for
   the corresponding secondary neighbor, and the LSA should be flushed.
   If the state of the neighbor is 2-way or higher, the local router
   should send a Hello packet to the secondary neighbor which omits it
   from the neighbor list (See Section 5.5). The conditions which cause
   the execution of the KillNbr and LLDown events for primary neighbors
   should trigger the same events for any of their corresponding
   secondary neighbors.



Murphy                                                          [Page 9]


Internet Draft          OSPF Multiple Area Links           February 2002


   Since the formation of secondary neighbors is linked with the
   database exchange and the link state update of the mlink Type 9 LSAs
   received across the primary link, the timing of this exchange effects
   when a secondary neighbor transitions to ExStart state. The mlink
   Type 9 LSA of a secondary Area 0 should be listed at the top of the
   database summary list. The mlink Type 9 LSAs of non-backbone
   secondary areas should be listed at the bottom of the database
   summary list. These tools mitigate the effect of the database
   exchange by non-backbone secondary areas on the primary neighbor
   state machine as it transitions to Full state, while at the same time
   letting an Area 0 secondary neighbor state machine proceed to Full
   state roughly in parallel with the primary neighbor state machine.

5.3 Receiving Mlink Type 9 Neighbor Discovery LSAs

   This section explains the detailed processing of a received mlink
   Type 9 LSA. Note that any mlink Type 9 LSAs received across a
   secondary interface are simply ignored. Thus two neighbors which
   don't agree on the primary area will never form either primary or
   secondary adjacencies.

   When an mlink Type 9 LSA is acknowledged during a primary neighbor's
   database exchange or received via link state update, its Secondary
   Area ID is checked against those listed in the primary interface's
   SecondaryAreas parameter. If it is not listed processing of this LSA
   stops. If it is listed, for point-to-multipoint and transit networks
   the originator of the mlink Type 9 LSA should be on the same network
   as the receiving interface.  This can be verified by comparing the
   mlink Type 9 LSA's IP address field with the IP address of the
   primary interface, after masking both addresses with the interface
   mask. If a match does not occur processing of this LSA stops.

   Next check for the existence of a secondary neighbor in the current
   list of secondary neighbors contained in the corresponding secondary
   interface data structure. If a matching secondary neighbor data
   structure cannot be found, (i.e. this is the first time the secondary
   neighbor has been detected), and if the secondary network type is
   either point-to-point or point-to-multipoint or the secondary network
   type is NBMA and either the local router or the originating router is
   DR eligible across the secondary NBMA, then create a secondary
   neighbor data structure for the neighbor described in the mlink Type
   9. The Neighbor ID and the Neighbor IP address of the secondary
   neighbor data structure are copied from the Advertising Router and IP
   Address fields of the mlink Type 9 LSA. The initial state of the
   newly created secondary neighbor is set to Down. If the secondary
   network type is point-to-point or point-to-multipoint, or the
   secondary network type is NBMA and both the local router and the
   originating router are DR eligible (as defined the secondary neighbor



Murphy                                                         [Page 10]


Internet Draft          OSPF Multiple Area Links           February 2002


   data structure and the newly received mlink Type 9 LSA) then execute
   a Start event for the newly created secondary neighbor.

5.4 Receiving Secondary Hello Packets

   The processing of Secondary Hello Packets proceeds as described in
   [OSPF] Section 10.5 with just a few exceptions. If a Secondary Hello
   Packet is received from a non-existent secondary neighbor the
   processing of the Hello Packet stops and the packet is dropped.
   Secondary neighbor data structures are created by the processing of
   received mlink Type 9 LSAs (See Section 5.4). If a Secondary Hello
   Packet is received with a router priority which does not match that
   of the mlink Type 9 LSA which created the secondary neighbor, a 1-
   WayReceived event should be executed.

6.0 Advertising Secondary Adjacencies

   A Border router advertises its secondary adjacencies in the router-
   LSAs of its configured secondary areas as point-to-point links even
   though they may be secondary NBMA links. Any stub or transit networks
   shared by the primary link with its secondary links are never
   advertised in the router-LSAs of its secondary areas. This allows
   these stub and transit networks to retain a single area identity.
   Noting that a secondary interface does share the IP address of its
   corresponding primary interface, when adding the secondary link to
   the router LSA [OSPF] Section 12.4.1.1 is reduced to simply

      If a neighboring router has formed a secondary adjacency then add
      a type 1 (point-to-point) link for this adjacency. Its Link ID
      should be set to the Router ID of the neighboring router. If the
      corresponding primary interface is numbered, the Link Data should
      specify the primary interface's IP address. If the primary
      interface is unnumbered, the Link Data field should specify the
      interface's MIB-II [MIB] ifIndex value. The cost should be set to
      the configured output cost of the corresponding secondary
      interface.

7.0 The Shortest Path First Calculation

   Since secondary links appear in the link state data base of an area
   as point-to-point links there is no change required in the Shortest
   Path First (SPF) calculation, except on those border routers where
   they are configured.  Border routers do not include in a secondary
   area's SPF tree any network which one of its secondary adjacencies
   transit. This ensures synchronization of the SPF tree amongst the
   secondary area's other routers. However border routers do use the IP
   addresses stored in their secondary neighbors' router-LSAs for
   determining a destination's next hop across a secondary link when the



Murphy                                                         [Page 11]


Internet Draft          OSPF Multiple Area Links           February 2002


   associated interface connects to a point-to-multipoint or transit
   network. In this case the outgoing interface is derived directly from
   the destination router's next hop IP address.

8.0 Flushing Secondary Adjacencies

   Secondary adjacencies are flushed from the link state database of a
   secondary area when their neighbors transition down from Full state,
   just as with normal OSPF adjacencies. A new router-LSA is built for
   the secondary area and flooded out all of the secondary area's
   primary and secondary interfaces. Finally the SPF calculation is
   performed to reflect the new link state topology.

9.0 Security Considerations

   Security issues are not discussed in this memo.

10.0 Acknowledgments

   This document was produced by the OSPF Working Group, chaired by John
   Moy.  Most notably, Acee Lindem, Redback Networks, provided
   outstanding input which substantially simplified this document from
   its previous incarnations.

11.0 References

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

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

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

12.0 Author's Address

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

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





Murphy                                                         [Page 12]


Internet Draft          OSPF Multiple Area Links           February 2002


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 13]


Internet Draft          OSPF Multiple Area Links           February 2002


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

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

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

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

      # links
          The number of router links described in this LSA. This must be
          the total collection of router links (i.e., interfaces) to the
          area including a separate entry for each fully adjacent
          secondary neighbor, regardless of its secondary link's network
          type.

   The following fields are used to describe each router link (i.e.,
   interface). Each router link is typed (see the below Type field). The
   Type field indicates the kind of link being described. It may be a
   link to a transit network, to another router or to a stub network.
   The values of all the other fields describing a router link depend on
   the link's Type. For example, each link has an associated 32-bit Link
   Data field. For links to stub networks this field specifies the
   network's IP address mask. For other link types the Link Data field
   specifies the router interface's IP address.

      Type
          A quick description of the router link for one of the
          following. Note that host routes are classified as links to
          stub networks with network mask of 0xffffffff. Secondary
          router links are always type 1 point-to-point even when they
          have secondary NBMA network type.


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




Murphy                                                         [Page 14]


Internet Draft          OSPF Multiple Area Links           February 2002


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

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

      Link Data
          Value again depends on the link's Type field. For connections
          to stub networks, Link Data specifies the network's IP address
          mask. For unnumbered point-to-point connections, it specifies
          the interface's MIB-II [MIB] ifIndex value. For the other link
          types it specifies the router interface's IP address. This
          latter piece of information is needed during the routing table
          build process, when calculating the IP address of the next
          hop. Recall a secondary router link (Type 1) shares the IP
          address of its corresponding primary interface, if it exists.
          Otherwise it is an unnumbered point-to-point connection. See
          Section 6.0 of this document and [OSPF] Section 16.1.1 for
          more details.

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

      metric
          The cost of using this router link. For secondary links the
          cost is specified in the secondary interface data structure.


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





Murphy                                                         [Page 15]


Internet Draft          OSPF Multiple Area Links           February 2002


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

      TOS metric
          TOS-specific metric information.













































Murphy                                                         [Page 16]


Internet Draft          OSPF Multiple Area Links           February 2002


Appendix B. Mlink Type 9 Neighbor Discovery LSAs

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

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

       0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |    Options    |       9       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Opaque Type   |               Opaque ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Advertising Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      LS Sequence Number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Secondary Area ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          IP Address                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Sec Rtr Pri  |                       0                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

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



Murphy                                                         [Page 17]


Internet Draft          OSPF Multiple Area Links           February 2002


      IP Address
         The IP Address of the secondary area's corresponding primary
         interface. If the primary interface has unnumbered point-to-
         point type, then IP Address should be set to 0.

      Sec Rtr Pri
         This router's Designated Router priority for a secondary link
         across a transit network. This parameter is used during the
         secondary links (Backup) Designated Router election.  If set to
         0, the router will be ineligible to become the (Backup)
         Designated Router for this secondary link.








































Murphy                                                         [Page 18]


Internet Draft          OSPF Multiple Area Links           February 2002


Appendix C. Interface Data Structure

   Chapter 9 in the OSPF specification documents the interface data
   structure and the data items which are included in it. Section 3.1 of
   this document defines a new interface configuration parameter called
   SecondaryAreas which supports OSPF Multiple Area Links. The
   SecondaryAreas interface parameter lists a set of areas which may
   form secondary adjacencies across the interface. The SecondaryAreas
   parameter's default setting is null. If a virtual link is configured
   across a transit area linked to an interface, then Area 0 may not be
   configured in the interface's SecondaryAreas parameter.

   Each area listed in the SecondaryAreas interface parameter should
   have a secondary interface data structure. With the exception of Area
   ID all of secondary interface parameters which are usually
   configurable, such as interface cost, authentication parameters and
   Designated Router priority, default to the values assigned to the
   primary interface. Furthermore, except for the Area ID, IP interface
   address and mask, all configurable interface parameters should be
   separately configurable for each secondary interface.  The
   SecondaryAreas parameter in a secondary interface data structure is
   always null.





























Murphy                                                         [Page 19]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/