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

Versions: 00 01 02

Internet-Draft                      ARA                         August 1997


Expiration Date: February 1998
File name: draft-ietf-ospf-ara-00.txt












               The OSPF Address Resolution Advertisement Option






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


                               Juha Heinanen
                              Telecom Finland
                             +358 400 500 958
                                jh@tele.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".



Coltun, Heinanen                                                   [Page 1]


Internet-Draft                      ARA                         August 1997


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


Internet-Draft                      ARA                         August 1997


     Table Of Contents

          1.0 Abstract ................................................. 5

          2.0 Overview ................................................. 5

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

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

          4.0 ARA Associations ......................................... 7

          5.0 Examples ................................................. 8

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

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

          6.0 Description Of ARA Packet Formats ........................ 10

          6.1 Vertex Types And Vertex Identifiers ...................... 11

          7.0 Distribution Of ARA Information .......................... 11

          8.0 ARA Routing Table Extensions ............................. 13

          8.1 Adding ARA Routing Table Extensions ...................... 13

          8.1.1 Modifications To The Intra-Area Route Calculation ...... 14

          8.1.2 Modifications To The Inter-Area Route Calculations ..... 15

          8.1.3 Modifications To The AS External Route Calculations .... 15

          9.0 Receiving ARAs ........................................... 16

          10.0 Additional Data Structures And APIs ..................... 17

          Appendix A: ARA Data Formats ................................. 17

          A.1 ARA Formats .............................................. 17

          A.1.1 The ARA Header ......................................... 18

          A.1.2 Router ARAs ............................................ 20

          A.1.3 Network ARAs ........................................... 20




Coltun, Heinanen                                                   [Page 3]


Internet-Draft                      ARA                         August 1997


          A.1.4 Vertex Association ..................................... 22

          A.1.5 Resolution Information ................................. 23

          A.1.6 ATM Address ............................................ 24

          References ................................................... 26












































Coltun, Heinanen                                                   [Page 4]


Internet-Draft                      ARA                         August 1997


1.0  Abstract

     This document defines an OSPF option which enables routers to distri-
     bute IP to link-layer address resolution information.  An OSPF Address
     Resolution Advertisement (ARA) may include link-layer specific func-
     tionality such as a multipoint-to-point connection identifier along
     with the address resolution information.  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 and cut-through data switch-
     ing (bypassing router intervention).  Before the ingress devices is
     able to 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
     discovery 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 router-to-router and router-to-network inter-subnet
     shortcuts.  The ARA option supports both topology-derived and data-
     driven shortcuts architectures with simple extensions to OSPF.  Dis-
     tribution of address resolution information is performed using stan-
     dard OSPF flooding mechanisms.  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 support the follow-
     ing operations.


          Shortcuts between core or access routers within ISP Backbones.

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

          Distributed router architectures.

          Interoperation with ION NHRP and MPOA.

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


2.1 Acknowledgments



Coltun, Heinanen                                                   [Page 5]


Internet-Draft                      ARA                         August 1997


     The author would like to thank Lou Berger, John Moy and Yiqun Cai, and
     the rest of the OSPF Working Group for the ideas and support they have
     given to this project.


3.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 returned address may be the address of the requested host system
     or the address of a router which is on the path to the destination.
     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 limi-
     tation may be over restrictive).

     o The target of a request may be a host or network addresses (exclud-
     ing 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.  Participation in the



Coltun, Heinanen                                                   [Page 6]


Internet-Draft                      ARA                         August 1997


     ARA option is discovered through 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 will 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 an OSPF area.  Inter-area shortcuts are sup-
     ported 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 run-
     ning NHRP.

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


4.0 ARA Associations

     The ARA option defines three types of advertisements.  These include
     1) intra-area router associations, 2) intra-area network associations,
     and 3) inter-area ASBR associations.  Associations correspond to a
     piece of the OSPF topology.  Intra-area router associations correspond
     to link-layer reachability of a router within the local area, intra-
     area network associations correspond to link-layer reachability of a
     router's directly connected networks (also within the local area), and
     inter-area ASBR associations correspond to ASBRs that may be in the
     local or in a remote area.  An ingress router can use these associa-
     tions as follows.

          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 the router
          including ones that are in the local area, in a remote area or
          external to the autonomous system.  A destination that is "beyond



Coltun, Heinanen                                                   [Page 7]


Internet-Draft                      ARA                         August 1997


          the router" is determined by the OSPF topology map.

          Intra-area network associations (which may advertise a host, net-
          work or IP multicast address) are used to setup a shortcuts to
          systems whose address fall within the range of the advertised
          network.

          Inter-area ASBR associations are used to setup shortcuts to ASBRs
          that are in the local or remote area.  These shortcuts are used
          to send data to destinations that are external to the autonomous
          system and reachable via the ASBR.

     The ARA option maintains a list of all association for a specific ver-
     tex and vertex type in an ARA Association Table.  The lookup keys to
     an entry in the table include the vertex type, vertex ID and, if the
     scope is area-local, the area ID.

     Associations are added to the routing table during the OSPF routing
     table calculation (see the section entitled Adding ARA Routing Table
     Extensions below).  So, in addition to the standard information fields
     contained in the routing table (i.e., IP network number, IP mask,
     next-hop interface, etc.), the routing table is extended to contain
     link-layer associations (via a reference to the ARA Association
     Table).  The use of the extensions are ARA user application specific
     and beyond the scope of this document.  See [HEIN] for an example of
     an ARA user application.


5.0 Examples

5.1 Example 1: Intra-Area

     Consider the sample single-area topology in Figure 1 below.  In this
     example RT1, RT2 and RT5 support the ARA option (by definition they
     also support the Opaque LSA option) and RT4 supports the Opaque LSA
     option only (this is necessary so that RT4 redistributes the ARAs ori-
     ginated by RT1, RT2 and RT5).  RT2 and RT5 have each originated an ARA
     with an intra-area router association and RT5 has originated an ARA
     with an intra-area network association for N5.

     As a result of running the routing table calculation, RT1 would have
     entries for N1-N8 in its routing table.  The entry for N2 would refer-
     ence the link-layer associations distributed in RT2's R-ARA, the
     entries for N3, N4, N6, N7, N8 would reference the link-layer associa-
     tions distributed in RT5's R-ARA and the entry for N5 would reference
     the link-layer associations distributed in RT5's intra-area N-ARA.





Coltun, Heinanen                                                   [Page 8]


Internet-Draft                      ARA                         August 1997



                +   ARA
                |  +---+                   N3       N5
              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 the sample 2-area topology in Figure 2 below.  In this exam-
     ple RT1, RT2, RT3, RT4 and RT6 support the ARA option and RT5 supports
     the Opaque option.  N3-N7 are AS external routes and RT5 and RT6 are
     ASBRs.  RT4 is an area-border router and originates LS Type-4 LSAs on
     behalf of RT5 and RT6 and a LS Type-3 LSA for N8 into area 1.1.1.1.

     RT1, RT2, RT3 and RT4 have originated intra-area R-ARAs, and RT6 has
     originated an inter-area R-ARA.

     As a result of running the routing table calculation, RT1 would have
     entries for N1-N8 in its routing table.  The entry for N2 would refer-
     ence the link-layer associations distributed in RT3's R-ARA, the
     entries for N3, N4, N5 and N8 would reference the link-layer associa-
     tions distributed in RT4's intra-area R-ARA (i.e., R1 can't see link-
     layer information beyond the area border router) and the entries for
     N6 and N7 would reference the link-layer associations distributed in
     RT6's inter-area R-ARA.





Coltun, Heinanen                                                   [Page 9]


Internet-Draft                      ARA                         August 1997



                                    |
             +   ARA      ARA       |
             |  +---+    +---+      |      N3       N5
           N1|--|RT1|----|RT2|\     |        \ N4  /
             |  +---+    +---+ \    |         \ | /
             +                  \  ARA         \|/
                                 \+---+      +---+
                                  |RT4|------|RT5|
                                  +---+      +---+
                       +   ARA   /  |          |     N6
                       |  +---+ /   |          |    /
                     N2|--|RT3|/    |         ARA  /
                       |  +---+     |        +---+/
                       +            |        |RT6|----N7
                                    |        +---+
                                    |          |
                                    |          |
                                    |        +---+
                                    |        |RT7|
                                    |        +---+
                                    |          |
                                    |       +-----+
                                    |         N8
                                    |
                                    |
                                    |
                Area 1.1.1.1        |    OSPF Backbone
            ------------------------|-------------------------

                      Figure 2: Sample Area Toplogy



6.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 to be used when more than one vir-
     tual overlay network is present within the OSPF domain.

     The ARA format allows more than one equivalent association to been
     advertised by a router for a specific vertex.  The association can
     include a preference which identifies the advertising router's



Coltun, Heinanen                                                  [Page 10]


Internet-Draft                      ARA                         August 1997


     relative preference for the equivalent associations.  Equivalent asso-
     ciations are ones that have identical link service type, integrated
     service type and logical network identifier fields.

     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 of the information may be
     limited appropriately by the originator of the LSA.  Opaque LSAs have
     a sub-type which identifies the specific information that is carried
     within the LSA.  The ARA Opaque types are Opaque-type 1 and 2.  The
     flooding scope for specific vertex types is realized by embedding the
     association in the appropriate Opaque LSA type.

6.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 router address resolution associations.
     These associations are used to advertise the router's link-layer
     attachments.  A Vertex Type of 1 is identified by an Opaque type of 1.
     The vertex identifier for a Router ARA (R-ARA) is the advertising
     router field of the ARA header.  Intra-area vertex type-1 advertise-
     ments are included in Opaque Type-10 LSAs (their flooding scope is
     area-local).  Inter-area vertex type-1 advertisements are included in
     Opaque Type-11 LSAs (their flooding scope is domain-wide).  Inter-area
     vertex type-1 advertisements are originated by as AS boundary routers.

     Vertex type 2 ARAs advertise IP network address resolution associa-
     tions (the network may be a IP multicast (class D) network).  These
     associations are used to advertise the link-layer associations for a
     router's directly connected network.  Vertex Type 2 advertisements are
     be included in area-local (LS Type 10) advertisements.  A Vertex Type
     of 2 is identified by an Opaque type of 2.  The vertex identifier (the
     network and mask) for a Network ARA (N-ARA) is contained in the body
     of the advertisement.  A N-ARA may only identify a single network
     (i.e., lists of networks are not permitted).

     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.


7.0 Distribution Of ARA Information



Coltun, Heinanen                                                  [Page 11]


Internet-Draft                      ARA                         August 1997


     In general, OSPF is composed of two components.  It's transport com-
     ponent deals with adjacency formation and reliable distribution of
     topology information.  The second component tracks topology informa-
     tion changes and organizes the topology information that has gathered
     from other routers into to a topology map which 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 information. This information may be used
     directly by OSPF or by other protocols and mechanisms such as the ARA
     option.  Opaque LSAs use standard OSPF link-state database flooding
     mechanisms for distribution. Each of the three Opaque types (LS Types
     9, 10 and 11) have a scope associated with them so that distribution
     of the information throughout the OSPF topology may be limited if
     appropriate.  ARA information has topology-specific scopes (i.e., dif-
     ferent Opaque types) depending on the ARA vertex type (see the section
     entitled Vertex Types and Vertex Identifiers).

     The ARA option 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 routing table.  Validation is needed
     because topology information contained in the OSPF link-state database
     may be stale (i.e., the originator of the information is no longer
     reachable).

     It is envisioned that an implementor designs an ARA user application
     interface to 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) determining the validity (and
     change of validity) of ARA information.

     For the realization of 1 above, an implementation must provide an API
     which allows the ARA user application to have its local OSPF entity
     distribute resolution information in the ARA defined format (if the
     scope is area-local, the area must also be supplied).  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 document extends the rout-
     ing table to include the associations that have been advertised by the
     ARA capable routers.  (i.e,. the routing table provides the API for
     the ARA user application).  That is, in addition to the standard
     information fields contained in the routing table (i.e., IP network
     number, IP mask, next-hop interface, etc.), the routing table is
     extended to contain link-layer associations. The associations are



Coltun, Heinanen                                                  [Page 12]


Internet-Draft                      ARA                         August 1997


     added to the routing table during the OSPF routing table calculation
     (see the section on Adding ARA Routing Table Extensions below).  The
     use of the extensions are ARA user application specific and beyond the
     scope of this document.  See [HEIN] for an example of an ARA user
     application.

     The following section defines the mechanism to calculate the ARA rout-
     ing table extensions.




8.0 ARA Routing Table Extensions

     OSPF determines reachability and topology changes by performing the
     algorithms described in the section entitled "Calculation of the rout-
     ing table" (see section 16 of [OSPF]).  ARAs are included in this cal-
     culation 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 QoS service specific information.
     (See section Appendix A for a more complete description of the
     specific link-layer information distributed in ARAs).  The associa-
     tions that are bound to a routing table entry are the associations
     that are closest to the originator of the routing table's network
     entry. The closest associations are determined during to the construc-
     tion of the OSPF topology map.  The associations that are bound to the
     routing table entries are subsequently used by the ARA user applica-
     tion to setup shortcut paths.  Because a link-layer association may be
     bound to more than one entry in the routing table, an ARA implementa-
     tion keeps a table of ARA derived link-layer associations which is
     referenced by the routing table entry.  An entry in the ARA Associa-
     tion Table consists of a list of all association for a specific vertex
     and vertex type.  The lookup keys to an entry in the table include the
     vertex type, vertex ID and, if the scope is area-local, the area ID.


8.1 Adding ARA Routing Table Extensions

     Section 16 of the OSPF specification is modified for the purpose of
     adding the ARA routing table extensions.  Transit vertex data struc-
     tures and the internal representation of Type-3, Type-4 and Type-5
     LSAs are extended to be able to reference a list of link-layer associ-
     ations (i.e., they have a reference to the ARA Association Table).
     The vertex and LSA's list of link-layer associations are added to the
     routing table along with the entry.



Coltun, Heinanen                                                  [Page 13]


Internet-Draft                      ARA                         August 1997


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 the vertex that is about to be added to the SPF tree ver-
          tex M. If vertex M was originated by the calculating router skip
          this procedure.

          o If vertex M is a transit network vertex lookup the link-layer
          association entry in the ARA Association Table.  This entry's
          vertex type will be type-2, the vertex identifier will consist of
          a network and mask which are equivalent to those found in vertex
          M and its area ID will be the one that is associated with the
          shortest-path calculation.

          o If an entry is found reference this entry in vertex M's link-
          layer association field.

          o If vertex M is a router vertex lookup the an entry in the ARA
          Association Table.  This entry's vertex type will be type-1, the
          vertex identifier will be vertex M's advertising router and its
          area ID will be the one that is associated with the shortest-path
          calculation.

          o If an entry is found reference this entry in vertex M's link-
          layer association field.

          o If no link-layer association entries are found, and vertex M's
          parent vertex has link-layer association information, vertex M
          inherits it's parent vertex's information (else the information
          field is left blank).

          o When vertex M is added to the routing table, copy vertex M's
          link-layer association list into the routing table entry's link-
          layer association field.


     The following describes the enhancements to section 16.1 step 2 of
     [OSPF] which adds intra-area stub networks to the routing table.


          o Before adding the stub network to the routing table lookup the
          entry in the ARA Association Table.  This entry's vertex type
          will be type-2, the vertex identifier will consist of a network
          and mask which are equivalent to those found in the stub network
          and its area ID will be the one that is associated with the
          shortest-path calculation.



Coltun, Heinanen                                                  [Page 14]


Internet-Draft                      ARA                         August 1997


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

          o If an entry is not found and the stub network's advertising
          router vertex has link-layer association information, the routing
          table entry will use the advertising router's information (else
          the information field is left blank).


8.1.2 Modifications To The Inter-Area Route Calculations

     The following describes the enhancements to OSPF sections 16.2, 16.3,
     16.5 which calculate inter-area routes. Before the destination associ-
     ated with the LSA is added to the routing table the following is per-
     formed.


          o If the LSA is a Type-3 summary LSA, locate the area border
          router (ABR) that originated the advertisement. If link-layer
          association information is available for the ABR entry, copy the
          contents of the ABR's link-layer association information field
          into the routing table entry's link-layer association field.

          o If the LSA is a Type-4 summary LSA, lookup the entry in the ARA
          Association Table.  This entry's vertex type will be type-1, the
          vertex identifier will the Type-4's Link-State ID (the link-state
          ID identifies the ASBR) the area ID will not be used (the ARAs
          have domain-wide scope).

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

          o If an entry is not found locate the area border router (ABR)
          that originated the Type-4 advertisement.  Copy the contents of
          the ABR's link-layer association information field into the rout-
          ing table entry's link-layer association field.


8.1.3 Modifications To The AS External Route Calculations


     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 the routing table (this will be an internal OSPF



Coltun, Heinanen                                                  [Page 15]


Internet-Draft                      ARA                         August 1997


          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.

          o If the LSA does not have a forwarding address, copy the con-
          tents of the advertising ASBR's link-layer association informa-
          tion field into the routing table entry's link-layer association
          field. Note that the ASBR's association information may have been
          added from an intra-area or domain-wide 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 newer invocation of with the same
     contents, 2) a newer invocation with different contents, 3) a new ARA
     or 4) a newer invocation that is being flushed by the ARA's origina-
     tor.  Actions need to be taken if the ARA is new, the ARA is being
     purged or the contents of the ARA has changed.

          o Lookup the ARA's vertex in the ARA Association Table.  If the
          ARA is a LS Type-10, the table entry will reference the ARA's
          associated area. If the ARA is Type-11 the table entry will not
          be associated with an area.

          o If the ARA is new and there is an existing entry, add the asso-
          ciations found in the newly received ARA to the entry.  The ARA
          application must be informed that new associations have been
          added.

          o If there is no existing entry, create one which contains the
          associations found in the ARA.  Reschedule the SPF calculation.

          o If the ARA's contents have changed, modify the existing entry
          and inform the ARA application that there has been a change to
          the contents of the link-layer association entry for the speci-
          fied vertex.

          o If the ARA is being flushed and there is an existing entry,
          remove the associations from the link-layer entry that were
          included in the ARA. If the contents of the entry is now empty,
          remove the entry from the table and reschedule the SPF calcula-
          tion.  If the entry still contains associations inform the ARA
          user application that there has been a change to the contents of
          the entry.




Coltun, Heinanen                                                  [Page 16]


Internet-Draft                      ARA                         August 1997


10.0 Additional Data Structures And APIs

     This section lists the additional data structures and APIs needed to
     support the OSPF ARA option.

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

          o Configuration flag to enable the OSPF ARA option.

          o A ARA Association Table is added. An entry in this table con-
          tains the list of link-layer associations for a specific vertex
          and vertex type. The lookup keys to an entry in the table include
          the vertex type, vertex ID and, if the scope is area-local, the
          area ID.  The table is referenced by the routing table and the
          data structures used in the SPF calculation.

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

          o The routing table is extended to contain a reference to the an
          entry in 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 the
          ARA user application to have its local OSPF entity distribute
          resolution information in ARA format (if the scope is area-local,
          a reference to the area must also be supplied).  Additionally the
          API must be able to purge the associations that were previously
          distributed when they are no longer valid and send out new ver-
          sions when the associations information has changed.




A.1 ARA Formats

     This document defines three 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.1. Subse-
     quent sections describe the specific advertisements and their content
     (i.e., the formats of the resolution information).

     Each ARA describes a link-layer association for a piece of the OSPF
     routing domain. Any router may originate intra-area router ARAs and
     network ARAs. These ARAs are distributed throughout the local area.
     ASBRs may originate domain-wide router ARAs.  An ARA capable router



Coltun, Heinanen                                                  [Page 17]


Internet-Draft                      ARA                         August 1997


     may use the ARAs to build shortcut paths to other ARA capable routers.

A.1.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 vertex identifier for a Router ARA (R-ARA) is the advertising
     router field of the ARA header. The vertex identifier for a Network
     ARA (N-ARA) is contained in the body of the advertisement. A N-ARA may
     only identify a single network (i.e., lists of networks are not per-
     mitted).  A router may originate multiple (N or R) ARAs each contain-
     ing different associations or may originate a single (N or R) ARA con-
     taining 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. 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



Coltun, Heinanen                                                  [Page 18]


Internet-Draft                      ARA                         August 1997


               advertisement format.  The AR LSA as defined in this docu-
               ment may be Type-10 (for N-ARAs and R-ARAs with intra-area
               scope) or Type-11 (for ASBR R-ARA with inter-domain 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 and 2.  Opaque-type 1 advertisements are
               Router Address Resolution Advertisements and contain associ-
               ations for the advertising router.  R-ARAs may be encapsu-
               lated in type-10 (Opaque) LSAs when the associations are to
               be distributed within the area or encapsulated in type-11
               (Opaque) LSAs when the associations are to be coordinated
               with inter-area ASBR (LS Type-4) advertisements (i.e., the
               router is an ASBR).

               Opaque-type 2 advertisements area Network Address Resolution
               Advertisements and contain associations for one of the
               advertising router's directly connected IP networks (or
               hosts).  N-ARAs are encapsulated in LS Type-10 (Opaque) LSAs
               (i.e., their scope is area local).

          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
               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 is 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 LSA.  This includes the 20 byte
               ARA header.




Coltun, Heinanen                                                  [Page 19]


Internet-Draft                      ARA                         August 1997


A.1.2 Router ARAs

     Opaque-type 1 advertisements are Router Address Resolution Advertise-
     ments and contain associations for the advertising router.  R-ARAs may
     be encapsulated in LS Type-10 (Opaque) LSAs when the associations are
     to be distributed within the area or encapsulated in LS Type-11
     (Opaque) LSAs when the associations are to be coordinated with inter-
     area ASBR (LS Type-4) advertisements (i.e., the router is an ASBR).
     All of the router's associations may be described in a single R-LSA or
     they may distributed over several R-LSAs.




        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 or 11    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       1       |               Opaque ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      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.1.4) followed by association-
     specific resolution information (described in Section A.1.5).




A.1.3 Network ARAs




Coltun, Heinanen                                                  [Page 20]


Internet-Draft                      ARA                         August 1997


     Opaque-type 2 advertisements area Network Address Resolution Adver-
     tisements and contain associations for one of the advertising router's
     directly connected IP networks (or hosts).  N-ARAs are encapsulated in
     LS Type-10 (Opaque) LSAs (i.e., their scope is area local).




        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                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         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 21]


Internet-Draft                      ARA                         August 1997


     Network Number.  Each Vertex Association begins with a common 6-byte
     header (described in Section A.1.4) followed by association-specific
     resolution information (described in Section A.1.5).




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





Coltun, Heinanen                                                  [Page 22]


Internet-Draft                      ARA                         August 1997


                                  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 virtual overlay network is used to estab-
               lish shortcut paths within the OSPF domain, this number
               identifies a specific virtual overlay network.  The router
               must have an active attachment to the specific logical net-
               work to use the associated resolution information.  An ARA
               capable router is configured with a list of Logical Network
               IDs.  The default value (i.e., only one virtual overlay net-
               work 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.1.5 of this document.  The
               Vertex Association may include several resolution informa-
               tion items.


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



Coltun, Heinanen                                                  [Page 23]


Internet-Draft                      ARA                         August 1997


       |                            ...                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





          Res Type
               Identifies the resolution being advertised.  Resolution
               Types 1 and 2 are defined by this specification.  Resolution
               Type 1 is defined in A.1.6, Type 2 is defined in A.1.7.  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 Identifier



                                  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
               The resolution type-specific data.




A.1.6 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   |
               +---+---+---+---+---+---+---+---+



Coltun, Heinanen                                                  [Page 24]


Internet-Draft                      ARA                         August 1997


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


     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 [AF] signalling specification.




References





Coltun, Heinanen                                                  [Page 25]


Internet-Draft                      ARA                         August 1997


    [AF] ATM Forum, "ATM User-Network Interface (UNI) Specification
        Version 3.1.", ISBN 0-13-393828-X, Prentice-Hall, Inc., Upper
        Saddle River, NJ, 07458, September, 1994.

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































Coltun, Heinanen                                                  [Page 26]


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