draft-ietf-ospf-manet-mpr-02.txt   draft-ietf-ospf-manet-mpr-03.txt 
Open Shortest Path (OSPF) E. Baccelli Open Shortest Path (OSPF) E. Baccelli
Internet-Draft P. Jacquet Internet-Draft P. Jacquet
Intended status: Experimental INRIA Intended status: Experimental INRIA
Expires: April 3, 2009 D. Nguyen Expires: May 22, 2009 D. Nguyen
CRC CRC
T. Clausen T. Clausen
LIX, Ecole Polytechnique, France LIX, Ecole Polytechnique, France
September 30, 2008 November 18, 2008
OSPF MPR Extension for Ad Hoc Networks OSPF MPR Extension for Ad Hoc Networks
draft-ietf-ospf-manet-mpr-02 draft-ietf-ospf-manet-mpr-03
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 3, 2009. This Internet-Draft will expire on May 22, 2009.
Abstract Abstract
This document specifies an OSPFv3 interface type tailored for mobile This document specifies an OSPFv3 interface type tailored for mobile
ad hoc networks. This interface type is derived from the broadcast ad hoc networks. This interface type is derived from the broadcast
interface type, and denoted the "OSPFv3 MANET interface type". interface type, and denoted the "OSPFv3 MANET interface type".
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 31 skipping to change at page 2, line 31
5.1.8. MPR-selector set . . . . . . . . . . . . . . . . . . . 10 5.1.8. MPR-selector set . . . . . . . . . . . . . . . . . . . 10
5.2. Hello Protocol . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Hello Protocol . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Flooding-MPR Selection . . . . . . . . . . . . . . . . 11 5.2.1. Flooding-MPR Selection . . . . . . . . . . . . . . . . 11
5.2.2. Flooding-MPR Selection Signaling - FMPR TLV . . . . . 11 5.2.2. Flooding-MPR Selection Signaling - FMPR TLV . . . . . 11
5.2.3. Neighbor Ordering . . . . . . . . . . . . . . . . . . 11 5.2.3. Neighbor Ordering . . . . . . . . . . . . . . . . . . 11
5.2.4. Metric Signaling - METRIC TLV and PMPR TLV . . . . . . 12 5.2.4. Metric Signaling - METRIC TLV and PMPR TLV . . . . . . 12
5.2.5. Path-MPR Selection . . . . . . . . . . . . . . . . . . 12 5.2.5. Path-MPR Selection . . . . . . . . . . . . . . . . . . 12
5.2.6. Path-MPR Selection Signaling - PMPR TLV . . . . . . . 12 5.2.6. Path-MPR Selection Signaling - PMPR TLV . . . . . . . 12
5.2.7. Hello Packet Processing . . . . . . . . . . . . . . . 13 5.2.7. Hello Packet Processing . . . . . . . . . . . . . . . 13
5.3. Adjacencies . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Adjacencies . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Packets over 2-Way Links . . . . . . . . . . . . . . . 13 5.3.1. Packets over 2-Way Links . . . . . . . . . . . . . . . 14
5.3.2. Adjacency Conservation . . . . . . . . . . . . . . . . 14 5.3.2. Adjacency Conservation . . . . . . . . . . . . . . . . 14
5.4. Link State Advertisements . . . . . . . . . . . . . . . . 14 5.4. Link State Advertisements . . . . . . . . . . . . . . . . 14
5.4.1. LSA Flooding . . . . . . . . . . . . . . . . . . . . . 15 5.4.1. LSA Flooding . . . . . . . . . . . . . . . . . . . . . 15
5.4.2. Link State Acknowledgments . . . . . . . . . . . . . . 16 5.4.2. Link State Acknowledgments . . . . . . . . . . . . . . 16
5.5. Hybrid Routers . . . . . . . . . . . . . . . . . . . . . . 17 5.5. Hybrid Routers . . . . . . . . . . . . . . . . . . . . . . 17
5.6. Synch Routers . . . . . . . . . . . . . . . . . . . . . . 17 5.6. Synch Routers . . . . . . . . . . . . . . . . . . . . . . 18
5.7. Routing Table Computation . . . . . . . . . . . . . . . . 18 5.7. Routing Table Computation . . . . . . . . . . . . . . . . 18
6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Flooding-MPR TLV . . . . . . . . . . . . . . . . . . . . 18 6.1. Flooding-MPR TLV . . . . . . . . . . . . . . . . . . . . 18
6.2. Metric TLV . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Metric TLV . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Path-MPR TLV . . . . . . . . . . . . . . . . . . . . . . 21 6.3. Path-MPR TLV . . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Flooding-MPR Selection Heuristic . . . . . . . . . . 26 Appendix A. Flooding-MPR Selection Heuristic . . . . . . . . . . 27
Appendix B. Path-MPR Selection Heuristic . . . . . . . . . . . . 27 Appendix B. Path-MPR Selection Heuristic . . . . . . . . . . . . 28
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 28 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 29
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . . 29 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
This document specifies an extension of OSPFv3 [RFC5340] adapted to This document specifies an extension of OSPFv3 [RFC5340] adapted to
MANETs [RFC2501], and based on mechanisms providing: MANETs [RFC2501], and based on mechanisms providing:
Flooding reduction: only a subset of all routers will be involved in Flooding reduction: only a subset of all routers will be involved in
(re)transmissions during a flooding operation. (re)transmissions during a flooding operation.
Topology reduction: only a subset of links are advertised, hence Topology reduction: only a subset of links are advertised, hence
skipping to change at page 6, line 40 skipping to change at page 6, line 40
4.2. MPR Topology Reduction 4.2. MPR Topology Reduction
OSPFv3 MANET interfaces use a topology reduction mechanism denoted OSPFv3 MANET interfaces use a topology reduction mechanism denoted
MPR topology reduction, whereby only necessary links to MANET MPR topology reduction, whereby only necessary links to MANET
neighbors (those identified by Path-MPR selection as belonging to neighbors (those identified by Path-MPR selection as belonging to
shortest paths) are included in LSAs. Routers in a MANET shortest paths) are included in LSAs. Routers in a MANET
periodically generate and flood Router-LSAs describing their periodically generate and flood Router-LSAs describing their
selection of such links to their Path-MPRs. Such links are reported selection of such links to their Path-MPRs. Such links are reported
as point-to-point links. This reduces the size of LSAs originated by as point-to-point links. This reduces the size of LSAs originated by
routers on a MANET [MPR-topology], while retaining classic OSPF routers on a MANET [MPR-topology], while retaining classic OSPF
properties: optimal paths using synchronized adjacencies. properties: optimal paths using synchronized adjacencies (if
synchronized paths are preferred over non-synchronized paths of equal
cost).
4.3. Multicast Transmissions of Protocol Packets 4.3. Multicast Transmissions of Protocol Packets
OSPFv3 MANET interfaces employ multicast transmissions, when OSPFv3 MANET interfaces employ multicast transmissions, when
possible, thereby taking advantage of inherent broadcast capabilities possible, thereby taking advantage of inherent broadcast capabilities
of the medium, if present (with wireless interfaces, this can often of the medium, if present (with wireless interfaces, this can often
be the case [RFC2501]). In particular, LSA acknowledgments are sent be the case [RFC2501]). In particular, LSA acknowledgments are sent
via multicast over these interfaces, and retransmissions over the via multicast over these interfaces, and retransmissions over the
same interfaces are considered as implicit acknowledgments. Jitter same interfaces are considered as implicit acknowledgments. Jitter
management, such as delaying packet (re)transmission, can be employed management, such as delaying packet (re)transmission, can be employed
skipping to change at page 13, line 12 skipping to change at page 13, line 12
The list of neighbor IDs is followed by a list of costs for the links The list of neighbor IDs is followed by a list of costs for the links
from these neighbors and to the router generating the Hello packet from these neighbors and to the router generating the Hello packet
containing this PMPR TLV, as detailed in Section 5.2.4. The PMPR TLV containing this PMPR TLV, as detailed in Section 5.2.4. The PMPR TLV
structure is detailed in Section 6.3. structure is detailed in Section 6.3.
5.2.7. Hello Packet Processing 5.2.7. Hello Packet Processing
In addition to the processing specified in [RFC5340], N and N2 MUST In addition to the processing specified in [RFC5340], N and N2 MUST
be updated when received Hello packets indicate changes to the be updated when received Hello packets indicate changes to the
neighborhood of an OSPFv3 MANET interface. The Flooding-MPR set and neighborhood of an OSPFv3 MANET interface. In particular, if a
the Path-MPR set MUST then be recomputed when either of N or N2 has received Hello packet signals that a tuple in N (or N2) is to be
changed. deleted, the deletion is done immediately, without waiting for the
tuple to expire. Note that N2 records not only 2-hop neighbors
listed in received Hellos, but also 2-hop neighbors listed in the
appended PMPR TLVs.
Moreover, the Flooding-MPR selector set and the Path-MPR selector set The Flooding-MPR set and the Path-MPR set MUST then be recomputed
MUST be updated upon receipt of a Hello packet containing LLS when either of N or N2 has changed. Moreover, the Path-MPR set MUST
information indicating changes in the list of neighbors that has be recomputed if appended LLS information signals change with respect
selected the router as MPR. to one or more link cost(s).
The Flooding-MPR selector set and the Path-MPR selector set MUST be
updated upon receipt of a Hello packet containing LLS information
indicating changes in the list of neighbors that has selected the
router as MPR.
If a Hello with the S bit set is received on a OSPFv3 MANET interface
of a router, from a non-adjacent neighbor, the router MUST transition
this neighbor's state to ExStart.
5.3. Adjacencies 5.3. Adjacencies
Adjacencies are brought up between OSPFv3 MANET interfaces as Adjacencies are brought up between OSPFv3 MANET interfaces as
described in [RFC5340] and [RFC2328]. However, in order to reduce described in [RFC5340] and [RFC2328]. However, in order to reduce
the control traffic overhead over the OSPFv3 MANET interfaces, a the control traffic overhead over the OSPFv3 MANET interfaces, a
router which has one or more such OSPFv3 MANET interface(s) MAY bring router which has one or more such OSPFv3 MANET interface(s) MAY bring
up adjacencies with only subset of its MANET neighbors. up adjacencies with only subset of its MANET neighbors.
Over an OSPFv3 MANET interface, a router MUST bring up adjacencies Over an OSPFv3 MANET interface, a router MUST bring up adjacencies
with all MANET neighbors which are included in its MPR set and its with all MANET neighbors which are included in its MPR set and its
MPR Selector set; this ensures that beyond the first hop, routes use MPR Selector set; this ensures that beyond the first hop, routes use
synchronized links. A router MAY bring up adjacencies with other synchronized links (if synchronized paths are preferred over non-
MANET neighbors, at the expense of additional synchronization synchronized paths of equal cost). A router MAY bring up adjacencies
overhead. with other MANET neighbors, at the expense of additional
synchronization overhead.
5.3.1. Packets over 2-Way Links 5.3.1. Packets over 2-Way Links
When a router does not form a full adjacency with a MANET neighbor, When a router does not form a full adjacency with a MANET neighbor,
the state of that neighbor does not progress beyond 2-Way (as defined the state of that neighbor does not progress beyond 2-Way (as defined
in [RFC2328]). A router can send protocol packets, such as LSAs, to in [RFC2328]). A router can send protocol packets, such as LSAs, to
a MANET neighbor in 2-Way state. Therefore, any packet received from a MANET neighbor in 2-Way state. Therefore, any packet received from
a symmetric MANET neighbor MUST be processed. a symmetric MANET neighbor MUST be processed.
As with the OSPF broadcast interface [RFC2328], the next hop in the As with the OSPF broadcast interface [RFC2328], the next hop in the
forwarding table MAY be a neighbor that is not adjacent. However, forwarding table MAY be a neighbor that is not adjacent. However,
when a data packet has travelled beyond its first hop, the MPR when a data packet has travelled beyond its first hop, the MPR
selection process guarantees that subsequent hops in the SPT will be selection process guarantees that subsequent hops in the SPT will be
over adjacencies. over adjacencies (if synchronized paths are preferred over non-
synchronized paths of equal cost).
5.3.2. Adjacency Conservation 5.3.2. Adjacency Conservation
Adjacencies are torn down according to [RFC2328]. When the MPR set Adjacencies are torn down according to [RFC2328]. When the MPR set
or MPR selector set is updated (due to changes in the neighborhood), or MPR selector set is updated (due to changes in the neighborhood),
and when a neighbor was formerly, but is no longer, in the MPR set or and when a neighbor was formerly, but is no longer, in the MPR set or
the MPR selector set, then the adjacency with that neighbor is kept, the MPR selector set, then the adjacency with that neighbor is kept,
unless the change causes the neighbor to cease being a symmetric unless the change causes the neighbor to cease being a symmetric
1-hop neighbor. 1-hop neighbor.
When a router receives Hello packets from a symmetric 1-hop neighbor When a router receives Hello packets from a symmetric 1-hop neighbor
which ceases to list this router as being adjacent (see which ceases to list this router as being adjacent (see
Section 5.2.3), the state of that neighbor MUST be changed to (i) Section 5.2.6), the state of that neighbor MUST be changed to (i)
2-Way if the neighbor is not in the MPR set or the MPR selector set, 2-Way if the neighbor is not in the MPR set or the MPR selector set,
or (ii) ExStart if the neighbor is in the MPR set or the MPR selector or (ii) ExStart if the neighbor is in the MPR set or the MPR selector
set, or if the neighbor or the router itself is a Synch router. set, or if the neighbor or the router itself is a Synch router.
5.4. Link State Advertisements 5.4. Link State Advertisements
Routers generate Router-LSAs periodically, using the format specified Routers generate Router-LSAs periodically, using the format specified
in [RFC5340] and [RFC2328]. in [RFC5340] and [RFC2328].
Routers which have one or more OSPFv3 MANET interface(s) MUST include Routers which have one or more OSPFv3 MANET interface(s) MUST include
skipping to change at page 14, line 47 skipping to change at page 15, line 13
In addition, routers which have one or more OSPFv3 MANET interface(s) In addition, routers which have one or more OSPFv3 MANET interface(s)
MUST generate updated Router-LSAs when either of the following MUST generate updated Router-LSAs when either of the following
occurs: occurs:
o a new adjacency has been brought up, reflecting a change in the o a new adjacency has been brought up, reflecting a change in the
MPR set; MPR set;
o a new adjacency has been brought up, reflecting a change in the o a new adjacency has been brought up, reflecting a change in the
MPR Selector set; MPR Selector set;
o a formerly adjacent and advertised neighbor ceases to be adjacent. o a formerly adjacent and advertised neighbor ceases to be adjacent;
o the cost of a link to (or from) an advertised neighbor has
changed.
5.4.1. LSA Flooding 5.4.1. LSA Flooding
An originated LSA is flooded according to [RFC5340], out all
interfaces concerned by the scope of this LSA.
Link State Updates received on an interface of a type other than Link State Updates received on an interface of a type other than
OSPFv3 MANET interface are processed and flooded according to OSPFv3 MANET interface are processed and flooded according to
[RFC2328] and [RFC5340], over every interface. If a Link State [RFC2328] and [RFC5340], over every interface. If a Link State
Update was received on an OSPFv3 MANET interface, it is processed as Update was received on an OSPFv3 MANET interface, it is processed as
follows: follows:
1. Consistency checks are performed on the received packet according 1. Consistency checks are performed on the received packet according
to [RFC2328] and [RFC5340], and the Link State Update packet is to [RFC2328] and [RFC5340], and the Link State Update packet is
thus associated with a particular neighbor and a particular area. thus associated with a particular neighbor and a particular area.
skipping to change at page 17, line 48 skipping to change at page 18, line 13
generated Router-LSAs. generated Router-LSAs.
5.6. Synch Routers 5.6. Synch Routers
In a network with no hybrid routers, at least one Synch router MUST In a network with no hybrid routers, at least one Synch router MUST
be selected. A Synch router MUST: be selected. A Synch router MUST:
o set the S bit in the PMPR TLV appended to the Hello packets it o set the S bit in the PMPR TLV appended to the Hello packets it
generates; AND generates; AND
o bring up adjacencies with ALL MANET neighbors. o become adjacent with ALL MANET neighbors.
A proposed heuristic for selection of Sync routers is as follows: A proposed heuristic for selection of Sync routers is as follows:
o A router which has a MANET interface and an ID that is higher than o A router which has a MANET interface and an ID that is higher than
the ID of all of its current neighbors, and whose ID is higher the ID of all of its current neighbors, and whose ID is higher
than any other ID present in Router-LSAs currently in its Link than any other ID present in Router-LSAs currently in its Link
State Database selects itself as Synch router. State Database selects itself as Synch router.
Other heuristics are possible, however any heuristic for selecting Other heuristics are possible, however any heuristic for selecting
Synch routers MUST ensure the presence of at least one sync or hybrid Synch routers MUST ensure the presence of at least one sync or hybrid
router in the network. router in the network.
5.7. Routing Table Computation 5.7. Routing Table Computation
When routing table (re)computation occurs, in addition to the When routing table (re)computation occurs, in addition to the
processing of the Link State Database defined in [RFC5340] and processing of the Link State Database defined in [RFC5340] and
[RFC2328], routers which have one or more MANET interfaces MAY [RFC2328], routers which have one or more MANET interfaces MUST take
include links between themselves and MANET neighbors that are in into account links between themselves and MANET neighbors that are in
state 2-Way or higher (as data and protocol packets may be sent, state 2-Way or higher (as data and protocol packets may be sent,
received and processed over these links too). received and processed over these links too). Thus, the connectivity
matrix used to compute routes MUST reflect links between the root and
all its neighbors in state 2-Way and higher, as well as links
described in the Link State Database.
6. Packet Formats 6. Packet Formats
OSPFv3 packets are as defined by [RFC5340] and [RFC2328]. Additional OSPFv3 packets are as defined by [RFC5340] and [RFC2328]. Additional
LLS signaling [RFC4813] is used in Hello packets sent over OSPFv3 LLS signaling [RFC4813] is used in Hello packets sent over OSPFv3
MANET interfaces, as detailed in this section. MANET interfaces, as detailed in this section.
This specification uses network byte order (most significant octet This specification uses network byte order (most significant octet
first) for all fields. first) for all fields.
skipping to change at page 29, line 7 skipping to change at page 30, line 7
sets. sets.
Appendix C. Contributors Appendix C. Contributors
The authors would like to thank Cedric Adjih, Acee Lindem, Padma The authors would like to thank Cedric Adjih, Acee Lindem, Padma
Pillay-Esnault and Laurent Viennot for their contributions to this Pillay-Esnault and Laurent Viennot for their contributions to this
document. document.
Appendix D. Acknowledgments Appendix D. Acknowledgments
The authors would like to thank Juan Antonio Cordero Fuertes and The authors would like to thank Juan Antonio Cordero Fuertes, Ulrich
Ulrich Herberg for their reviewing of this document. Herberg and Richard Ogier for reviewing this document.
Authors' Addresses Authors' Addresses
Emmanuel Baccelli Emmanuel Baccelli
INRIA INRIA
Phone: +33 1 69 33 55 11 Phone: +33 1 69 33 55 11
EMail: Emmanuel.Baccelli@inria.fr EMail: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/ URI: http://www.emmanuelbaccelli.org/
 End of changes. 19 change blocks. 
35 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/