Expiration Date: May 1998
File name: draft-ietf-ospf-ara-01.txt draft-ietf-ospf-ara-02.txt

               The OSPF Address Resolution Advertisement Option

                                Rob Coltun
                               FORE Systems
                              (301) 571-2521
                              (703) 245-4543
                             rcoltun@fore.com

                               Juha Heinanen
                              Telecom Finland
                            Telia Finland, Inc.
                             +358 400 500 958
                                jh@tele.fi 303 944 808
                                jh@telia.fi

     Status Of This Memo

     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments of the Internet Engineering Task Force (IETF), its areas, and
     its working groups.  Note that other groups may also distribute work-
     ing 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 ds.internic.net (US East Coast), nic.nordu.net
     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

Coltun, Heinanen                                                   [Page 1]

     Table Of Contents

          1.0 Abstract ................................................. 4

          2.0 Overview ................................................. 4

          2.1 Acknowledgments .......................................... 5

          3.0 Examples ................................................. 6

          3.1 Example 1: Intra-Area .................................... 6

          3.2 Example 2: Inter-Area .................................... 7

          3.3 Example 3: Multiple Logical Networks ..................... 8

          4.0 A Brief Comparison Of Address Resolution Models .......... 9

          5.0 ARA Components ........................................... 11

          5.1 Address Resolution Advertisements ........................ 5

          2.2 11

          5.2 ARA Association Table .................................... 5

          2.3 11

          5.3 Logical Network ID List .................................. 5

          2.4 12

          5.4 Routing Table Extensions ................................. 5

          2.5 12

          5.5 Restricting Shortcut Connectivity ........................ 6

          2.6 Acknowledgments .......................................... 6

          3.0 A Brief Comparison Of Address Resolution Models .......... 7

          4.0 12

          6.0 ARA Associations ......................................... 8

          5.0 Examples ................................................. 9

          5.1 Example 1: Intra-Area .................................... 9

          5.2 Example 2: Inter-Area .................................... 10

          5.3 Example 3: Multiple Logical Networks ..................... 11

          6.0 13

          7.0 Description Of ARA Packet Formats ........................ 12

          6.1 14

          7.1 Vertex Types And Vertex Identifiers ...................... 13

          7.0 14

          8.0 Distribution Of ARA Information .......................... 14

          7.1 15

          8.1 Originating Inter-Area ARAs .............................. 15

          8.0 17

          9.0 ARA Routing Table Extensions ............................. 17

          8.1 19

          9.1 Adding ARA Routing Table Extensions ...................... 18

          8.1.1 20

          9.1.1 Modifications To The Intra-Area Route Calculation ...... 18

          8.1.2 20

          9.1.2 Modifications To The Inter-Area Route Calculation ...... 19

          8.1.3 21
          9.1.3 Modifications To The AS External Route Calculation ..... 20

Coltun, Heinanen                                                   [Page 2]
          9.0 22

          9.2 Routing Table Extension Completion ....................... 23

          10.0 Receiving ARAs ........................................... 21

          10.0 .......................................... 24

          11.0 Additional Data Structures And APIs ..................... 21 24

          12.0 Security Considerations ................................. 24

          Appendix A: ARA Packet Formats ............................... 23 27

          A.1 The ARA Header ........................................... 23 27

          A.2 Intra-Area Router ARA .................................... 26 30

          A.3 Intra-Area Network ARA ................................... 27 31

          A.4 Inter-Area Router ARA .................................... 28 32

          A.5 Inter-Area Network ARA ................................... 30 34

          A.6 Vertex Association ....................................... 31 35

          A.7 Resolution Information ................................... 32 37

          A.7.1 ATM Address ............................................ 34 38

          A.7.2 ATM LIJ Call Identification ............................ 35 39

          References ................................................... 35

Coltun, Heinanen                                                   [Page 3] 40

1.0  Abstract

     This document defines an OSPF option optional extension to enable OSPF which enables
     routers to distribute IP to link-layer address resolution information. information
     An OSPF Address Resolution Advertisement (ARA) may include media-specific media-
     specific information such as a multipoint-to-point connection identifier
     along with the address resolution information to support media-specific
     functions.  The ARA option can be used to support router-to-router
     inter-subnet shortcut architectures such as those described in [HEIN].

2.0  Overview

     Along with the evolution of switched layer 2 technologies comes the
     ability to provide inter-subnet shortcut data switching (bypassing
     router
     layer-3 forwarding intervention).  Before the ingress devices is able
     to dynami-
     cally dynamically set up the switched path it must have the link-layer
     address of the egress device.  Acquisition of the egress device's
     link-layer address may be through configuration or through a dynamic
     mechanism which resolves an IP address (or an IP end-point identifier)
     to a link-layer address.

     This document introduces a method for IP to link-layer address resolu-
     tion to support addresses reso-
     lution which supports router-to-router and router-to-network inter-subnet inter-
     subnet shortcuts.  The ARA  Fundamentally, the option supports both topology-derived and data-
     driven shortcuts architectures with simple extensions provides a mechanism for
     routers to OSPF.  Dis-
     tribution of distribute their IP to link-layer address resolution information is performed using stan-
     dard OSPF flooding mechanisms.  This document does not define an
     architecture but is meant infor-
     mation (referred to be used with architectures such as those
     defined in [HEIN].  The ARA option is designed this document as link-layer associations), and
     for routers to support determine the follow-
     ing operations.

          Shortcuts between core or access routers within ISP Backbones.

          Shortcuts link-layer association which are closest
     to their target networks (within an OSPF domain).  Address Resolution
     Advertisements (ARAs) are used to distribute the link-layer associa-
     tions of routers (Router ARAs) and their directly connected networks
     (Network ARAs) within and between OSPF areas.  Distribution of ARAs is
     performed using standard OSPF flooding mechanisms.  ARA information is
     encapsulated in Opaque LSAs [OPAQ] and flooded using the mechanisms
     defined in [OPAQ].

     The ARA option supports both topology-derived and data-driven shortcut
     architectures with this simple extensions to OSPF.  This document does
     not define an architecture but is meant to be used with architectures
     such as those defined in [HEIN].  The ARA option is designed to sup-
     port the following types of operations.

          Shortcuts between core or access routers within ISP Backbones.

          Shortcuts in enterprise networks between routers in the same OSPF
          autonomous system, between OSPF internal routers and autonomous
          system border routers (ASBR) or between routers and servers.

          Distributed router architectures.

          Interoperation with ION NHRP and ATMF MPOA.

          Inter-subnet multicast shortcuts using LIJ or Point-to-MultiPoint
          procedures.

Coltun, Heinanen                                                   [Page 4]

2.1 Address Resolution Advertisements Acknowledgments

     The ARA option defines a set of link-state advertisements called
     address resolution advertisements (ARAs).  ARAs are used authors would like to distribute
     link-layer information of routers and their directly connected net-
     works within thank Atul Bansal, Lou Berger, Yiqun Cai,
     John Moy, Stephen Shew, George Swallow and between the rest of the OSPF areas.  ARA information is encapsulated
     in Opaque LSAs (see [OPAQ]
     Working Group for a further description of Opaque LSAs).
     Three LS Types (LS Type 9, 10 the ideas and 11) constitute support they have given to this project.

3.0 Examples

     In this section three example ARA topologies are presented for the Opaque class of
     link-state advertisements.  Each
     purpose of explaining the three Opaque link-state types
     have ARA model and capabilities. These examples
     include a scope associated single-area topology with them so that distribution intra-area shortcuts, a multiple-
     area topology with inter-area shortcuts and an example of shortcuts
     using the informa-
     tion may be limited appropriately by ARA multiple logical network capability.

3.1 Example 1: Intra-Area

     Consider the originator of sample single-area topology in Figure 1 below.  In this
     example RT1, RT2 and RT5 support the LSA.
     Because ARA option (by definition they
     also support the flooding scope for ARAs is always area local, ARAs are
     encapsulated in LS Type 10 LSAs. Opaque LSAs have a sub-type which
     identifies LSA option) and RT4 supports the specific information that Opaque LSA
     option only (this is carried within necessary so that RT4 redistributes the LSA.
     ARA uses Opaque-types 1, 2, 3 ARAs ori-
     ginated by RT1, RT2 and 4.  See section 6.0 for RT5).  RT2 and RT5 have each originated a further
     description of the ARA packet formats.

2.2
     Router ARA Association Table

     A (R-ARA) with an intra-area router implementing the ARA option maintains association and RT5 has
     originated a table of link-layer
     associations Network ARA (N-ARA) with an intra-area network associa-
     tion for each N5.

     As a result of its OSPF areas.  The ARA Association Table is
     used in calculating running the ARA routing table extensions and by area
     border routers calculation, RT1 has entries
     for N1-N8 in the inter-area ARA origination process. its routing table.  The indexes
     for an entry for N2 references the
     link-layer associations distributed in this table entry are RT2's R-ARA, the Vertex Type, Vertex ID and entries for
     N3, N4, N6, N7, N8 references the Vertex Originator.  The Vertex Type identifies link-layer associations distributed
     in RT5's R-ARA and the type of IP
     topology element that entry for N5 references the link-layer information is being associated
     with (i.e., a router or a network).  The Vertex ID identifies a piece
     of the OSPF topology (i.e., a router ID or an IP network number).  The
     Vertex Originator is the associa-
     tions distributed in RT5's intra-area N-ARA.

                +   ARA originator's Router ID.

2.3 Logical Network ID List

     An
                |  +---+                   N3       N5 (ARA)
              N1|--|RT1|\                    \ N4  /
                |  +---+ \                    \ | /
                +         \                    \|/
                           \+---+            +---+
                            |RT4|------------|RT5| ARA capable router maintains a configured list of logical networks
     IDs.  This list represents
                            +---+            +---+
                 +   ARA   /                   |     N7
                 |  +---+ /                    |    /
               N2|--|RT2|/                     |   /
                 |  +---+    +---+           +---+/
                 +           |RT3|-----------|RT6|----N8
                             +---+           +---+
                               |
                               |
                          +---------+
                              N6

                      Figure 1: Sample Single-Area Topology

3.2 Example 2: Inter-Area

     Consider the logical networks that a router is con-
     nected to sample 2-area topology in Figure 2 below.  In this exam-
     ple RT1, RT2, RT3, RT4, RT6 and may be used to restrict RT7 support the set of devices that ARA option, and RT5
     supports the
     router may setup shortcuts Opaque option.  N4 is an AS external route (which is
     flooded to (see section 2.5 "Restricting Shortcut
     Connectivity").  The absence all areas) and RT6 is an ASBR.  RT4 is an area-border
     router and originates an LS Type-4 LSA on behalf of entries in RT6 and a LS
     Type-3 LSA for N5 into area 1.1.1.1.

     Within area 1.1.1.1, RT1, RT2, RT3 and RT4 originate intra-area R-
     ARAs.  Within the router's list backbone RT6 and RT7 originate intra-area R-ARAs and
     R7 originates a N-ARA for N5. All backbone ARAs of Logi-
     cal Network IDs means have their the P-
     bit set (this bit informs ABRs that the router will only activate ARA Associa-
     tion Table entries with the default Logical Network ID (Logical Net-
     work ID 0).

2.4 Routing Table Extensions

     Associations are added to the routing table during may be propagated between
     areas).  RT4 originates an inter-area R-ARA for RT6 (which is an ASBR)
     as well as an inter-area N-ARA for N5 into area 1.1.1.1 RT4 does not
     originate an inter-area R-ARA for RT7 because it is not an ASBR.

     As a result of running the OSPF routing table calculation (see section 8.1 entitled "Adding ARA Routing Table

Coltun, Heinanen                                                   [Page 5]
     Extensions").  That is, calculation, RT1 has entries
     for N1-N5 in addition to its routing table.  The entry for N2 references the standard information fields
     contained
     link-layer associations distributed in RT3's R-ARA, the routing table (IP network number, IP mask, next-hop
     interface, etc.), entry for N3
     references the routing table is extended to contain link-layer
     associations.  However, only 'active' link-layer associations are
     added to distributed in RT4's intra-area
     R-ARA, the routing table.  Associations containing a logical network
     ID that matches a currently enabled entry in for N4 references the router's list of log-
     ical network IDs are considered to be active.  Both active and non-
     active link-layer associations may be included distri-
     buted in RT4's inter-area ARAs that
     are originated by an ABR.

     The routing table (and its ARA routing table extensions) must be
     recalculated if 1) there is a change to R-ARA (indirectly referencing RT6's R-ARA)
     and the OSPF topology, 2) there is
     a change to entry for N5 references the components link-layer associations
     distributed in the RT4's inter-area N5 N-ARA.

             +   ARA Association Table (see section
     9.0 "Receiving ARAs"), or 3) the router's logical network connectivity
     has changed (e.g., the logical network ID list is modified or the
     status of      ARA       |
             |  +---+    +---+      |
           N1|--|RT1|----|RT2|\     |        N3          N4<ASE
             |  +---+    +---+ \    |     +-----+        /
             +                  \  ARA       |      ARA /
                                 \+---+    +---+   +---+
                                  |RT4|----|RT5|---|RT6|<ASBR
                                  +---+    +---+   +---+
                       +   ARA   /  |                |
                       |  +---+ /   |               ARA    +
                     N2|--|RT3|/    |              +---+   |
                       |  +---+     |              |RT7|---|N5(ARA)
                       +            |              +---+   |
            ------------------------|--------------------  +
		Area 1.1.1.1	    |    OSPF Backbone

                      Figure 2: Sample Area Topology

3.3 Example 3: Multiple Logical Networks

     The ARA option supports the router's connections to one existence of its logical disjoint switched networks has
     changed).

     The use of
     within an OSPF domain. To accomplish this, an ARA may include an iden-
     tifier (the logical network ID) for a specific switched network. When
     associations are added to the routing table extensions are application specific and
     beyond during the scope of this document.  See [HEIN] for an example of an OSPF routing
     table calculation (see the Section 9.1 "Adding ARA user application.

2.5 Restricting Shortcut Connectivity

     As Routing Table
     Extensions") only the associations that include a result logical network ID
     that matches one of setting up shortcuts in an OSPF topology between ARA-
     capable routers, the shortcut connectivity may become fully meshed.
     In many environments this may be desirable whereas in in others this
     may be undesirable.  The ARA option allows for several methods router's configured logical network IDs are
     added to the routing table.  This function may also be used which can limit shortcut connectivity.

          o [HEIN] proposes to support
     a variation of closed user groups so that shortcuts are setup by ingress limited to
     those routers
          only after the sending data rate has passed a that are configured thres-
          hold.

          o ARA-capable routers may choose not to advertise their resolu-
          tion information until some event has occured.

          o Routers may be associated with "closed user shortcut groups" so
          that only routers that are within in the same shortcut group may
          set-up shortcuts to each other. This is done by coordinating the
          configuration of a router's logical network ID list with the log-
          ical network ID advertised in ARA associations.

2.6 Acknowledgments network.

     The author would like to thank Atul Bansal, Lou Berger, Yiqun Cai,

Coltun, Heinanen                                                   [Page 6]
     John Moy single-area topology described in Figure 3 below divides an OSPF
     area into logical networks X and Y.  In this example RT1, RT2 and RT4
     support the rest of the OSPF Working Group for ARA option and RT3 supports the ideas Opaque LSA option only.
     RT1 is connected to logical network (LN) X, RT2 is connected LN Y and sup-
     port they have given
     RT4 is connected to this project.

3.0 A Brief Comparison Of Address Resolution Models

     Current models both LN X and LN Y.  RT1, RT2 and RT4 all ori-
     ginate R-ARAs.

     As a result of inter-subnet address resolution running their routing table calculation, RT1 and RT2
     have taken the form
     of a query/response protocol as entries for N1-N5 in the case of [NHRP]. their routing table.  In this model both routing
     tables, the ingress device originates a resolution request which is forwarded
     hop-by-hop through a series of NHRP servers towards N3-N5 entries reference the destination IP
     address contained link-layer associations dis-
     tributed in the request.  The the last-hop server (the one
     that is closest to the destination) responds to the request with the RT4's R-ARA.  However, RT1's routing table does not refer-
     ence RT2's link-layer associations for N2 and RT2's routing table does
     not reference RT1's link-layer associations for N1 (i.e., they would
     not be able to set up shortcuts to each other and would be forced to
     use a hop-by-hop path to communicate).

                +   ARA (LN=X)
                |  +---+                   N3       N5
              N1|--|RT1|\                    \ N4  /
                |  +---+ \                    \ | /
                +         \                    \|/
                           \+---+            +---+
                            |RT3|------------|RT4| ARA (LN=X,Y)
                            +---+            +---+
                            /
                 +   ARA (LN=Y)
                 |  +---+ /
               N2|--|RT2|/
                 |  +---+
                 +

              Figure 3: Sample Topology With Logical Networks

4.0 A Brief Comparison Of Address Resolution Models

     Current models of inter-subnet address resolution have taken the form
     of a query/response protocol as in the case of [NHRP].  In this model
     the ingress device originates a resolution request which is forwarded
     hop-by-hop through a series of NHRP servers towards the destination IP
     address contained in the request.  The the last-hop server (the one
     that is closest to the destination) responds to the request with the
     link-layer address that it associates with the requested IP address.
     The address that is returned may be the address of the requested host
     system or the address of a router which is on the path to the destina-
     tion.  Upon receiving a response to its request, the ingress device
     sets up a shortcut path to be used for data transfer.  The resolution
     request mechanism has the following characteristics.

          o Routers and hosts may participate in the request mechanism.
          The participating devices are discovered through polling.

          o The request mechanism requires polling by the ingress device to
          detect topology and reachability changes. Changes in the topology
          could result in packet loss for the polling interval.  Stable
          routing loops may form as a result of topology changes (given a
          limited set of failure conditions and topologies).

          o Requests are unreliable and are subject to packet loss.

          o It is recommended that the request mechanism be limited to
          intra-area shortcuts (although with correctly designed topologies
          this limitation may be over restrictive).

          o The target of a request may be a host or network addresses
          (excluding class D (multicast) networks).

          o The response to the request allows the requesting entity to set
          up a point-to-point shortcut.

     Given the above characteristics, the query-response protocol may not
     be the optimal mechanism for particular applications such as the one
     described in [HEIN]. The ARA option has the following characteristics.

          o Only routers participate in the ARA option.  A router's

Coltun, Heinanen                                                   [Page 7]
          participation parti-
          cipation in the ARA option is discovered through its address
          resolution advertisements.

          o The ARA option does not require polling by the ingress device
          to detect topology and reachability changes. Changes in the
          topology and system reachability may result in packet loss (or
          transient loops) for the OSPF convergence time.  Additionally,
          since topology changes are determined as a result of OSPF's SPF
          calculation (which results in loop-free paths), shortcuts derived
          from the ARA option can never result in stable routing loops.

          o Address resolution distribution is reliable and is not subject
          to packet loss.

          o The target of ARA derived shortcuts may be routers and and
          their connected networks within the OSPF autonomous system.
          Shortcuts are also supported when the destination is associated
          with an OSPF AS boundary router advertisement (e.g., networks
          external to the OSPF autonomous system).

          o The ARA option allows the requesting entity to set up point-
          to-point shortcuts as well as shortcuts that join point-to-
          multipoint and multipoint-to-point trees.

          o Routers that run the ARA option can interoperate with systems
          running NHRP.

          o The ARA option may easily be extended to support inter-subnet
          multicast shortcuts.

4.0

5.0 ARA Associations Components

     The ARA option defines four types is comprised of advertisements.  These include 1)
     intra-area router associations, 2) intra-area network associations, 3)
     inter-area network associations several components including Address
     Resolution Advertisements, the ARA association table, a logical net-
     work ID List, routing table extensions and 3) inter-area autonomous system
     boundary router (ASBR) associations.  Associations correspond to methods for restricting
     shortcut connectivity. The following sections gives an overview of
     these components.

5.1 Address Resolution Advertisements

     The ARA option defines a
     piece set of the OSPF topology.  Intra-area router associations correspond link-state advertisements called
     address resolution advertisements (ARAs).  ARAs are used to distribute
     the link-layer reachability associations of a router within the local area, intra-
     area network associations correspond to the link-layer reachability of
     a router's routers and their directly connected network (also
     networks.  ARAs are distributed within the local area),
     inter-area network associations correspond to the link-layer reacha-
     bility of a remote single area router's directly connected network, and
     inter-area ASBR associations correspond to ASBRs that are in remote may be dis-
     tributed between OSPF areas.  Note  ARA information is encapsulated in
     Opaque LSAs (see [OPAQ] for a further description of Opaque LSAs).
     Three LS Types (LS Type 9, 10 and 11) constitute the Opaque class of
     link-state advertisements.  Each of the three Opaque link-state types
     have a scope associated with them so that an inter-area network association distribution of the informa-
     tion may be ori-
     ginated limited appropriately by an area border router (ABR) only if the network is not a
     component originator of a configured net range.  An ingress router can use these
     associations as follows.

Coltun, Heinanen                                                   [Page 8]
          Intra-area router associations are used to setup shortcuts to
          routers within the local area.  Data sent over the shortcut will
          be forwarded to destinations local to and beyond LSA.
     Because the router
          including ones that flooding scope for ARAs is always area local, ARAs are
     encapsulated in the local area, in LS Type 10 LSAs.  Opaque LSAs have a remote area or
          external to sub-type which
     identifies the autonomous system.  Destinations specific information that are "beyond
          the router" are determined by the OSPF topology map.

          Intra-area network associations (which may advertise hosts or
          networks) are used to setup intra-area shortcuts to systems whose
          addresses fall is carried within the range of the advertised network.

          Inter-area network associations (which may advertise LSA.
     ARA uses Opaque-types 1, 2, 3 and 4.  See Section 7.0 for a host or
          network address) are used to setup inter-area shortcuts to sys-
          tems whose address fall within the range further
     description of the advertised net-
          work.

          Inter-area ASBR ARA packet formats.

5.2 ARA Association Table

     A router implementing the ARA option maintains a table of link-layer
     associations are for each of its OSPF areas.  The ARA Association Table is
     used to setup shortcuts to ASBRs
          that are in a remote area.  These shortcuts are used to send data
          to destinations that are external to calculating the autonomous system ARA routing table extensions and
          reachable via the ASBR.

5.0 Examples

5.1 Example 1: Intra-Area

     Consider the sample single-area topology by area
     border routers in Figure 1 below.  In this
     example RT1, RT2 and RT5 support the inter-area ARA option (by definition they
     also support origination process.  The indexes
     for an entry in this table are the Opaque LSA option) Vertex Type, Vertex ID and RT4 supports the Opaque LSA
     option only (this is necessary so Ver-
     tex Originator.  The Vertex Type identifies the type of IP topology
     element that RT4 redistributes the ARAs ori-
     ginated by RT1, RT2 and RT5).  RT2 and RT5 have each originated a R-
     ARA link-layer information is being associated with an intra-area
     (i.e., a router association and RT5 has originated or a N-
     ARA with an intra-area network association for N5.

     As network), the Vertex ID identifies a result piece of running the routing table calculation, RT1 has entries
     for N1-N8 in its routing table.  The entry for N2 references
     OSPF topology (i.e., a router ID or an IP network number) and the
     link-layer associations distributed in RT2's R-ARA, the entries for
     N3, N4, N6, N7, N8 references the link-layer associations distributed
     in RT5's R-ARA and the entry for N5 references Ver-
     tex Originator is the link-layer associa-
     tions distributed in RT5's intra-area N-ARA.

Coltun, Heinanen                                                   [Page 9]
                +   ARA
                |  +---+                   N3       N5 (ARA)
              N1|--|RT1|\                    \ N4  /
                |  +---+ \                    \ | /
                +         \                    \|/
                           \+---+            +---+
                            |RT4|------------|RT5|ARA
                            +---+            +---+
                 +   ARA   /                   |     N7
                 |  +---+ /                    |    /
               N2|--|RT2|/                     |   /
                 |  +---+    +---+           +---+/
                 +           |RT3|-----------|RT6|----N8
                             +---+           +---+
                               |
                               |
                          +---------+
                              N6

                      Figure 1: Sample Single-Area Toplogy

5.2 Example 2: Inter-Area

     Consider Router ID of the sample 2-area topology in Figure 2 below.  In this exam-
     ple RT1, RT2, RT3, RT4, RT6 and RT7 support router originating the ARA.

5.3 Logical Network ID List

     An ARA option, and RT5
     supports the Opaque option.  N4 is an AS external route (which is
     flooded to all areas) and RT6 is an ASBR.  RT4 is an area-border capable router and originates an LS Type-4 LSA on behalf of RT6 and maintains a LS
     Type-3 LSA for N5 into area 1.1.1.1.

     Within area 1.1.1.1, RT1, RT2, RT3 and RT4 originate intra-area R-
     ARAs.  Within configured list of logical networks
     IDs.  This list represents the backbone RT6 and RT7 originate intra-area R-ARAs and
     R7 originates logical networks that a N-ARA for N5. All backbone ARAs of have their router is con-
     nected to and may be used to restrict the P-
     bit set (this bit informs ABRs of devices that the ARA
     router may be propagated between
     areas).  RT4 originates an inter-area R-ARA for RT6 (which is an ASBR)
     as well as an inter-area N-ARA for N5 into area 1.1.1.1 RT4 does not
     originate an inter-area R-ARA for RT7 because it is not an ASBR.

     As a result setup shortcuts to (see Section 4.5 "Restricting Shortcut
     Connectivity").  The absence of running entries in the router's list of Logi-
     cal Network IDs means that the router will only activate ARA Associa-
     tion Table entries with the default Logical Network ID (Logical Net-
     work ID 0).

5.4 Routing Table Extensions

     Associations are added to the routing table calculation, RT1 has entries
     for N1-N5 in its during the OSPF routing table.  The entry for N2 references
     table calculation (see Section 9.1 entitled "Adding ARA Routing Table
     Extensions").  That is, in addition to the
     link-layer associations distributed standard information fields
     contained in RT3's R-ARA, the entry for N3
     references routing table (IP network number, IP mask, next-hop
     interface, etc.), the routing table is extended to contain link-layer
     associations.  However, only 'active' link-layer associations distributed in RT4's intra-area
     R-ARA, are
     added to the routing table.  Associations containing a logical network
     ID that matches a currently enabled entry for N4 references in the router's list of log-
     ical network IDs are considered to be active.  Both active and non-
     active link-layer associations distri-
     buted may be included in RT4's inter-area R-ARA (indirectly referencing RT6's R-ARA)
     and ARAs that
     are originated by an ABR.

     The routing table (and its ARA routing table extensions) must be
     recalculated if 1) there is a change to the entry for N5 references OSPF topology, 2) there is
     a change to the link-layer associations

Coltun, Heinanen                                                  [Page 10]
     distributed components in RT4's inter-area N5 N-ARA.

             +   ARA the ARA       |
             |  +---+    +---+      |
           N1|--|RT1|----|RT2|\     |        N3          N4<ASE
             |  +---+    +---+ \    |     +-----+        /
             +                  \  ARA       |      ARA /
                                 \+---+    +---+   +---+
                                  |RT4|----|RT5|---|RT6|<ASBR
                                  +---+    +---+   +---+
                       +   ARA   /  |                |
                       |  +---+ /   | Association Table (see Section
     10.0 "Receiving ARAs"), or 3) the router's logical network connec-
     tivity has changed (e.g., the logical network ID list is modified or
     the status of the router's connections to one of its logical networks
     has changed).

     The use of the routing table extensions are application specific and
     beyond the scope of this document.  See [HEIN] for an example of an
     ARA    +
                     N2|--|RT3|/    |              +---+   |
                       |  +---+     |              |RT7|---|N5(ARA)
                       +            |              +---+   |
            ------------------------|--------------------  +
		Area 1.1.1.1	    | user application.

5.5 Restricting Shortcut Connectivity

     As a result of setting up shortcuts in an OSPF Backbone

                      Figure 2: Sample Area Toplogy

5.3 Example 3: Multiple Logical Networks topology between ARA-
     capable routers, the shortcut connectivity may become fully meshed.
     In many environments this may be desirable whereas in in others this
     may not be.  The ARA option allows for several methods which can limit
     shortcut connectivity.

          o [HEIN] proposes that shortcuts are setup by ingress routers
          only after the sending data rate has passed a configured thres-
          hold.

          o ARA-capable routers may choose not to advertise their resolu-
          tion information until some event has occurred.

          o Routers may be associated with "closed user shortcut groups" so
          that only routers that are within the same shortcut group may
          set-up shortcuts to each other. This is done by coordinating the
          configuration of a router's logical network ID list with the log-
          ical network ID advertised in ARA associations.

6.0 ARA Associations

     The ARA option supports the existence defines four types of disjoint switched networks
     within an OSPF domain. To accomplish this, an ARA may advertisements.  These include an iden-
     tifier (the logical 1)
     intra-area router associations, 2) intra-area network associations, 3)
     inter-area network ID) for a specific switched network.  When associations are added and 4) inter-area autonomous system
     boundary router (ASBR) associations.  Associations correspond to the routing table during a
     piece of the OSPF routing
     table calculation (see the section 8.1 "Adding ARA Routing Table
     Extensions") only the topology.  Intra-area router associations that include correspond
     to link-layer reachability of a logical router within the local area, intra-
     area network ID
     that matches one of associations correspond to the link-layer reachability of
     a router's configured logical directly connected network IDs are
     added to (also within the routing table.  This function may also be used local area),
     inter-area network associations correspond to support
     a variation the link-layer reacha-
     bility of closed user groups so that shortcuts are limited a remote area router's directly connected network, and
     inter-area ASBR associations correspond to
     those routers ASBRs that are configured to be in the same logical network.

     The single-area topology described in Figure 3 below divides an remote
     OSPF areas.  Note that an inter-area network association may be ori-
     ginated by an area into logical networks X and Y.  In this example RT1, RT2 and RT4
     support border router (ABR) only if the ARA option and RT3 supports network is not a
     component of a configured net range.  An ingress router can use these
     associations as follows.

          Intra-area router associations are used to setup shortcuts to
          routers within the local area.  Data sent over the Opaque LSA option only.
     RT1 is connected shortcut will
          be forwarded to logical network (LN) X, RT2 is connected LN Y and
     RT4 is connected destinations local to both LN X and LN Y.  RT1, RT2 and RT4 all ori-
     ginate R-ARAs.

     As a result of running their routing table calculation, RT1 and RT2
     have entries for N1-N5 in their routing table.  In both routing
     tables, beyond the N3-N5 entries reference router
          including ones that are in the link-layer associations dis-
     tributed local area, in RT4's R-ARA.  However, RT1's routing table does not refer-
     ence RT2's link-layer a remote area or
          external to the autonomous system.  Destinations that are "beyond
          the router" are determined by the OSPF topology map.

          Intra-area network associations for N2 and RT2's routing table does

Coltun, Heinanen                                                  [Page 11]
     not reference RT1's link-layer (which may advertise hosts or
          networks) are used to setup intra-area shortcuts to systems whose
          addresses fall within the range of the advertised network.

          Inter-area network associations for N1 (i.e., they would
     not be able (which may advertise a host or
          network address) are used to set up setup inter-area shortcuts to each other and would be forced sys-
          tems whose address fall within the range of the advertised net-
          work.

          Inter-area ASBR associations are used to
     use a hop-by-hop path setup shortcuts to communicate).

                +   ARA (LN=X)
                |  +---+                   N3       N5
              N1|--|RT1|\                    \ N4  /
                |  +---+ \                    \ | /
                +         \                    \|/
                           \+---+            +---+
                            |RT3|------------|RT4| ARA (LN=X,Y)
                            +---+            +---+
                            /
                 +   ARA (LN=Y)
                 |  +---+ /
               N2|--|RT2|/
                 |  +---+
                 +

              Figure 3: Sample Toplogy With Logical Networks

6.0 ASBRs
          that are in a remote area.  These shortcuts are used to send data
          to destinations that are external to the autonomous system and
          reachable via the ASBR.

7.0 Description Of ARA Packet Formats

     ARA LSAs (ARAs) include the information necessary to associate an IP
     entity (i.e., a router, network or host) with a link-layer address.
     The ARA option allows further refinement so that an association may
     additionally include information about QoS control services and link-
     layer functionality (e.g., for Point-to-MultiPoint and MultiPoint-to-
     point connections).  ARA advertisements may also include a logical
     network identifier field, which is used when multiple switched net-
     works are present within the OSPF domain.

     The ARA format allows more than one equivalent association to been be
     advertised by a router for a specific vertex.  Equivalent associations
     are ones that have identical link service type, integrated service
     type and logical network identifier fields, but have different resolu-
     tion information.  Associations can include a preference which identi-
     fies the advertising router's relative preference for the equivalent
     associations.
     associations (a higher numeric preference denotes a better choice).

     ARA information is encapsulated in Opaque LSAs.  Three LS Types (LS
     Type 9, 10 and 11) constitute the Opaque class of link-state adver-
     tisements.  Each of the three Opaque link-state types have a scope
     associated with them so that distribution may be limited appropriately

Coltun, Heinanen                                                  [Page 12]
     by the originator of the LSA.  Opaque LSAs have a sub-type which iden-
     tifies the specific information that is carried within the LSA.  The
     ARA Opaque types are Opaque-type Opaque-types 1 - 4.  Because the flooding scope
     for ARAs is always area local, ARAs are encapsulated in LS Type 10
     LSAs.

6.1

7.1 Vertex Types And Vertex Identifiers

     The Vertex Type identifies the piece of IP topology that the link-
     layer information is being associated with.  The Vertex Type may be a
     router or a network (a host is considered a network with a mask of
     255.255.255.255).

     Vertex Type 1 ARAs advertise intra-area router resolution associa-
     tions.  These associations distribute the router's link-layer attach-
     ments.  A Vertex Type of 1 is identified by an Opaque type of 1.  The
     Vertex Identifier for a R-ARA is the advertising router field in the
     ARA header.

     Vertex Type 2 ARAs advertise intra-area IP network address resolution
     associations.  These associations distribute the link-layer associa-
     tions for a router's directly connected network. networks. A Vertex Type of 2
     is identified by an Opaque type of 2.  The Vertex Identifier (the net-
     work and mask) for a N-ARA is contained in the body of the advertise-
     ment.  N-ARAs may only contain a single network (i.e., lists of net-
     works are not permitted).

     Vertex Type 3 ARAs advertise inter-area IP network address resolution
     associations.  These associations are used to distribute link-layer
     associations for networks into remote areas.  A Vertex Type of 3 is
     identified by an Opaque type of 3.  The Vertex Identifier (the network
     and mask) for a an inter-area N-ARA is contained in the body of the
     advertisement.  N-ARAs may only identify a single network (i.e., lists
     of networks are not permitted).  Vertex Type 3 N-ARAs are originated
     by an area border router (ABR) into an area when 1) the ABR originates
     a type-3 LSA for the network into the target area, 2) the network is
     not included in any of the area border router's configured area
     ranges, 3) there is a N-ARA for the network in the source area, 4) the
     source N-ARA may be an intra or inter-area N-ARA.  If it is an intra-
     area N-ARA the P-bit must be set in its options field.  The setting of
     the P-bit by the originator denotes that the associations contained in
     the N-ARA are allowed to be propagated into other areas.  The default
     setting for the P-bit is off.

     Vertex Type 4 ARAs advertise inter-area router address resolution
     associations. These R-ARAs redistribute associations for ASBRs into
     remote areas.  A Vertex Type of 4 is identified by an Opaque type of
     4.  The Vertex Identifiers for an inter-area R-ARA are the advertising
     router field of the ARA header and the ASBR Router ID found in the

Coltun, Heinanen                                                  [Page 13]
     body of the ARA.  Vertex Type 4 R-ARAs are originated by an area
     border router (ABR) into a target area when 1) the ABR originates a
     type-4 LSA for the ASBR into the target area, 2) there is a R-ARA for
     the network in the source area, 3) the source R-ARA may be an intra or
     inter-area R-ARA.  If the source R-ARA is an intra-area R-ARA its P-
     bit must be set in the options field. The setting of the P-bit by the
     originator denotes that the associations contained in the R-ARA are
     allowed to be propagated into other areas.  The default setting for
     the P-bit is off.

     If a router wishes to advertise several associations for a single ver-
     tex it has two options.  It may originate multiple (N or R) ARAs each
     containing different associations or it may originate a single (N or
     R) ARA containing a list of associations.  An implementation must not
     include identical associations in more than one ARA.

7.0

8.0 Distribution Of ARA Information
     In general, OSPF is composed of two components.  It's transport com-
     ponent handles adjacency formation and reliable distribution of topol-
     ogy information.  The second component tracks topology changes and
     organizes the topology information that has been gathered from other
     routers into to a topology map. This map is used to build the router's
     routing table.  The ARA option uses both the OSPF transport component
     and of the topology map component.

     ARA uses the OSPF Opaque LSA as defined in [OPAQ] for distribution of
     resolution information. The Opaque LSA is an optional mechanism to
     allow for distribution of opaque information which may be used directly by
     OSPF or by other protocols and mechanisms.  Opaque LSAs use the standard stan-
     dard OSPF link-state database flooding mechanisms for dis-
     tribution. distribution.
     Each of the three Opaque types (LS Types 9, 10 and 11) have a scope
     associated with them (link-local, area-local or domain-
     wide, respectively). domain-wide, respec-
     tively). Scoping provides an application with a method to limit the
     range of information distribution.  ARA information is dis-
     tributed distributed
     with area-local scope (i.e., ARA information is encapsulated in LS
     Type 10 LSAs).

     The ARA option uses uses the topology map component of OSPF to validate the
     information that is received by the distribution mechanism and to
     install the associations into the ARA routing table extensions.  Vali-
     dation is necessary because topology information contained in the OSPF
     link-state database may be stale and therefore unusable (e.g., the
     originator of the information is no longer reachable).

     It is envisioned that an implementor designs an ARA user application
     interface which facilitates 1) flooding of ARA information to other
     routers in the OSPF network, 2) receiving ARA information from other
     routers in the OSPF network and 3) determines the validity (and change
     of validity) of ARA information.

     For the realization of 1 above, an implementation must provide an API
     to facilitate the ARA user application's "hand off" of resolution
     information to its local OSPF entity who will then distribute the
     information throughout the OSPF topology.  In addition, the API must
     support the purging of associations that were previously originated by
     the router if they are no longer valid and send out new versions when
     the association information has changed.

     For the realization of 2 and 3 above, this option extends the topology map component of OSPF rout-
     ing table to validate include the
     information associations that is received have been advertised by the distribution mechanism and to
     install
     ARA capable routers (i.e,. the associations into routing table provides the API for the
     ARA user application).  That is, in addition to the standard informa-
     tion fields contained in the routing table (i.e., IP network number,
     IP mask, next-hop interface, etc.), the routing table extensions.  Vali-
     dation is necessary because topology information contained in extended to
     contain link-layer associations. The associations are added to the
     routing table during the OSPF
     link-state database may be stale (e.g., routing table calculation.  Section 8.0
     defines the originator mechanism to calculate the ARA routing table extensions.
     The use of the informa-
     tion is no longer reachable).

     It is envisioned that an implementor designs an extensions are ARA user application
     interface which facilitates 1) flooding specific and beyond
     the scope of this document.  See [HEIN] for an example of an ARA information user
     application.

8.1 Originating Inter-Area ARAs

     Inter-area ARAs provide a mechanism to distribute link-layer associa-
     tions to other
     routers in the OSPF network, 2) receiving ARA information from other

Coltun, Heinanen                                                  [Page 14]
     routers in the OSPF network areas.  Inter-area ARAs (consisting of Vertex Type-3
     and 3) determines Type-4 ARAs) have a one-to-one correspondence to Summary LSAs (LS
     type-3 and type-4 LSAs).  Vertex Type-3 ARAs advertise the validity (and change link-layer
     associations of validity) IP networks whereas Vertex Type-4 ARAs advertise the
     link-layer associations of ARA information. autonomous system boundary routers (ASBR).
     As with Summary LSAs, inter-area ARAs are originated by area border
     routers into a target area based on a set of conditions in the source
     area.  For both intra and inter-are ARAs, there may be more than one
     ARA which collectively make up the realization complete set of 1 above, link-layer associa-
     tions (recall that an implementation must provide an API
     to facilitate not include identical asso-
     ciations in more than one ARA).  Inter-area ARAs must include, in one
     or more ARA, all of the ARA user application's "hand off" link-layer associations contained in their
     'trigger' ARAs (see below for a description of resolution
     information the conditions for ABRs
     to its local OSPF entity which will then be distributed
     throughout trigger inter-area ARAs).

     The link-layer associations that comprise the OSPF topology.  In addition, 'trigger' ARAs (in the API must support
     source area) may include logical network IDs that are not in the
     purging ABR's
     configured list of associations that were previously originated by logical network IDs (i.e., the router
     if they ABR itself may not
     be able to set up a shortcut because it may be connected to a disjoint
     set of logical networks). Despite the ABR's logical network affilia-
     tion, all trigger ARAs' link-layer associations are no longer valid and send out new versions when included in the associ-
     ation information has changed.

     For
     newly originated inter-area ARAs.

     The origination process for type-3 and type-4 Summary LSAs (as dis-
     cussed in Section 12.4.3 of [OSPF]) consists of an ABR evaluating each
     entry in the realization routing table.  If an entry satisfies a set of 2 and 3 above, this document extends condi-
     tions, the rout-
     ing table to include ABR originates a Summary LSA into the associations target area.

     This process is extended for inter-area ARA origination so that have been advertised when a
     Summary LSA is originated into an area by an ABR, the conditions for
     the origination of inter-area ARAs are also evaluated. When these con-
     ditions are satisfied, an inter-area ARA capable routers (i.e,. is originated into the routing table provides target
     area.  Conversely, when a Summary route is withdrawn from an area by
     an ABR and a corresponding ARA was previously originated into the API for
     area, the ARA user application).  That is, in addition to the standard informa-
     tion fields contained in must be withdrawn from the routing table (i.e., IP network number,
     IP mask, next-hop interface, etc.), target area.  The following
     sections describe the routing table is extended to
     contain link-layer associations. conditions for inter-area ARA origination.

     The associations conditions for inter-area N-ARA origination are added to as follows.

          o The ABR is originating a type-3 LSA for a network into the
     routing table during tar-
          get area.  The network and mask that triggered the OSPF routing table calculation.  Section 8.0
     defines origination of
          the mechanism type-3 LSA must be identical to calculate the ARA routing table extensions.
     The use network and mask of the extensions are ARA user application specific and beyond
          type-3 LSA.  (i.e., the scope of this document.  See [HEIN] 'trigger network' is not included in the
          area border router's configured area ranges).

          o There are one or more reachable N-ARAs for an example of an ARA user
     application.

7.1 Originating Inter-Area ARAs

     Inter-area ARAs provide a mechanism to distribute link-layer associa-
     tions to other areas.  Inter-area ARAs (consisting of Vertex Type-3
     and Type-4 ARAs) the network in the
          source area.  These N-ARAs 1) must be valid (e.g., their ages
          must not be MaxAge), 2) must have a one-to-one correspondence to Summary LSAs (LS the same advertising router as
          the LSA that triggered the origination of the type-3 LSA and type-4 LSAs). 3)
          the Vertex Type-3 ARAs advertise Type must correspond to the link-layer
     associations 'trigger' network's LSA
          type (recall that only the contents of IP networks whereas Vertex Type-4 intra-area ARAs advertise are adver-
          tised into the
     link-layer associations backbone, whereas the contents of autonomous system boundary routers (ASBR).
     As with Summary LSAs, intra-area or
          inter-area ARAs are originated by area border
     routers may be advertised into a target area based on a set of the other areas).  These
          conditions are verified by looking up an entry in the source
     area.  For both intra and inter-are ARAs, there may be more than one area's
          ARA which collectively make up Association Table.  The Vertex Type is 2 if the complete 'trigger'
          network is an intra-area LSA and is Vertex Type 3 if the
          'trigger' network is an inter-area LSA. The Vertex Identifier is
          the 'trigger' network's IP network number and mask.  The Vertex
          Originator is the router ID of the trigger network's originator.

          o The set of link-layer associa-
     tions (recall associations that are to be included in
          the advertisement are contained in the ARA Association Table
          entry.  However, if the network that triggered the origination of
          the type-3 LSA is an implementation must not include identical intra-area route, only the link-layer asso-
          ciations in more than one ARA).  Inter-area ARAs whose ARA's P-bit were set may be advertised.  (if no
          associations have their P-bit set the inter-area N-ARA must include, in one
     or more ARA, all not
          be originated).  The setting of the P-bit in the N-ARA by its
          originator gives the ABRs permission to propagate the resolution
          information into other areas.

     Inter-area R-ARAs redistribute link-layer associations contained in their
     'trigger' ARAs (see below for ASBRs to
     other areas. Inter-area R-ARAs have a description Vertex Type of the conditions 4.  The Vertex
     Identifiers for ABRs
     to trigger an inter-area ARAs).

     The link-layer associations that comprise the 'trigger' ARAs (in the
     source area) may include logical network IDs that R-ARA are not in 1) the ABR's
     configured list advertising router
     field of logical network IDs (i.e., the ABR itself may not
     be able to set up a shortcut because it may be connected to a disjoint
     set of logical networks). Despite ARA header and 2) the ABR's logical network

Coltun, Heinanen                                                  [Page 15]
     affiliation, all trigger ARAs' link-layer associations are included ASBR's Router ID which is found in
     the newly originated inter-area ARAs.

     The origination process for type-3 and type-4 Summary LSAs (as dis-
     cussed in section 12.4.3 of [OSPF]) consists body of an ABR evaluating each
     entry in the routing table.  If ARA.  Vertex Type-4 R-ARAs are originated by an entry satisfies a set of condi-
     tions, area
     border router (ABR) into an area if the following conditions are met.

          o The ABR originates a Summary type-4 LSA for the ASBR into the target
          area.

     This process is extended for inter-area ARA origination so that when a
     Summary LSA is originated

          o Only the contents of intra-area ARAs are advertised into an area by an ABR, the conditions for
          backbone, whereas the origination contents of intra-area or inter-area ARAs are also evaluated. When these con-
     ditions are satisfied, an inter-area ARA is originated
          may be advertised into the target
     area.  Conversely, when other areas.  If the router advertise-
          ment that triggered the origination of a Summary route type-4 LSA is withdrawn from an intra-
          area by
     an ABR and advertisement (i.e., a corresponding ARA was previously originated into the
     area, the ARA type-1 LSA) then there must be withdrawn from a
          corresponding intra-area R-ARA in the target source area.  The following
     sections describe

          o If the router advertisement that triggered the conditions for inter-area ARA origination.

     The conditions for inter-area N-ARA origination are as follows.

          o The ABR of
          the type-4 LSA is originating also a type-3 type-4 LSA for (the source area is the OSPF
          backbone), there must be a network into corresponding inter-area R-ARA in the tar-
          get
          source area.

          o The network and mask set of link-layer associations that are to be included in
          the advertisement are contained in the ARA Association Table
          entry.  However, if the router advertisement that triggered the
          origination of the type-3 LSA is an intra-area route, only the
          link-layer associations whose ARA's P-bit are set may be adver-
          tised in the newly originated inter-area R-ARA (if no associa-
          tions have their P-bit set the inter-area N-ARA must not be identical ori-
          ginated).  The setting of the P-bit in the R-ARA by its origina-
          tor gives the ABRs permission to propagate the network resolution infor-
          mation into other areas.

9.0 ARA Routing Table Extensions

     OSPF determines reachability and topology changes by performing the
     algorithms described in the Section 16 of [OSPF] entitled "Calculation
     of the routing table".  ARAs are included in this calculation for the
     purpose of binding link-layer associations to IP routing table
     entries.

     A link-layer association consists of the list of link-layer addresses,
     link-layer service types and other link-layer objects such as Point-
     to-MultiPoint call identifiers and mask QoS service specific information
     (see Appendix A for a more complete description of the
          type-3 LSA.  (i.e., the 'trigger network' is not included specific link-
     layer information distributed in the
          area border router's configured area ranges).

          o There ARAs).  The associations that are
     bound to a routing table entry are one or more reachable N-ARAs for the network in the
          source area.  These N-ARAs associations that are 1) must be valid (e.g., their ages
          must not be MaxAge),
     closest to the destination and 2) must have are on the same advertising router logical network as
     the LSA that triggered the origination of the type-3 LSA and 3) calculating router (as identified by the Vertex Type must correspond logical network ID).  The
     closest associations are determined during to the 'trigger' network's LSA
          type (recall that only the contents construction of intra-area ARAs the
     OSPF topology map.  The associations that are adver-
          tised into bound to the backbone, whereas routing
     table entries are subsequently used by the contents of intra-area or
          inter-area ARAs ARA user application (e.g.,
     a shortcut manager) to setup shortcut paths.

     Multiple link-layer associations may be advertised into the other areas).  These
          conditions bound to a single routing
     table entry when multiple link-layer association are verified advertised by looking up an entry in the
     source area's
          ARA Association Table.  The Vertex Type is 2 if or when the 'trigger'
          network is an intra-area LSA and is Vertex Type 3 if routing table calculation discovers equal cost
     paths.  These may be used as alternate entries (e.g., when a call set
     up to a one association fails another may be used) or may be used to
     set up equal-cost shortcuts.

     Because a link-layer association may be bound to more than one entry
     in the
          'trigger' network is routing table, an inter-area LSA. The Vertex Identifier is
          the 'trigger' network's IP network number and mask.  The Vertex
          Originator is the router ID of the trigger network's originator.

          o The set ARA implementation keeps a table of ARA
     derived link-layer associations that are to be included in which is referenced by the advertisement are contained routing
     table entry.  Each area has its own ARA Association table.  An entry
     in the ARA Association Table
          entry.  However, if the network that triggered the origination consists of
          the type-3 LSA is an intra-area route, only the link-layer asso-
          ciations whose ARA's P-bit were set may be advertised.  (if no
          associations have their P-bit set the inter-area N-ARA must not
          be originated).  The setting a list of all associations
     for a specific vertex and vertex type by a specific originator; the P-bit
     lookup keys for an entry in the N-ARA by its

Coltun, Heinanen                                                  [Page 16]
          originator gives table include the ABRs permission to propagate Vertex Type, Vertex
     ID and the resolution
          information into other areas.

     Inter-area R-ARAs redistribute link-layer associations for ASBRs to
     other areas. Inter-area R-ARAs have a Vertex Type Originator.

9.1 Adding ARA Routing Table Extensions

     Section 16 of 4.  The Vertex
     Identifiers the OSPF specification is modified for an inter-area R-ARA are 1) the advertising router
     field purpose of
     adding the ARA header routing table extensions.  Transit vertex data struc-
     tures and 2) the ASBR's Router ID which is found in the body internal representation of the ARA.  Vertex Type-3, Type-4 R-ARAs and Type-5
     LSAs are originated by an area
     border router (ABR) into an area if extended to be able to reference a list of link-layer associ-
     ations (i.e., they have a reference to the following conditions are met.

          o ARA Association Table).
     The ABR originates a type-4 LSA for vertex and LSA's list of link-layer associations are added to the ASBR into
     routing table along with the target
          area.

          o Only entry.

     Prior to running the contents of intra-area ARAs are advertised into route calculation the
          backbone, whereas ARA Association
     Table is examined.  Associations containing a logical network ID that
     matches an entry in the contents router's list of logical network IDs are
     marked 'active'.

9.1.1 Modifications To The Intra-Area Route Calculation

     The intra-area or inter-area ARAs
          may route calculation is enhanced (specifically Section
     16.1 step 3 of [OSPF]) as follows.

          o Call the vertex that is about to be advertised into added to the other areas. SPF tree ver-
          tex M. If vertex M was originated by the calculating router advertise-
          ment that triggered the origination of a type-4 LSA skip
          this procedure.

          o If vertex M is an intra-
          area advertisement (i.e., a type-1 LSA) then there must be a
          corresponding intra-area R-ARA in transit network vertex lookup the source area.

          o If link-layer
          association entry in the router advertisement that triggered ARA Association Table.  This entry's
          Vertex Type will be 2, the origination of Vertex Identifier will be vertex M's
          network and mask, the type-4 LSA is also a type-4 LSA (the source Vertex Originator will be vertex M's Router
          ID and its area is the OSPF
          backbone), there must ID will be a corresponding inter-area R-ARA in the
          source area.

          o The set of link-layer associations one that are is associated with the
          shortest-path calculation.

          o If an active entry is found, copy this entry to be included in vertex M's
          link-layer association list.

          o If vertex M is a router vertex lookup the advertisement are contained an entry in the ARA
          Association Table
          entry.  However, if the router advertisement that triggered the
          origination of the type-3 LSA is an intra-area route, only the
          link-layer associations whose ARA's P-bit are set may Table.  This entry's Vertex Type will be adver-
          tised in the newly originated inter-area R-ARA (if no associa-
          tions have their P-bit set 1, the inter-area N-ARA must not Ver-
          tex Identifier will be ori-
          ginated).  The setting of the P-bit in the R-ARA by its origina-
          tor gives the ABRs permission to propagate vertex M's advertising router, the resolution infor-
          mation into other areas.

8.0 ARA Routing Table Extensions

     OSPF determines reachability Vertex
          Originator will be vertex M's advertising router and topology changes by performing the
     algorithms described in its area ID
          will be the section 16 of [OSPF] entitled "Calculation
     of one that is associated with the routing table".  ARAs are included in shortest-path calcu-
          lation.

          o If an an active entry is found, add this calculation for the
     purpose of binding link-layer associations entry to IP routing table
     entries.

     A vertex M's
          link-layer association consists of the list of link-layer addresses, list.

          o If no active link-layer service types association entries are found, and other ver-
          tex M's parent vertex has link-layer objects such as Point-

Coltun, Heinanen                                                  [Page 17]
     to-MultiPoint call identifiers and QoS service specific information
     (see Appendix A for a more complete description of the specific link-
     layer information distributed in ARAs).  The associations that are
     bound to a routing table entry are association information,
          vertex M inherits it's parent vertex's information (else the associations that are 1)
     closest
          information field is left blank).

          o When vertex M is added to the destination and 2) are on the same logical network as routing table, copy the calculating router (as identified by active
          associations from vertex M's link-layer association list into the logical network ID).
          routing table entry's link-layer association field.

     The
     closest associations are determined during to following describes the construction enhancements to Section 16.1 step 2 of the
     OSPF topology map.  The associations that are bound
     [OSPF] which adds intra-area stub networks to the routing
     table entries are subsequently used by table.

          o Before adding the ARA user application to
     setup shortcut paths.

     Because a link-layer association may be bound stub network to more than one entry
     in the routing table, an ARA implementation keeps a table of ARA
     derived link-layer associations which is referenced by lookup the routing
     table entry.  Each area has its own ARA Association table.  An
          entry in the ARA Association Table consists of a list Table.  This entry's Vertex Type
          will be 2, the Vertex Identifier will consist of all association for
     a specific vertex and vertex type by a specific originator; the lookup
     keys for an entry in network and
          mask of the table include stub network, the Vertex Type, Vertex Originator will be the
          advertising router's Router ID and its area ID will be the Vertex Originator.

8.1 Adding ARA Routing Table Extensions

     Section 16 of one
          that is associated with the OSPF specification shortest-path calculation.

          o If an active entry is modified for found copy the entry's active association
          information into the routing table entry's link-layer association
          field.

          o If an entry is not found and the purpose of
     adding stub network's advertising
          router vertex has link-layer association information, the ARA routing
          table extensions.  Transit vertex data struc-
     tures and entry will inherit the internal representation of Type-3, Type-4 and Type-5
     LSAs are extended to be able advertising router's information
          (else the information field is left blank).

9.1.2 Modifications To The Inter-Area Route Calculation

     The following describes the enhancements to reference a list of link-layer OSPF Sections 16.2, 16.3,
     16.5 which calculate inter-area routes. Before the destination associ-
     ations (i.e., they have a reference to
     ated with the ARA Association Table).
     The vertex and LSA's list of link-layer associations are LSA is added to the routing table along with the entry.

     Prior to running the intra-area route calculation following is per-
     formed.

          o If the ARA Association
     Table LSA is examined.  Associations containing a logical network ID that
     matches an Type-3 Summary LSA, lookup the entry in the router's list of logical ARA
          Association Table. This entry's Vertex Type will be 3, the Vertex
          Identifier will be the Summary LSA's network IDs are
     marked 'active'.

8.1.1 Modifications To The Intra-Area Route Calculation

     The intra-area route calculation is enhanced (specifically section
     16.1 step 3) as follows.

          o Call and mask, the vertex Vertex
          Originator will be the advertising router's Router ID and its
          area ID will be the one that is about to be added to associated with the SPF tree ver-
          tex M. shortest-path
          calculation.  If vertex M was originated by an active entry is found copy the calculating router skip
          this procedure. entry's active
          association information into the routing table entry's link-layer
          association field.

          o If vertex M the LSA is a transit network vertex Type-4 Summary LSA, lookup the link-layer
          association entry a type-4 ARA in the
          ARA Association Table.  This entry's

Coltun, Heinanen                                                  [Page 18] Vertex Type will be 2, 4, the
          Vertex Identifier will be vertex M's
          network and mask, the Summary LSA's ASBR ID, the Vertex
          Originator will be vertex M's the advertising router's Router ID and its
          area ID will be the one that is associated with the shortest-path
          calculation.  If an active entry is found copy the entry's active
          association information into the routing table entry's link-layer
          association field.

          o If an active entry was not found for the type-3 or type-4 LSA,
          locate the area border router (ABR) that originated the adver-
          tisement. If link-layer association information is found, reference this available for
          the ABR entry, copy the contents of the ABR's link-layer associa-
          tion information field into the routing table entry's link-layer
          association field.  If no active entry was found for the ABR the
          routing table entry's information field will be left blank.

9.1.3 Modifications To The AS External Route Calculation

     The following describes the enhancements to OSPF Sections 16.4 and
     16.6 which calculate AS external routes. Before the destination asso-
     ciated with the LSA is added to the routing table the following is
     performed.

          o If the LSA has a forwarding address, look up the forward
          address in vertex M's the routing table (this will be an internal OSPF
          route).  Copy the contents of the route's link-layer association
          information field into the external route's routing table entry's
          link-layer association field.  The forwarding address' link-layer
          association information may have been added as a result of pro-
          cessing intra-area or inter-area N-ARAs.

          o If vertex M is the LSA does not have a router vertex lookup forwarding address, copy the an entry in con-
          tents of the advertising ASBR's link-layer association informa-
          tion field into the routing table entry's link-layer association
          field.  The ASBR's link-layer association information may have
          been added as a result of processing intra-area or inter-area R-
          ARAs.

9.2 Routing Table Extension Completion

     Upon completing the calculation of ARA
          Association Table.  This entry's Vertex Type will be 1, the Ver-
          tex Identifier will be vertex M's advertising router, routing table extensions the Vertex
          Originator will
     entity that manages shortcuts must be vertex M's advertising router informed so that it can reevalu-
     ate existing shortcuts and its area ID
          will determine if new shortcuts are to be setup.
     Reevaluation of existing shortcuts is necessary so that the one router can
     determine if shortcuts that is associated it has previously set up are no longer on
     the path to their target destinations.  Packets that are sent on these
     invalid shortcuts may result in packet loss or forwarding loops.

     Reevaluating existing shortcuts requires comparing the shortcut's
     currently active link-layer associations with the shortest-path calcu-
          lation.

          o link-layer associa-
     tions that have just been derived.  If an an active entry a destination is found, reference this entry no longer in vertex
          M's link-layer association field.

          o If
     the routing table or no active link-layer association entries are found, and ver-
          tex M's parent vertex longer has link-layer association information,
          vertex M inherits it's parent vertex's information (else an association, the
          information field is left blank).

          o When vertex M shortcut must
     be terminated.  If there is added to the routing table, copy a mismatch between the associations
     currently being used by an active shortcut (for a specific target net-
     work) and the associations from vertex M's link-layer association list into that have just been derived, the
          routing table entry's link-layer association field.

     The following describes currently
     active shortcut must be terminated and if warranted, a new shortcut
     must be set up.

     An implementation may want to consider methods for dampening the enhancements
     number of existing shortcuts that are terminated and set up immedi-
     ately following a route calculation.  One dampening model would be to section 16.1 step 2
     configure a maximum number of
     [OSPF] which adds intra-area stub networks to changes per time period. If the routing table.

          o Before adding number
     of changes exceeds the stub network to maximum number, the routing table lookup router must either stop
     forwarding on invalid paths (dropping all packets for the
          entry in destinations
     unsing invalid shortcuts) or revert to hop-by-hop forwarding until the ARA Association Table.  This entry's Vertex Type
          will
     invalid shortcuts are terminated and new ones have been set up.

     An enhancement to this model would be 2, to allow "pretty good" shortcuts
     to exist for a some time after a route calculation has completed.
     That is, the Vertex Identifier will consist list of associations for a destination would be extended
     to include both the network associations that are closest to the target net-
     work and
          mask ones that are on the path towards the destination.  To imple-
     ment this, during the calculation of the stub network, ARA routing table extensions,
     the Vertex Originator will list of associations for a specific target network would be
     extended to inherit all associations from it's parents (in addition to
     the
          advertising router's Router ID and its area ID will associations that it has determined to be closest to the one
          that is associated with target
     network).  After running the shortest-path calculation.

          o If an active entry is found copy calculation the entry's active association
          information into shortcut manager would
     check each the routing table entry's link-layer association
          field. of the currently active shortcut's associations:

          o If an entry the associations currently being used by the shortcut is not found and the stub network's advertising
          router vertex has link-layer association information,
          closest one to the routing
          table entry will inherit target network, evaluate the advertising router's information
          (else next shortcut.

          o If the information field is left blank).

Coltun, Heinanen                                                  [Page 19]

8.1.2 Modifications To The Inter-Area Route Calculation

     The following describes associations currently being used by the enhancements shortcut are
          not the closest ones to OSPF sections 16.2, 16.3,
     16.5 which calculate inter-area routes. Before the destination associ-
     ated with target network but are on the LSA is added path to
          the routing table target network the following is per-
     formed. shortcut may remain.

          o If the LSA is a Type-3 Summary LSA, lookup associations currently being used by the entry in shortcut are
          not on the ARA
          Association Table. This entry's Vertex Type will be 3, path to the Vertex
          Identifier will be target network, forwarding must cease on
          the Summary LSA's network shortcut and mask, the Vertex
          Originator will shortcut must be terminated.

10.0 Receiving ARAs

     After the advertising router's Router ID and its
          area ID will be ARA has been processed according to Section 13 of [OSPF] the one that is associated
     ARA has been determined to be 1) a new ARA, 2) a newer instance of an
     existing ARA with the shortest-path
          calculation.  If same contents, 3) a newer instance with dif-
     ferent contents, or 4) an active entry ARA that is found copy the entry's active
          association information into the routing table entry's link-layer
          association field.

          o being withdrawn by it's origina-
     tor.  If the LSA ARA is a Type-4 Summary LSA, lookup a type-4 new, the contents of the ARA in have changed or the
     ARA Association Table.  This entry's Vertex Type will be 4, is being withdrawn, the
          Vertex Identifier will following actions must be taken.

          o Lookup the Summary LSA's ASBR ID, the Vertex
          Originator will be entry for the advertising router's Router ID and its
          area ID will be ARA in the one that ARA Association Table.  If
          there is associated with no existing entry and the shortest-path
          calculation.  If ARA has determined to be new,
          create an active entry is in the ARA Association Table which contains the
          associations found copy in the entry's active
          association information into ARA.  The newly added associations
          should reflect the routing table entry's link-layer
          association field. state of the ARA's P-bit.

          o If the there is an active existing entry was not and the newly received ARA
          contents have changed modify the entry to reflect the associa-
          tions found for in the type-3 or type-4 LSA,
          locate newly received ARA.  The changed associations
          should reflect the area border router (ABR) that originated state of the adver-
          tisement. ARA's P-bit.

          o If link-layer association information is available for the ABR ARA is being withdrawn and there is an existing entry, copy
          remove the contents of associations from the ABR's link-layer associa-
          tion information field into entry that were pre-
          viously included in the routing table entry's link-layer
          association field. ARA. If no active entry was found for the ABR contents of the
          routing table entry's information field will entry
          is now empty remove the entry from the table.

     If the above process has resulted in a modification to the ARA table,
     the SPF calculation must be left blank.

8.1.3 Modifications To The AS External Route Calculation

     The following describes rescheduled (see Section 8.1 entitled
     "Adding ARA Routing Table Extensions").  If the enhancements receiving router is an
     ABR the inter-area origination process must be scheduled to OSPF sections 16.4 and
     16.6 which calculate AS external routes. Before be run
     following the destination asso-
     ciated with SPF calculation (see Section 8.1 entitled "Originating
     Inter-area ARAs").

11.0 Additional Data Structures And APIs

     This section lists the LSA is added additional data structures and APIs needed to
     support the routing table the following is
     performed. OSPF ARA option.

          o If The implementation must support the Opaque LSA has a forwarding address, look up the forward
          address option as
          defined in [OPAQ].

          o A configuration knob to enable the routing table (this will be an internal OSPF
          route).  Copy ARA option.

          o A router implementing the contents ARA option maintains a table of the route's
          link-layer association
          information field into associations for each of its OSPF areas.  The ARA
          Association Table is used in calculating the external route's ARA routing table entry's
          link-layer association field.  The forwarding address' link-layer

Coltun, Heinanen                                                  [Page 20]
          association information may have been added as a result of pro-
          cessing intra-area or
          extensions and in the inter-area N-ARAs.

          o If ARA origination process.  The
          indexes for an entry in this table are the LSA does not have a forwarding address, copy Vertex Type, Vertex
          ID and the con-
          tents of Vertex Originator.  The Vertex Type identifies the advertising ASBR's link-layer association informa-
          tion field into
          type of IP topology element that the routing table entry's link-layer association
          field.  The ASBR's link-layer association information may have
          been added as
          is being associated with (i.e., a result of processing intra-area router or inter-area R-
          ARAs.

9.0 Receiving ARAs

     After the ARA has been processed according to section 13 of [OSPF] the
     ARA has been determined to be 1) a new ARA, 2) network).  The Ver-
          tex ID identifies a newer instance piece of an
     existing ARA with the same contents, 3) a newer instance with dif-
     ferent contents, specific OSPF network's topology
          (i.e., a router ID or 4) an ARA that is being withdrawn by it's origina-
     tor.  Actions need to be taken if the ARA IP network number).  The Vertex Origina-
          tor is new, the contents originator of the
     ARA have changed ARA's router ID.  Entries in this
          table may be either active or non-active.  Active entries are
          ones whose Logical Network IDs match one of the ARA is being withdrawn. router's config-
          ured (and currently active) Logical Network IDs.

          o Lookup Transit vertex data structures and the entry for internal representation
          of Type-3, Type-4 and Type-5 LSAs are extended to contain a
          reference to the ARA an entry in the ARA Association Table.  If
          there

          o The routing table is no existing entry, create one which contains extended to contain a reference to the associ-
          ations found an
          entry in the ARA.  The newly added associations should
          reflect the state of the ARA's P-bit. ARA Association Table.

          o If the there is To be able to flood ARA information to other ARA capable
          routers an existing entry and implementation must provide an API which allows the newly received
          ARA
          contents user application to have changed modify its local OSPF entity distribute
          resolution information in ARA format (if the entry scope is area-local,
          a reference to reflect the associa-
          tions found in area must also be supplied).  Additionally,
          the newly received ARA.  The changed API must allow for associations
          should reflect the state of the ARA's P-bit.

          o If the ARA is being to be withdrawn when they are
          no longer valid and there is an existing entry,
          remove the for new versions of associations from the link-layer entry that were pre-
          viously included in the ARA. If to be ori-
          ginated when association information has changed.

          o A router running the contents ARA option may be configured with a list
          of the table entry logical network IDs. This list is now empty remove the entry from used when the table.

     If router calcu-
          lates the above process has resulted in a modification link-layer associations for its routing table and when
          receiving ARAs to determine the change in active status for its
          ARA table,
     the SPF calculation must be rescheduled.  (see section 8.1 entitled
     "Adding ARA Routing Association Table Extensions").  If entries.  Status information is kept for
          each of the receiving router's attached logical network so that a router
          can determine which logical networks are active at a given point
          in time.  To insure that ARA reachability is an
     ABR up-to-date, a change
          in status of one of the inter-area origination process router's connected logical networks must be scheduled to be run
     following
          result in the SPF calculation (see section 7.1 entitled "Originating
     Inter-area ARAs").

10.0 Additional Data Structures And APIs

Coltun, Heinanen                                                  [Page 21]
     This section lists being rerun.

          The absence of entries in the additional data structures and APIs needed to
     support router's list of Logical Network
          IDs means that the OSPF router will only activate ARA option.

          o The implementation must support Association
          Table entries with the Opaque LSA option as
          defined in [OPAQ].

          o default Logical Network ID which is Logi-
          cal Network ID 0.

          A configuration flag router may originate ARAs with Logical Network IDs that are not
          contained in its list of Logical Network IDs. This may be used,
          for example, to enable the OSPF ARA option.

          o A router implementing the ARA option maintains shortcuts to be set up from any router to
          any server but to disable shortcuts from being set up between
          routers that are not associated with a table of
          link-layer associations for each server.

12.0 Security Considerations

     There are two types of its OSPF areas.  The ARA
          Association Table is used in calculating the ARA issues that need be addressed when looking at
     protecting routing table
          extensions protocols from misconfigurations and in the inter-area ARA origination process. malicious
     attacks.  The
          indexes for an entry in this table entry are the Vertex Type,
          Vertex ID first is authentication and the Vertex Originator. certification of routing
     protocol information.  The Vertex Type identifies
          the type second is denial of service attacks result-
     ing from repetitive origination of IP topology element that the link-layer information
          is being associated with (i.e., a same router advertisement or
     origination a network).  The Ver-
          tex ID identifies a piece large number of distinct advertisements resulting in
     database overflow.  Note that both of these concerns exist indepen-
     dently of a specific OSPF network's topology
          (i.e., a router ID or an IP network number).  The Vertex Origina-
          tor is router's support for the originator of ARA option.

     To address the ARA's router ID.  Entries in this
          table authentication concerns, OSPF protocol exchanges may be either active or non-active.  Active entries are
          ones whose Logical Network IDs match one
     authenticated.  OSPF supports multiple types of authentication; the router's config-
          ured (and currently active) Logical Network IDs.

          o Transit vertex data structures and the internal representation
     type of Type-3, Type-4 and Type-5 LSAs are extended authentication in use can be configured on a per network seg-
     ment basis. One of OSPF's authentication types, namely the Crypto-
     graphic authentication option, is believed to contain be secure against pas-
     sive attacks and provide significant protection against active
     attacks. When using the Cryptographic authentication option, each
     router appends a
          reference "message digest" to its transmitted OSPF packets.
     Receivers then use the shared secret key and received digest to verify
     that each received OSPF packet is authentic.

     The quality of the security provided by the Cryptographic authentica-
     tion option depends completely on the an entry in strength of the ARA Association Table.

          o The routing table message digest
     algorithm (MD5 is extended to contain a reference to currently the an
          entry only message digest algorithm speci-
     fied), the strength of the key being used, and the correct implementa-
     tion of the security mechanism in all communicating OSPF implementa-
     tions. It also requires that all parties maintain the ARA Association Table.

          o To be able to flood ARA information to other ARA capable
          routers an implementation must provide an API which allows secrecy of the
          ARA user application to have its local
     shared secret key.  None of the standard OSPF entity distribute
          resolution authentication types
     provide confidentiality. Nor do they protect against traffic analysis.
     For more information in ARA format (if on the scope is area-local,
          a reference to standard OSPF security mechanisms, see
     Sections 8.1, 8.2, and Appendix D of [OSPF].

     [DIGI] describes the area must extensions to OSPF required to add digital
     signature authentication to Link State data and to provide a certifi-
     cation mechanism for router data.  [DIGI] also be supplied).  Additionally, describes the API must allow for associations to be withdrawn when they are
          no longer valid added LSA
     processing and key management as well as a method for migration from,
     or co-existence with, standard OSPF V2.

     Repetitive origination of advertisements are addressed by OSPF by man-
     dating a limit on the frequency that new versions instances of associations to any particular
     LSA can be ori-
          ginated when association information has changed.

          o A router running originated and accepted during the ARA option flooding procedure.  The
     frequency at which new LSA instances may be configured with a list
          of logical network IDs. This list originated is used when the router calcu-
          lates the link-layer associations for its routing table and when
          receiving ARAs set equal to determine the change in active status for its
          ARA Association Table entries.  Status information
     once every MinLSInterval seconds, whose value is kept for
          each 5 seconds (see Sec-
     tion 12.4 of the router's attached logical network so that a router
          can determine [OSPF]).  The frequency at which logical networks new LSA instances are active at a given point
          in time.  To insure that ARA reachability
     accepted during flooding is up-to-date, a change
          in status of one once every MinLSArrival seconds, whose
     value is set to 1 (see Section 13, Appendix B and G.5 of the router's connected logical networks must

Coltun, Heinanen                                                  [Page 22]
          result in the SPF calculation being rerun.

          The absence [OSPF]).

     Proper operation of entries in the router's list of Logical Network
          IDs means OSPF protocol requires that all OSPF routers
     maintain an identical copy of the router will only activate ARA Association
          Table entries with OSPF link-state database.  However,
     when the default Logical Network ID which is Logi-
          cal Network ID 0.

          A router may originate ARAs with Logical Network IDs that are not
          contained in its list size of Logical Network IDs. This the link-state database becomes very large, some
     routers may be used,
          for example, to enable shortcuts to be set up from any router unable to
          any server but keep the entire database due to disable shortcuts from being set up between resource
     shortages; we term this "database overflow".  When database overflow
     is anticipated, the routers that are not associated with a server. limited resources can be accommodated
     by configuring OSPF stub areas and NSSAs.  [OVERFLOW] details a way of
     gracefully handling unanticipated database overflows.

Appendix A: ARA Packet Formats

     This document defines four different types of Address Resolution
     Advertisements. Each type of ARA begins with a standard 20-byte Opaque
     LSA header [OPAQ]. This header is described in section A.1. Subsequent
     sections describe the specific advertisements and their content
     including the formats of the resolution information.  An ARA capable
     router may use the ARAs to build shortcut paths to other ARA capable
     routers.

     Each ARA describes a link-layer association for a piece of the OSPF
     routing domain. Any router may originate intra-area router and network
     ARAs.  These ARAs advertise address resolution information for routers
     and networks within the local area and are advertised locally (they
     have an area-local scope).

     Area border routers may originate inter-area network and router ARAs.
     These ARAs advertise address resolution to areas that are beyond the
     source local area. Inter-area network and router ARAs correspond to LS
     Type-3 and LS Type-4 advertisements.

A.1 The ARA Header
     All ARAs begin with a common 20-byte header. This header contains
     enough information to uniquely identify the ARA.  The header, which is
     a subset of the standard LSA header, includes the ARA Vertex Type and
     distribution scope.  The Vertex Type is derived from the Opaque Type
     field; the distribution scope is derived from the LS type field. ARAs
     have an area-local scope (LS Type = 10).

     The Vertex Identifier for an intra-area Router ARA is the advertising
     router field of the ARA header; for inter-area Router ARAs the vertex

Coltun, Heinanen                                                  [Page 23]
     is identified by the advertising router field and the ASBR Router ID
     field which is in the body of the advertisement.

     The Vertex Identifier for both intra and inter-area Network ARAs is
     contained in the network and mask field (which is in the body of the
     advertisement).  A N-ARA may only identify a single network (i.e.,
     lists of networks are not permitted).

     ARAs make use of the P-bit in the same as the NSSA option [NSSA].
     That is, ARAs may not be advertised beyond area borders unless the P-
     bit is set in the original intra-area ARA.  See the section entitled
     "Originating Inter-Area ARAs" for a further discussion on this topic.

     All of a router's associations for a specific vertex may be described
     in a single ARA or they may distributed over several ARAs.  That is, a
     router may originate multiple (N or R) ARAs each containing different
     associations or may originate a single (N or R) ARA containing a list
     of associations.

        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   |   LS Type     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Opaque Type   |               Opaque ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Advertising Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      LS Sequence Number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          LS age
               The time in seconds since the ARA was originated.

          Options
               The optional capabilities supported by the described portion
               of the routing domain. The ARA uses two option bits.

                    O-bit
                         This bit describes the router's willingness to

Coltun, Heinanen                                                  [Page 24]
                         receive and forward Opaque-LSAs as specified in
                         [OPAQ]. All routers supporting the ARA option as
                         described in this document support the Opaque
                         option.

                    P-Bit
                         ARAs make use of the P-Bit in a manner consistent
                         with [NSSA].  An ARA may not be advertised beyond
                         an area border unless the P-bit is set in the ori-
                         ginal intra-area ARA.

               The remainder of OSPF's optional capabilities are documented
               in Section A.2 of [OSPF].

          LS Type
               The type of the LSA. Each LSA type has a separate advertise-
               ment format. The ARA LSA as defined in this document are LS
               Type-10 advertisements (they all have an intra-area scope).

          Opaque Type
               The link-state ID of the Opaque LSA is divided into an
               Opaque Type field (the first 8 bits) and an Opaque ID (the
               remaining 24 bits).  The Address Resolution Advertisements
               are Opaque-types 1 - 4.  The Opaque Type field identifies
               the Vertex Type.

               Opaque Type-1 advertisements are intra-area Router Address
               Resolution Advertisements and contain link-layer associa-
               tions for the advertising router.  These ARAs are advertised
               throughout the local area.

               Opaque Type-2 advertisements are intra-area Network Address
               Resolution Advertisements and contain link-layer associa-
               tions for a router's directly connected IP networks (or
               hosts).  These ARAs are advertised throughout the local
               area.

               Opaque Type-3 advertisements are inter-area Network Address
               Resolution Advertisements and contain link-layer associa-
               tions
               associations for IP networks that reside in other areas.  Inter-
               area
               Inter-area N-ARAs are coordinated with inter-area network
               (LS Type-3) advertisements.

               Opaque-type 4 advertisement are inter-area Router Address
               Resolution Advertisements and contain link-layer associa-
               tions for ASBR that reside in other areas.  Inter-area R-
               ARAs are coordinated with inter-area ASBR (LS Type-4) adver-
               tisements.

Coltun, Heinanen                                                  [Page 25]

          Opaque ID
               A 24-bit semantic-less LSA identifier which serves to dif-
               ferentiate between multiple LSAs originated by the same
               router.  The Opaque ID must be unique for an advertising
               router within the advertising scope of the LSA.

          Advertising Router
               The Router ID of the router that originated the ARA.  For
               intra-area R-ARAs the Advertising Router also serves as the
               ARA Vertex Identifier.

          LS Sequence Number
               Detects old or duplicate ARAs.  Successive instances of an
               ARA are given successive LS sequence numbers.  See Section
               12.1.6 of [OSPF] for more details.

          LS Checksum
               The Fletcher checksum of the complete contents of the ARA,
               including the ARA header but excluding the LS age field. See
               Section 12.1.7 of [OSPF] for more details.

          Length
               The length in bytes of the ARA.  This includes the 20 byte
               ARA header.

A.2 Intra-Area Router ARAs

     Opaque Type-1 advertisements are intra-area Router Address Resolution
     Advertisements and contain associations for the advertising router.

     If the originating router is an ASBR and wishes to have the contents
     of the R-ARA distributed beyond the local area (i.e., translated into
     an inter-area R-ARA), the R-ARA must have the P-bit set in its Options
     field.

        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   |       10      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       1       |               Opaque ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Coltun, Heinanen                                                  [Page 26]
       |                      Advertising Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      LS Sequence Number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-+                   Vertex Association                      +-+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-+                   Vertex Association                      +-+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     The body of the R-ARA consists of a list of associations for the
     advertising router.  Each Vertex Association begins with a common 6-
     byte header (described in Section A.6) followed by association-
     specific resolution information (described in Section A.7).

A.3 Intra-Area Network ARAs

     Opaque Type-2 advertisements are intra-area Network Address Resolution
     Advertisements and contain associations for one of the advertising
     router's directly connected IP networks (or hosts).

     If the originating router is wishes the contents of the N-ARA are to
     be distributed beyond the local area (i.e., translated into an inter-
     area N-ARA) the N-ARA must have the P-bit set in its Options field.

        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   |      10       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       2       |               Opaque ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Advertising Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      LS Sequence Number                       |

Coltun, Heinanen                                                  [Page 27]
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      IP Network Number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      IP Network Mask                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-+                   Vertex Association                      +-+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-+                   Vertex Association                      +++
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          IP Network Number
               One of the router's directly connect network.  This number
               represents an IP network/subnet/supernet.

          IP Network Mask
               A 32-bit number indicating the range of IP addresses resid-
               ing on a single IP network/subnet/supernet.

     The body of the N-ARA consists of a list of associations for this IP
     Network Number.  Each Vertex Association begins with a common 6-byte
     header (described in Section A.6) followed by association-specific
     resolution information (described in Section A.7).

A.4 Inter-Area Network ARAs

     Opaque Type-3 advertisements are inter-area Network Address Resolution
     Advertisements and contain associations for a remote area's IP net-
     works
     networks (or hosts).  Inter-area N-ARAs are coordinated with LS type-3
     advertisements.

     Inter-area network ARAs are originated by an area border router into a
     target area if 1) the ABR originates a type-3 LSA for the network into
     the target area, 2) the network is not included in any of the area
     border router's configured area ranges, 3) there is an N-ARA for the

Coltun, Heinanen                                                  [Page 28]
     network in the source area and 4) the source N-ARA is an intra-area
     N-ARA with a P-bit set in the options field (which denotes that the
     originator of the N-ARA will allow the N-ARA to be propagated into
     other areas) or the source N-ARA is an inter-area N-ARA.

        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   |      10       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       3       |               Opaque ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Advertising Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      LS Sequence Number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      IP Network Number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      IP Network Mask                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-+                   Vertex Association                      +-+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-+                   Vertex Association                      +++
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          IP Network Number
               One of the router's directly connect network.  This number
               represents an IP network/subnet/supernet.

          IP Network Mask
               A 32-bit number indicating the range of IP addresses resid-
               ing on a single IP network/subnet/supernet.

     The body of the N-ARA consists of a list of associations for this IP

Coltun, Heinanen                                                  [Page 29]
     Network Number.  Each Vertex Association begins with a common 6-byte
     header (described in Section A.6) followed by association-specific
     resolution information (described in Section A.7).

A.5 Inter-Area Router ARAs

     Opaque Type-4 advertisements are inter-area Router Address Resolution
     Advertisements and contain associations for the an autonomous system
     boundary router.  Inter-area R-ARAs are coordinated with LS type-4
     advertisements.

     Inter-area router ARAs are originated into a target area if 1) the ABR
     originates a type-4 LSA for the ASBR into the target area, 2) there is
     a R-ARA for the ASBR in the source area and 3) the source R-ARA is an
     intra-area R-ARA with a P-bit set in the options field (which denotes
     that the originator of the R-ARA will allow the R-ARA to be propagated
     into other areas) or the source R-ARA is an inter-area R-ARA.

        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   |       10      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       4       |               Opaque ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Advertising Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      LS Sequence Number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       ASBR Router ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-+                   Vertex Association                      +-+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-+                   Vertex Association                      +-+
       |                                                               |

Coltun, Heinanen                                                  [Page 30]
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          ASBR Router ID
               The router ID of the ASBR being advertised. This field
               corresponds to the link-state ID of the LS type-4 advertise-
               ment.

     The body of the inter-area R-ARA consists of a list of associations
     for the advertising router.  Each Vertex Association begins with a
     common 6-byte header (described in Section A.6) followed by
     association-specific resolution information (described in Section
     A.7).

A.6 Vertex Association

     The Vertex Association field consists of the link service type,
     IntServ service name, administrative weight, association length, logi-
     cal network ID followed by the association-specific resolution infor-
     mation.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Link Svc Type |  IS Svc Name  | Admin Weight  | Assoc Length  +
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Logical Network ID      |     Resolution Information    +
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       + Remaining Octets of Resolution Information padded to 32-bits  +
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Link Svc Type
               Identifies the link-layer functionality for this associa-
               tion.  Link Service Types 1, 2 and 3 are defined by this
               specification.  All other Link Service Types are reserved

Coltun, Heinanen                                                  [Page 31]
               for definition by the IANA (iana@isi.edu). The current list
               of Link Service Types is described below in Table 1.

                  Link Service Type       Description
                  -------------------------------------------------
                  1                       ATM Point-To-Point
                  2                       ATM MultiPoint-To-Point
                  3                       ATM Point-To-MultiPoint

                                  Table 1

          IS Svc Name
               The IntServ Service Name. Refer to [IS] as a reference for
               the IETF defined service specifications.

          Admin Weight
               When more than one equivalent association has been adver-
               tised for a specific vertex, this field is used to denote
               the advertising router's preference for each association.
               Equivalent associations are ones that have identical Link
               Service Type, IS Svc Name and Logical Network Identifier
               fields.

          Assoc Length
               The length in bytes of this association.

          Logical Network ID
               When more than one overlay network is used to establish
               shortcut paths within the OSPF domain, this number identi-
               fies a specific logical network.  This function may also be
               used to support a variation of closed user groups so that
               shortcuts are limited to those routers that are configured
               to be in the same logical network.  To use the association
               information, a router must have an active attachment to the
               specific logical network identified in the resolution infor-
               mation.  An ARA capable router is configured with a list of
               Logical Network IDs.  The default value (i.e., only one
               overlay network or too lazy to care) for the ID is 0.

          Resolution Information
               The resolution information field includes link-layer and
               service-type specific information.  The contents of this
               field is defined in section A.7 of this document.  The Ver-
               tex Association may include several resolution information

Coltun, Heinanen                                                  [Page 32]
               items.

A.7 Resolution Information

     The resolution information field is an extensible field that includes
     link-layer and service-type specific information.

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Res Type   |   Res Length  |       Resolution Value        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   remaining octets of  Resolution Value padded to 32-bits     |
       |                            ...                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Res Type
               Identifies the resolution being advertised.  Resolution
               Types 1 and 2 are defined by this specification.  Resolution
               Type 1 is defined in A.7.1, Type 2 is defined in A.7.2.  All
               other resolution types are reserved for definition by the
               IANA (iana@isi.edu). The current list of resolution types is
               described below in Table 2.

                  Resolution Type         Description
                  -------------------------------------------------
                  1                       ATM Address
                  2                       ATM LIJ Call Identification

                                  Table 2

          Res Length
               The total length in octets of this resolution information
               field This value includes the Res Type and Res Length
               fields.

          Resolution Value

Coltun, Heinanen                                                  [Page 33]
               The resolution type-specific data.

A.7.1 ATM Address

     An ATM address is the Resolution Type 1.  This includes the type and
     length of ATM number (8 bits), the type and length of ATM subaddress
     (8 bits), the ATM number (x octets) and possibly the ATM subaddress (y
     octets).

                 8   7   6   5   4   3   2   1
               +---+---+---+---+---+---+---+---+
               |  Type And Len Of ATM Number   |
               +---+---+---+---+---+---+---+---+
               |  Type And Len Of ATM Subaddr  |
               +-----+-----+-----+-----+-----+-----+-----+-----+
               |  ATM Number...
               +-----+-----+-----+-----+-----+-----+-----+-----+
               |  ATM Subaddress...
               +-----+-----+-----+-----+-----+-----+-----+-----+

                             Format Of The ATM Address

     The Type and Length field of ATM number and ATM subaddress are encoded
     as follows.

            MSB   8     7     6     5     4     3     2     1   LSB
               +-----+-----+-----+-----+-----+-----+-----+-----+
               |  0  | 1/0 |   Octet length of address         |
               +-----+-----+-----+-----+-----+-----+-----+-----+

     Where:

             Bit(s)                  Description
             -------------------------------------------------
             8                       Reserved = 0  (for future use)
             7                       Type = 0  ATM Forum NSAPA format
                                          = 1  E.164 format
             6-1                     Length = 6 bit unsigned octet length of
                                     address (MSB = bit.6, LSB = bit.1).
                                     Value range is from 0 to 20 (decimal).

Coltun, Heinanen                                                  [Page 34]

     A non-existing ATM subaddress is indicated by setting the subaddress
     length to zero.  If the subaddress length is zero, the corresponding
     type field MUST be ignored and the ATM subaddress field MUST NOT con-
     sume any octets in the packet.

     The ATM number and ATM subaddress fields are encoded as defined by the
     ATM Forum UNI 3.1 [AF1] signalling specification.

A.7.2  ATM LIJ Call Identification

     An ATM LIJ Call Identification is the Resolution Type 2.  This
     includes an ATM address as defined in A.7.1 followed by a four octet
     Leaf Initiated Join Call Identifier Value, which together uniquely
     identify an ATM Point-To-Multipoint or Multipoint-To-Point call at a
     root's interface.

             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
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |              ATM Address as defined in A.7.1                  +
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |                                                               |
            +              Remaining Octets of ATM Address                  +
            |                              ...                              |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |          Leaf Initiated Join Call Identifier Value            |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Format Of LIJ Call Identification

     The Leaf Initiated Join Call Identifier Value is encoded as defined in
     Section 6.1.2.1 of the ATM Forum UNI 4.0 [AF2] signalling specifica-
     tion.

References

    [AF1] ATM Forum, "ATM User-Network Interface (UNI) Specification
    Version 3.1.", ISBN 0-13-393828-X, Prentice-Hall, Inc., Upper

Coltun, Heinanen                                                  [Page 35]
    Saddle River, NJ, 07458, September, 1994.

    [AF2] ATM Forum, "ATM User-Network Interface (UNI) Signalling
    Specification", July 1996.

    [DIGI] S. Murphy, M. Badger, B. Wellington, "OSPF with Digital
    Signatures", RFC 2154, Trusted Information Systems, June 1997.

    [HEIN] Heinanen, J., "Intra-area IP unicast among routers over legacy ATM",
    Internet Draft, July 1997, <draft-ietf-ion-intra-area-unicast-00.txt>

    [IS] S. Shenker and J. Wroclawski. "Network Element QoS Control
    Service Specification Template". Internet Draft, July 1996, <draft-
    ietf-intserv-svc-template-03.txt>

    [OPAQ] Coltun, R., "The OSPF Opaque LSA Option", Internet Draft
        May 1997, <draft-ietf-ospf-opaque-01.txt>

    [OSPF] Moy, J., "OSPF Version 2", RFC 2178, July 1997

    [NHRP]  Luciani, J., Katz, D., Piscitello, D., Cole, B., "NBMA
    Next-Hop Resolution Protocol", Internet Draft, March 1997,
        <draft-ietf-rolc-nhrp-11.txt>
    <draft-ietf-rolc-nhrp-15.txt>

    [NSSA] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587,
    RainbowBridge Communications, Stanford University, March 1994.

    [OPAQ] Coltun, R., "The OSPF Opaque LSA Option", Internet Draft
    May 1997, <draft-ietf-ospf-opaque-04.txt>

    [OSPF] Moy, J., "OSPF Version 2", RFC 2178, July 1997

    [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765,
    Cascade, March 1995.