GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5820

Internet Engineering Task Force (IETF) A. Roy, Ed. Request for Comments: 5820 Cisco Systems Category: Experimental M. Chandra, Ed. ISSN: 2070-1721 March 2010

       Extensions to OSPF to Support Mobile Ad Hoc Networking

Abstract

 This document describes extensions to OSPF to support mobile ad hoc
 networks (MANETs).  The extensions, called OSPF-OR (OSPF-Overlapping
 Relay), include mechanisms for link-local signaling (LLS), an OSPF-
 MANET interface, a simple technique to reduce the size of Hello
 packets by only transmitting incremental state changes, and a method
 for optimized flooding of routing updates.  OSPF-OR also provides a
 means to reduce unnecessary adjacencies to support larger MANETs.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for examination, experimental implementation, and
 evaluation.
 This document defines an Experimental Protocol for the Internet
 community.  This document is a product of the Internet Engineering
 Task Force (IETF).  It represents the consensus of the IETF
 community.  It has received public review and has been approved for
 publication by the Internet Engineering Steering Group (IESG).  Not
 all documents approved by the IESG are a candidate for any level of
 Internet Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5820.

Roy & Chandra Experimental [Page 1] RFC 5820 Extensions to OSPF to Support MANETs March 2010

Copyright Notice

 Copyright (c) 2010 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Roy & Chandra Experimental [Page 2] RFC 5820 Extensions to OSPF to Support MANETs March 2010

Table of Contents

 1. Introduction ....................................................4
    1.1. Problem Statement ..........................................4
    1.2. Motivation for Extending OSPF to Support MANETs ............5
 2. Requirements Notation ...........................................5
 3. Proposed Enhancements ...........................................5
    3.1. OSPF-MANET Interface .......................................7
         3.1.1. Interface Operation .................................8
         3.1.2. LSA Formats and Examples ............................8
    3.2. Incremental OSPF-MANET Hellos .............................12
         3.2.1. The I Option Bit ...................................12
         3.2.2. State Check Sequence TLV (SCS TLV) .................12
         3.2.3. Neighbor Drop TLV ..................................13
         3.2.4. Request From TLV (RF TLV) ..........................14
         3.2.5. Full State For TLV (FSF TLV) .......................14
         3.2.6. Neighbor Adjacencies ...............................15
         3.2.7. Sending Hellos .....................................16
         3.2.8. Receiving Hellos ...................................17
         3.2.9. Interoperability ...................................19
         3.2.10. Support for OSPF Graceful Restart .................19
    3.3. Optimized Flooding (Overlapping Relays) ...................20
         3.3.1. Operation Overview .................................20
         3.3.2. Determination of Overlapping Relays ................21
         3.3.3. Terminology ........................................21
         3.3.4. Overlapping Relay Discovery Process ................22
         3.3.5. The F Option Bit ...................................23
         3.3.6. Active Overlapping Relay TLV (AOR TLV) .............23
         3.3.7. Willingness TLV ....................................24
         3.3.8. Flooding and Relay Decisions .......................25
         3.3.9. Intelligent Transmission of Link State
                Acknowledgments ....................................26
         3.3.10. Important Timers ..................................27
         3.3.11. Miscellaneous Protocol Considerations .............28
         3.3.12. Interoperability ..................................28
    3.4. New Bits in LLS Type 1 Extended Options and Flags .........29
    3.5. Smart Peering .............................................29
         3.5.1. Rationale for Smart Peering ........................29
         3.5.2. Previous Related Work ..............................30
         3.5.3. Smart Peering Solution .............................30
         3.5.4. Advertising 2-Way Links in Router-LSAs .............33
 4. Security Considerations ........................................36
 5. IANA Considerations ............................................38
 6. Contributors ...................................................39
 7. Acknowledgments ................................................39
 8. References .....................................................39
    8.1. Normative References ......................................39
    8.2. Informative References ....................................40

Roy & Chandra Experimental [Page 3] RFC 5820 Extensions to OSPF to Support MANETs March 2010

1. Introduction

 Mobile ad hoc networks (MANETs) have been an area of study for some
 time within various working groups and areas within the IETF, various
 military branches, and various government agencies.  Recently,
 networks with mobile ad hoc requirements have been proposed and are
 being seriously considered for deployment in the near term, which
 means the concepts and research now need to be applied to deployed
 networks.  Towards that end, this document applies many of the
 principles and concepts learned through prior work to [OSPFv3], along
 with new concepts based on current requirements.

1.1. Problem Statement

 MANETs are synonymous with packet radio networks, which have been
 around since the 1960s in a limited military capacity.  With the boom
 in mobile devices and wireless communications, MANETs are finding
 scope in commercial and military environments.  The aim of these
 networks is to support robust and efficient communication in a mobile
 wireless network by incorporating routing functionality into mobile
 nodes.
 A MANET is an autonomous set of nodes distributed over a wide
 geographical area that communicate over bandwidth-constrained
 wireless links.  Each node may represent a transmitter, receiver, or
 relay station with varying physical capabilities.  Packets may
 traverse through several intermediate (relay) nodes before reaching
 their destination.  These networks typically lack infrastructure:
 nodes are mobile, and there is no central hub or controller; thus,
 there is no fixed network topology.  Moreover, MANETs must contend
 with a difficult and variable communication environment.  Packet
 transmissions are plagued by the usual problems of radio
 communication, which include propagation path loss, signal multipath
 and fading, and thermal noise.  These effects vary with terminal
 movement, which also induces Doppler spreading in the frequency of
 the transmitted signal.  Finally, transmissions from neighboring
 terminals, known as multi-access interference, hostile jammers, and
 impulsive interference, e.g., ignition systems, generators, and other
 non-similar in-band communications, may contribute additional
 interference.
 Given this nature of MANETs, the existence of a communication link
 between a pair of nodes is a function of their variable link quality,
 including signal strength and bandwidth.  Thus, routing paths vary,
 based on environment and the resulting network topology.  In such
 networks, the topology may be stable for periods of time and then
 suddenly become unpredictable.  Since MANETs are typically
 decentralized systems, there are no central controllers or specially

Roy & Chandra Experimental [Page 4] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 designated routers to determine the routing paths as the topology
 changes.  All of the routing decisions and forwarding (relaying) of
 packets must be done by the nodes themselves, and communication is on
 a peer-to-peer basis.

1.2. Motivation for Extending OSPF to Support MANETs

 The motivation to extend a standard protocol, OSPF (described in
 [OSPF] and [OSPFv3]), to operate on MANETs is twofold.  The primary
 reason is for interoperability -- MANET devices need to be able to
 work when plugged into a wireline network in as many cases as
 possible.  The junction point between a MANET and wire-line network
 should also be as fluid as possible, allowing a MANET to "plug in" to
 just about any location within a wire-line network, and also find
 connectivity, etc., as needed.
 While routes could be redistributed between two routing protocols,
 one designed just for wire-line networks, and the other just for
 MANETs, this adds complexity and overhead to the MANET/wireline
 interface, increases the odds of an error being introduced between
 the two domains, and decreases flexibility.
 The second motivation is that OSPF is a well-understood and widely
 deployed routing protocol.  This provides a strong basis of
 experience and skills from which to work.  A protocol that is known
 to work can be extended, rather than developing a new protocol that
 must then be completely troubleshot, tested, and modified over a
 number of years.  Working with a well-known protocol allows
 development effort to be placed in a narrowly focused area, rather
 than rebuilding, from scratch, many things that are already known to
 work.

2. Requirements Notation

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [KEY].

3. Proposed Enhancements

 This document proposes modifications to [OSPFv3] to support mobile ad
 hoc networks (MANETs).  Note that it is possible to use the
 mechanisms defined in Sections 3.2 and 3.3 independently of one
 another.
 The challenges with deploying standard [OSPFv3] in a MANET
 environment fit into two categories.  First, traditional link-state
 routing protocols are designed for a statically configured

Roy & Chandra Experimental [Page 5] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 environment.  As a result, most of the configuration is done manually
 when a new router is placed in the network.  Thus, OSPF will not
 function in an environment where routers interconnect and disconnect
 in somewhat random topologies and combinations.  There are
 modifications that must be made in order for routers running the same
 protocol to communicate in a heterogeneous and dynamic environment.
 Currently there is no defined interface type that describes a
 wireless network.  Wireless links have characteristics of both multi-
 access and point-to-multipoint links.  Treating wireless links as
 multi-access does not take into account that not all nodes on the
 same Layer 2 link have bi-directional connectivity.  However, any
 transmission on a link will reach nodes that are within transmission
 range.  In this way, the link is multi-access due to the fact that
 two simultaneous transmissions may collide.  A new interface type
 needs to be defined in order to accurately describe this behavior.
 The second category of challenges involves scalability.  A MANET must
 transmit more state information to maintain reachability.  Therefore,
 OSPF will need scalability enhancements to support MANETs.  While
 some flooding optimizations are present in OSPF, such as designated
 router (DR) election, many of these were built under the assumption
 of a true multi-access network.  Wireless networks are not true
 multi-access networks, because it cannot be assumed that there is
 2-way connectivity between everyone on the same Layer 2 link.
 Therefore, optimizations such as DR election will not perform
 correctly in MANET networks.  Without any further optimizations in
 link-state flooding, current OSPF would not be able to operate in a
 highly dynamic environment in which links are constantly being formed
 and broken.  The amount of information that would need to be flooded
 would overload the network.
 Another scalability issue is the periodic transmission of Hello
 messages.  Currently, even if there are no changes in a router's
 neighbor list, the Hello messages still list all the neighbors on a
 particular link.  For a MANET router, where saving bandwidth and
 transmission power is a critical issue, the transmission of
 potentially large Hello messages is particularly wasteful.
 Finally, current routing protocols will form a neighbor relationship
 with any router on a Layer 2 link that is correctly configured.  For
 MANET routers in a wireless network, this may lead to an excessive
 number of parallel links between two routers if communication is
 achieved via multiple interfaces.  In a statically configured
 network, this is not a problem, since the physical topology can be
 built to prevent excessive redundancy.  However, in a dynamic
 network, there must exist additional mechanisms to prevent too many
 redundant links.  (Note that links between two nodes on different

Roy & Chandra Experimental [Page 6] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 radio types, different antennae, different channels, etc., are
 considered different links and not redundant links.)  In scalability
 tests, it has been demonstrated that the presence of too many
 redundant links will both increase the size of routing updates and
 cause extra flooding, resulting in even relatively small networks not
 converging.

3.1. OSPF-MANET Interface

 Interfaces are defined as the connection between a router and one of
 its attached networks [OSPF].  Four types of interfaces have been
 defined and supported in [OSPF] and [OSPFv3]: broadcast, Non-
 Broadcast Multi-Access (NBMA), point-to-point, and point-to-
 multipoint.
 The point-to-multipoint model has been chosen to represent MANET
 interfaces.  (The features designed in this document MAY be included
 on other interface types as appropriate.)  The MANET interface allows
 the following:
 o  OSPF treats all router-to-router connections over the MANET
    interface as if they were point-to-point links.
 o  Link metric can be set on a per-neighbor basis.
 o  Broadcast and multicast can be accomplished through Layer 2
    broadcast or Layer 2 pseudo-broadcast.
  • The MANET interface supports Layer 2 broadcast if it is able to

address a single physical message to all of the attached

       neighbors.  One such example is 802.11.
  • The MANET interface supports Layer 2 pseudo-broadcast if it is

able to pick up a packet from the broadcast queue, replicate

       the packet, and send a copy over each point-to-point link.  One
       such example is Frame Relay.
 o  An API must be provided for Layer 3 to determine the Layer 2
    broadcast capability.  Based on the return of the API, OSPF
    classifies the MANET interfaces into the following three types:
    MANET broadcast, MANET pseudo-broadcast, and MANET non-broadcast.
 o  Multicast SHOULD be used for OSPF packets.  When the MANET
    interface supports Layer 2 broadcast or pseudo-broadcast, the
    multicast process is transparent to OSPF.  Otherwise, OSPF MUST
    replicate multicast packets by itself.

Roy & Chandra Experimental [Page 7] RFC 5820 Extensions to OSPF to Support MANETs March 2010

3.1.1. Interface Operation

 A MANET node has at least one MANET interface.  MANET nodes can
 communicate with each other through MANET interfaces.  MANET nodes
 can communicate with non-MANET routers only through normal
 interfaces, such as Ethernet, ATM, etc.
 For scalability reasons, it is not required to configure IPv6 global
 unicast addresses on MANET interfaces.  Instead, a management
 loopback interface with an IPv6 global unicast address MAY be
 configured on each MANET node.
 The link state advertisements (LSAs) associated with a MANET
 interface SHOULD have the DC-bit set in the OSPFv3 Options Field and
 the DoNotAge bit set in the LS Age field as described in [OSPFv3].
 Demand Circuits are an optional feature; hence, the DC-bit setting
 recommendation level is SHOULD.

3.1.2. LSA Formats and Examples

 LSA formats are specified in [OSPFv3].
 In order to display example LSAs, a network map is included below.
 Router names are prefixed with the letters RT, network names with the
 letter N, and router interface names with the letter I.
 o  Four MANET nodes, RT1, RT2, RT3, and RT4, reside in area 2.
 o  RT1 has one MANET interface, I11.  Through the interface, RT1 is
    full-adjacent to RT2, RT3, and RT4.
 o  RT2 has two MANET interfaces, I21 and I22, and one Ethernet
    interface, I23.  RT2 is full-adjacent to RT1 and RT4 through the
    interface I21, and full-adjacent to RT4 through the interface I22.
    Stub network N1 is attached with RT2 through the interface I23.
 o  RT3 has one MANET interface, I31, and is full-adjacent to RT1
    through the interface.
 o  RT4 has two MANET interfaces, I41 and I42.  It is full-adjacent to
    RT2 through the interface I41, and full-adjacent to RT1 and RT2
    through the interface I42.
 o  Moreover, each MANET node is configured with a management loopback
    interface.

Roy & Chandra Experimental [Page 8] RFC 5820 Extensions to OSPF to Support MANETs March 2010

    +---+I11        I21+---+I23   |
    |RT1|-+----------+-|RT2|------|N1
    +---+ |          | +---+      |
    |                |   VI22
    |                |   +
    |                |   |
    |                |   |
    |                |   |
    |                |   |
    |                |   +
    |                |   ^I41
    +---+ |          +---+
    |RT3|-+        +-|RT4|
    +---+I31      I42+---+
 The assignment of IPv6 global unicast prefixes to network links is
 shown below.  (Note: No IPv6 global unicast addresses are configured
 on the MANET interfaces).
  1. ———————————————————-

RT1 LOOPBACK 2001:DB8:0001::/64

             I11           n/a
    RT2      LOOPBACK      2001:DB8:0002::/64
             I21           n/a
             I22           n/a
             I23           2001:DB8:0012::/60
    RT3      LOOPBACK      2001:DB8:0003::/64
             I31           n/a
    RT4      LOOPBACK      2001:DB8:0004::/64
             I41           n/a
             I42           n/a
 The OSPF interface IDs and the link-local addresses for the router
 interfaces in the network are shown below.  EUIxy represents the
 64-bit interface identifier of the interface Ixy, in Modified EUI-64
 format [IPV6ADD].

Roy & Chandra Experimental [Page 9] RFC 5820 Extensions to OSPF to Support MANETs March 2010

    Node    Interface    Interface ID    Link-Local address
    -----------------------------------------------------------
    RT1     LOOPBACK     1               n/a
            I11          2               fe80:0002::EUI11
    RT2     LOOPBACK     1               n/a
            I21          2               fe80:0002::EUI21
            I22          3               fe80:0003::EUI22
            I23          4               fe80:0004::EUI23
    RT3     LOOPBACK     1               n/a
            I31          2               fe80:0002::EUI31
    RT4     LOOPBACK     1               n/a
            I41          2               fe80:0002::EUI41
            I42          3               fe80:0003::EUI42

3.1.2.1. Router-LSAs

 As an example, consider the router-LSAs that node RT2 would
 originate.  Two MANET interfaces, consisting of 3 point-to-point
 links, are presented.
    RT2's router-LSA
    LS age = DoNotAge+0              ;newly originated
    LS type = 0x2001                 ;router-LSA
    Link State ID = 0                ;first fragment
    Advertising Router = 192.0.2.2   ;RT2's Router ID
    bit E = 0                        ;not an AS boundary router
    bit B = 0                        ;not an area border router
    Options = (V6-bit|E-bit|R-bit)
     Type = 1                        ;p2p link to RT1 over I21
     Metric = 10                     ;cost to RT1
     Interface ID = 2                ;Interface ID of I21
     Neighbor Interface ID = 2       ;Interface ID of I11
     Neighbor Router ID = 192.0.2.1  ;RT1's Router ID
     Type = 1                        ;p2p link to RT4 over I21
     Metric = 25                     ;cost to RT4
     Interface ID = 2                ;Interface ID of I21
     Neighbor Interface ID = 3       ;Interface ID of I42
     Neighbor Router ID = 192.0.2.4  ;RT4's Router ID
     Type = 1                        ;p2p link to RT4 over I22
     Metric = 15                     ;cost to RT4
     Interface ID = 3                ;Interface ID of I22
     Neighbor Interface ID = 2       ;Interface ID of I41
     Neighbor Router ID = 192.0.2.4  ;RT4's Router ID

Roy & Chandra Experimental [Page 10] RFC 5820 Extensions to OSPF to Support MANETs March 2010

3.1.2.2. Link-LSAs

 A MANET node originates a separate link-LSA for each attached
 interface.  As an example, consider the link-LSA that RT3 will build
 for its MANET interface I31.
    RT3's link-LSA for MANET interface I31
    LS age = DoNotAge+0              ;newly originated
    LS type = 0x0008                 ;link-LSA
    Link State ID = 2                ;Interface ID of I31
    Advertising Router = 192.0.2.3   ;RT3's Router ID
    Rtr Pri = 1                      ;default priority
    Options = (V6-bit|E-bit|R-bit)
    Link-local Interface Address = fe80:0002::EUI31
    # prefixes = 0                   ;no global unicast address

3.1.2.3. Intra-Area-Prefix-LSAs

 A MANET node originates an intra-area-prefix-LSA to advertise its own
 prefixes and those of its attached stub links.  As an example,
 consider the intra-area-prefix-LSA that RT2 will build.
    RT2's intra-area-prefix-LSA for its own prefixes
    LS age = DoNotAge+0              ;newly originated
    LS type = 0x2009                 ;intra-area-prefix-LSA
    Link State ID = 177              ;or something else
    Advertising Router = 192.0.2.2   ;RT2's Router ID
    # prefixes = 2
    Referenced LS type = 0x2001      ;router-LSA reference
    Referenced Link State ID = 0     ;always 0 for router-LSA
                                     ;reference
    Referenced Advertising Router = 192.0.2.2
                                     ;RT2's Router ID
     PrefixLength = 64               ;prefix on RT2's LOOPBACK
     PrefixOptions = 0
     Metric = 0                      ;cost of RT2's LOOPBACK
     Address Prefix = 2001:DB8:0002::
     PrefixLength = 60               ;prefix on I23
     PrefixOptions = 0
     Metric = 10                     ;cost of I23
     Address Prefix = 2001:DB8:0012::
 Note: MANET nodes may originate intra-area-prefix-LSAs for attached
 transit (broadcast/NBMA) networks.  This is normal behavior (defined
 in [OSPFv3]), which is irrelevant to MANET interfaces.  Please
 consult [OSPFv3] for details.

Roy & Chandra Experimental [Page 11] RFC 5820 Extensions to OSPF to Support MANETs March 2010

3.2. Incremental OSPF-MANET Hellos

 In MANETs, reducing the size of periodically transmitted packets can
 be very important in decreasing the total amount of overhead
 associated with routing.  Towards this end, removing the list of
 neighbors from Hello packets, unless that information changes, can
 reduce routing protocol overhead.  While the reduction for each Hello
 packet is small, over time it will be significant.
 A new option bit is defined in this document to facilitate the
 operation of incremental Hello packets.  A new State Check Sequence
 TLV (SCS TLV) and Neighbor Drop TLV are also defined, transmitted
 using LLS [LLS].

3.2.1. The I Option Bit

 A new I-bit is defined in the LLS Type 1 Extended Options and Flags
 field.  The bit is defined for Hello packets and indicates that only
 incremental information is present.  See Section 5 for placement of
 the I-bit.

3.2.2. State Check Sequence TLV (SCS TLV)

 A new TLV is defined that indicates the current state, which is
 represented by a State Check Sequence (SCS) number of the
 transmitting router.
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Type               |           Length                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         SCS Number            |R|FS|N |   Reserved              |
 +-----------------------------------------------------------------+
 o  Type: 6
 o  Length: Set to 4.
 o  SCS Number: A circular two-octet unsigned integer indicating the
    current state of the transmitting device.  Note that when the
    incremental Hello mechanism is invoked (or re-started), an initial
    SCS value of '1' SHOULD be used for the first incremental Hello
    packet.  This sequence number is referred to as InitialSCS.  Note
    that InitialSCS also implies a full state.

Roy & Chandra Experimental [Page 12] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 o  R: Request bit.  If set, this is a request for current state.  The
    list of routers that should respond to this request is indicated
    in the Request From TLV (RF TLV) (defined below).  If the RF TLV
    is not present, it is assumed that the request is meant for all
    nodes.
 o  FS: Full State bit. If set, the Hello packet contains full state
    as far as the neighbor(s) in the Full State For TLV (FSF TLV)
    (defined below) are concerned.  If the FSF TLV is not present, the
    Hello packet contains full state for all neighbors.
 o  N: Incomplete bit.  If NOT set, the complete state associated with
    the SCS number is included in the Hello packet.  If set, this
    indicates that the appended TLVs are being sent 'persistently',
    and that there is more state associated with the SCS number that
    was sent originally, but is not included in this Hello packet.
    This bit allows any desired TLVs to be sent 'persistently' for a
    number of Hellos with the same SCS number without requiring all of
    the TLVs associated with that SCS number to be transmitted.  The
    first time an SCS number is sent, the entire state associated with
    that SCS number is transmitted, and the N-bit MUST NOT be set.
 o  Reserved: Set to 0.  Reserved for future use.
 A Hello with the SCS TLV appended and with the R-bit set will be
 referred to as a Hello request.

3.2.3. Neighbor Drop TLV

 A new TLV is defined in this document that indicates neighbor(s) that
 have been removed from the list of known neighbors.
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Type               |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Dropped Neighbor(s)                                           |
 +---------------------------------------------------------------+
 | ....
 +--------------------
 o  Type: 7
 o  Length: Set to the number of dropped neighbors included in the TLV
    multiplied by 4.
 o  Dropped Neighbor(s) - Router ID of the neighbor being dropped.

Roy & Chandra Experimental [Page 13] RFC 5820 Extensions to OSPF to Support MANETs March 2010

3.2.4. Request From TLV (RF TLV)

 A new TLV is defined in this document that indicates neighbor(s) from
 which the latest Hello state is being requested.
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Type               |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Request From Neighbor(s)                    |
 +---------------------------------------------------------------+
 | ....
 +--------------------
 o  Type: 8
 o  Length: Set to the number of neighbors included in the TLV
    multiplied by 4.
 o  Request From Neighbor(s) - Router ID of the neighbor(s) from which
    Hello state is being requested.

3.2.5. Full State For TLV (FSF TLV)

 A new TLV is defined in this document that indicates neighbor(s) to
 which the transmitting node is responding with full state.
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Type               |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Full State For Neighbor(s)                  |
 +---------------------------------------------------------------+
 | ....
 +--------------------
 o  Type: 9
 o  Length: Set to the number of neighbors included in the TLV
    multiplied by 4.
 o  Full State For Neighbor(s) - Router ID of the neighbor(s) should
    process this packet.

Roy & Chandra Experimental [Page 14] RFC 5820 Extensions to OSPF to Support MANETs March 2010

3.2.6. Neighbor Adjacencies

 This section describes building neighbor adjacencies and the failure
 of such adjacencies using the incremental Hello signaling.

3.2.6.1. Building Neighbor Adjacencies

 Hello packets are sent periodically in accordance with [OSPF] and
 [OSPFv3].  An OSPF implementation that supports sending only partial
 neighbor information in Hello packets SHOULD always set the I-bit in
 its transmitted Hello packets, except as described elsewhere in this
 document.  Hello packets MAY be suppressed from being transmitted
 every HelloInterval if other packet transmissions are sent by the
 router during that time.
 On receiving a Hello packet from a new neighbor (in this context, a
 new neighbor is a neighbor in less than Init state as defined in
 Section 10.1 [OSPF]), if the Hello has the I-bit set, a router will:
 o  Place the new neighbor in the neighbor list described in [OSPFv3],
    Appendix A.3.2.
 o  Increment the router's SCS number that it will use in its next
    Hello (indicated in the SCS TLV).
 o  Remove the neighbor from the neighbor list described in [OSPFv3],
    Appendix A.3.2, when the neighbor has reached the Exchange state
    (as described in [OSPF], Section 10.1).
 o  Remove the neighbor from the neighbor list described in [OSPFv3],
    Appendix A.3.2, if the neighbor is not a DR or backup designated
    router (BDR) on an OSPF broadcast link, and if the neighbor is
    advertised as connected in the network-LSA advertised by the DR.

3.2.6.2. Adjacency Failure

 On discovering an adjacency failure (going to state less than
 Exchange), a router using I-bit signaling SHOULD:
 o  Remove the adjacent router from local tables, and take the
    appropriate actions for a failed adjacency described in [OSPF] and
    [OSPFv3].
 o  Add the formerly adjacent router to a Neighbor Drop TLV.
 o  Increment the router's SCS number that it will transmit in its
    next Hello.

Roy & Chandra Experimental [Page 15] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 o  Transmit Hellos with this Neighbor Drop TLV.  It may be desirable
    to send the Neighbor Drop TLV in three consecutive Hellos to
    increase the probability of reception.  In this case, 'persistent'
    Hello packets would be sent with the same SCS number, the Neighbor
    Drop TLV, and the N-bit set.  Thus, the receiver knows that the
    Neighbor Drop TLV is being sent persistently, and there is more
    state associated with the SCS in case it must request missing
    state presumably transmitted in a previous Hello.

3.2.7. Sending Hellos

 When a device is first attached to a network (whether by being
 brought within range of another device, powering the device on,
 enabling the device's radio interface, etc.), it will need to obtain
 complete neighbor state from each of its neighbors before it can
 utilize the incremental Hello mechanism.  Thus, upon initialization,
 a device MAY send a multicast Hello request (and omit the Request
 From TLV).  Neighbors will receive the request and respond with a
 Hello with their complete neighbor state.
 If a device is in INIT state with a neighbor and receives a Hello
 from the neighbor without its router ID listed in the neighbor list,
 the device SHOULD request the current state from the neighbor.  Note
 that this is to avoid a "race" condition, since the received Hello
 can either mean that the device is NOT SEEN by the neighbor, or that
 the device is adjacent and not listed in the incremental list.  Thus,
 by receiving a Hello request, the neighbor will respond with its
 neighbor state for the neighbor.
 The first Hello packet with a particular SCS number MUST contain the
 full state associated with that SCS number, i.e., all state changes
 since the last SCS number.  The N-bit MUST NOT be set in the State
 Check Sequence TLV.
 Incremental Hello packets can be sent persistently (sent in k
 successive Hello packets), with flexibility in the actual amount of
 information being sent.  The three options include:
 o  The entire incremental Hello packet is sent persistently.  This is
    accomplished by simply sending the entire state associated with a
    SCS number for k successive Hellos.  Since the SCS number remains
    the same, the N-bit is not set in these incremental Hello packets.
 o  Partial information for a particular SCS number is sent
    persistently.  After the first Hello packet with a particular SCS
    number is sent, only the TLVs that are desired to be sent

Roy & Chandra Experimental [Page 16] RFC 5820 Extensions to OSPF to Support MANETs March 2010

    persistently are sent in subsequent Hellos with the same SCS
    number and the N-bit set.
 o  No information is sent persistently.  This is simply the default
    behavior where an incremental Hello packet with a particular SCS
    number is only sent once.

3.2.8. Receiving Hellos

 Each OSPF device supporting incremental Hello signaling, as described
 in this document, MUST keep the last known SCS number from each
 neighbor it has received Hellos from as long as the neighbor
 adjacency structure is maintained.
 If a device receives a Hello from an adjacent neighbor with an SCS
 number less than the last known SCS number from that neighbor, it
 MUST first check if the SCS number is a wrap around.  "Wrap around"
 is a condition when the last known SCS number is MAX_SCS (65535) and
 the new SCS number is 1.  If it is not a wrap around, then the device
 MUST send a Hello request to the neighbor.
 If it is a wrap around, or if a device receives a Hello from an
 adjacent neighbor with an SCS number one greater than the last known
 SCS number from that neighbor, it MUST:
 o  Examine the neighbor list described in [OSPFv3], Appendix A.3.2.
    If any neighbors are contained in this list, increment the SCS
    number contained in the adjacent neighbor's data structure.
 o  Examine the Neighbor Drop TLV as described in Section 3.2.6.2.  If
    this list contains a neighbor other than the local router,
    increment the SCS number contained in the adjacent neighbor's data
    structure.
 o  Examine the Neighbor Drop TLV as described in Section 3.2.6.2.  If
    the local router identifier is contained in this list, destroy the
    transmitting adjacent neighbor's data structures.
 o  Examine any other TLVs incrementally signaled, as described in
    documents referring to this RFC.  If there are other state changes
    indicated, increment the SCS number contained in the adjacent
    neighbor's data structure.
 o  If no state change information is contained in the received Hello,
    send a request for current state (by setting the 'R'-bit) in the
    next Hello.

Roy & Chandra Experimental [Page 17] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 If a device receives a Hello from an adjacent neighbor with an SCS
 number greater than the last known SCS number + 1 from that neighbor,
 it MUST send a Hello request to the neighbor, since it may be missing
 some neighbor state.

3.2.8.1. Receiving Hellos with the N-bit Set

 If a device receives a Hello with the SCS TLV included and the N-bit
 set in this TLV, it MUST verify that it has already received the SCS
 number with the N-bit NOT set from the neighbor.  If the device
 determines that this is the first receipt of the SCS number from this
 neighbor, then it MUST send a Hello request to the neighbor, since it
 missed the initial Hello packet with the SCS number and thus is
 missing state.

3.2.8.2. Receiving Hellos with the R-bit Set

 If a device receives a Hello with the SCS TLV included and the R-bit
 set, it looks for the RF TLV.  If its router ID is listed in the RF
 TLV or the TLV is not found, it includes its full state in the next
 Hello.  This MUST include:
 o  The neighbor ID of the requesting neighbor(s) in the list of
    neighbors described in [OSPFv3], Appendix A.3.2.
 o  An SCS TLV with the transmitter's current SCS number and the
    FS-bit set.  Note that the transmitter's SCS number is NOT
    incremented.
 o  Any other TLVs, defined in other documents referencing this RFC,
    indicating the current state of the local system.
 o  The neighbor ID of all the neighbors who have requested current
    state, in the FSF TLV.
 If the full state is being sent to a large number of existing
 neighbors, an implementation could choose to instead generate a full
 state for all neighbors and omit the FSF TLV.

3.2.8.3. Receiving Hellos with the FS-bit Set

 When a device receives a Hello with the SCS TLV included and the
 FS-bit set, the Hello packet contains the neighbor's full state for
 the device.  The packet SHOULD be processed as follows:

Roy & Chandra Experimental [Page 18] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 o  If the received SCS number is equal to the last known SCS number,
    the packet SHOULD be ignored, since the device already has the
    latest state information.
 o  If the received SCS number is different than the last known SCS
    number, this Hello has new information and MUST be parsed.
 o  If it is listed in the FSF TLV, or if the FSF TLV is not present,
    the device MUST save the SCS number, process the Hello as
    described in Section 3.2.8, and process any other appended TLVs.

3.2.9. Interoperability

 On receiving a Hello packet from a new neighbor without the I-bit
 set, the local router will continue to place that router's identifier
 in transmitted Hellos on this link as described in [OSPFv3],
 Appendix A.3.2.

3.2.10. Support for OSPF Graceful Restart

 OSPF graceful restart, as described in [OSPFREST] and [OSPFGR],
 relies on the lack of neighbors in the list of neighbors described in
 [OSPFv3], Appendix A.3.2, to determine that an adjacent router has
 restarted, and other signaling to determine that the adjacency should
 not be torn down.  If all Hello packets transmitted by a given router
 have an empty Hello list, reliance on an empty Hello packet to signal
 a restart (or to reliably tear down an OSPF adjacency) is no longer
 possible.  Hence, this signaling must be slightly altered.  When a
 router would like to tear down all adjacencies, or signal that it has
 restarted:
 o  On initially restarting, during the first RouterDeadInterval after
    restart, the router will transmit Hello packets with an empty
    neighbor list and the I-bit cleared.  Any normal restart or other
    signaling may be included in these initial Hello packets.
 o  As adjacencies are learned, these newly learned adjacent routers
    are included in the multicast Hellos transmitted on the link.
 o  After one RouterDeadInterval has passed, the incremental Hello
    mechanism is invoked.  An incremental Hello packet with full state
    is sent with the I-bit set, the SCS TLV included with the FS-bit
    set, and the InitialSCS value (e.g., SCS of '1').  Subsequent
    Hello packets will include only incremental state.
 Routers that are neighboring with a restarting router MUST continue
 sending their Hello packets with the I-bit set.

Roy & Chandra Experimental [Page 19] RFC 5820 Extensions to OSPF to Support MANETs March 2010

3.3. Optimized Flooding (Overlapping Relays)

 A component that may influence the scalability and convergence
 characteristics of OSPF ([OSPF], [OSPFv3]) in a MANET environment is
 how much information needs to be flooded.  The ideal solution is that
 a router will receive a particular routing update only once.
 However, there must be a trade-off between protocol complexity and
 ensuring that every speaker in the network receives all of the
 information.  Note that a speaker refers to any node in the network
 that is running the routing protocol and transmitting routing updates
 and Hello messages.
 Controlling the amount of information on the link has increased
 importance in a MANET environment due to the potential transmission
 costs and resource availability in general.
 In some environments, a group of speakers that share the same logical
 segment may not be directly visible to each other; some of the
 possible causes are the following: low signal strength, long distance
 separation, environmental disruptions, partial VC (virtual circuit)
 meshing, etc.  In these networks, a logical segment refers to the
 local flooding domain dynamically determined by transmission radius.
 In these situations, some speakers (the ones not able to directly
 reach the sender) may never be able to synchronize their databases.
 To solve the synchronization issues encountered in these
 environments, a mechanism is needed through which all the nodes on
 the same logical segment can receive the routing information,
 regardless of the state of their adjacency to the source.

3.3.1. Operation Overview

 The optimized flooding operation relies on the ability of a speaker
 to advertise all of its locally connected neighbors.  In OSPF, this
 ability is realized through the use of link state advertisements
 (LSA)s ([OSPF], [OSPFv3]).
 A speaker receives router-LSAs from its adjacent neighbors.  A
 speaker's router-LSA conveys the list of the adjacent speakers of the
 originator ("neighbor list").  The local speaker can compare the
 neighbor list reported by each speaker to its own neighbor list.  If
 the local neighbor list contains adjacent speakers that the
 originator cannot reach directly (i.e., those speakers that are not
 in the originator's neighbor list), then these speakers are locally
 known as non-overlapping neighbors for the originator.
 The local speaker should relay any routing information to non-
 overlapping neighbors of the sender based on the algorithm outlined
 in Section 3.3.8.  Because more than one such speaker may exist, the

Roy & Chandra Experimental [Page 20] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 mechanism is called "overlapping relays".  The algorithm, however,
 does select the set of overlapping relays that should transmit first.
 This set is known as the active set of overlapping relays for a
 speaker.

3.3.2. Determination of Overlapping Relays

 The first step in the process is for each speaker to build and
 propagate their neighbor lists in router-LSA packets.  Every speaker
 is then in a position to determine their 2-hop neighborhood, i.e.,
 those nodes that are neighbors of the speaker's 1-hop neighbors.
 A bidirectional neighbor is considered an overlapping relay for a
 speaker if it can reach a node in the 2-hop neighborhood of the
 speaker, i.e., if it has 1-hop neighbors (excluding the speaker
 itself).
 The set of Active Overlapping Relays for a speaker is the minimum set
 of direct neighbors such that every node in the 2-hop neighborhood of
 the speaker is a neighbor of at least one overlapping relay in the
 active set.
 Each speaker SHOULD select a set of Active Overlapping Relays based
 on a selection algorithm (one such algorithm is suggested in
 Section 3.3.4 and is based on the multipoint relay (MPR) selection
 algorithm described in [OLSR]).  The behavior of the overlapping
 relays MUST follow that specified in Section 3.3.8.
 Note that a speaker MUST NOT choose a neighbor to serve as an Active
 Overlapping Relay if that neighbor set the N-bit in its Active
 Overlapping Relay TLV as defined in Section 3.3.6, unless the
 neighbor is the only neighbor to reach a 2-hop neighbor.
 Election of Active Overlapping Relays is done across interfaces, and
 thus, it is node-based and not link-based.

3.3.3. Terminology

 The following heuristic and terminology for Active Overlapping Relay
 selection is largely taken from [OLSR]:
 o  FULL: Neighbor state FULL as defined in [OSPF] and [OSPFv3].  Note
    that all neighbor references in this document are assumed to be
    FULL neighbors.
 o  N: N is the set of FULL neighbors of the node.

Roy & Chandra Experimental [Page 21] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 o  2-hop FULL neighbors (N2): The list of 2-hop neighbors of the node
    that are FULL and that can be reached from direct neighbors,
    excluding any directly connected neighbors.
 o  Active Set: A (sub)set of the neighbors selected, such that
    through these selected nodes, all 2-hop FULL neighbors are
    reachable.
 o  D(y): The degree of a 1-hop neighbor node y (where y is a member
    of N) is defined as the number of FULL neighbors of node y,
    EXCLUDING all the members of N and EXCLUDING the node performing
    the computation.

3.3.4. Overlapping Relay Discovery Process

 A possible algorithm for discovering overlapping relays is the
 following:
 1. Start with an active set made of all members of N that have set
    the A-bit in their Active Overlapping Relay TLV (AOR TLV) as
    defined in Section 3.3.6.
 2. Calculate D(y), where y is a member of N, for all nodes in N.
 3. Add to the active set those nodes in N, which are the *only* nodes
    to provide reachability to a node in N2, i.e., if node b in N2 can
    be reached only through a symmetric link to node a in N, then add
    node a to the active set.  Remove the nodes from N2 that are now
    covered by a node in the active set.
 4. While there exist nodes in N2 that are not covered by at least one
    node in the active set:
    A. For each node in N, calculate the reachability, i.e., the
       number of nodes in N2 that are not yet covered by at least one
       node in the active set and that are reachable through this
       1-hop neighbor.
    B. Select as an Active Overlapping Relay the node with the highest
       Willingness value (Section 3.3.7) among the nodes in N with
       non-zero reachability.  In the case of multiple choices, select
       the node that provides reachability to the maximum number of
       nodes in N2.  In the case of multiple nodes providing the same
       amount of reachability, select as active the node whose D(y) is
       greater.  As a final tie breaker, the node with the highest
       router ID should be chosen.  Remove the nodes from N2 that are
       now covered by a node in the active set.

Roy & Chandra Experimental [Page 22] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 5. As an optimization, process each node, y, in the active set in
    increasing order of Willingness value.  If all nodes in N2 are
    still covered by at least one node in the active set, excluding
    node y, and if Willingness of node y is smaller than
    MAX_WILLINGNESS, then node y should be removed from the active
    set.

3.3.5. The F Option Bit

 A single new option bit, the F-bit, is defined in the LLS Type 1
 Extended Options and Flags field.  The F-bit indicates that the node
 supports the optimized flooding mechanism as specified in this
 document.  See Section 5 for placement of the F-bit.

3.3.6. Active Overlapping Relay TLV (AOR TLV)

 A new TLV is defined so that each speaker can convey its set of
 Active Overlapping Relays in the Hello messages.  The TLV is
 transmitted using LLS [LLS].
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Type                  |        Length                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Relays Added |A|N|           Reserved                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Router ID(s) of Active Overlapping Relay(s)                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              ...                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 o  Type: 10
 o  Length - variable.  Length of TLV in bytes, NOT including Type and
    Length.
 o  Relays Added - variable.  Number of Active Overlapping Relays that
    are being added.  Note that the number of Active Overlapping
    Relays that are being dropped is then given by
    [(Length - 4)/4 - Relays Added].
 o  A-bit - If this bit is set, the node is specifying that it will
    always flood routing updates that it receives, regardless of
    whether it is selected as an Active Overlapping Relay.
 o  N-bit - If this bit is set, the node is specifying that it most
    likely will not flood routing updates.  The node SHOULD NOT be

Roy & Chandra Experimental [Page 23] RFC 5820 Extensions to OSPF to Support MANETs March 2010

    chosen to be an Active Overlapping Relay unless it is the *only*
    neighbor that can reach 2-hop neighbor(s).  Note that if the node
    is selected as an Active Overlapping Relay and the node cannot
    perform the required duties, network behavior is not compromised,
    since it results in the same behavior as if the node was not
    chosen as an Active Overlapping Relay.
 o  Reserved - Reserved for future use. MUST be set to zero by the
    sender, and MUST be ignored upon receipt.
 o  Router ID(s) of Active Overlapping Relay(s) - The router ID(s) of
    neighbor(s) that are either chosen to serve as an Active
    Overlapping Relay or removed from serving as an Active Overlapping
    Relay.  The Active Overlapping Relays that are being added MUST be
    listed first, and the number of such relays MUST equal Add Length.
    The remaining listed relays are being dropped as Active
    Overlapping Relays, and the number of such relays MUST equal
    [(Length - 4)/4 - Relays Added].
 Note that the A-bit and N-bit are independent of any particular
 selection algorithm to determine the set of Active Overlapping
 Relays.  However, the bits SHOULD be considered as input into the
 selection algorithm.
 If a node is selected as an Active Overlapping Relay and it does not
 support the Incremental Hello mechanism defined in Section 3.2, then
 it SHOULD always be included as an Active Overlapping Relay in the
 TLV.  Note that while a node needs to know whether it is an Active
 Overlapping Relay, it does not necessarily have to know the
 identities of the other Active Overlapping Relays.

3.3.7. Willingness TLV

 A new TLV is defined so that each speaker can convey its willingness
 to serve as an Active Overlapping Relay in the Hello message.  The
 TLV is transmitted using the LLS [LLS].
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Type                  |        Length                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Willingness |                       Reserved                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 o  Type: 11
 o  Length - 4 bytes.  It does not include the Type and Length fields.

Roy & Chandra Experimental [Page 24] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 o  Willingness - 1 byte to indicate the willingness of the node to
    serve as an Active Overlapping Relay for its neighbors.
       *  0: MIN_WILLINGNESS
       *  128: DEFAULT_WILLINGNESS
       *  255: MAX_WILLINGNESS
 The TLV is optional and MUST be silently ignored if not understood.
 If the Willingness TLV is not included in the Hello packet, the
 Willingness value SHOULD be taken as DEFAULT_WILLINGNESS.

3.3.8. Flooding and Relay Decisions

 The decision whether to relay any received LSAs, and when to relay
 such information, is made depending on the topology and whether the
 node is part of the set of Active Overlapping Relays.
 Upon receiving an LSA from a bi-directional neighbor, a node makes
 flooding decisions based on the following algorithm:
 1. If the node is an Active Overlapping Relay for the adjacent
    speaker, then the router SHOULD immediately relay any information
    received from the adjacent speaker.
 2. If the node is a non-Active Overlapping Relay for the adjacent
    speaker, then the router SHOULD wait a specified amount of time
    (PushbackInterval plus jitter (see Section 3.3.10)) to decide
    whether to transmit.  [Jitter is used to try to avoid several non-
    Active Overlapping Relays from propagating redundant information.]
    Note that a node with the N-bit set in the 'Active Overlapping
    Relays' extension will not be chosen as an Active Overlapping
    Relay unless it is the only node to provide reachability to a
    2-hop neighbor.  However, it MUST perform the duties of a non-
    Active Overlapping Relay as required.  Non-Active Overlapping
    Relays MUST follow the acknowledgment mechanism outlined in
    Section 3.3.9.
    A. During this time, if the node determines that flooding the LSA
       will only result in a redundant transmission, the node MUST
       suppress its transmission.  Otherwise, it MUST transmit upon
       expiration of PushbackInterval plus jitter.
    B. If a non-Active Overlapping Relay hears a re-flood from another
       node that covers its non-overlapping neighbors before its timer
       to transmit expires, it SHOULD reset its PushbackInterval plus
       jitter timer.  (Note that the implementation should take care
       to avoid resetting the PushbackInterval timer based on
       transmissions from Active Overlapping Relays.)  During this
       time, if the node determines that flooding the update will only

Roy & Chandra Experimental [Page 25] RFC 5820 Extensions to OSPF to Support MANETs March 2010

       result in a redundant transmission, the node MUST suppress its
       transmission.  Otherwise, it MUST transmit upon expiration of
       PushbackInterval plus jitter.
    C. If a non-Active Overlapping Relay hears an old instance of the
       LSA during this time, it SHOULD ignore the LSA, and it SHOULD
       NOT send a unicast packet to the neighbor with the most recent
       LSA as specified in [OSPFv3].
 3. For LSAs that are received unicast because of retransmission by
    the originator, the node MUST determine whether it has already
    received the LSA from another speaker.  If it already has the
    current instance of the LSA in its database, it MUST do nothing
    further in terms of flooding the LSA (since it would have taken
    appropriate action when it initially received the LSA).  However,
    if it does not have the current instance of the LSA in its
    database, it MUST take action according to the rules above, just
    as if it received the multicast LSA.  The acknowledgment mechanism
    outlined in Section 3.3.9 MUST be followed, and any timeout
    mechanism for unicast LSAs MAY be followed.
 Note that a node can determine whether further flooding an LSA will
 only result in a redundant transmission by already having heard link
 state acknowledgments (ACKs) or floods for the LSA from all of its
 neighbors.
 Due to the dynamic nature of a network, the set of Active Overlapping
 Relays may not be up to date at the time the relay decision is made
 or may not be able to perform the flooding duties, e.g., due to poor
 link quality.  The non-Active Overlapping Relays prevent this
 situation from causing database synchronization issues and, thus,
 packet loss.
 Since the originator of the information, the relay, and the receiver
 are all in the same dynamically determined local flooding domain, the
 relay MUST NOT change the routing update information.  In general,
 LSAs SHOULD be sent to a well-known multicast address.  In some
 cases, routing updates MAY be sent using unicast packets.

3.3.9. Intelligent Transmission of Link State Acknowledgments

 In order to optimize the bandwidth utilization on the link, a speaker
 MUST follow these recommendations related to ACK transmissions:
 1. All ACKs MUST be sent via multicast.
 2. Typically, LSAs are acknowledged by all of the adjacent speakers.
    In the case of relayed information, the relay MUST only expect

Roy & Chandra Experimental [Page 26] RFC 5820 Extensions to OSPF to Support MANETs March 2010

    either explicit or implicit acknowledgments from neighbors that
    have not previously acknowledged this LSA.
 3. Because routing updates are sent via multicast, the set of
    overlapping speakers will usually receive the same update more
    than once.  A speaker SHOULD only acknowledge the first update
    received on the link.
 4. An Active Overlapping Relay SHOULD NOT explicitly acknowledge
    information that it is relaying.  The relayed information will
    serve as an acknowledgment to the sender.  If no information is
    being relayed, then an explicit ACK MUST be sent.
 5. Several ACKs MAY be bundled into a single packet.  The wait
    (AckInterval) before sending one such packet reduces the number of
    packet transmissions required in acknowledging multiple LSAs.
 6. All ACK packets SHOULD reset the RouterDeadInterval at the
    receiver.  If there is no state waiting to be transmitted in a
    Hello packet at the sender, then the HelloInterval at the sender
    SHOULD be reset.  Note that an ACK serves as a Hello packet with
    no state change.
 7. Any LSA received via unicast MUST be acknowledged.  (Note that
    acknowledgment is via multicast as specified in rule (1) above.)
 An ACK received from a non-overlapping neighbor should prevent
 redundant transmission of the information to it by another
 overlapping relay.

3.3.10. Important Timers

 This section details the timers that were introduced in Sections
 3.3.8 and 3.3.9.
 o  PushbackInterval: The length of time in seconds that a non-Active
    Overlapping Relay SHOULD wait before further flooding an LSA if
    needed.  This timer MUST be less than 1/2 of the RxmtInterval
    ([OSPF], [OSPFv3]) minus propagation delays, i.e.,
    (PushbackInterval + propagation delay) < RxmtInterval/2.  The
    PushbackInterval is set by a non-Active Overlapping Relay upon
    receipt of an LSA.
 o  AckInterval: After a node determines that it must transmit an ACK
    and the AckInterval timer is not already set, the node SHOULD set
    the AckInterval timer.  The AckInterval is the length of time in
    seconds that a node should wait in order to transmit many ACKs in
    the acknowledgment packet.  This wait reduces the number of packet

Roy & Chandra Experimental [Page 27] RFC 5820 Extensions to OSPF to Support MANETs March 2010

    transmissions required in acknowledging multiple LSAs.  The
    AckInterval MUST be less than the PushbackInterval minus
    propagation delays, i.e.,
    (AckInterval + propagation delay) < PushbackInterval.

3.3.11. Miscellaneous Protocol Considerations

 The mechanism described refers to the operation of relays on a common
 media segment.  In other words, an LSA is only relayed out the same
 interface through which it was received.  However, the concept of
 information relay may be extended to the flooding of all link state
 advertisements received on any interface (and forwarded on any other
 interface).  OSPF works on the premise that all of the nodes in a
 flooding domain will receive all of the routing information.  Note
 that one of the important properties is that the routing information
 is not altered when relayed.
 If each speaker advertised all of its adjacent neighbors on all
 interfaces, then the overlap check would result in the determination
 of which speakers are adjacent to both speakers.  As a result, link
 state information should only be flooded to non-overlapping neighbors
 (taking all of the interfaces into account).
 The flooding mechanism in OSPF relies on a designated router to
 guarantee that any new LSA received by one router attached to the
 broadcast network will be re-flooded properly to all the other
 routers attached to the broadcast network.  Such designated routers
 must be able to reach all of the other speakers on the same subnet.
 A designated router SHOULD NOT be elected if overlapping relays are
 used.
 If such designated routers already exist, then the relays MUST be
 capable of differentiating them and then making the relaying
 decisions based on the OSPF's normal operation.  As a result, there
 may be groups of neighbors to which some information should not be
 relayed.  This mode of operation is NOT RECOMMENDED, as it adds to
 the complexity of the system.
 The intent of the overlapping relay mechanism is to optimize flooding
 of routing control information.  However, other information (such as
 data) may also be relayed in some networks using the same mechanism.

3.3.12. Interoperability

 On receiving a Hello packet from a new neighbor without the F-bit
 set, the local router will assume that the new neighbor will flood
 normally as described in [OSPFv3].  Thus, the local router SHOULD
 include the neighbor in its overlapping relay set since the neighbor

Roy & Chandra Experimental [Page 28] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 will flood by default.  This will allow the local router to more
 optimally select its entire overlapping relay set.
 If the F-bit is set and the I-bit as defined in Section 3.2 is not
 set in the neighbor's Hello, and the neighbor is selected as an
 overlapping relay by the local router, the local router will continue
 to include the neighbor's identifier in its active relay set.

3.4. New Bits in LLS Type 1 Extended Options and Flags

 Two new option bits are defined in the "LLS Type 1 Extended Options
 and Flags" Field [LLS] as follows:
 o  I-bit - defined in Section 3.2.1: The I-bit is only defined for
    Hello packets and indicates that only incremental information is
    present.
 o  F-bit - defined in Section 3.3.5: The F-bit indicates that the
    node supports the optimized flooding mechanism as specified in
    this document.

3.5. Smart Peering

 There is significant overhead in OSPF when a router has to establish
 adjacencies with every peer with whom it can verify 2-way
 connectivity.  OSPF supports the broadcast network type for these
 scenarios, where you only have to peer with the designated router
 (DR).  However, a full mesh of connectivity is required for proper
 operation, and this doesn't help in networks with overlapping partial
 meshes of connectivity.  This document proposes a technique to reduce
 the number of adjacencies based on shortest path tree (SPT)
 reachability information.

3.5.1. Rationale for Smart Peering

 In OSPF ([OSPF], [OSPFv3]), nodes establish an adjacency by first
 verifying 2-way connectivity between them and then synchronizing
 their link state databases.  Once the peering relationship is
 complete and the adjacency is established, the nodes will continue to
 advertise each other in their LSAs.  As a result, the peers are
 maintained in the link state database and are included in all SPF
 (Shortest Path First) calculations.  During the reliable flooding
 process, a node must ensure that each peer has indeed received the
 flooded routing update via an acknowledgment and retransmission
 mechanism.
 Consequently, maintaining an adjacency for a particular peer is a
 trade-off between the added redundancy in routing paths and network

Roy & Chandra Experimental [Page 29] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 reachability versus the associated overhead (memory consumption, SPF
 computations, routing overhead, and network convergence).
 Consider the possibility of reducing the number of adjacencies that a
 node maintains without compromising reachability and redundancy.
 This will have direct implications on network scalability and is
 especially attractive in environments where the network topology is
 dynamic.  For example, in a mobile ad hoc network (MANET), where
 nodes are mobile and the topology is constantly changing, it seems
 highly desirable to 'intelligently' become adjacent with only
 selected peers and not establish a peering session with every node
 that comes within transmission range.  Selective peering can be
 particularly useful in avoiding the peering process for unstable
 nodes, i.e., nodes that come in and out of transmission range.

3.5.2. Previous Related Work

 The formation of a FULL adjacency requires discovery (2-way
 relationship) and database synchronization.  To prevent achieving the
 FULL state, others have taken the approach of modifying link state
 protocols to use periodic advertisements (instead of a database
 exchange).  The result is that neighbor discovery is still required,
 but routing information is learned over time.  An example of this
 approach is:
 o  OSPFv2 Wireless Interface Type [WINTF]
  • where the use of periodic advertisements "eliminates the

formation of full adjacencies on wireless interfaces; all

       neighbor states beyond 2-Way are not reached,and no database
       synchronization is performed".
 What we propose in this specification goes a step further by not
 requiring the formation and maintenance of neighbor state (2-way, or
 other) *and* without changing the route distribution mechanisms in
 the link state protocols.  In other words, the mechanism described is
 completely backward compatible.

3.5.3. Smart Peering Solution

 Two routers are defined as synchronized when they have identical link
 state databases.  To limit the number of neighbors that are formed,
 an algorithm is needed to select which neighbors with whom to peer.
 The algorithm MUST provide reachability to every possible destination
 in the network, just as when normal adjacency formation processes are
 used.  We should always peer with a neighbor if it provides our only
 path to currently unreachable destinations.

Roy & Chandra Experimental [Page 30] RFC 5820 Extensions to OSPF to Support MANETs March 2010

3.5.3.1. SPT Reachability Heuristics

 The peering decision is really a local matter to a router.  If a
 router can ensure that reachability to other nodes is available
 without bringing up a new adjacency, it can choose not to bring up
 the new adjacency.
 We propose an algorithm that uses the existing information about a
 new neighbor's reachability in the SPT.  If the two routers can
 already reach each other in the SPT, it is not necessary to form an
 adjacency between them.
 The decision to peer or not is made when a Hello is received.  When a
 Hello is received from a new neighbor or a neighbor in a state lower
 than Exchange:
 o  A check is made in the link state database to see if the peer is
    already reachable in the SPT.
  • If the peer is either not known in the SPT or is not reachable,

we start the Exchange process.

  • If the peer is reachable, then bringing up adjacency with this

neighbor does not provide reachability to any new destinations.

 Let's take an example of a single OSPF area.  This check would look
 for the neighbor's router-LSA.  If the LSA is present in the database
 and is reachable in the SPT, we have a chance to suppress adjacency
 formation.
 It's worth noting that as the number of links and redundancy in the
 network is reduced, the likelihood of suboptimal routing increases.

3.5.3.2. State Machine

 The state machine of a basic implementation of this algorithm is
 provided below.  An implementation MAY use some heuristics (Step (3)
 below), beyond the SPT reachability, to decide whether or not it
 considers a new adjacency to be of value.

Roy & Chandra Experimental [Page 31] RFC 5820 Extensions to OSPF to Support MANETs March 2010

                      ......................
                      |Receive a Hello     |
                  (1) |from a new potential|
                      |neighbor            |
                      '`''''''''''''''''''''
                                |
                                |
                                |
                      ,''''''''''''''''''''''|
                      |Check to see if there |
                  (2) |is a router-LSA from  |----no--(4)form a
                      |the new potential     |          new
                      |neighbor in the link  |          neighbor
                      |state database, which |
                      |is reachable in SPT   |
                      '`''''''''''''''''''''''
                                |
                                |yes
       (3)                      |
    ,'''''''''''''''''''''''''''''''''''''''''''''''''''''''''|
    |                            (3b)........................ |
    |(3a),______________________     |Determine if the      | |
    |    |Determine if the new |     |number of redundant   | |
    |    |link cost is better  |     |paths to the potential| |
    |    |than the current path|     |neighbor is < the     | |
    |    |cost by a configured |     |maximum configured    | |
    |    |amount               |     |value                 | |
    |    '`'''''''''''''''''''''     '`'''''''''''''''''''''' |
    |                       \             /                   |
    |                   .....\.........../....                |
    |                   |User configurable   |                |
    |                   |selection algorithm |                |
    |                   '`'''/'''''''\''''''''                |
    |                       /         \                       |
    '`'''''''''''''''''''''/'''''''''''\'''''''''''''''''''''''
                          /             \
                   requirements     requirements
                      met              not met
                      /                    \
                     /                      \
         (4) form a new neighbor      (5) do not become
                                          neighbors

Roy & Chandra Experimental [Page 32] RFC 5820 Extensions to OSPF to Support MANETs March 2010

3.5.4. Advertising 2-Way Links in Router-LSAs

 The technique described in Section 3.5.3 minimizes the number of
 adjacencies in highly meshed environments.  This is especially useful
 when the network is in motion and the average adjacency lifetime is
 small.
 However, it suffers from an undesirable side effect of limiting the
 number of transit links available to forward traffic.
 An implementation may choose to allow some (or even all) of these
 2-way state neighbors to be announced in the router-LSA.  Since the
 state remains 2-way, we don't incur control plane (database sync and
 flooding) overhead.  However, advertising the link in the router-LSA
 makes the link available to the data plane.
 This can be safely done if the neighbor is reachable in a special SPT
 constructed by ignoring any other 2-way links in the network.  This
 optional optimization is described below.

3.5.4.1. Unsynchronized Adjacencies

 If the new neighbor is already reachable in the SPT, there is no
 urgency in doing a full database sync with it.  These are the steps
 we need to perform when a neighbor has reached 2-way state.
 Note that when we say "SPT" in this section, we mean the special SPT
 constructed based on rules in Section 3.5.4.2.
 o  After a 2-WayReceived event, check if the neighbor is reachable in
    the SPT.  If yes, mark the neighbor as FULL with respect to link
    advertisement.
 o  This means that the router-LSA or network-LSA link corresponding
    to the neighbor is advertised as if the neighbor is FULL.
 o  The adjacency information is constructed with the U-bit (see
    below).
 o  Database synchronization is postponed:
  • By a configured amount of time -OR-
  • Until the time it's absolutely "necessary"
 In either case, if a database sync is currently pending, it is
 started as soon as we detect that the neighbor is no longer reachable
 in the SPT.  The database sync can be done by Out-of-Band Sync [OOB],

Roy & Chandra Experimental [Page 33] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 which maintains the current adjacency and does the sync in the
 background.  A normal resync can alternately be done with the
 drawback of adjacency flap.
 In standard OSPF, we first bring up adjacency and then announce a
 transit link.  The approach described above allows the link to be
 used as a forwarding path very quickly and still allows the database
 to be synchronized in a timely fashion when the alternate flooding
 path has recently been broken.
 There is a circular dependency issue that also needs to be resolved.
 Once you start announcing the link, the shortest path will likely be
 via this very link.  So it's non-trivial to detect when the alternate
 dependent path is gone.  We would like to be able to detect that the
 neighbor is reachable via a path that doesn't traverse an
 unsynchronized path.
 We have generally solved this class of problems by running an SPF and
 pretending that the link in question doesn't exist.  It doesn't
 require a full SPF, but just enough to see if ANY other path is
 available to reach the neighbor.  The worst case is when the
 alternate path is really gone, which we find that out by building a
 full SPT.  This needs to be done every time the link state database
 changes, and for EACH link that has SPT dependence for its viability.
 This approach has scalability concerns and is not considered further
 here.
 We can achieve the same results with just ONE additional SPF that is
 capable of ignoring these Unsynchronized links.  The result from this
 SPT can be used to satisfy the reachability condition for ANY number
 of Unsynchronized Adjacencies.  This basically requires that we can
 actually tell the difference between a normal FULL adjacency and this
 new Unsynchronized Adjacency.  We can do this in one of two ways:
 (A) Defining LD Options and using a bit in it, as shown below:
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |   LD Options  |          Metric               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Interface ID                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Neighbor Interface ID                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Neighbor Router ID                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Link Description in a Router-LSA

Roy & Chandra Experimental [Page 34] RFC 5820 Extensions to OSPF to Support MANETs March 2010

    LD Options
       Link Description options.  Used to specify some special
       capability or state of a link.
                             +-+-+-+-+-+-+-+-+
                             | | | | | | | |U|
                             +-+-+-+-+-+-+-+-+
                                 LD Options
    U-bit
       The "Unsynchronized" bit.  This is set if the adjacency is
       being announced before databases are fully synchronized.
    This approach is backward compatible, because the only routers
    looking at this bit are those that support the mechanisms
    specified in this document.
 (B) Introducing a new link type in router-LSA.
    This is a much more complex solution, with backward compatibility
    concerns, due to the fact that unknown link type handling is not
    defined in the OSPF standard [OSPF].  Hence, this solution isn't
    considered further.

3.5.4.2. Unsynchronized SPT

 Whenever link state changes happen, we need to run ONE additional SPF
 by ignoring all links with the U-bit set.  This SPT is then consulted
 to see if any of our Unsynchronized Adjacencies need to start
 database sync.  This SPT is also consulted when a new neighbor goes
 into 2-way state to decide if we should form the adjacency
 immediately or defer it for later.

3.5.4.3. Flooding Considerations

 One of the main goals in trying to delay the database synchronization
 is to be able to reduce unnecessary OSPF packets traversing these
 links.  Since the unsynchronized Adjacencies remain in 2-way state,
 OSPF updates will not be flooded over the corresponding interfaces,
 resulting in additional savings.
 An option is provided to enable or disable flooding over these
 Unsynchronized Adjacencies.  The advantage of allowing flooding is
 being able to use more links for control plane purposes.  We will
 still have the savings of not having to form the adjacency.

Roy & Chandra Experimental [Page 35] RFC 5820 Extensions to OSPF to Support MANETs March 2010

3.5.4.4. Overlapping Relay (OR) Election Impact

 The overlapping relay election algorithm uses the 2-hop neighborhood
 it gleans from our neighbor's router-LSAs.  The introduction of
 Unsynchronized Adjacencies needs to be considered in the relay
 election algorithm.
 If flooding is enabled on unsynchronized Adjacencies, no change is
 needed in the relay election algorithm.  If flooding is disabled,
 then the relay election algorithm needs to prune neighbors that are
 connected via an Unsynchronized Adjacency from our 1-hop and 2-hop
 neighbor lists.

4. Security Considerations

 In a MANET, security is both more difficult and important, due to the
 wireless nature of the medium.  Controlling the ability of devices to
 connect to a MANET at Layer 2 will be relegated to Layer 2 security
 mechanisms, such as 802.1x, and others.  Controlling the ability of
 attached devices to transmit traffic will require some type of
 security system (outside the scope of this document) that can
 authenticate, and provide authorization for, individual members of
 the routing domain.
 Additional security considerations are similar to any MANET protocol
 extension.  The following text is from [MDR]:
 As with OSPFv3 [OSPFv3], OSPF-OR can use the IPv6 Authentication
 Header (AH) [AH] and/or the IPv6 Encapsulation Security Payload (ESP)
 [ESP] to provide authentication, integrity, and/or confidentiality.
 The use of AH and ESP for OSPFv3 is described in [OSPFv3-SEC].
 Generic threats to routing protocols are described and categorized in
 [THREATS].  The mechanisms described in [OSPFv3-SEC] provide
 protection against many of these threats, but not all of them.  In
 particular, as mentioned in [OSPFv3], these mechanisms do not provide
 protection against compromised, malfunctioning, or misconfigured
 routers (also called Byzantine routers); this is true for both OSPFv3
 and OSPF-OR.
 The extension of OSPFv3 to include MANET routers does not introduce
 any new security threats.  However, the use of a wireless medium and
 lack of infrastructure, inherent with MANET routers, may render some
 of the attacks described in [THREATS] easier to mount.  Depending on
 the network context, these increased vulnerabilities may increase the
 need to provide authentication, integrity, and/or confidentiality, as
 well as anti-replay service.

Roy & Chandra Experimental [Page 36] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 For example, sniffing of routing information and traffic analysis are
 easier tasks with wireless routers than with wired routers, since the
 attacker only needs to be within the radio range of a router.  The
 use of confidentiality (encryption) provides protection against
 sniffing but not traffic analysis.
 Similarly, interference attacks are also easier to mount against
 MANET routers due to their wireless nature.  Such attacks can be
 mounted even if OSPF packets are protected by authentication and
 confidentiality, e.g., by transmitting noise or replaying outdated
 OSPF packets.  As discussed below, an anti-replay service (provided
 by both ESP and AH) can be used to protect against the latter attack.
 The following threat actions are also easier with MANET routers:
 spoofing (assuming the identity of a legitimate router),
 falsification (sending false routing information), and overloading
 (sending or triggering an excessive amount of routing updates).
 These attacks are only possible if authentication is not used, or the
 attacker takes control of a router or is able to forge legitimacy
 (e.g., by discovering the cryptographic key).
 [OSPFv3-SEC] mandates the use of manual keying when current IPsec
 protocols are used with OSPFv3.  Routers are required to use manually
 configured keys with the same security association (SA) parameters
 for both inbound and outbound traffic.  For MANET routers, this
 implies that all routers attached to the same MANET must use the same
 key for multicasting packets.  This is required in order to achieve
 scalability and feasibility, as explained in [OSPFv3-SEC].  Future
 specifications can explore the use of automated key management
 protocols that may be suitable for MANETs.
 As discussed in [OSPFv3-SEC], the use of manual keys can increase
 vulnerability.  For example, manual keys are usually long lived, thus
 giving an attacker more time to discover the keys.  In addition, the
 use of the same key on all routers attached to the same MANET leaves
 all routers insecure against impersonation attacks if any one of the
 routers is compromised.
 Although [AH] and [ESP] state that implementations of AH and ESP
 SHOULD NOT provide anti-replay service in conjunction with SAs that
 are manually keyed, it is important to note that such service is
 allowed if the sequence number counter at the sender is correctly
 maintained across local reboots until the key is replaced.
 Therefore, it may be possible for MANET routers to make use of the
 anti-replay service provided by AH and ESP.

Roy & Chandra Experimental [Page 37] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 When an OSPF routing domain includes both MANETs and fixed networks,
 the frequency of OSPF updates either due to actual topology changes
 or malfeasance could result in instability in the fixed networks.  In
 situations where this is a concern, it is recommended that the border
 routers segregate the MANETs from the fixed networks with either
 separate OSPF areas or, in cases where legacy routers are very
 sensitive to OSPF update frequency, separate OSPF instances.  With
 separate OSPF areas, the 5-second MinLSInterval will dampen the
 frequency of changes originated in the MANETs.  Additionally, OSPF
 ranges can be configured to aggregate prefixes for the areas
 supporting MANETs.  With separate OSPF instances, more conservative
 local policies can be employed to limit the volume of updates
 emanating from the MANETs.

5. IANA Considerations

 IANA has made the assignments as explained below using the policies
 outlined in [IANA].
 o  I-bit and F-bit from "LLS Type 1 Extended Options and Flags"
    registry as defined below:
 +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
 | * | * | * | * | * | * | * |...| * | * | * | * | F | I | RS| LR|
 +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
                Bits in Extended Options and Flags TLV
 o  New TLV types from the "Link Local Signalling TLV Identifiers (LLS
    Types)" registry as defined below:
    TLV Name                      TLV Type
    --------                      --------
    State Check Sequence TLV          6
    Neighbor Drop TLV                 7
    Request From TLV                  8
    Full State For TLV                9
    Active Overlapping Relay TLV      10
    Willingness TLV                   11
 o  A new registry has been defined for LD Options as defined in
    Section 3.5.4.1.  The U-bit is allocated by this document.
    All future additions to LD Options are subject to OSPF WG review
    and require IETF Review.

Roy & Chandra Experimental [Page 38] RFC 5820 Extensions to OSPF to Support MANETs March 2010

6. Contributors

 The following persons are contributing authors to the document:
 Fred Baker                         Dave Cook
 Cisco Systems                      Cisco Systems
 1121 Via Del Rey                   7025-4 Kit Creek Road
 Santa Barbara, CA 93117            Research Triangle Park, NC 27709
 USA                                USA
 EMail: fred@cisco.com              EMail: dacook@cisco.com
 Alvaro Retana                      Yi Yang
 Cisco Systems                      Cisco Systems
 7025-4 Kit Creek Road              7025-4 Kit Creek Road
 Research Triangle Park, NC 27709   Research Triangle Park, NC 27709
 USA                                USA
 EMail: aretana@cisco.com           EMail: yiya@cisco.com
 Russ White
 Cisco Systems
 7025-4 Kit Creek Road
 Research Triangle Park, NC 27709
 USA
 EMail: riw@cisco.com

7. Acknowledgments

 The authors and contributors would like to thank Pratap Pellakuru and
 Stan Ratliff for their feedback and implementation of the document.
 Thanks to Richard Ogier and John Avery for doing a final review.

8. References

8.1. Normative References

 [OSPF]         Moy, J., "OSPF Version 2", STD 54, RFC 2328,
                April 1998.
 [OSPFv3]       Coltun, R., Ferguson, D., Moy, J., and A. Lindem,
                "OSPF for IPv6", RFC 5340, July 2008.
 [LLS]          Zinin, A., Roy, A., Nguyen, L., Friedman, B., and
                D. Yeung, "OSPF Link-Local Signaling", RFC 5613,
                August 2009.

Roy & Chandra Experimental [Page 39] RFC 5820 Extensions to OSPF to Support MANETs March 2010

 [IANA]         Narten, T. and H. Alvestrand, "Guidelines for Writing
                an IANA Considerations Section in RFCs", BCP 26,
                RFC 5226, May 2008.
 [KEY]          Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2. Informative References

 [IPV6ADD]      Hinden, R. and S. Deering, "IP Version 6 Addressing
                Architecture", RFC 4291, February 2006.
 [OSPFGR]       Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful
                OSPF Restart", RFC 3623, November 2003.
 [OSPFREST]     Nguyen, L., Roy, A., and A. Zinin, "OSPF Restart
                Signaling", RFC 4812, March 2007.
 [OOB]          Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band
                Link State Database (LSDB) Resynchronization",
                RFC 4811, March 2007.
 [OLSR]         Clausen, T., Ed., and P. Jacquet, Ed., "Optimized Link
                State Routing Protocol (OLSR)", RFC 3626,
                October 2003.
 [WINTF]        Ahrenholz J., et al., "OSPFv2 Wireless Interface
                Type", Work in Progress, May 2004.
 [MDR]          Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network
                (MANET) Extension of OSPF Using Connected Dominating
                Set (CDS) Flooding", RFC 5614, August 2009.
 [AH]           Kent, S., "IP Authentication Header", RFC 4302,
                December 2005.
 [ESP]          Kent, S., "IP Encapsulating Security Payload (ESP)",
                RFC 4303, December 2005.
 [OSPFv3-SEC]   Gupta, M. and N. Melam,
                "Authentication/Confidentiality for OSPFv3", RFC 4552,
                June 2006.
 [THREATS]      Barbir, A., Murphy, S., and Y. Yang, "Generic Threats
                to Routing Protocols", RFC 4593, October 2006.

Roy & Chandra Experimental [Page 40] RFC 5820 Extensions to OSPF to Support MANETs March 2010

Authors' Addresses

 Abhay Roy (Editor)
 Cisco Systems
 170 W. Tasman Drive
 San Jose, CA 95134
 USA
 EMail: akr@cisco.com
 Madhavi W. Chandra (Editor)
 113 Holmhurst Court
 Cary, NC 27519
 EMail: mw.chandra@gmail.com

Roy & Chandra Experimental [Page 41]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5820.txt · Last modified: 2010/03/19 01:04 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki