summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5820.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5820.txt')
-rw-r--r--doc/rfc/rfc5820.txt2299
1 files changed, 2299 insertions, 0 deletions
diff --git a/doc/rfc/rfc5820.txt b/doc/rfc/rfc5820.txt
new file mode 100644
index 0000000..33e1473
--- /dev/null
+++ b/doc/rfc/rfc5820.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+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).
+
+ -----------------------------------------------------------
+ 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]
+