[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

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


                        OSPF Multiple Area Links

Status of this Memo


   This document is an Internet-Draft. 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".

   To learn the current status of any Internet-Draft, please check the
   "1id- abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

























Murphy                                                          [Page i]


Internet Draft          OSPF Multiple Area Links               July 1998


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
   3.0 Implementation Details ...................................  6
   3.1 SecondaryAreas Interface parameter .......................  6
   3.2 Advertising Secondary Areas ..............................  6
   3.3 Forming Secondary Adjacencies ............................  7
   3.4 Advertising Secondary Adjacencies ........................  7
   3.5 Secondary Area Link State Data Base Exchange and Update ..  8
   3.6 The Shortest Path First Calculation ......................  9
   3.7 Flushing Secondary Adjacencies ...........................  9
   4.0 Acknowledgments .......................................... 10
   5.0 References ............................................... 10
   6.0 Security Considerations .................................. 10
   7.0 Authors' Addresses ....................................... 10
   Appendix A: Router LSAs ...................................... 11
   Appendix B: mlink Opaque LSAs ................................ 13
   Appendix C: Configuration Parameters ......................... 14

1.0  Abstract

   This memo describes an option to the OSPF Version 2 specification
   which allows multiple areas to share the same link. This option adds
   no additional link state flooding over shared links other than the
   normal link state database exchange and update originating from the
   link's configured primary area. The option applies to standard areas,
   stub areas, and NSSAreas. It eliminates the excess Area 0 link state
   baggage that accompanies the use of virtual links as currently
   practiced when configuring similar transits for standard OSPF areas.
   Routers with this option configured are backward compatible with
   routers running the standard OSPF Version 2 compliant implementation
   as defined in RFC 2328, and can be restricted to a subset of the OSPF
   routing domain. This option is applied only on OSPF border routers.

   Implementation of OSPF multiple area links requires a modification to
   the OSPF interface data structure which allows each interface of a
   border router to be connected to multiple areas. One area is always
   configured as the interface's primary area. Any additional areas
   which are configured for an interface are called the interface's
   secondary areas. Two adjacent border routers with mutually shared
   secondary areas may transit a secondary area's intra-area traffic
   over the adjacency. A typical application is a stub area or NSSArea
   which is dual homed to the Area 0 backbone and loosely joined by an
   internal slow speed link. If there exists a high speed Area 0 link
   between two of the stub area's border routers, this option allows the



Murphy                                                          [Page 1]


Internet Draft          OSPF Multiple Area Links               July 1998


   stub area's intra-area traffic to route across this high speed area 0
   link. The current specification forces traffic to prefer the intra-
   area path over the slow speed link.

   Another not so common application makes Area 0 the secondary area
   over a local high speed LAN link with the primary area a local stub
   or NSSArea.  Here Area 0 is not primary due to topological
   limitations which restrict its applicability. E.g. the local LAN link
   could be a campus backbone with dozens of routers on it, all part of
   the same NSSArea.

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







































Murphy                                                          [Page 2]


Internet Draft          OSPF Multiple Area Links               July 1998


2.0  Overview

2.1  Requirement for OSPF Multiple Area Links

   Large corporate networks in todays modern Internet invest tremendous
   human and equipment resources, coupled with sizable budget, into
   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 high speed and high reliability
   network links. Performance over a T1 link can pale by comparison to
   performance over a DS3 or OC3 backbone link.  Indeed, even a high
   speed 100 megabit LAN link can carry an order of magnitude more
   traffic than a standard 10 megabit link. Large corporate networks
   have sizable backbone routing tables and routinely use stub areas and
   NSSAreas. 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                 |
           |                                    |
           |NSSArea 1 link        NSSArea 1 link|
           |    T1                        T1    |
           |                                    |
           |                                    |
           A1---------NSSArea 1 link-----------B1-------M1
                            T1

   where A0 and B0 are border routers attached to NSSArea 1. A1 and B1
   are internal routers in NSSArea 1. N1 and M1 are standard ethernet
   networks in NSSArea 1 directly attached to B0 and B1 respectively.
   Assume all T1 links have an OSPF cost of 28 in both directions, N1
   and M1 are attached with interface costs 2. The DS3 link has an OSPF
   cost of 1. All costs are symmetric. Under the current OSPF
   specification the preferred path between A0 and M1 is

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

   with OSPF cost 58, even though there exists a more preferred path
   through B0 namely

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

   with OSPF cost 31. Indeed the DS3 link between A0 and B0 has the
   potential of making the performance between A0 and B1 approach that
   of a single T1.



Murphy                                                          [Page 3]


Internet Draft          OSPF Multiple Area Links               July 1998


   Consider also the NSSArea 1 OSPF preferred path between A1 and N1,

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

   with cost 58. Again there exists a more preferred path through the
   link between A0 and B0, namely

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

   with cost 31. This link also has the potential of performing at
   single hop T1 speeds. Under the current OSPF specification NSSArea
   1's router A1 does not even see this path to N1 since it has no
   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 in NSSArea 1. Virtual links are not an option since
   virtual links don't work over NSSAreas. If the link between A0 and B0
   were part of NSSArea 1, path preference would be optimal as the DS3
   path would be intra-area for NSSArea 1. This cannot be the non-
   backbone equivalent of an Area 0 virtual link. Excessive use of such
   a feature would negate the purpose of the Area 0 backbone.

2.2  Proposed Solution

   OSPF multiple area links provide the capability of allowing multiple
   areas to use the same link/path 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/path as part of its link state topology. Only areas which are
   dual homed to Area 0 may take advantage of this option, since any
   router with multiple directly attached areas must be in Area 0 and it
   takes at least two such border routers to create a multiple area
   link.

   The current OSPF specification only allows one area per interface.
   Thus, should an Area L dual-home to two Area 0 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 link.

   The softening of this restriction is facilitated by the addition of a
   new parameter to the interface data structure called SecondaryAreas.
   The SecondaryAreas interface parameter is a self-defining structure
   containing a list of Area Ids for additional areas in which the



Murphy                                                          [Page 4]


Internet Draft          OSPF Multiple Area Links               July 1998


   interface also belongs, along with their associated OSPF costs. The
   areas listed in this parameter are called the interface's secondary
   areas, as opposed to the interface's configured Area ID, hereafter
   called the primary area. For each secondary area listed in the
   SecondaryAreas parameter there is a list of neighboring Router Ids
   which have formed adjacencies for the secondary area across the
   interface's directly attached network or router link. These
   adjacencies are called secondary adjacencies. Secondary adjacencies
   are formed during the primary area's link state data base exchange
   and update as defined in Sections 3.2 and 3.3.

   A type 9 Opaque LSA is used to exchange/update the interface's
   secondary areas with adjacent Opaque capable border routers. Until an
   opaque type is assigned for this option, it will be simply referred
   to as an mlink type 9 opaque LSA. A type 9 opaque LSA is used because
   the flooding scope of the mlink type 9 opaque LSA needs to be
   restricted to those routers directly attached to a common network or
   router link. Each router will list its configured secondary addresses
   as defined by the interface's SecondaryAreas parameter in its mlink
   type 9 opaque LSA. The mlink type 9 opaque LSA is propagated during
   the primary area's link state data base exchange and update with its
   fully adjacent neighbors. If a router A receives an mlink type 9
   opaque LSA from an adjacent router B during primary area K's link
   state data base exchange, then router A and B form a secondary
   adjacency in area L if and only if

        1) Area L is listed in the interface's SecondaryArea parameter.

        2) Area L is listed in router B's received mlink type 9 opaque
           LSA.

        3) Router A contains a type 1 (router) LSA from router B in Area
           L's link state data base.

   If routers A and B form a secondary adjacency then the router ID of
   router B is added to Area L's list of secondary adjacencies for the
   interface.

   Secondary adjacencies are either point-to-point or point-to-
   multipoint. Any intervening transit networks always belong to the
   interface's primary area.  There is no network LSA for a secondary
   adjacency's intervening transit network in the secondary area. Hence
   all secondary adjacencies for Area L must be advertised in router A's
   type 1 (router) LSA with unnumbered point-to-point type.

   During the Dykstra SPF calculation the LSAs for secondary adjacencies
   look like unnumbered point-to-point links, except on border routers
   where they originate. A Border router never includes in a secondary



Murphy                                                          [Page 5]


Internet Draft          OSPF Multiple Area Links               July 1998


   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 do use
   the IP addresses stored in neighboring border router LSAs for
   determining link paths across a multi-access secondary adjacency.

   There is no secondary link state data base exchange or update over
   secondary adjacencies. Instead, these adjacencies rely on the
   secondary area's base topology (minus the secondary links) for
   flooding link state information regarding an area's secondary
   adjacencies. The reasons for not attempting a secondary link state
   data base exchange/update are two fold. First, the goal of this
   document is to establish a transit for multiple areas over a single
   link without imposing the additional traffic load caused by passing
   the secondary area's link state database over that link. Second the
   added complexity of synchronizing multiple secondary area link state
   databases over the link is unnecessary when the primary area is the
   Area 0 backbone. Should the secondary area partition, traffic between
   the two parts of the partitioned secondary area would still use the
   secondary adjacent link via OSPF inter-area routing.

   It is true that routing between the different parts of a secondary
   area partitioned by a defunct secondary adjacency over an Area 0 link
   would be based on the inter-area route computation results from
   processing summary links. Summary-range aggregation may over simplify
   routing between the different parts of a partitioned area. However
   this is no different that what exists under the current OSPF base
   standards. Furthermore, the proper partitioning of a secondary area's
   assigned address space not only allows the summary-range aggregates
   to effect proper routing during topological failures, but it also
   promotes more cost effective and efficient routing even when
   secondary areas are whole.

   Consider now the example mentioned in Section 2.3 and assume Area 1
   is configured as a secondary area over the Area 0 link between A0 and
   B0. The NSSArea 1 intra-area shortest path first tree computed by the
   Dykstra calculation now includes the DS3 link between A0 and B0 with
   a cost of 1.  Given that all four routers possess link state
   advertisements for the link between A0 and B0 in NSSArea 1, the path
   between A0 and M1 is now

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

   and the path between A1 and N1 is

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

   Furthermore, should the link between A1 and B1 fail terminating the



Murphy                                                          [Page 6]


Internet Draft          OSPF Multiple Area Links               July 1998


   NSSArea 1's secondary adjacency between A0 and B0, the path between
   A0 and M1 would still be

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

   as the summary LSA for M1 originating from B0 forms an inter-area
   path to M1.

3.0  Implementation Details

3.1  SecondaryAreas Interface parameter

   A new parameter called SecondaryAreas is added to the OSPF interface
   data structure. Implementations must support the manual configuration
   of this parameter. The SecondaryAreas interface parameter lists the
   set of Areas which can form secondary adjacencies over the interface,
   complete with their secondary area interface costs. By default a
   secondary area's interface cost is set to the value of the
   interface's primary area cost. Only those Areas listed in the
   SecondaryAreas interface parameter are candidate areas for the
   interface's secondary adjacencies. If the SecondaryAreas interface
   parameter has a null list, then no secondary areas are configured for
   this interface and no secondary adjacencies can be formed over the
   interface.

   For each secondary area listed in the SecondaryAreas interface
   parameter, there is a list of Router Ids which have formed secondary
   adjacencies to the router over the interface. These Routers Ids
   should also be listed in the interface's list of neighboring routers.
   If the list of Router Ids is null, then the interface has no
   secondary adjacencies for this secondary area.  This list is
   populated as defined in Section 3.3 below.

3.2  Advertising Secondary Areas

   All routers which support secondary areas must also be opaque
   capable. If the interface is of broadcast type, then all candidate
   designated routers must be opaque capable, even if they have no
   secondary areas configured for the interface which connects to the
   broadcast transit network. Otherwise type 9 opaque LSAs, which are
   used by this option, will not propagate to all potential routers
   capable of forming secondary adjacencies over the broadcast transit
   network. Note that candidate designated routers do not have to
   support OSPF multiple area links, but they do have to be opaque
   capable in order to flood the type 9 opaque LSA to their adjacent
   neighbors who may or may not support OSPF multiple area links.

   Any router which has an interface with a non-empty SecondaryAreas



Murphy                                                          [Page 7]


Internet Draft          OSPF Multiple Area Links               July 1998


   interface parameter must advertise a type 9 opaque LSA with opaque
   type mlink to the interface's fully adjacent neighbors. The mlink
   type 9 opaque LSA contains the Area Ids listed in the interface's
   SecondaryAreas parameter as Opaque Information. See Appendix B for
   details. If an interface's SecondaryAreas parameter is null, then the
   mlink type 9 opaque LSA should not be advertised.

   By default, the mlink opaque type sets it opaque ID to the last 24
   bits of the interface's IP address, if it has one. In the case of
   unnumbered point-to-point connections, the mlink opaque ID is set to
   the last 24 bits of the interface's MIB-II [MIB] ifIndex value. All
   implementations should also support the manual configuration of an
   interface's mlink opaque ID in the rare instance this default schema
   results in duplication.

3.3  Forming Secondary Adjacencies

   Two border routers A and B in area L may form a secondary adjacency
   across an interface, whose primary area is K, under the following
   conditions:

      (a) Routers A and B are fully adjacent across the interface's
          primary area K or they share a common area K full adjacency
          with the interface's designated router.

      (b) Routers A and B see router LSAs (type-1) for each other in
          Area L's link state data base.

      (c) Routers A and B have exchanged/updated mlink type 9 opaque
          LSAs across the interface both of which contain Area L as a
          candidate secondary area.

   When all three conditions are met, a secondary adjacency is formed
   between routers A and B across the interface's primary area. There is
   no particular ordering of events. Either (a), (b), or (c) can trigger
   the event which forms the secondary adjacency, provided the other two
   conditions have already been met.

3.4  Advertising Secondary Adjacencies

   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 transit
   network links in their associated interface's primary area. This
   allows their interconnecting networks to retain a single area
   identity, thus avoiding the inevitable problems which would occur
   with duplicate summary links advertisements and aggregation. It also
   makes configuration and deployment seamless.



Murphy                                                          [Page 8]


Internet Draft          OSPF Multiple Area Links               July 1998


   As unnumbered point-to-point links, all secondary adjacencies have
   link type 1. The building of the router LSA is described in [OSPF]
   Section 12.4.1. For the purpose of building the router LSA, an
   interface belongs to both its primary area and its secondary areas.
   With this in mind, no change is required to [OSPF] Section 12.4.1.

   Even though secondary adjacencies are considered unnumbered point-
   to-point links, for the purpose of defining Link Data in the type 1
   (router) LSA (see Appendix A) we allow them to use the 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 link (point-to-point). The Link ID should be set to the
      Router ID of the neighboring router. If the interface is numbered,
      the Link Data should specify the IP interface 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 of the point-to-point
      interface as defined in the interface's SecondaryAreas parameter.

   By not adding the type 3 links noted in [OSPF] Section 12.4.1.
   secondary adjacencies retain the look and feel of an unnumbered
   point-to-point links to the remaining routers in the secondary area,
   even though they may configure their link data with the interface's
   IP address.

3.5  Secondary Area Link State Data Base Exchange and Update

   There is no link state data base exchange or update across a
   secondary adjacency. Only the interface's primary area synchronizes
   its link state data base with the interface's neighboring routers.
   Instead, secondary areas rely on their base topology (i.e. the
   topology without the secondary links), for complete flooding and
   synchronization of the link state data base throughout the secondary
   area. If the primary area is the area 0 backbone this is not a
   problem, since the routing table entries generated by the secondary
   areas summary links will forward packets when a secondary area's base
   topology partitions in such a way that its secondary adjacencies are
   dropped.

   If the primary area is non-zero, then a simple IP over IP tunnel may
   be configured for the secondary across the physical link. This tunnel
   will perform link state data base synchronization for the secondary
   area across the interface. The IP tunnel is not part of this
   specification, but clearly it is advantageous to any OSPF multiple
   area links implementation if tunneling of IP over IP is supported.
   Note that if the tunnel is suitably configured with a high OSPF cost,



Murphy                                                          [Page 9]


Internet Draft          OSPF Multiple Area Links               July 1998


   it would never be used for forwarding packets other than those
   required for link state data base exchange and update. Moreover the
   tunnel will always exist as long as the secondary adjacency's
   physical link is active.

3.6  The Shortest Path First Calculation

   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' type-1 (router)
   LSAs for determining the destination next hop across a secondary
   adjacency when the associated interface connects the destination
   router via a point-to-multipoint link or transit network link.  In
   this case the outgoing interface is derived directly from the
   destination router's next hop IP address.

3.7  Flushing Secondary Adjacencies

   The dropping and flushing of secondary adjacencies from the link
   state database of a secondary area is triggered by any of the
   following events:

      The secondary area is manually purged from the interface's
      SecondaryAreas parameter.

      An adjacent router looses its primary area adjacency. Note that
      over a multi-access network termination happens when a neighboring
      router ceases to be listed in the Designated Router's list of
      neighbors.

      The secondary area is no longer listed in the adjacent router's
      mlink type 9 opaque LSA.

      The adjacent router's mlink type 9 opaque LSA is flushed from the
      primary area or exceeds MAXAge.

      The adjacent router's type 1 (router) LSA is flushed from the
      secondary area or exceeds MAXAge. In other words, the secondary
      area has partitioned with the two formerly adjacent routers now in
      separate parts.

   When any of these events occur the interface's SecondaryAreas
   parameter is updated to purge the adjacency. A new router LSA is



Murphy                                                         [Page 10]


Internet Draft          OSPF Multiple Area Links               July 1998


   built for the secondary area and flooded out those interfaces for
   which the secondary area is primary. The SPF calculation is done to
   reflect the new link state topology.

4.0 Acknowledgments

   This document was produced by the OSPF Working Group, chaired by John
   Moy.

   In addition, the comments of the following individuals are also
   acknowledged:

      Derek Yeung                     Cisco Systems
      Rob Colton                      Fore Systems

5.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.

   [1583]  Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March
           1994.

6.0 Security Considerations

   Security issues are not discussed in this memo.

7.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.doi.net







Murphy                                                         [Page 11]


Internet Draft          OSPF Multiple Area Links               July 1998


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, including secondary
   links, to an area must be described in a single router-LSA. For details
   concerning the construction of router-LSAs, see this document's Section 3.6
   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 Transit
          area (V is for virtual link endpoint).




Murphy                                                         [Page 12]


Internet Draft          OSPF Multiple Area Links               July 1998


      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 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.

   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


      Link ID
          Identifies the object that this router link connects to. Value



Murphy                                                         [Page 13]


Internet Draft          OSPF Multiple Area Links               July 1998


          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 area are always type 1 point-to-
          point regardless of the type of their associated primary area.
          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 3.6 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 may use
          TOS.

      metric
          The cost of using this router link.


   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 TOS-specific link information may be encoded as follows:

      TOS
          IP Type of Service that this metric refers to. The encoding of



Murphy                                                         [Page 14]


Internet Draft          OSPF Multiple Area Links               July 1998


          TOS in OSPF LSAs is described in [1583] Section 12.3.

      TOS metric
          TOS-specific metric information.















































Murphy                                                         [Page 15]


Internet Draft          OSPF Multiple Area Links               July 1998


Appendix B. mlink Opaque LSA

   The mlink Opaque LSA is used directly by OSPF to distribute list of
   candidate secondary areas among neighboring routers. The flooding
   scope of the mlink type 9 Opaque LSA is link-local, which means mlink
   LSAs are never forwarded beyond the local (sub)network.

   Section 3.3 of this document describes the purpose of the mlink
   Opaque LSA 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   |   Link State  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Opaque Type   |               Opaque ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Advertising Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      LS Sequence Number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Secondary Area ID 1                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             .                                 |
       |                             .                                 |
       |                             .                                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Secondary Area ID n                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Syntax Of The Opaque LSA's Link-State ID

      The link-state ID of the mlink Opaque 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 Opaque ID is set
      to the last 24 bits of the interface's primary area IP address, if
      it has one. In the case of unnumbered point-to-point connections,
      the mlink opaque ID is set to the last 24 bits of the interface's
      MIB-II [MIB] ifIndex value. All implementations should also
      support the manual configuration of an interface's mlink opaque ID
      in the rare instance this default schema results in duplication.








Murphy                                                         [Page 16]


Internet Draft          OSPF Multiple Area Links               July 1998


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 configuration parameter called
   SecondaryAreas which is to be included in support of OSPF multiple
   area links. Sections 3.2 and 3.4 describe the application of the
   parameter.

   In addition, for each secondary area listed in an interface's
   SecondaryAreas parameter, the interface data structure must maintain
   a list of Router IDs which have formed secondary adjacencies for this
   secondary area.






































Murphy                                                         [Page 17]