draft-ietf-manet-olsrv2-14.txt   draft-ietf-manet-olsrv2-15.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique Internet-Draft LIX, Ecole Polytechnique
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: September 9, 2012 BAE Systems ATC Expires: November 16, 2012 BAE Systems ATC
P. Jacquet P. Jacquet
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
U. Herberg U. Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
March 8, 2012 May 15, 2012
The Optimized Link State Routing Protocol version 2 The Optimized Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-14 draft-ietf-manet-olsrv2-15
Abstract Abstract
This specification describes version 2 of the Optimized Link State This specification describes version 2 of the Optimized Link State
Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 9, 2012. This Internet-Draft will expire on November 16, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Routers and Interfaces . . . . . . . . . . . . . . . . . 13 4.2. Routers and Interfaces . . . . . . . . . . . . . . . . . 13
4.3. Information Base Overview . . . . . . . . . . . . . . . . 14 4.3. Information Base Overview . . . . . . . . . . . . . . . . 14
4.3.1. Local Information Base . . . . . . . . . . . . . . . 14 4.3.1. Local Information Base . . . . . . . . . . . . . . . 14
4.3.2. Interface Information Bases . . . . . . . . . . . . . 14 4.3.2. Interface Information Bases . . . . . . . . . . . . . 14
4.3.3. Neighbor Information Base . . . . . . . . . . . . . . 15 4.3.3. Neighbor Information Base . . . . . . . . . . . . . . 14
4.3.4. Topology Information Base . . . . . . . . . . . . . . 15 4.3.4. Topology Information Base . . . . . . . . . . . . . . 15
4.3.5. Received Message Information Base . . . . . . . . . . 16 4.3.5. Received Message Information Base . . . . . . . . . . 16
4.4. Signaling Overview . . . . . . . . . . . . . . . . . . . 16 4.4. Signaling Overview . . . . . . . . . . . . . . . . . . . 16
4.5. Link Metrics . . . . . . . . . . . . . . . . . . . . . . 18 4.5. Link Metrics . . . . . . . . . . . . . . . . . . . . . . 18
4.6. Routing Set Use . . . . . . . . . . . . . . . . . . . . . 19 4.6. Routing Set Use . . . . . . . . . . . . . . . . . . . . . 19
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 19 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 19
5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 20 5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 19
5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 20 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 20
5.3. Interface Parameters . . . . . . . . . . . . . . . . . . 20 5.3. Interface Parameters . . . . . . . . . . . . . . . . . . 20
5.3.1. Received Message Validity Time . . . . . . . . . . . 20 5.3.1. Received Message Validity Time . . . . . . . . . . . 20
5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 21 5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 20
5.4.1. Local History Times . . . . . . . . . . . . . . . . . 21 5.4.1. Local History Times . . . . . . . . . . . . . . . . . 20
5.4.2. Link Metric Parameters . . . . . . . . . . . . . . . 21 5.4.2. Link Metric Parameters . . . . . . . . . . . . . . . 21
5.4.3. Message Intervals . . . . . . . . . . . . . . . . . . 21 5.4.3. Message Intervals . . . . . . . . . . . . . . . . . . 21
5.4.4. Advertised Information Validity Times . . . . . . . . 22 5.4.4. Advertised Information Validity Times . . . . . . . . 22
5.4.5. Processing and Forwarding Validity Times . . . . . . 22 5.4.5. Processing and Forwarding Validity Times . . . . . . 22
5.4.6. Jitter . . . . . . . . . . . . . . . . . . . . . . . 23 5.4.6. Jitter . . . . . . . . . . . . . . . . . . . . . . . 23
5.4.7. Hop Limit . . . . . . . . . . . . . . . . . . . . . . 23 5.4.7. Hop Limit . . . . . . . . . . . . . . . . . . . . . . 23
5.4.8. Willingness . . . . . . . . . . . . . . . . . . . . . 24 5.4.8. Willingness . . . . . . . . . . . . . . . . . . . . . 24
5.5. Parameter Change Constraints . . . . . . . . . . . . . . 25 5.5. Parameter Change Constraints . . . . . . . . . . . . . . 25
5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 27 5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 27
5.6.1. Link Metric Constants . . . . . . . . . . . . . . . . 27 5.6.1. Link Metric Constants . . . . . . . . . . . . . . . . 27
skipping to change at page 3, line 25 skipping to change at page 3, line 25
9. Neighbor Information Base . . . . . . . . . . . . . . . . . . 31 9. Neighbor Information Base . . . . . . . . . . . . . . . . . . 31
10. Topology Information Base . . . . . . . . . . . . . . . . . . 33 10. Topology Information Base . . . . . . . . . . . . . . . . . . 33
10.1. Advertising Remote Router Set . . . . . . . . . . . . . . 33 10.1. Advertising Remote Router Set . . . . . . . . . . . . . . 33
10.2. Router Topology Set . . . . . . . . . . . . . . . . . . . 34 10.2. Router Topology Set . . . . . . . . . . . . . . . . . . . 34
10.3. Routable Address Topology Set . . . . . . . . . . . . . . 34 10.3. Routable Address Topology Set . . . . . . . . . . . . . . 34
10.4. Attached Network Set . . . . . . . . . . . . . . . . . . 35 10.4. Attached Network Set . . . . . . . . . . . . . . . . . . 35
10.5. Routing Set . . . . . . . . . . . . . . . . . . . . . . . 36 10.5. Routing Set . . . . . . . . . . . . . . . . . . . . . . . 36
11. Received Message Information Base . . . . . . . . . . . . . . 36 11. Received Message Information Base . . . . . . . . . . . . . . 36
11.1. Received Set . . . . . . . . . . . . . . . . . . . . . . 37 11.1. Received Set . . . . . . . . . . . . . . . . . . . . . . 37
11.2. Processed Set . . . . . . . . . . . . . . . . . . . . . . 37 11.2. Processed Set . . . . . . . . . . . . . . . . . . . . . . 37
11.3. Forwarded Set . . . . . . . . . . . . . . . . . . . . . . 38 11.3. Forwarded Set . . . . . . . . . . . . . . . . . . . . . . 37
12. Information Base Properties . . . . . . . . . . . . . . . . . 38 12. Information Base Properties . . . . . . . . . . . . . . . . . 38
12.1. Corresponding Protocol Tuples . . . . . . . . . . . . . . 38
12.2. Address Ownership . . . . . . . . . . . . . . . . . . . . 39
13. Packets and Messages . . . . . . . . . . . . . . . . . . . . 40 13. Packets and Messages . . . . . . . . . . . . . . . . . . . . 40
13.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . 40 13.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . 40
13.2. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 40 13.2. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 40
13.3. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 40 13.3. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 41
13.3.1. Message TLVs . . . . . . . . . . . . . . . . . . . . 41 13.3.1. Message TLVs . . . . . . . . . . . . . . . . . . . . 41
13.3.2. Address Block TLVs . . . . . . . . . . . . . . . . . 41 13.3.2. Address Block TLVs . . . . . . . . . . . . . . . . . 41
14. Message Processing and Forwarding . . . . . . . . . . . . . . 43 14. Message Processing and Forwarding . . . . . . . . . . . . . . 43
14.1. Actions when Receiving a Message . . . . . . . . . . . . 44 14.1. Actions when Receiving a Message . . . . . . . . . . . . 44
14.2. Message Considered for Processing . . . . . . . . . . . . 45 14.2. Message Considered for Processing . . . . . . . . . . . . 45
14.3. Message Considered for Forwarding . . . . . . . . . . . . 46 14.3. Message Considered for Forwarding . . . . . . . . . . . . 46
15. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . 47 15. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . 47
15.1. HELLO Message Generation . . . . . . . . . . . . . . . . 48 15.1. HELLO Message Generation . . . . . . . . . . . . . . . . 48
15.2. HELLO Message Transmission . . . . . . . . . . . . . . . 50 15.2. HELLO Message Transmission . . . . . . . . . . . . . . . 50
15.3. HELLO Message Processing . . . . . . . . . . . . . . . . 50 15.3. HELLO Message Processing . . . . . . . . . . . . . . . . 50
skipping to change at page 4, line 48 skipping to change at page 4, line 50
24.3. Message-Type-Specific TLV Type Registries . . . . . . . . 84 24.3. Message-Type-Specific TLV Type Registries . . . . . . . . 84
24.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 85 24.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 85
24.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 86 24.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 86
24.6. NBR_ADDR_TYPE and MPR Values . . . . . . . . . . . . . . 89 24.6. NBR_ADDR_TYPE and MPR Values . . . . . . . . . . . . . . 89
25. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 89 25. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 89
26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 90 26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 90
27. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 90
27.1. Normative References . . . . . . . . . . . . . . . . . . 90 27.1. Normative References . . . . . . . . . . . . . . . . . . 90
27.2. Informative References . . . . . . . . . . . . . . . . . 91 27.2. Informative References . . . . . . . . . . . . . . . . . 91
Appendix A. Example Algorithm for Calculating MPRs . . . . . . . 91 Appendix A. Example Algorithm for Calculating MPRs . . . . . . . 91
A.1. Additional Notation . . . . . . . . . . . . . . . . . . . 91 A.1. Additional Notation . . . . . . . . . . . . . . . . . . . 92
A.2. MPR Selection Algorithm . . . . . . . . . . . . . . . . . 92 A.2. MPR Selection Algorithm . . . . . . . . . . . . . . . . . 92
Appendix B. Example Algorithm for Calculating the Routing Set . 93 Appendix B. Example Algorithm for Calculating the Routing Set . 93
B.1. Local Interfaces and Neighbors . . . . . . . . . . . . . 93 B.1. Local Interfaces and Neighbors . . . . . . . . . . . . . 93
B.2. Add Neighbor Routers . . . . . . . . . . . . . . . . . . 94 B.2. Add Neighbor Routers . . . . . . . . . . . . . . . . . . 94
B.3. Add Remote Routers . . . . . . . . . . . . . . . . . . . 94 B.3. Add Remote Routers . . . . . . . . . . . . . . . . . . . 94
B.4. Add Neighbor Addresses . . . . . . . . . . . . . . . . . 96 B.4. Add Neighbor Addresses . . . . . . . . . . . . . . . . . 96
B.5. Add Remote Routable Addresses . . . . . . . . . . . . . . 96 B.5. Add Remote Routable Addresses . . . . . . . . . . . . . . 96
B.6. Add Attached Networks . . . . . . . . . . . . . . . . . . 97 B.6. Add Attached Networks . . . . . . . . . . . . . . . . . . 97
B.7. Add 2-Hop Neighbors . . . . . . . . . . . . . . . . . . . 97 B.7. Add 2-Hop Neighbors . . . . . . . . . . . . . . . . . . . 98
Appendix C. TC Message Example . . . . . . . . . . . . . . . . . 98 Appendix C. TC Message Example . . . . . . . . . . . . . . . . . 98
Appendix D. Constraints . . . . . . . . . . . . . . . . . . . . 100 Appendix D. Constraints . . . . . . . . . . . . . . . . . . . . 101
Appendix E. Flow and Congestion Control . . . . . . . . . . . . 105 Appendix E. Flow and Congestion Control . . . . . . . . . . . . 105
1. Introduction 1. Introduction
The Optimized Link State Routing protocol version 2 (OLSRv2) is an The Optimized Link State Routing protocol version 2 (OLSRv2) is the
update to OLSR (version 1) as published in [RFC3626]. Compared to successor to OLSR (version 1) as published in [RFC3626]. Compared to
[RFC3626], OLSRv2 retains the same basic mechanisms and algorithms, [RFC3626], OLSRv2 retains the same basic mechanisms and algorithms,
enhanced by the ability to use a link metric other than hop count in enhanced by the ability to use a link metric other than hop count in
the selection of shortest routes. OLSRv2 also uses a more flexible the selection of shortest routes. OLSRv2 also uses a more flexible
and efficient signaling framework, and includes some simplification and efficient signaling framework, and includes some simplification
of the messages being exchanged. of the messages being exchanged.
OLSRv2 is developed for mobile ad hoc networks (MANETs). It operates OLSRv2 is developed for mobile ad hoc networks (MANETs). It operates
as a table driven, proactive protocol, i.e., it exchanges topology as a table driven, proactive protocol, i.e., it exchanges topology
information with other routers in the network regularly. OLSRv2 is information with other routers in the network regularly. OLSRv2 is
an optimization of the classic link state routing protocol. Its key an optimization of the classic link state routing protocol. Its key
skipping to change at page 7, line 8 skipping to change at page 7, line 8
MPRs and routing MPRs. MPRs and routing MPRs.
A router selects both routing and flooding MPRs from among its one A router selects both routing and flooding MPRs from among its one
hop neighbors connected by "symmetric", i.e., bidirectional, links. hop neighbors connected by "symmetric", i.e., bidirectional, links.
Therefore, selecting routes through routing MPRs avoids the problems Therefore, selecting routes through routing MPRs avoids the problems
associated with data packet transfer over unidirectional links (e.g., associated with data packet transfer over unidirectional links (e.g.,
the problem of not getting link layer acknowledgments at each hop, the problem of not getting link layer acknowledgments at each hop,
for link layers employing this technique). for link layers employing this technique).
OLSRv2 uses and extends the MANET NeighborHood Discovery Protocol OLSRv2 uses and extends the MANET NeighborHood Discovery Protocol
(NHDP) defined in [RFC6130] and also uses the MANET generalized (NHDP) defined in [RFC6130] and also uses the Generalized MANET
packet/message format [RFC5444], the TLVs specified in [RFC5497] and, Packet/Message Format [RFC5444], the TLVs specified in [RFC5497] and,
optionally, message jitter as specified in [RFC5148]. These four optionally, message jitter as specified in [RFC5148]. These four
other protocols and specifications were all originally created as other protocols and specifications were all originally created as
part of OLSRv2, but have been specified separately for wider use. part of OLSRv2, but have been specified separately for wider use.
OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, OLSRv2 makes no assumptions about the underlying link layer. OLSRv2,
through its use of [RFC6130], may use link layer information and through its use of [RFC6130], may use link layer information and
notifications when available and applicable. In addition, OLSRv2 notifications when available and applicable. In addition, OLSRv2
uses link metrics that may be derived from link layer or any other uses link metrics that may be derived from link layer or any other
information. OLSRv2 does not specify the physical meaning of link information. OLSRv2 does not specify the physical meaning of link
metrics, but specifies a means by which new types of link metrics may metrics, but specifies a means by which new types of link metrics may
skipping to change at page 10, line 5 skipping to change at page 10, line 5
interfaces, which will consist of some or all of its MANET interfaces, which will consist of some or all of its MANET
interfaces using [RFC6130]. The set of a router's OLSRv2 interfaces using [RFC6130]. The set of a router's OLSRv2
interfaces, and the sets of its other MANET and non-MANET interfaces, and the sets of its other MANET and non-MANET
interfaces, may change over time. Each interface may have one or interfaces, may change over time. Each interface may have one or
more network addresses (which may have prefix lengths), and these more network addresses (which may have prefix lengths), and these
may also be dynamically changing. may also be dynamically changing.
o Enables hop-by-hop routing, i.e., each router can use its local o Enables hop-by-hop routing, i.e., each router can use its local
information provided by this protocol to route packets. information provided by this protocol to route packets.
o Enables source routing, i.e., each router can use its local
information provided by this protocol to specify the complete path
for a packet. (This will require the retention of additional
information during the Routing Set evaluation.)
o Continuously maintains routes to all destinations in the network, o Continuously maintains routes to all destinations in the network,
i.e., routes are instantly available and data traffic is subject i.e., routes are instantly available and data traffic is subject
to no delays due to route discovery. Consequently, no data to no delays due to route discovery. Consequently, no data
traffic buffering is required. traffic buffering is required.
o Supports routers that have non-OLSRv2 interfaces that may be local o Supports routers that have non-OLSRv2 interfaces that may be local
to a router or that can serve as gateways towards other networks. to a router or that can serve as gateways towards other networks.
o Enables the use of bidirectional additive link metrics to use o Enables the use of bidirectional additive link metrics to use
shortest distance routes (i.e., routes with smallest total of link shortest distance routes (i.e., routes with smallest total of link
skipping to change at page 16, line 43 skipping to change at page 16, line 36
received by this router on that OLSRv2 interface. received by this router on that OLSRv2 interface.
o A Processed Set, describing TC messages processed by this router. o A Processed Set, describing TC messages processed by this router.
o A Forwarded Set, describing TC messages forwarded by this router. o A Forwarded Set, describing TC messages forwarded by this router.
The Received Message Information Base serves the MPR flooding The Received Message Information Base serves the MPR flooding
mechanism by ensuring that received messages are forwarded at most mechanism by ensuring that received messages are forwarded at most
once by a router, and also ensures that received messages are once by a router, and also ensures that received messages are
processed exactly once by a router. The Received Message Information processed exactly once by a router. The Received Message Information
Base may also record information about other message types that use Base may also record information about other Message Types that use
the MPR flooding mechanism. the MPR flooding mechanism.
4.4. Signaling Overview 4.4. Signaling Overview
This protocol generates and processes HELLO messages according to This protocol generates and processes HELLO messages according to
[RFC6130]. HELLO messages transmitted on OLSRv2 interfaces are [RFC6130]. HELLO messages transmitted on OLSRv2 interfaces are
extended according to Section 15 of this specification to include an extended according to Section 15 of this specification to include an
originator address, link metrics, and MPR selection information. originator address, link metrics, and MPR selection information.
This specification defines a single message type, the TC message. TC This specification defines a single Message Type, the TC message. TC
messages are sent by their originating router proactively, at a messages are sent by their originating router proactively, at a
regular interval, on all OLSRv2 interfaces. This interval may be regular interval, on all OLSRv2 interfaces. This interval may be
fixed, or may be dynamic, for example it may be backed off due to fixed, or may be dynamic, for example it may be backed off due to
congestion or network stability. TC messages may also be sent as a congestion or network stability. TC messages may also be sent as a
response to a change in the router itself, or its advertised response to a change in the router itself, or its advertised
symmetric 1-hop neighborhood, for example on first being selected as symmetric 1-hop neighborhood, for example on first being selected as
a routing MPR. a routing MPR.
Because TC messages are sent periodically, this protocol is tolerant Because TC messages are sent periodically, this protocol is tolerant
of unreliable transmissions of TC messages. Message losses may occur of unreliable transmissions of TC messages. Message losses may occur
skipping to change at page 18, line 24 skipping to change at page 18, line 18
TC messages include outgoing neighbor metrics that will be used in TC messages include outgoing neighbor metrics that will be used in
the selection of routes. the selection of routes.
4.5. Link Metrics 4.5. Link Metrics
OLSRv1 [RFC3626] created minimum hop routes to destinations. However OLSRv1 [RFC3626] created minimum hop routes to destinations. However
in many, if not most, circumstances, better routes (in terms of in many, if not most, circumstances, better routes (in terms of
quality of service for end users) can be created by use of link quality of service for end users) can be created by use of link
metrics. metrics.
OLSRv2, as defined in this specification, allows links to have a OLSRv2, as defined in this specification, supports metric-based
metric (also known as a cost). Link metrics as defined in OLSRv2 are routing, i.e., it allows links to each have a chosen metric. Link
additive, and the routes that are to be created are minimum length metrics as defined in OLSRv2 are additive, and the routes that are to
routes, where the length of a route is defined as the sum of the be created are those with the minimum sum of the link metrics along
metrics of the links in that route. that route.
Link metrics are defined to be directional; the link metric from one Link metrics are defined to be directional; the link metric from one
router to another may be different from that on the reverse link. router to another may be different from that on the reverse link.
The link metric is assessed at the receiver, as on a (typically) The link metric is assessed at the receiver, as on a (typically)
wireless link, that is the better informed as to link information. wireless link, that is the better informed as to link information.
Both incoming and outgoing link information is used by OLSRv2, the Both incoming and outgoing link information is used by OLSRv2, the
distinctions in this specification must be clearly followed. distinctions in this specification must be clearly followed.
This specification also defines both incoming and outgoing neighbor This specification also defines both incoming and outgoing neighbor
metrics for each symmetric 1-hop neighbor, these being the minimum metrics for each symmetric 1-hop neighbor, these being the minimum
skipping to change at page 19, line 8 skipping to change at page 18, line 50
However, this specification allows, through use of the type extension However, this specification allows, through use of the type extension
of a defined Address Block TLV, for link metrics with specific of a defined Address Block TLV, for link metrics with specific
meanings to be defined and either allocated by IANA or privately meanings to be defined and either allocated by IANA or privately
used. Each HELLO or TC message carrying link (or neighbor) metrics used. Each HELLO or TC message carrying link (or neighbor) metrics
thus indicates which link metric information it is carrying, allowing thus indicates which link metric information it is carrying, allowing
routers to determine if they can interoperate. If link metrics routers to determine if they can interoperate. If link metrics
require additional signaling to determine their values, whether in require additional signaling to determine their values, whether in
HELLO messages or otherwise, then this is permitted but is outside HELLO messages or otherwise, then this is permitted but is outside
the scope of this specification. the scope of this specification.
Users are advised that they should carefully consider how to use link Careful consideration should be given to how to use link metrics. In
metrics. In particular they should not simply default to use of all particular it is advisable to not simply default to use of all links
links with equal metrics (i.e., hop count) for routing without with equal metrics (i.e., hop count) for routing without careful
careful consideration of whether that is advisable or not. consideration of whether that is appropriate or not.
4.6. Routing Set Use 4.6. Routing Set Use
The purpose of the Routing Set is to determine and record routes The purpose of the Routing Set is to determine and record routes
(local interface network address and next hop interface network (local interface network address and next hop interface network
address) to all possible routable addresses advertised by this address) to all possible routable addresses advertised by this
protocol, as well as of all destinations that are local, i.e., within protocol, as well as of all destinations that are local, i.e., within
one hop, to the router (whether using routable addresses or not). one hop, to the router (whether using routable addresses or not).
Only symmetric links are used in such routes. Only symmetric links are used in such routes.
skipping to change at page 20, line 8 skipping to change at page 19, line 46
and constants is also used in this specification. and constants is also used in this specification.
As for the parameters in [RFC6130], parameters defined in this As for the parameters in [RFC6130], parameters defined in this
specification MAY be changed dynamically by a router, and need not be specification MAY be changed dynamically by a router, and need not be
the same on different routers, even in the same MANET, or, for the same on different routers, even in the same MANET, or, for
interface parameters, on different interfaces of the same router. interface parameters, on different interfaces of the same router.
5.1. Protocol and Port Numbers 5.1. Protocol and Port Numbers
This protocol specifies TC messages, which are included in packets as This protocol specifies TC messages, which are included in packets as
defined by [RFC5444]. These packets may be sent either using the defined by [RFC5444]. These packets MAY be sent either using the
"manet" protocol number or the "manet" UDP well-known port number, as "manet" protocol number or the "manet" UDP well-known port number, as
specified in [RFC5498]. specified in [RFC5498].
TC messages and HELLO messages [RFC6130] MUST, in a given MANET, both TC messages and HELLO messages [RFC6130] MUST, in a given MANET, both
be using the same of either of IP or UDP, in order that it is be using the same of either of IP or UDP, in order that it is
possible to combine messages of both protocols into the same possible to combine messages of both protocols into the same
[RFC5444] packet for transmission. [RFC5444] packet for transmission.
5.2. Multicast Address 5.2. Multicast Address
This protocol specifies TC messages, which are included in packets as This protocol specifies TC messages, which are included in packets as
defined by [RFC5444]. These packets MAY be transmitted using the defined by [RFC5444]. These packets MAY be transmitted using the
link local multicast address "LL-MANET-Routers", as specified in Link-Local multicast address "LL-MANET-Routers", as specified in
[RFC5498]. [RFC5498].
5.3. Interface Parameters 5.3. Interface Parameters
A single additional interface parameter is specified for OLSRv2 A single additional interface parameter is specified for OLSRv2
interfaces only. interfaces only.
5.3.1. Received Message Validity Time 5.3.1. Received Message Validity Time
The following parameter manages the validity time of recorded The following parameter manages the validity time of recorded
skipping to change at page 21, line 7 skipping to change at page 20, line 41
o RX_HOLD_TIME > 0 o RX_HOLD_TIME > 0
o RX_HOLD_TIME SHOULD be greater than the maximum difference in time o RX_HOLD_TIME SHOULD be greater than the maximum difference in time
that a message may take to traverse the MANET, taking into account that a message may take to traverse the MANET, taking into account
any message forwarding jitter as well as propagation, queuing, and any message forwarding jitter as well as propagation, queuing, and
processing delays. processing delays.
5.4. Router Parameters 5.4. Router Parameters
The following router parameters are specified for routers.
5.4.1. Local History Times 5.4.1. Local History Times
The following router parameter manages the time for which local The following router parameter manages the time for which local
information is retained: information is retained:
O_HOLD_TIME: O_HOLD_TIME:
The time for which a recently used and replaced originator address The time for which a recently used and replaced originator address
is used to recognize the router's own messages. is used to recognize the router's own messages.
The following constraint apply to this parameter: The following constraint applies to this parameter:
o O_HOLD_TIME > 0 o O_HOLD_TIME > 0
5.4.2. Link Metric Parameters 5.4.2. Link Metric Parameters
All routes found using this specification use a single link metric All routes found using this specification use a single link metric
type that is specified by the router parameter LINK_METRIC_TYPE, type that is specified by the router parameter LINK_METRIC_TYPE,
which may take any value from 0 to 255, inclusive. which may take any value from 0 to 255, both inclusive.
5.4.3. Message Intervals 5.4.3. Message Intervals
The following parameters regulate TC message transmissions by a The following parameters regulate TC message transmissions by a
router. TC messages are usually sent periodically, but MAY also be router. TC messages are usually sent periodically, but MAY also be
sent in response to changes in the router's Neighbor Set and/or Local sent in response to changes in the router's Neighbor Set and/or Local
Attached Network Set. In a highly dynamic network, and with a larger Attached Network Set. In a highly dynamic network, and with a larger
value of the parameter TC_INTERVAL and a smaller value of the value of the parameter TC_INTERVAL and a smaller value of the
parameter TC_MIN_INTERVAL, TC messages may be transmitted more often parameter TC_MIN_INTERVAL, TC messages MAY be transmitted more often
in response to changes than periodically. However, because a router in response to changes than periodically. However, because a router
has no knowledge of, for example, routers remote to it (i.e., beyond has no knowledge of, for example, routers remote to it (i.e., beyond
two hops away) joining the network, TC messages MUST NOT be sent two hops away) joining the network, TC messages MUST NOT be sent
purely responsively. purely responsively.
TC_INTERVAL: TC_INTERVAL:
The maximum time between the transmission of two successive TC The maximum time between the transmission of two successive TC
messages by this router. When no TC messages are sent in response messages by this router. When no TC messages are sent in response
to local network changes (by design, or because the local network to local network changes (by design, or because the local network
is not changing) then TC messages MUST be sent at a regular is not changing) then TC messages MUST be sent at a regular
skipping to change at page 27, line 20 skipping to change at page 27, line 12
- L_MPR_selector := false. - L_MPR_selector := false.
+ Remove all Router Topology Tuples, Routable Address Topology + Remove all Router Topology Tuples, Routable Address Topology
Tuples, Attached Network Tuples and Routing Tuples from Tuples, Attached Network Tuples and Routing Tuples from
their respective Protocol Sets in the Topology Information their respective Protocol Sets in the Topology Information
Base. Base.
5.6. Constants 5.6. Constants
The following constants are specified for routers. Unlike router
parameters, constants MUST NOT change, and MUST be the same on all
routers.
5.6.1. Link Metric Constants 5.6.1. Link Metric Constants
The constant minimum and maximum link metric values are defined by: The constant minimum and maximum link metric values are defined by:
o MINIMUM_METRIC := 1 o MINIMUM_METRIC := 1
o MAXIMUM_METRIC := 16776960 o MAXIMUM_METRIC := 16776960
The symbolic value UNKNOWN_METRIC is defined in Section 6.1. The symbolic value UNKNOWN_METRIC is defined in Section 6.1.
skipping to change at page 29, line 33 skipping to change at page 29, line 26
A router's Originator Set records addresses that were recently used A router's Originator Set records addresses that were recently used
as originator addresses by this router. If a router's originator as originator addresses by this router. If a router's originator
address is immutable then the Originator Set is always empty and MAY address is immutable then the Originator Set is always empty and MAY
be omitted. It consists of Originator Tuples: be omitted. It consists of Originator Tuples:
(O_orig_addr, O_time) (O_orig_addr, O_time)
where: where:
O_orig_addr is a recently used originator address; note that this O_orig_addr is a recently used originator address; note that this
does not include a prefix length; does not include a prefix length.
O_time specifies the time at which this Tuple expires and MUST be O_time specifies the time at which this Tuple expires and MUST be
removed. removed.
7.2. Local Attached Network Set 7.2. Local Attached Network Set
A router's Local Attached Network Set records its local non-OLSRv2 A router's Local Attached Network Set records its local non-OLSRv2
interfaces via which it can act as gateways to other networks. The interfaces via which it can act as gateways to other networks. The
Local Attached Network Set is not modified by this protocol. This Local Attached Network Set is not modified by this protocol. This
protocol MAY respond to changes to the Local Attached Network Set, protocol MAY respond to changes to the Local Attached Network Set,
skipping to change at page 30, line 10 skipping to change at page 30, line 6
where: where:
AL_net_addr is the network address of an attached network which AL_net_addr is the network address of an attached network which
can be reached via this router. This SHOULD be a routable can be reached via this router. This SHOULD be a routable
address. It is constrained as described below. address. It is constrained as described below.
AL_dist is the number of hops to the network with network address AL_dist is the number of hops to the network with network address
AL_net_addr from this router. AL_net_addr from this router.
AL_metric is the metric of the link to the attached network with AL_metric is the metric of the link to the attached network with
address AL_net_addr from this router; address AL_net_addr from this router.
Attached networks local to this router only (i.e., not reachable Attached networks local to this router only (i.e., not reachable
except via this router) SHOULD be treated as local non-MANET except via this router) SHOULD be treated as local non-MANET
interfaces, and added to the Local Interface Set, as specified in interfaces, and added to the Local Interface Set, as specified in
[RFC6130], rather than be added to the Local Attached Network Set. [RFC6130], rather than be added to the Local Attached Network Set.
Because an attached network is not specific to the router, and may be Because an attached network is not specific to the router, and may be
outside the MANET, an attached network MAY also be attached to other outside the MANET, an attached network MAY also be attached to other
routers. Routing to an AL_net_addr will use maximum prefix length routers. Routing to an AL_net_addr will use maximum prefix length
matching; consequently an AL_net_addr MAY include, but MUST NOT equal matching; consequently an AL_net_addr MAY include, but MUST NOT equal
skipping to change at page 36, line 29 skipping to change at page 36, line 25
where: where:
R_dest_addr is the network address of the destination, either the R_dest_addr is the network address of the destination, either the
network address of an interface of a destination router, or the network address of an interface of a destination router, or the
network address of an attached network; network address of an attached network;
R_next_iface_addr is the network address of the "next hop" on the R_next_iface_addr is the network address of the "next hop" on the
selected path to the destination; selected path to the destination;
R_local_iface_addr is the network address of the local OLSRv2 R_local_iface_addr is an address of the local interface over which
interface over which an IP packet MUST be sent to reach the an IP packet MUST be sent to reach the destination by the selected
destination by the selected path. path.
R_dist is the number of hops on the selected path to the R_dist is the number of hops on the selected path to the
destination; destination;
R_metric is the metric of the route to the destination with R_metric is the metric of the route to the destination with
address R_dest_addr. address R_dest_addr.
The Routing Set for a router is derived from the contents of other The Routing Set for a router is derived from the contents of other
Protocol Sets of the router (the Link Sets, the Neighbor Set, the Protocol Sets of the router (the Link Sets, the Neighbor Set, the
Router Topology Set, the Routable Address Topology Set, the Attached Router Topology Set, the Routable Address Topology Set, the Attached
skipping to change at page 38, line 28 skipping to change at page 38, line 22
note that this does not include a prefix length; note that this does not include a prefix length;
F_seq_number is the message sequence number of the forwarded F_seq_number is the message sequence number of the forwarded
message; message;
F_time specifies the time at which this Tuple expires and MUST be F_time specifies the time at which this Tuple expires and MUST be
removed. removed.
12. Information Base Properties 12. Information Base Properties
This section describes some additional properties of Information
Bases and their contents.
12.1. Corresponding Protocol Tuples
As part of this specification, in a number of cases there is a As part of this specification, in a number of cases there is a
natural correspondence from a Protocol Tuple in one Protocol Set to a natural correspondence from a Protocol Tuple in one Protocol Set to a
single Protocol Tuple in another Protocol Set, in the same or another single Protocol Tuple in another Protocol Set, in the same or another
Information Base. The latter Protocol Tuple is referred to as Information Base. The latter Protocol Tuple is referred to as
"corresponding" to the former Protocol Tuple. "corresponding" to the former Protocol Tuple.
Specific examples of corresponding Protocol Tuples include: Specific examples of corresponding Protocol Tuples include:
o There is a Local Interface Tuple corresponding to each Link Tuple, o There is a Local Interface Tuple corresponding to each Link Tuple,
where the Link Tuple is in the Link Set for a MANET interface, and where the Link Tuple is in the Link Set for a MANET interface, and
skipping to change at page 39, line 18 skipping to change at page 39, line 18
o There is an Advertising Remote Router Tuple corresponding to each o There is an Advertising Remote Router Tuple corresponding to each
Routable Address Topology Tuple such that AR_orig_addr = Routable Address Topology Tuple such that AR_orig_addr =
TA_from_orig_addr. TA_from_orig_addr.
o There is an Advertising Remote Router Tuple corresponding to each o There is an Advertising Remote Router Tuple corresponding to each
Attached Network Tuple such that AR_orig_addr = AN_orig_addr. Attached Network Tuple such that AR_orig_addr = AN_orig_addr.
o There is a Neighbor Tuple corresponding to each Routing Tuple such o There is a Neighbor Tuple corresponding to each Routing Tuple such
that N_neighbor_addr_list contains R_next_iface_addr. that N_neighbor_addr_list contains R_next_iface_addr.
12.2. Address Ownership
Addresses or network addresses with the following properties are Addresses or network addresses with the following properties are
considered as "fully owned" by a router when processing a received considered as "fully owned" by a router when processing a received
message: message:
o Equaling its originator address, OR; o Equaling its originator address, OR;
o Equaling the O_orig_addr in an Originator Tuple, OR; o Equaling the O_orig_addr in an Originator Tuple, OR;
o Equaling or being a sub-range of the I_local_iface_addr_list in a o Equaling or being a sub-range of the I_local_iface_addr_list in a
Local Interface Tuple, OR; Local Interface Tuple, OR;
skipping to change at page 44, line 7 skipping to change at page 44, line 8
14. Message Processing and Forwarding 14. Message Processing and Forwarding
This section describes the optimized flooding operation (MPR This section describes the optimized flooding operation (MPR
flooding) used when control messages, as instances of [RFC5444], are flooding) used when control messages, as instances of [RFC5444], are
intended for MANET wide distribution. This flooding mechanism intended for MANET wide distribution. This flooding mechanism
defines when a received message is, or is not, processed and/or defines when a received message is, or is not, processed and/or
forwarded. forwarded.
This flooding mechanism is used by this protocol and MAY be used by This flooding mechanism is used by this protocol and MAY be used by
extensions to this protocol which define, and hence own, other extensions to this protocol which define, and hence own, other
message types, to manage processing and/or forwarding of these Message Types, to manage processing and/or forwarding of these
messages. This specification contains elements (P_type, RX_type, messages. This specification contains elements (P_type, RX_type,
F_type) required only for such usage. F_type) required only for such usage.
This flooding mechanism is always used for TC messages (see This flooding mechanism is always used for TC messages (see
Section 16). Received HELLO messages (see Section 15) are, unless Section 16). Received HELLO messages (see Section 15) are, unless
invalid, always processed, and never forwarded by this flooding invalid, always processed, and never forwarded by this flooding
mechanism. They thus do not need to be recorded in the Received mechanism. They thus do not need to be recorded in the Received
Message Information Base. Message Information Base.
The processing selection and forwarding mechanisms are designed to The processing selection and forwarding mechanisms are designed to
skipping to change at page 54, line 35 skipping to change at page 54, line 35
with an associated Address Block TLV with Type = LINK_STATUS and with an associated Address Block TLV with Type = LINK_STATUS and
Value = SYMMETRIC in the HELLO message, then for the current Value = SYMMETRIC in the HELLO message, then for the current
Neighbor Tuple: Neighbor Tuple:
* N_mpr_selector := false; * N_mpr_selector := false;
* The router MAY also set N_advertised := false. * The router MAY also set N_advertised := false.
16. TC Messages 16. TC Messages
This protocol defines, and hence owns, the TC message type (see This protocol defines, and hence owns, the TC Message Type (see
Section 24). Thus, as specified in [RFC5444], this protocol Section 24). Thus, as specified in [RFC5444], this protocol
generates and transmits all TC messages, receives all TC messages and generates and transmits all TC messages, receives all TC messages and
is responsible for determining whether and how each TC message is to is responsible for determining whether and how each TC message is to
be processed (updating the Topology Information Base) and/or be processed (updating the Topology Information Base) and/or
forwarded, according to this specification. forwarded, according to this specification.
16.1. TC Message Generation 16.1. TC Message Generation
A TC message is a message as defined in [RFC5444]. A generated TC A TC message is a message as defined in [RFC5444]. A generated TC
message MUST contain the following elements as defined in [RFC5444]: message MUST contain the following elements as defined in [RFC5444]:
skipping to change at page 57, line 38 skipping to change at page 57, line 38
router MUST then follow the processing and forwarding procedures, router MUST then follow the processing and forwarding procedures,
defined in Section 14. defined in Section 14.
If the message is considered for processing (Section 14.2), then a If the message is considered for processing (Section 14.2), then a
router MUST first check if the message is invalid for processing by router MUST first check if the message is invalid for processing by
this router, as defined in Section 16.3.1. A router MAY make a this router, as defined in Section 16.3.1. A router MAY make a
similar check before considering a message for forwarding, it MUST similar check before considering a message for forwarding, it MUST
make those aspects of the check that apply to elements in the Message make those aspects of the check that apply to elements in the Message
Header. Header.
If the TC message is not invalid, then the TC message type specific If the TC message is not invalid, then the TC Message Type specific
processing, described in Section 16.3.2 MUST be applied. This will processing, described in Section 16.3.2 MUST be applied. This will
update its appropriate Interface Information Bases and its Router update its appropriate Interface Information Bases and its Router
Information Base. Following this, if there are any changes in these Information Base. Following this, if there are any changes in these
Information Bases, then the processing in Section 17 MUST be Information Bases, then the processing in Section 17 MUST be
performed. performed.
16.3.1. TC Message Discarding 16.3.1. TC Message Discarding
A received TC message is invalid for processing by this router if the A received TC message is invalid for processing by this router if the
message: message:
skipping to change at page 81, line 52 skipping to change at page 81, line 52
23. Security Considerations 23. Security Considerations
Currently, this protocol does not specify any special security Currently, this protocol does not specify any special security
measures. As a proactive routing protocol, this protocol is a measures. As a proactive routing protocol, this protocol is a
potential target for various attacks. Various possible potential target for various attacks. Various possible
vulnerabilities are discussed in this section. vulnerabilities are discussed in this section.
23.1. Confidentiality 23.1. Confidentiality
This protocol periodically MPR floods topological information to all This protocol periodically MPR floods topological information to all
routers in the network. Hence, if used in an unprotected wireless routers in the network. Hence, if used in an unprotected network,
network, the network topology is revealed to anyone who listens to such as an unprotected wireless network, the network topology is
the control messages. revealed to anyone who listens to the control messages.
In situations where the confidentiality of the network topology is of In situations where the confidentiality of the network topology is of
importance, regular cryptographic techniques, such as exchange of importance, regular cryptographic techniques, such as exchange of
OLSRv2 control traffic messages encrypted by PGP [RFC4880] or OLSRv2 control traffic messages encrypted by PGP [RFC4880] or
encrypted by some shared secret key, can be applied to ensure that encrypted by some shared secret key, can be applied to ensure that
control traffic can be read and interpreted by only those authorized control traffic can be read and interpreted by only those authorized
to do so. to do so.
23.2. Integrity 23.2. Integrity
Each router is injecting topological information into the network Each router is injecting topological information into the network
through transmitting HELLO messages and, for some routers, TC through transmitting HELLO messages and, for some routers, TC
messages. If some routers for some reason, malicious or malfunction, messages. If some routers for some reason, malice or malfunction,
inject invalid control traffic, network integrity may be compromised. inject invalid control traffic, network integrity may be compromised.
Therefore, message authentication is recommended. Therefore, message authentication is RECOMMENDED.
Different such situations may occur, for instance: Different such situations may occur, for instance:
1. A router generates TC messages, advertising links to non-neighbor 1. A router generates TC messages, advertising links to non-neighbor
routers; routers;
2. A router generates TC messages, pretending to be another router; 2. A router generates TC messages, pretending to be another router;
3. A router generates HELLO messages, advertising non-neighbor 3. A router generates HELLO messages, advertising non-neighbor
routers; routers;
skipping to change at page 83, line 8 skipping to change at page 83, line 8
Authentication of the originator router for control messages (for Authentication of the originator router for control messages (for
situations 2, 4 and 5) and on the individual links announced in the situations 2, 4 and 5) and on the individual links announced in the
control messages (for situations 1 and 3) may be used as a control messages (for situations 1 and 3) may be used as a
countermeasure. However to prevent routers from repeating old (and countermeasure. However to prevent routers from repeating old (and
correctly authenticated) information (situation 9) temporal correctly authenticated) information (situation 9) temporal
information is required, allowing a router to positively identify information is required, allowing a router to positively identify
such delayed messages. such delayed messages.
In general, digital signatures and other required security In general, digital signatures and other required security
information may be transmitted as a separate Message Type, or information MAY be transmitted as a separate Message Type, or
signatures and security information may be transmitted within the signatures and security information MAY be transmitted within the
HELLO and TC messages, using the TLV mechanism. Either option HELLO and TC messages, using the TLV mechanism. Either option
permits that "secured" and "unsecured" routers can coexist in the permits that "secured" and "unsecured" routers can coexist in the
same network, if desired. same network, if desired.
Specifically, the authenticity of entire control packets can be Specifically, the authenticity of entire control packets can be
established through employing IPsec authentication headers, whereas established through employing IPsec authentication headers, whereas
authenticity of individual links (situations 1 and 3) require authenticity of individual links (situations 1 and 3) require
additional security information to be distributed. additional security information to be distributed.
An important consideration is that all control messages (HELLO An important consideration is that all control messages (HELLO
skipping to change at page 83, line 47 skipping to change at page 83, line 47
protocol and, potentially, injected into an external domain, if the protocol and, potentially, injected into an external domain, if the
routing protocol governing that domain permits this. routing protocol governing that domain permits this.
When operating routers connecting a MANET using this protocol to an When operating routers connecting a MANET using this protocol to an
external routing domain, care MUST be taken not to allow potentially external routing domain, care MUST be taken not to allow potentially
insecure and untrustworthy information to be injected from this insecure and untrustworthy information to be injected from this
domain to external routing domains. Care MUST also be taken to domain to external routing domains. Care MUST also be taken to
validate the correctness of information prior to it being injected as validate the correctness of information prior to it being injected as
to avoid polluting routing tables with invalid information. to avoid polluting routing tables with invalid information.
A recommended way of extending connectivity from an existing routing A RECOMMENDED way of extending connectivity from an external routing
domain to a MANET routed using this protocol is to assign an IP domain to a MANET routed using this protocol is to assign an IP
prefix (under the authority of the routers/gateways connecting the prefix (under the authority of the routers/gateways connecting the
MANET with the exiting routing domain) exclusively to that MANET MANET with the external routing domain) exclusively to that MANET
area, and to statically configure the gateways to advertise routes area, and to statically configure the gateways to advertise routes
for that IP sequence to routers in the existing routing domain. for that IP sequence to routers in the external routing domain.
24. IANA Considerations 24. IANA Considerations
This specification defines one Message Type, which must be allocated This specification defines one Message Type, which must be allocated
from the "Message Types" repository of [RFC5444], two Message TLV from the "Message Types" repository of [RFC5444], two Message TLV
Types, which must be allocated from the "Message TLV Types" Types, which must be allocated from the "Message TLV Types"
repository of [RFC5444], and four Address Block TLV Types, which must repository of [RFC5444], and four Address Block TLV Types, which must
be allocated from the "Address Block TLV Types" repository of be allocated from the "Address Block TLV Types" repository of
[RFC5444]. [RFC5444].
skipping to change at page 90, line 13 skipping to change at page 90, line 13
<philippe.jacquet@alcatel-lucent.fr> <philippe.jacquet@alcatel-lucent.fr>
o Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com> o Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>
o Kenichi Mase, Niigata University, Japan, <mase@ie.niigata-u.ac.jp> o Kenichi Mase, Niigata University, Japan, <mase@ie.niigata-u.ac.jp>
o Ryuji Wakikawa, Toyota, Japan, <ryuji@sfc.wide.ad.jp> o Ryuji Wakikawa, Toyota, Japan, <ryuji@sfc.wide.ad.jp>
26. Acknowledgments 26. Acknowledgments
The authors would like to acknowledge the team behind OLSRv1, The authors would like to acknowledge the team behind OLSRv1, as
specified in RFC3626, including Anis Laouiti (INT, Paris), Pascale listed in RFC3626, including Anis Laouiti (INT), Pascale Minet
Minet (INRIA, France), Laurent Viennot (INRIA, France), and Amir (INRIA), Paul Muhlethaler (INRIA), Amir Qayyum (M.A. Jinnah
Qayyum (M.A. Jinnah University, Islamabad) for their contributions. University), and Laurent Viennot (INRIA) for their contributions.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components (listed alphabetically): Khaldoun Al specification and its components (listed alphabetically): Khaldoun Al
Agha (LRI), Teco Boot (Infinity Networks), Song-Yean Cho (Samsung), Agha (LRI), Teco Boot (Infinity Networks), Song-Yean Cho (Samsung),
Alan Cullen (BAE Systems), Louise Lamont (CRC), Li Li (CRC), Joe Alan Cullen (BAE Systems), Louise Lamont (CRC), Li Li (CRC), Joseph
Macker (NRL), Richard Ogier (SRI), Charles E. Perkins, Henning Rogge Macker (NRL), Richard Ogier (SRI), Charles E. Perkins (Futurewei),
(FGAN), and the entire IETF MANET working group. Henning Rogge (Frauenhofer FKIE), and the entire IETF MANET Working
Group.
27. References 27. References
27.1. Normative References 27.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
Considerations in Mobile Ad Hoc Networks (MANETs)", Considerations in Mobile Ad Hoc Networks (MANETs)",
 End of changes. 46 change blocks. 
64 lines changed or deleted 76 lines changed or added

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