One document matched: draft-chandra-ospf-manet-ext-00.txt
OSPF Working Group Madhavi W. Chandra
Internet Draft Editor
Expiration Date: August 2004 Cisco Systems
File Name: draft-chandra-ospf-manetext-00.txt February 2004
Extensions to OSPF to Support Mobile Ad Hoc Networking
draft-chandra-ospf-manet-ext-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
The list of current Internet-Drafts can be accessed at
http//www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http//www.ietf.org/shadow.html.
Abstract
This document describes extensions to OSPF to support mobile ad hoc
networking. Specifically, the document specifies a mechanism for
link-local signaling, a 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.
Chandra [Page 1]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
1. Motivation
Mobile Ad Hoc Networks 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 are being proposed and
seriously considered for deployment in the near term, which means the
concepts and research now needs to be applied to deployed networks.
Towards that end, this draft applies many of the principles and
concepts learned through prior work to the OSPFv3 protocol, 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
of 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, there is no central hub or controller, and 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
Chandra [Page 2]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
decentralized systems, there are no central controllers or specially
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 [1]
and [2]) to operate on MANET networks 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 network to "plug in" to just
about any location within a wire-line network, and 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
MANET networks, this adds complexity and overhead to the MANET/wire-
line 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 understand and widely
deployed routing protocol. This provides a strong basis of experience
and skills from which to work. A protocol which is known to work can
be extended, rather than developing a new protocol, which must then
be completely tested, troubleshoot, 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 which are already known to work.
2. Proposed Enhancements
This document proposes modifications to OSPF [1], [2], to support
mobile ad hoc networks (MANETs).
The challenges with deploying standard OSPF [1], [2], in a MANET
environment fit into two categories. First, traditional link-state
routing protocols were designed for a static environment. As a
result, most of the configuration is done manually when a new router
is placed in the network. Thus, OSPF will not continue to function in
the presence of interfaces being arbitrarily connected and
disconnected. There are modifications that must be made in order for
routers running the same protocol to communicate in a heterogeneous
and dynamic environment. Second, a MANET network must transmit more
Chandra [Page 3]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
state information to maintain reachability. Therefore, OSPF will need
scalability enhancements to support MANETs.
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 fall into is scalability. 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 because it cannot be assumed that there is two-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 device 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 static 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 radio types, different antenna,
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 increase both the size
of routing updates and cause extra flooding resulting in even
relatively small networks not converging.
Chandra [Page 4]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
2.1. Link Local Signaling
Link Local signaling (LLS) describes a modification to OSPFv3 [2] to
support exchanging arbitrary data on a link, and is designed
analogously to the LLS for OSPFv2 [1] described in [8]. OSPFv3 packet
formats are not flexible to introduce new information needed to be
exchanged among neighbors on a link. This section proposes a
Type/Length/Value (TLV) style data block which is capable of carrying
future extension data.
To perform LLS, OSPFv3 routers add a special data block at the end of
OSPFv3 packets. The length of the LLS block is not included in the
OSPFv3 packet length field, but is included in the IP packet length,
as illustrated below.
+---------------------+ --
| IPv6 Header | ^
| Length = HL+X+Y | | Header Length
| | v
+---------------------+ --
| OSPFv3 Header | ^
| Length = X | |
|.....................| | X
| | |
| OSPFv3 Data | |
| | v
+---------------------+ --
| | ^
| LLS Data | | Y
| | v
+---------------------+ --
The LLS data block may be attached to OSPFv3 Hello and Database
Descriptor (DD) packets. The data included in LLS block attached to a
Hello packet may be used for dynamic signaling, since Hello packets
may be sent at any moment in time. However, delivery of LLS data in
Hello packets is not guaranteed. The data sent with DD packets is
guaranteed to be delivered as soon as the adjacency proceeds.
This document does not specify how the data transmitted by the LLS
mechanism should be interpreted by OSPFv3 routers. The interface
between OSPFv3 LLS component and its clients is implementation
specific.
Chandra [Page 5]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
2.1.1. Options Field
A new bit, called L (L stands for LLS) is introduced to OSPFv3
Options field (see Figure 2). The value of the bit is TBD; the next
available bit is used for the purposes of this document. Routers set
the L bit in Hello and DD packets to indicate that the packet
contains LLS data block.
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+
| | | | | | | | | | | | | | | |L|AF|DC| R| N|MC| E|V6|
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+
The L-bit is set only in Hello and DD packets. It is not set in
OSPFv3 LSAs and may be used in them for different purposes.
2.1.2. LLS Data Block
The data block used for LLS is described below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | LLS Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LLS TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o The Checksum field contains the standard IP checksum of the
entire contents of the LLS block.
o The 16-bit LLS Data Length field contains the length (in 32-bit
words) of the LLS block including the header and payload. Imple-
mentations should not use the Length field in the IP packet
header to determine the length of the LLS data block.
o The rest of the block contains a set of Type/Length/Value (TLV)
triplets as described in the LLS TLVs section. All TLVs must be
32-bit aligned (with padding if necessary).
Chandra [Page 6]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
2.1.3. LLS TLVs
The of LLS data block is constructed using TLVs.
The type field contains the TLV ID which is unique for each type of
TLVs. The Length field contains the length of the Value field (in
bytes) that is variable and contains arbitrary data.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that TLVs are always padded to 32-bit boundary, but padding
bytes are not included in TLV Length field (though it is included in
the LLS Data Length field of the LLS block header). Note that the
value of 0 is reserved.
2.1.4. Extended Options TLV
This subsection describes a TLV called Extended Options (EO) TLV. The
format of EO-TLV is shown below.
Bits in the Value field do not have any semantics from the point of
view of LLS mechanism. This field may be used to announce some OSPFv3
capabilities that are link-specific. Also, other OSPFv3 extensions
may allocate bits in the bit vector to perform boolean 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Set to 1.
o Length: Set to 4.
o Extended Options: A Bit Map
Only one EO-TLV should appear in the LLS data block.
Chandra [Page 7]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
2.1.5. Compatibility Issues
The modifications to OSPFv3 packet formats are compatible with stan-
dard OSPFv3, because LLS-incapable routers will not consider the
extra data after the packet.
2.2. OSPF-MANET Interface
Interfaces are defined as the connection between a router and one of
its attached networks [1]. Four types of interfaces have been defined
and supported in [1] and [2]: broadcast, NBMA, point-to-point, and
point-to-multipoint.
Broadcast, NBMA and point-to-point interfaces do not accurately model
MANET interfaces for the following reasons:
o Broadcast and NBMA requires homogeneous communications across
the network, i.e., if node A can communicate with node B and C
directly over the broadcast/NBMA interface, then node B and node
C must also be able to communicate with each other directly over
the corresponding interfaces. However, this is not always valid
for MANET interfaces.
o Multiple neighbors may exist on a single physical MANET inter-
face. Although it is possible to represent each neighbor as a
point-to-point sub interface, by doing that, the
broadcast/multicast potential of the MANET interfaces will not
be leveraged.
Point-to-multipoint model has been chose to represent MANET inter-
faces. In other words, a MANET interface is treated as a collection
of point-to-point links. And the MANET interface allows 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.
o 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.
Chandra [Page 8]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
o The MANET interface supports Layer-2 pseudo-broadcast if it
is able to pick up a packet from the broadcast queue, repli-
cate 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 clas-
sifies 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 inter-
face supports Layer-2 broadcast or pseudo-broadcast, the multi-
cast process is transparent to OSPF. Otherwise, OSPF MUST repli-
cate multicast packets by itself.
o When the MANET interface supports Layer-2 broadcast, OSPF uses
OSPF Hello packets to discover neighbors. Otherwise, the Layer-2
MUST provide an API to inform OSPF when a new neighbor is
detected.
2.2.1. Interface Operation
A MANET node has at least one MANET interface. MANET nodes can com-
municate with each other through MANET interfaces. MANET nodes can
communicate with non-MANET devices only through normal interfaces,
such as Ethernet, ATM and etc.
For scalability reason, 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.
2.2.2. LSA Formats and Examples
LSA formats are specified in [2].
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.
Chandra [Page 9]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
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 loop-
back interface.
+---+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)
Node Interface IPv6 global unicast prefix
-----------------------------------------------------------
RT1 LOOPBACK 5f00:0001::/64
I11 n/a
RT2 LOOPBACK 5f00:0002::/64
I21 n/a
I22 n/a
I23 5f00:0012::/60
RT3 LOOPBACK 5f00:0003::/64
I31 n/a
RT4 LOOPBACK 5f00:0004::/64
I41 n/a
I42 n/a
Chandra [Page 10]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
The OSPF interface IDs and the link local addresses for the router
interfaces in the network illustrated above below. EUIxy represents
the 64-bit interface identifier of the interface Ixy, in Modified
EUI-64 format [4].
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
2.2.2.1. Router LSAs
As an example, consider the router LSAs that node RT2 would ori-
ginate. Two MANET interfaces, consisting of 3 point-to-point links,
are presented.
RT2's router-LSA
LS age = 0 ;newly (re)originated
LS type = 0x2001 ;router-LSA
Link State ID = 0 ;first fragment
Advertising Router = 192.1.1.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.1.1.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.1.1.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
Chandra [Page 11]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
Neighbor Interface ID = 2 ;Interface ID of I41
Neighbor Router ID = 192.1.1.4 ;RT4's Router ID
2.2.2.2. Link LSAs
A MANET node originates a separate Link-LSA for each attached inter-
face. 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 = 0 ;newly (re)originated
LS type = 0x0008 ;Link-LSA
Link State ID = 2 ;Interface ID of I31
Advertising Router = 192.1.1.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
2.2.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, con-
sider the intra area prefix LSA that RT2 will build.
RT2's intra area prefix LSA for its own prefixes
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;intra area prefix LSA
Link State ID = 177 ;or something else
Advertising Router = 192.1.1.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.1.1.2
;RT2's Router ID
PrefixLength = 64 ;prefix on RT2's LOOPBACK
PrefixOptions = 0
Metric = 0 ;cost of RT2's LOOPBACK
Address Prefix = 5f00:0002::
PrefixLength = 60 ;prefix on I23
PrefixOptions = 0
Metric = 10 ;cost of I23
Address Prefix = 5f00:0012:: ;pad to 64-bit
Chandra [Page 12]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
Note: MANET nodes may originate Intra-Area-Prefix-LSAs for attached
transit (broadcast/NBMA) networks. This is normal behavior defined in
[2], which is irrelevant to MANET interfaces. Please consult [2] for
details.
2.3. Incremental OSPF-MANET Hellos
In MANETs, reducing the size of periodically transmitted packets can
be very important in decreasing the total amount of overhead associ-
ated with routing. Towards this end, removing the list of neighbors
from Hello packets unless that information changes can reduce the
overhead offered by the routing protocol by a small, but over a long
period of time, significant, amount.
A new option bit is defined in this document to facilitate the opera-
tion of incremental Hello packets. A new State Check Sequence TLV and
Neighbor Drop TLV are also defined, transmitted using the LLS tech-
nique described in the Link Local Signalling section.
2.3.1. The I Option Bit
A single new option bit is defined in the OSPFv3 option field
(defined in [2], A.2), the I bit, which indicates only newly
discovered neighbors are listed in the list of neighbors defined in
[2], A.3.2.
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+
| | | | | | | | | | | | | | |I|L|AF|DC| R| N|MC| E|V6|
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+
2.3.2. State Check Sequence TLV
A new TLV is defined in this document that indicates the current
state, which is represented by an State Check Sequence (SCS) number
of the transmitting device.
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|A| Reserved |
+---------------------------------------------------------------+
Chandra [Page 13]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
o Type: Type, set to 2.
o Length: Set to 4.
o SCS Number: A circular two octet unsigned integer indicating the
current state of the transmitting device.
o R: If set, this is a request for current state. In this case,
SCS Number field SHOULD be set to zero, and ignored upon recep-
tion.
o A: If set, this is a response to a request for current state.
o Reserved: Set to 0. Reserved for future use.
Note that a Hello with the State Check Sequence TLV appended with the
R bit set will be referred to as a Hello request.
2.3.3. Neighbor Drop TLV
A new TLV is defined in this document which indicates previously
adjacent 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: Type, set to 3.
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.
Chandra [Page 14]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
2.3.4. Neighbor Adjacencies
This section describes building neighbor adjacencies and the failure
of such adjacencies using the incremental Hello signaling.
2.3.4.1. Building Neighbor Adjacencies
Hello packets are sent periodically in accordance with [1] and [2],
except in special cases specified in this document. An OSPF implemen-
tation which 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 pack-
ets MAY be suppressed from being transmitted every HelloInterval if
other packet transmissions are sent by the device during that time.
On receiving a Hello packet from a new neighbor, if the Hello has the
I bit set, a router will:
o Place the new neighbor in the neighbor list described in [2],
A.3.2.
o Increment the SCS number indicated in the State Check Sequence
TLV.
o When the neighbor has reached the EXCHANGE state, described in
[1], 10.1, it is removed from the list of neighbors described in
[2], A.3.2.
o If the neighbor is not a DR or backup designated router (BDR) on
an OSPF broadcast link, and the neighbor is advertised as con-
nected in the Network LSA advertised by the DR, it is removed
from the list of neighbors described in [2], A.3.2.
2.3.4.2. Adjacency Failure
On discovering an adjacency failure, 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 [1] and
[2].
o Add the formerly adjacent router to a Neighbor Drop TLV.
Chandra [Page 15]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
o Increment the SCS number in transmitted Hello's.
o Transmit Hellos with this Neighbor Drop TLV at HelloInterval
until RouterDeadInterval has passed.
2.3.5. Sending Hello's
When a device comes up, it will first need to obtain complete neigh-
bor state from each of its peers before it can utilize the incremen-
tal Hello mechanism. Thus, upon initialization, a device MAY send a
multicast Hello request. 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 unicast a Hello request to 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 receiv-
ing a Hello request, the neighbor will respond with its neighbor
state for the peer.
Note that both the R and A bits may be set in the Hello packet, i.e.,
a response to a Hello request that in turn is also a Hello request.
2.3.6. Receiving Hello's
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 adja-
cency 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. If is it NOT a
wrap around, then the device MUST send a Hello request to the neigh-
bor.
If it is a wrap around or if a device receives a Hello from an adja-
cent 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 [2], A.3.2. If any neigh-
bors are contained in this list, increment the SCS number con-
tained in the adjacent neighbor's data structure.
Chandra [Page 16]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
o Examine the drop list described in the section Adjacency
Failure. 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 drop list described in the section Adjacency
Failure. If the local router identifier is contained in this
list, destroy the transmitting adjacent neighbor's data struc-
tures.
o Examine any other TLVs incrementally signaled, as described in
drafts referring to this document. 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, unicast a Hello packet with the last known SCS number
from this adjacent neighbor (taken from the adjacent neighbor's
dat structure) and the R bit set to the adjacent neighbor this
Hello was received from.
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.
Receiving Hello's with the R Bit Set
If a device receives a Hello with the State Check Sequence TLV
included, and the R bit set, it SHOULD unicast a Hello with the
current full state of the transmitting neighbor to the transmitting
neighbor. This MUST include:
o The neighbor ID of the transmitting neighbor in the list of
neighbors described in [2], A.3.2.,
o An State Check Sequence TLV with the transmitter's current SCS
number, and the A bit set, and
o Any other TLVs, defined in other drafts referencing this docu-
ment, indicating the current state of the local system.
Note that Hellos that are sent via multicast MUST include the
device's entire neighbor list since the Hello will be processed
by all peers.
Receiving Hello's with the A Bit Set
Chandra [Page 17]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
When a device receives a Hello with the State Check Sequence TLV
included, and the A bit set, the Hello packet contains the neighbor's
complete state for the device. The packet SHOULD be processed as fol-
lows:
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, the device must check whether its router ID is listed
either in the neighbor list or Neighbor Drop TLV.
o If it is listed in the received neighbor list, the device MUST
save the SCS number, process the Hello as described in the
Receiving Hellos section, and process any other appended TLVs.
o If the router ID is listed in the Neighbor Drop TLV, the
transmitting adjacent neighbor's data structures SHOULD be des-
troyed.
2.3.7. Interoperation with Implementations not Supporting this Signaling
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 [2], A.3.2.
2.3.8. Support for OSPF Graceful Restart
OSPF graceful restart, as described in [5] and [6], relies on the
lack of neighbors in the list of neighbors described in [2], A.3.2,
to determine that an adjacent router has restarted, and other signal-
ing to determine the adjacency should not be torn down. If all Hello
packets transmitted by a given router have an empty Hello list, reli-
ance on an empty Hello packet to signal a restart (or to reliably
tear down an OSPF adjacency) is no longer possible. This signaling,
then must be slightly altered.
When a router would like to tear down all adjacencies, or signal 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
Chandra [Page 18]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
or other signaling may be included in these initial Hello pack-
ets.
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, all learned neighbors
in 2-way state or above are removed from transmitted Hello pack-
ets, and the I bit is set.
Routers which are peering with a restarting router MUST continue
sending their Hello packets with the I bit set.
2.4. Optimized Flooding - Overlapping Relays
A component that may influence the scalability and convergence
characteristics of OSPF [1],[2] in a MANET environment is how much
information needs to be flooded. The ideal solution is that a router
will only receive a particular routing update only once. However,
there must be a tradeoff 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 mes-
sages.
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 possi-
ble causes are the following: low signal strength, long distance
separation, environmental disruptions, partial VC meshing, etc. Note
that in these networks, a logical segment refers to the local flood-
ing 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.
Chandra [Page 19]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
2.4.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 [1],[2].
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 origina-
tor 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 the Flooding and Relay Descisions section. Because more than one
such speaker may exist, the 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.
2.4.2. Determination of Overlapping Relays
The first step in the process is for each speaker to build and pro-
pagate their neighbor lists in router LSAs packets. Every speaker is
then in a position to determine their two-hop neighborhood, i.e.,
those nodes that are peers of the speaker's one-hop peers. A peer is
considered an overlapping relay for a speaker if it can reach a node
in the two-hop neighborhood of the peer, i.e., if it has one-hop
neighbors.
The set of active overlapping relays for a speaker is the minimum set
of direct neighbors such that every node in the two-hop neighborhood
of the speaker is a peer of a least one overlapping relay in the
active set. Each speaker SHOULD select a set of active overlapping
relays based on the MPR selection algorithm given in [7]. Note that
a speaker MUST NOT choose a peer to serve as an active overlapping
relay if that peer advertised a Willingness parameter as defined in
Willingness TLV section of WILL_NEVER.
Chandra [Page 20]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
2.4.3. Terminology
The following heuristic and terminology for active overlapping relay
selection is largely taken from [7]:
o FULL: Neighbor state FULL as defined in [1][2]. Note that all
neighbor references in this document are assumed to be FULL
neighbors.
o 2-hop FULL neighbors: 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 with Willingness dif-
ferent from WILL_NEVER, selected such that through these
selected nodes, all 2-hop FULL neighbors are reachable.
o N: N is the set of FULL neighbors of the node
o N2: A subset of 2-hop FULL neighbors excluding the nodes only
reachable by members of N with Willingness of WILL_NEVER.
o D(y): The degree of a one hop neighbor node y (where y is a
member of N), is defined as the number of symmetric neighbors of
node y, EXCLUDING all the members of N and EXCLUDING the node
performing the computation.
2.4.4. Overlapping Relay Discovery Process
The process for discovering overlapping relays is:
1. Start with an active set made of all members of N with WILLING-
NESS equal to WILL_ALWAYS. [WILLINGNESS is defined in Willing-
ness TLV section.]
1.1. If more than one such member of N provides reachability to the
exact same set of nodes in N2, then choose only one of the
members, e.g., the member with the highest router ID.
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
Chandra [Page 21]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
which are now covered by a node in the active set.
4. While there exist nodes in N2 which are not covered by at least
one node in the active set:
4.1. For each node in N, calculate the reachability, i.e., the number
of nodes in N2 which are not yet covered by at least one node in
the active set, and which are reachable through this one hop
neighbor;
4.2. Select as an active overlapping relay the node with highest Wil-
lingness among the nodes in N with non-zero reachability. In
case of multiple choice select the node which provides reacha-
bility to the maximum number of nodes in N2. In case of multiple
nodes providing the same amount of reachability, select the node
as active 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 which are now covered by a node in the active set.
5. As an optimization, process each node, y, in the active set in
increasing order of Willingness. 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 WILL_ALWAYS, then
node y SHOULD be removed from the active set.
2.4.5. Active Overlapping Relay Extension
Each speaker conveys its set of active overlapping relays by append-
ing the following extension in Figure 9 to its Hello message
described in Incremental OSPF-MANET Hellos.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID(s) of Active Overlapping Relay(s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Type, set to 4.
o Length - variable; Length of TLV in bytes NOT including Type and
Chandra [Page 22]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
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 Router ID(s) of Active Overlapping Relay(s) - The router ID(s)
of peer(s) that are either chosen to serve as an active overlap-
ping 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 list of relays are being dropped as active
overlapping relays, and the number of such relays MUST equal
[(Length - 4)/4 - Relays Added].
2.4.6. Willingness TLV
Each speaker conveys its willingness to serve as an active overlap-
ping relay, by appending the following extension:
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: Type, set to 5.
o Length - variable; Length of TLV in bytes NOT including Type and
Length.
o Willingness - 1 byte to indicate the willingness of the node to
serve as an active overlapping relay for its peers.
0: WILL_NEVER
128: WILL_DEFAULT
255: WILL_ALWAYS
Chandra [Page 23]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
2.4.7. 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 an adjacent speaker, 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 MUST 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 MUST wait a specified amount of time
(PushbackInterval plus jitter, see Important Timers) to decide
whether to transmit. [Jitter is used to try to avoid several
non-active overlapping relays from propagating redundant infor-
mation.] Note that a node with Willingness of WILL_NEVER will
not be chosen as an active overlapping relay. However, it MUST
perform the duties of a non-active overlapping relay as
required. Non-active overlapping relays MUST follow the ack-
nowledgment mechanism outlined in the section Intelligent
Transmission of Link State Acknowledgements.
2.1. During this time, if the node determines that its 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.
2.2. If a non-active overlapping relay hears a re-flood from another
overlapping relay that covers its non-overlapping neighbors
before its timer to transmit expires, it MUST reset its (Push-
backInterval plus jitter) timer. During this time, if the node
determines that its flooding the update will only result in a
redundant transmission, the node MUST suppress its transmission.
Otherwise, it MUST transmit upon expiration of PushbackInterval
+ jitter.
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 LSA
in its database, it MUST do nothing further in terms of flooding
the LSA (since it would have taken appropriate behavior when it
initially received the LSA.) However, if it does not have the
LSA in its database, it MUST take action according to the rules
above, just as if it received the multicast LSA. The
Chandra [Page 24]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
acknowledgement mechanism outlined in the section Intelligent
Transmission of Link State Acknowledgements MUST be followed,
and any timeout mechanism for unicast LSAs MAY be followed.
Note that a node can determine whether its further flooding a LSA
will only result in a redundant transmission by already having heard
link state acknowledgements (ACKs) or floods for the LSA from all of
its peers.
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 situa-
tion 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.
2.4.8. Intelligent Transmission of Link State Acknowledgements
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 speak-
ers. In the case of relayed information, the relay MUST only
expect either explicit or implicit acknowledgements from peers
that have not previously acknowledged this LSA. The retransmis-
sion procedures, if any exist, for the underlying protocol MUST
be followed.
3. Because routing updates are sent via multicast, the set of over-
lapping 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 acknowledgement to the sender. If no information is
being relayed, than an explicit ACK MUST be sent.
Chandra [Page 25]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
5. Several ACKs MAY be bundled into a single packet. The wait (Ack-
Interval) 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 redun-
dant transmission of the information to it by another overlapping
relay.
2.4.9. Important Timers
This section details the timers that are introduced in the Flooding
and Relay Decisions and Intelligent Transmission of Link State Ack-
nowledgements sections.
PushbackInterval:
The length of time in seconds that a non-active overlapping
relay MUST wait before further flooding an LSA if needed. This
timer MUST be less than 1/2 of the RxmtInterval [1],[2] minus
propagation delays, i.e., (PushbackInterval + propagation delay)
< RxmtInterval/2. The PushbackInterval is set by a non-active
overlapping relay upon reception of an LSA.
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 acknowledgement packet. This wait reduces the number of
packet transmissions required in acknowledging multiple LSAs.
The AckInterval MUST be less than the PushbackInterval minus
propagation delays, i.e., (AckInterval + propagation delay) <
PushbackInterval.
Chandra [Page 26]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
2.4.10. 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
routing 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 mechanisms in OSPF relies on a designated speaker to
guarantee that any information reaches all of the connected nodes on
the same media. In other words, such designated speakers must be able
to reach all of the other speakers on the same subnet. A designated
speaker SHOULD NOT be elected if overlapping relays are used.
If such designated speakers already exist, then the relays MUST be
capable of differentiating them, and then making the relaying deci-
sions 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 complex-
ity 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. IANA Considerations
This document creates several new name spaces. This section summar-
izes them and the criteria to be used for their assignment. It is
expected that IANA will maintain a registry and make the assignments
as explained below using the policies outlined in RFC2434 [3].
The "LLS TLVs" section defines a two-octet field called Type to
uniquely identify each type of TLV. Type 0 is reserved. Values 1
through 32767 are to be assigned using the "IETF Consensus" policy;
values 1 through 5 are assigned in this document. Values 32768
through 49151 are to be assigned using "Specification Required."
Chandra [Page 27]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
Values 49152 and above are for "Private Use."
The "Extended Options TLV" section defines a four-octet bitfield
called Extended Options. Values 0x00000001 through 0x08000000 are to
be assigned using the "IETF Consensus." Values 0x10000000 through
0x80000000 are for "Private Use."
The assignment of any of the Reserved fields requires the review of
the OSPF WG.
In addition to the maintenance of the name spaces described above,
IANA is is expected to assign the following:
An option bit value for the L-bit defined in the "Link-local Signal-
ing" section.
An option bit value for the I-bit defined in the "The I Option Bit"
section.
4. Security Considerations
In a MANET network, security is both more difficult and important due
to the wireless nature of the medium. Controlling the ability of dev-
ices to connect to a MANET network at Layer 2 will be relegated to
Layer 2 security mechanisms, such as 802.1x, and others. Controlling
the ability of attached devices to transit traffic will require some
type of security system (outside the scope of this document) which
can authenticate and provide authorization for individual members of
the routing domain.
5. 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 RTP, NC 27709
USA USA
Email: fred@cisco.com Email: dacook@cisco.com
Phone: +1-408-526-4257 Phone: +1-919-392-8772
Alvaro Retana Abhay Roy
Cisco Systems Cisco Systems
7025-4 Kit Creek Road 170 W. Tasman Drive
RTP, NC 27709 San Jose, CA 95134
Chandra [Page 28]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
USA USA
Email: aretana@cisco.com Email: akr@cisco.com
Phone: +1-919-392-2061 Phone: +1-408-527-2028
Russ White Yi Yang
Cisco Systems Cisco Systems
7025-4 Kit Creek Road 7025-4 Kit Creek Road
RTP, NC 27709 RTP, NC 27709
USA USA
Email: riw@cisco.com Email: yiya@cisco.com
Phone: +1-919-392-3139 Phone: +1-919-392-4035
6. Acknowledgements
The authors and contributors would like to thank Pratap Pellakuru and
Stan Ratliff for their feedback and implementation of the document.
7. References
7.1. Normative References
[1] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[2] Coltun, R., Ferguson, D., Moy, J., "OSPF for IPv6", RFC 2740,
December 1999.
[3] Narten, T., and Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
7.2. Informative References
[4] Hinden, R., and Deering, S., "IP Version 6 Addressing Architec-
ture", RFC 3513, April 2003.
[5] Moy, J., "Graceful OSPF Restart", draft-ietf-ospf-hitless-
restart-08.txt July 2003
[6] Zinin, A., "OSPF Restart Signaling", draftnguyen-ospf-restart-
Chandra [Page 29]
INTERNET DRAFT Extensions to OSPF to Support MANET February 2004
03.txt June 2003
[7] Clausen, T., ed, Jacquet, P., ed, "Optimized Link State Routing
Protocol", draft-ietf-manet-olsr-11.txt, IETF, July 2003.
[8] Zinin, A., Friedman, B., Roy, A., Nguyen, L., and Yeung, D.,
OSPF Link Local Signaling, draft-nguyen-ospf-lls-04.txt, IETF,
Jan. 2004.
8. Editor's Address:
Madhavi W. Chandra
Cisco Systems
7025-4 Kit Creek Road
RTP, NC 27709
USA
Email: mchandra@cisco.com
Phone: +1-919-392-8387
Chandra [Page 30]
| PAFTECH AB 2003-2026 | 2026-04-24 04:15:25 |