draft-ietf-manet-olsrv2-08.txt   draft-ietf-manet-olsrv2-09.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 11, 2009 BAE Systems ATC Expires: January 14, 2010 BAE Systems ATC
P. Jacquet P. Jacquet
Project Hipercom, INRIA Project Hipercom, INRIA
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
March 10, 2009 July 13, 2009
The Optimized Link State Routing Protocol version 2 The Optimized Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-08 draft-ietf-manet-olsrv2-09
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 September 11, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document describes version 2 of the Optimized Link State Routing This document describes version 2 of the Optimized Link State Routing
(OLSRv2) protocol. The protocol embodies an optimization of the (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).
classical link state algorithm tailored to the requirements of a
Mobile Ad hoc NETwork (MANET).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 8 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 8
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 10 4.1. Routers and Interfaces . . . . . . . . . . . . . . . . . . 10
5.1. Local History Times . . . . . . . . . . . . . . . . . . . 11 4.2. Information Base Overview . . . . . . . . . . . . . . . . 11
5.2. Message Intervals . . . . . . . . . . . . . . . . . . . . 11 4.2.1. Local Information Base . . . . . . . . . . . . . . . . 11
5.3. Advertised Information Validity Times . . . . . . . . . . 12 4.2.2. Interface Information Bases . . . . . . . . . . . . . 11
5.4. Received Message Validity Times . . . . . . . . . . . . . 13 4.2.3. Neighbor Information Base . . . . . . . . . . . . . . 11
5.5. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.4. Topology Information Base . . . . . . . . . . . . . . 12
5.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 14 4.2.5. Processing and Forwarding Information Base . . . . . . 13
5.7. Willingness . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 13
5.8. Parameter Change Constraints . . . . . . . . . . . . . . . 15 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 14
6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 14
6.1. Local Information Base . . . . . . . . . . . . . . . . . . 17 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Originator Set . . . . . . . . . . . . . . . . . . . . 17 5.3. Local History Times . . . . . . . . . . . . . . . . . . . 15
6.1.2. Local Attached Network Set . . . . . . . . . . . . . . 17 5.4. Message Intervals . . . . . . . . . . . . . . . . . . . . 15
6.2. Neighbor Information Base . . . . . . . . . . . . . . . . 18 5.5. Advertised Information Validity Times . . . . . . . . . . 16
6.3. Topology Information Base . . . . . . . . . . . . . . . . 18 5.6. Received Message Validity Times . . . . . . . . . . . . . 17
6.3.1. Advertised Neighbor Set . . . . . . . . . . . . . . . 19 5.7. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3.2. Advertising Remote Router Set . . . . . . . . . . . . 19 5.8. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 18
6.3.3. Topology Set . . . . . . . . . . . . . . . . . . . . . 20 5.9. Willingness . . . . . . . . . . . . . . . . . . . . . . . 18
6.3.4. Attached Network Set . . . . . . . . . . . . . . . . . 20 5.10. Parameter Change Constraints . . . . . . . . . . . . . . . 19
6.3.5. Routing Set . . . . . . . . . . . . . . . . . . . . . 21 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 20
6.4. Processing and Forwarding Information Base . . . . . . . . 21 6.1. Local Information Base . . . . . . . . . . . . . . . . . . 21
6.4.1. Received Set . . . . . . . . . . . . . . . . . . . . . 22 6.1.1. Originator Set . . . . . . . . . . . . . . . . . . . . 21
6.4.2. Processed Set . . . . . . . . . . . . . . . . . . . . 22 6.1.2. Local Attached Network Set . . . . . . . . . . . . . . 21
6.4.3. Forwarded Set . . . . . . . . . . . . . . . . . . . . 22 6.2. Neighbor Information Base . . . . . . . . . . . . . . . . 22
6.4.4. Relay Set . . . . . . . . . . . . . . . . . . . . . . 23 6.3. Topology Information Base . . . . . . . . . . . . . . . . 22
7. Message Processing and Forwarding . . . . . . . . . . . . . . 23 6.3.1. Advertised Neighbor Set . . . . . . . . . . . . . . . 22
7.1. Actions when Receiving a Message . . . . . . . . . . . . . 24 6.3.2. Advertising Remote Router Set . . . . . . . . . . . . 23
7.2. Message Considered for Processing . . . . . . . . . . . . 25 6.3.3. Topology Set . . . . . . . . . . . . . . . . . . . . . 23
7.3. Message Considered for Forwarding . . . . . . . . . . . . 25 6.3.4. Attached Network Set . . . . . . . . . . . . . . . . . 24
8. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 27 6.3.5. Routing Set . . . . . . . . . . . . . . . . . . . . . 25
8.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 28 6.4. Processing and Forwarding Information Base . . . . . . . . 25
8.1.1. HELLO Message TLVs . . . . . . . . . . . . . . . . . . 28 6.4.1. Received Set . . . . . . . . . . . . . . . . . . . . . 25
8.1.2. HELLO Message Address Block TLVs . . . . . . . . . . . 29 6.4.2. Processed Set . . . . . . . . . . . . . . . . . . . . 26
8.2. TC Messages . . . . . . . . . . . . . . . . . . . . . . . 29 6.4.3. Forwarded Set . . . . . . . . . . . . . . . . . . . . 26
8.2.1. TC Message TLVs . . . . . . . . . . . . . . . . . . . 30 6.4.4. Relay Set . . . . . . . . . . . . . . . . . . . . . . 27
8.2.2. TC Message Address Block TLVs . . . . . . . . . . . . 31 7. Message Processing and Forwarding . . . . . . . . . . . . . . 27
9. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 31 7.1. Actions when Receiving a Message . . . . . . . . . . . . . 28
9.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 32 7.2. Message Considered for Processing . . . . . . . . . . . . 28
10. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 32 7.3. Message Considered for Forwarding . . . . . . . . . . . . 29
10.1. Updating Willingness . . . . . . . . . . . . . . . . . . . 32 8. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 31
10.2. Updating MPR Selectors . . . . . . . . . . . . . . . . . . 33 8.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 32
10.3. Symmetric 1-Hop and 2-Hop Neighborhood Changes . . . . . . 33 8.1.1. HELLO Message TLVs . . . . . . . . . . . . . . . . . . 32
11. TC Message Generation . . . . . . . . . . . . . . . . . . . . 34 8.1.2. HELLO Message Address Block TLVs . . . . . . . . . . . 33
11.1. TC Message: Transmission . . . . . . . . . . . . . . . . . 35 8.2. TC Messages . . . . . . . . . . . . . . . . . . . . . . . 33
12. TC Message Processing . . . . . . . . . . . . . . . . . . . . 36 8.2.1. TC Message TLVs . . . . . . . . . . . . . . . . . . . 34
12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 36 8.2.2. TC Message Address Block TLVs . . . . . . . . . . . . 34
12.2. Initial TC Message Processing . . . . . . . . . . . . . . 37 9. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 35
12.3. Initial TC Message Processing . . . . . . . . . . . . . . 38 9.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 35
12.3.1. Populating the Advertising Remote Router Set . . . . . 38 10. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 36
12.3.2. Populating the Topology Set . . . . . . . . . . . . . 39 10.1. Updating Willingness . . . . . . . . . . . . . . . . . . . 36
12.3.3. Populating the Attached Network Set . . . . . . . . . 40 10.2. Updating MPR Selectors . . . . . . . . . . . . . . . . . . 36
12.4. Completing TC Message Processing . . . . . . . . . . . . . 40 10.3. Symmetric 1-Hop and 2-Hop Neighborhood Changes . . . . . . 37
12.4.1. Purging the Topology Set . . . . . . . . . . . . . . . 40 11. TC Message Generation . . . . . . . . . . . . . . . . . . . . 38
12.4.2. Purging the Attached Network Set . . . . . . . . . . . 41 11.1. TC Message: Transmission . . . . . . . . . . . . . . . . . 39
13. Information Base Changes . . . . . . . . . . . . . . . . . . . 41 12. TC Message Processing . . . . . . . . . . . . . . . . . . . . 40
14. Selecting MPRs . . . . . . . . . . . . . . . . . . . . . . . . 42 12.1. Invalid Message . . . . . . . . . . . . . . . . . . . . . 40
15. Populating Derived Sets . . . . . . . . . . . . . . . . . . . 43 12.2. Initial TC Message Processing . . . . . . . . . . . . . . 41
15.1. Populating the Relay Set . . . . . . . . . . . . . . . . . 43 12.3. Initial TC Message Processing . . . . . . . . . . . . . . 42
15.2. Populating the Advertised Neighbor Set . . . . . . . . . . 44 12.3.1. Populating the Advertising Remote Router Set . . . . . 42
16. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 44 12.3.2. Populating the Topology Set . . . . . . . . . . . . . 43
16.1. Network Topology Graph . . . . . . . . . . . . . . . . . . 44 12.3.3. Populating the Attached Network Set . . . . . . . . . 43
16.2. Populating the Routing Set . . . . . . . . . . . . . . . . 46 12.4. Completing TC Message Processing . . . . . . . . . . . . . 44
16.3. Routing Set Updates . . . . . . . . . . . . . . . . . . . 46 12.4.1. Purging the Topology Set . . . . . . . . . . . . . . . 44
17. Proposed Values for Parameters and Constants . . . . . . . . . 47 12.4.2. Purging the Attached Network Set . . . . . . . . . . . 44
17.1. Local History Time Parameters . . . . . . . . . . . . . . 47 13. Information Base Changes . . . . . . . . . . . . . . . . . . . 45
17.2. Message Interval Parameters . . . . . . . . . . . . . . . 47 14. Selecting MPRs . . . . . . . . . . . . . . . . . . . . . . . . 46
17.3. Advertised Information Validity Time Parameters . . . . . 47 15. Populating Derived Sets . . . . . . . . . . . . . . . . . . . 48
17.4. Received Message Validity Time Parameters . . . . . . . . 47 15.1. Populating the Relay Set . . . . . . . . . . . . . . . . . 48
17.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . . 48 15.2. Populating the Advertised Neighbor Set . . . . . . . . . . 48
17.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 48 16. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 49
17.7. Willingness Parameter and Constants . . . . . . . . . . . 48 16.1. Network Topology Graph . . . . . . . . . . . . . . . . . . 49
18. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 48 16.2. Populating the Routing Set . . . . . . . . . . . . . . . . 50
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 16.3. Routing Set Updates . . . . . . . . . . . . . . . . . . . 51
19.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 49 17. Proposed Values for Parameters and Constants . . . . . . . . . 51
19.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 49 17.1. Local History Time Parameters . . . . . . . . . . . . . . 51
19.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 50 17.2. Message Interval Parameters . . . . . . . . . . . . . . . 51
20. Security Considerations . . . . . . . . . . . . . . . . . . . 51 17.3. Advertised Information Validity Time Parameters . . . . . 52
20.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 51 17.4. Received Message Validity Time Parameters . . . . . . . . 52
20.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 51 17.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . . 52
20.3. Interaction with External Routing Domains . . . . . . . . 53 17.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 52
21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 17.7. Willingness Parameter and Constants . . . . . . . . . . . 52
22. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 18. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 52
23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
23.1. Normative References . . . . . . . . . . . . . . . . . . . 54 19.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 53
23.2. Informative References . . . . . . . . . . . . . . . . . . 55 19.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 53
Appendix A. Router Configuration . . . . . . . . . . . . . . . . 55 19.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 54
Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 56 20. Security Considerations . . . . . . . . . . . . . . . . . . . 55
B.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 56 20.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 55
B.2. MPR Selection Algorithm for each OLSRv2 Interface . . . . 57 20.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 56
Appendix C. Example Algorithm for Calculating the Routing Set . . 58 20.3. Interaction with External Routing Domains . . . . . . . . 57
C.1. Add Local Symmetric Links . . . . . . . . . . . . . . . . 58 21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 58
C.2. Add Remote Symmetric Links . . . . . . . . . . . . . . . . 59 22. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
C.3. Add Attached Networks . . . . . . . . . . . . . . . . . . 60 23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Appendix D. Example Message Layout . . . . . . . . . . . . . . . 61 23.1. Normative References . . . . . . . . . . . . . . . . . . . 58
Appendix E. Constraints . . . . . . . . . . . . . . . . . . . . . 62 23.2. Informative References . . . . . . . . . . . . . . . . . . 59
Appendix F. Flow and Congestion Control . . . . . . . . . . . . . 66 Appendix A. Router Configuration . . . . . . . . . . . . . . . . 60
Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 60
B.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 61
B.2. MPR Selection Algorithm for each OLSRv2 Interface . . . . 61
Appendix C. Example Algorithm for Calculating the Routing Set . . 62
C.1. Add Local Symmetric Links . . . . . . . . . . . . . . . . 62
C.2. Add Remote Symmetric Links . . . . . . . . . . . . . . . . 63
C.3. Add Attached Networks . . . . . . . . . . . . . . . . . . 64
Appendix D. Example Message Layout . . . . . . . . . . . . . . . 65
Appendix E. Constraints . . . . . . . . . . . . . . . . . . . . . 67
Appendix F. Flow and Congestion Control . . . . . . . . . . . . . 70
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 an
update to OLSRv1 as published in [RFC3626]. Compared to [RFC3626], update to OLSRv1 as published in [RFC3626]. Compared to [RFC3626],
OLSRv2 retains the same basic mechanisms and algorithms, while OLSRv2 retains the same basic mechanisms and algorithms, while using
providing a more flexible signaling framework and some simplification a more flexible and efficient signaling framework, and includes some
of the messages being exchanged. Also, OLSRv2 accommodates either simplification of the messages being exchanged.
IPv4 and IPv6 addresses in a compact manner.
OLSRv2 is developed for mobile ad hoc networks. It operates as a OLSRv2 is developed for mobile ad hoc networks. It operates as a
table driven, proactive protocol, i.e. it exchanges topology table driven, proactive protocol, i.e. it exchanges topology
information with other routers in the network regularly. Each router information with other routers in the network regularly. It is an
selects a set of its neighbor routers as "MultiPoint Relays" (MPRs). optimization of the classical link state routing protocol. The key
Control traffic may be flooded through the network using hop by hop concept used in the protocol is that of MultiPoint Relays (MPRs).
Each router selects a set of its neighbor routers (which "cover" all
of its symmetrically connected 2-hop neighbor routers) as MPRs.
Control traffic is flooded through the network using hop by hop
forwarding, but where a router only needs to forward control traffic forwarding, but where a router only needs to forward control traffic
directly received from its MPR selectors (routers which have selected directly received from its MPR selectors (routers which have selected
it as an MPR). This mechanism, denoted "MPR flooding", provides an it as an MPR). This mechanism, denoted "MPR flooding", provides an
efficient mechanism for information distribution within the MANET by efficient mechanism for information distribution within the MANET by
reducing the number of transmissions required. reducing the number of transmissions required.
Routers selected as MPRs also have a special responsibility when Routers selected as MPRs also have a special responsibility when
declaring link state information in the network. A sufficient declaring link state information in the network. A sufficient
requirement for OLSRv2 to provide shortest (lowest hop count) path requirement for OLSRv2 to provide shortest (lowest hop count) path
routes to all destinations is that routers declare link state routes to all destinations is that routers declare link state
information for their MPR selectors, if any. Additional available information for their MPR selectors, if any. Additional available
link state information may be transmitted, e.g. for redundancy. link state information may be transmitted, e.g. for redundancy.
Thus, as well as being used to facilitate MPR flooding, use of MPRs Thus, as well as being used to facilitate MPR flooding, use of MPRs
allows the reduction of the number and size of link state messages, allows the reduction of the number and size of link state messages,
and MPRs are used as intermediate routers in multi-hop routes. and MPRs are used as intermediate routers in multi-hop routes.
A router selects MPRs from among its one hop neighbors connected by A router selects MPRs from among its one hop neighbors connected by
"symmetric", i.e. bi-directional, links. Therefore, selecting routes "symmetric", i.e. bidirectional, links. Therefore, selecting routes
through MPRs automatically avoids the problems associated with data through MPRs automatically avoids the problems associated with data
packet transfer over uni-directional links (such as the problem of packet transfer over unidirectional links (such as the problem of not
not getting link layer acknowledgments at each hop, for link layers getting link layer acknowledgments at each hop, for link layers
employing this technique). employing this technique).
OLSRv2 is developed to work independently from other protocols. OLSRv2 uses and extends [NHDP] and uses [RFC5444], [RFC5497] and,
(Parts of OLSRv2 have been published separately as [RFC5444], optionally, [RFC5148]. (These other protocols and specifications
[timetlv], [RFC5148] and [NHDP] for wider use.) Likewise, OLSRv2 were all originally created as part of OLSRv2, but have been
makes no assumptions about the underlying link layer. However, specified separately for wider use.)
OLSRv2 may use link layer information and notifications when
available and applicable, as described in [NHDP]. OLSRv2 makes no assumptions about the underlying link layer.
However, OLSRv2, through its use of [NHDP], may use link layer
information and notifications when available and applicable.
OLSRv2, as OLSRv1, inherits its concept of forwarding and relaying OLSRv2, as OLSRv1, inherits its concept of forwarding and relaying
from HIPERLAN (a MAC layer protocol) which is standardized by ETSI from HIPERLAN (a MAC layer protocol) which is standardized by ETSI
[HIPERLAN], [HIPERLAN2]. [HIPERLAN], [HIPERLAN2].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
MANET specific terminology is to be interpreted as described in All terms introduced in [RFC5444], including "packet", "message",
[RFC5444] and [NHDP]. "Address Block", "TLV Block", and "TLV", are to be interpreted as
described there.
All terms introduced in [NHDP], including "interface", "MANET
interface", "address", "symmetric link", "symmetric 1-hop neighbor",
"symmetric 2-hop neighbor", "constant", "interface parameter", and
"router parameter", are to be interpreted as described there.
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Router - A MANET router which implements the Optimized Link State Router - A MANET router which implements the Optimized Link State
Routing protocol version 2 as specified in this document. Routing protocol version 2 as specified in this document.
OLSRv2 interface - A MANET interface, running OLSRv2. Note that all OLSRv2 interface - A MANET interface, running OLSRv2. Note that all
references to MANET interfaces in [NHDP] refer to OLSRv2 references to MANET interfaces in [NHDP] refer to OLSRv2
interfaces when using [NHDP] as part of OLSRv2. interfaces when using [NHDP] to support OLSRv2.
Address - An address, as recorded in the Information Bases specified Originator address - An address which is unique (within the MANET)
by this protocol, and included in HELLO and TC messages generated to the selecting router. A router MUST select an originator
by this protocol, may be either an address or an address prefix. address; it MAY choose one of its interface addresses as its
These can be represented as a single address object in a HELLO or originator address. An originator address MUST NOT have a prefix
TC message, as defined by [RFC5444]. An address so represented is length. An originator address MUST be included in all messages
considered to have a prefix length equal to its length (in bits) generated by this protocol, and as specified in [RFC5444].
when considered as an address object, and a similar convention is
used in the Information Bases specified by this protocol. Two
addresses (address objects) are considered equal only if their
prefix lengths are also equal.
Willingness - The willingness of a router is a numerical value Willingness - A numerical value between WILL_NEVER and WILL_ALWAYS
between WILL_NEVER and WILL_ALWAYS (both inclusive), which (both inclusive), which represents the router's willingness to be
represents the router's willingness to be selected as an MPR. selected as an MPR.
Willing symmetric 1-hop neighbor - A symmetric 1-hop neighbor of Willing symmetric 1-hop neighbor - A symmetric 1-hop neighbor of
this router which has willingness not equal to WILL_NEVER. this router which has willingness not equal to WILL_NEVER.
Symmetric strict 2-hop neighbor - A symmetric 2-hop neighbor of this Symmetric strict 2-hop neighbor - A router, X, is a symmetric strict
router which is not a symmetric 1-hop neighbor of this router, and 2-hop neighbor of a router Y, if router X is a symmetric 2-hop
is a symmetric 1-hop neighbor of a willing symmetric 1-hop neighbor of router Y and if router X is not also a willing
neighbor of this router. symmetric 1-hop neighbor of router Y.
Symmetric strict 2-hop neighbor through OLSRv2 interface I - A Symmetric strict 2-hop neighbor through OLSRv2 interface I - A
symmetric strict 2-hop neighbor of this router which is a symmetric strict 2-hop neighbor of the router with OLSRv2
symmetric 1-hop neighbor of a willing symmetric 1-hop neighbor of interface I which is a symmetric 1-hop neighbor of a willing
this router via a symmetric link including OLSRv2 interface I. symmetric 1-hop neighbor of that router via a symmetric link using
This router MAY elect to consider only information received over OLSRv2 interface I. The router MAY elect to consider only
OLSRv2 interface I in making this determination. information received over OLSRv2 interface I in making this
determination.
Symmetric strict 2-hop neighborhood - The set of the symmetric Symmetric strict 2-hop neighborhood - The symmetric strict 2-hop
strict 2-hop neighbors of a router. neighborhood of a router X is the set of symmetric strict 2-hop
neighbors of router X.
Multipoint relay (MPR) - A router which is selected by its symmetric Multipoint relay (MPR) - A router, X, is an MPR for a router, Y, if
1-hop neighbor, router X, to "re-transmit" all the broadcast router Y has selected router X to "re-transmit" all the broadcast
messages that it receives from router X, provided that the message messages that it receives from router X, provided that the message
is not a duplicate, and that the hop limit field of the message is is not a duplicate, and that the hop limit field of the message is
greater than one. greater than one.
MPR selector - A router which has selected its symmetric 1-hop MPR selector - A router, Y, is an MPR selector of router X if router
neighbor, router X, as one of its MPRs is an MPR selector of Y has selected router X as MPR.
router X.
MPR flooding - The optimized MANET-wide information distribution MPR flooding - The optimized MANET-wide information distribution
mechanism, employed by this protocol, in which a message is mechanism, employed by this protocol, in which a message is
relayed by only a reduced subset of the routers in the network. relayed by only a reduced subset of the routers in the network.
This document employs the same notational conventions as in [RFC5444] This document employs the same notational conventions as in [RFC5444]
and [NHDP]. and [NHDP].
3. Applicability Statement 3. Applicability Statement
OLSRv2 is a proactive routing protocol for mobile ad hoc networks The Optimized Link State Routing protocol version 2 (OLSRv2):
(MANETs) [RFC2501]. The larger and more dense a network, the more
optimization can be achieved by using MPRs compared to the classic
link state algorithm. OLSRv2 enables hop-by-hop routing, i.e. each
router using its local information provided by OLSRv2 to route
packets.
As OLSRv2 continuously maintains routes to all destinations in the o Is a proactive routing protocol for mobile ad hoc networks
network, the protocol is beneficial for traffic patterns where the (MANETs) [RFC2501].
traffic is random and sporadic between a large subset of routers, and
where the (source, destination) pairs are changing over time. No
additional control traffic need be generated in this case since
routes are maintained for all known destinations at all times. Also,
since routes are maintained continuously, traffic is subject to no
delays due to buffering or to route discovery, and consequently no
data traffic buffering is imposed.
OLSRv2 supports routers which have multiple interfaces which o Is designed to work in networks with a dynamic topology, and in
participate in the MANET using OLSRv2. As described in [NHDP], each which messages may be lost, such as due to collisions in wireless
OLSRv2 interface may have one or more network addresses (which may networks.
have prefix lengths). OLSRv2, additionally, supports routers which
have non-OLSRv2 interfaces which may be local to a router or which
can serve as gateways towards other networks.
OLSRv2 uses the format specified in [RFC5444] for all messages and o Supports routers that each have one or more participating OLSRv2
packets. OLSRv2 is thereby able to allow for extensions via interfaces. The set of a router's interfaces may change over
"external" and "internal" extensibility. External extensibility time. Each OLSRv2 interface may have one or more addresses (which
allows a protocol extension to specify and exchange new Message may have prefix lengths), and these may also be dynamically
Types, which can be forwarded and delivered correctly even by routers changing.
which do not support that extension. Internal extensibility allows a
protocol extension to define additional attributes to be carried
embedded in the standard OLSRv2 control messages detailed in this
specification (or any new Message Types defined by other protocol
extensions) using the TLV mechanism specified in [RFC5444], while
still allowing routers not supporting that extension to forward
messages including the extension, and to process messages ignoring
the extension.
The OLSRv2 neighborhood discovery protocol using HELLO messages is o Enables hop-by-hop routing, i.e., each router can use its local
specified in [NHDP]. This neighborhood discovery protocol serves to information provided by OLSRv2 to route packets.
ensure that each OLSRv2 router has available continuously updated
Information Bases describing the router's 1-hop and symmetric 2-hop
neighbors. This neighborhood discovery protocol, which also uses
[RFC5444], is extended in this document by the addition of MPR
information.
OLSRv2 does not make any assumption about router addresses, other o Continuously maintains routes to all destinations in the network,
than that each router is assumed to have at least one unique and i.e., routes are instantly available and data traffic is subject
routable IP address for each interface that it has which participates to no delays due to route discovery. Consequently, no data
in the MANET. traffic buffering is required.
OLSRv2 can, as does [NHDP], use the link local multicast address "LL- o Supports routers which have non-OLSRv2 interfaces which may be
MANET-Routers", and either the "manet" UDP port or the "manet" IP local to a router or which can serve as gateways towards other
protocol number, all as specified in [manet-iana]. networks.
o Is optimized for large and dense networks: the larger and more
dense a network, the more optimization can be achieved by using
MPRs, compared to the classic link state algorithm.
o Uses the message format specified in [RFC5444]. This includes the
definition of a TC Message Type, used for MANET wide signaling of
network topology information.
o Allows "external" and "internal" extensibility as enabled by
[RFC5444].
o Uses [NHDP] for discovering each OLSRv2 router's 1-hop and
symmetric 2-hop neighbors, and extends [NHDP] by addition of MPR
and willingness information.
o Is designed to work in a completely distributed manner, and does
not depend on any central entity.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
OLSRv2 is a proactive routing protocol for mobile ad hoc networks. The objective of OLSRv2 is, for each router to, independently:
The protocol inherits the stability of a link state algorithm and has
the advantage of having routes immediately available when needed due
to its proactive nature. OLSRv2 is an optimization of the classical
link state protocol, tailored for mobile ad hoc networks. The main
tailoring and optimizations of OLSRv2 are:
o Unacknowledged transmission of all control messages; control o Identify all destinations in the network.
messages are sent periodically, but may also be sent in response
to changes in the local neighborhood.
o MPR flooding for MANET-wide link state information distribution. o Identify a sufficient subset of links in the network, in order
that shortest paths can be calculated to all available
destinations.
o Partial topology maintenance - each router knows only a subset of o Provide a Routing Set, containing these shortest paths from this
the links in the network, sufficient for a minimum hop route to router to all destinations.
all destinations.
The MPR flooding and partial topology maintenance are based on the These objectives are achieved for each router by:
concept of MultiPoint Relays (MPRs), selected independently by
routers based on the symmetric 1-hop and 2-hop neighbor information
maintained using [NHDP].
Using the message exchange format [RFC5444] and the neighborhood o Using [NHDP] to identify symmetric 1-hop neighbors and symmetric
discovery protocol [NHDP], OLSRv2 also contains the following main 2-hop neighbors.
components:
o A TLV, to be included within the HELLO messages of [NHDP], o Independently selecting MPRs from among its symmetric 1-hop
allowing a router to signal MPR selection. neighbors such that all symmetric 2-hop neighbors are reachable
via at least one symmetric 1-hop neighbor. An analysis and
examples of MPR selection algorithms is given in [MPR], a
suggested algorithm is included in this specification. Note that
it is not necessary for routers to use the same algorithm to
interoperate.
o The optimized mechanism for MANET-wide information distribution, o Signaling its MPR selection by extending [NHDP] to include this
denoted "MPR flooding". information in outgoing HELLO messages.
o A specification of MANET-wide signaling, denoted TC (Topology o Extracting its MPR selectors from received HELLO messages.
Control) messages. TC messages in OLSRv2 serve to:
* inject link state information into the entire MANET; o Reporting its willingness to be an MPR in HELLO messages. The
router's willingness to be an MPR indicates how willing it is to
participate in MPR flooding and to be an intermediate node for
routing. A node can absolutely decline to perform either role.
* inject addresses of hosts and networks for which they may serve o Periodically signaling links between MPR selectors and itself
as a gateway into the entire network. throughout the MANET, by using TC (Topology Control) messages,
defined in this specification.
TC messages are emitted periodically, thereby allowing routers to o Diffusing TC messages by using flooding reduction mechanism,
continuously track changes in the network. Incomplete TC messages denoted "MPR flooding": only the MPRs of a router will retransmit
may be used to report additions to advertised information without messages received from (i.e., originated or last relayed by) that
repeating unchanged information. Some TC messages may be MPR router.
flooded over only part of the network, allowing a router to ensure
that nearer routers are kept more up to date than distant routers,
such as is used in Fisheye State Routing [FSR] and Fuzzy Sighted
Link State routing [FSLS].
Each router in the network selects a set of MPRs. The MPRs of a This specification defines, in turn:
router X may be any subset of router X's willing symmetric 1-hop
neighbors, such that every router in the symmetric strict 2-hop
neighborhood of router X has a symmetric link to at least one of
router X's MPRs. The MPRs of a router may thus be said to "cover"
the router's symmetric strict 2-hop neighborhood. Each router also
maintains information about the set of symmetric 1-hop neighbors that
have selected it as an MPR, its MPR selectors.
As long as the condition above is satisfied, any algorithm selecting o Parameters and constants used by OLSRv2, in addition to those
MPRs is acceptable in terms of implementation interoperability. specified in [NHDP]. Parameters used by OLSRv2 may be, where
However if smaller sets of MPRs are selected then the greater the appropriate, specific to a given OLSRv2 interface, or to an OLSRv2
efficiency gains that are possible. An analysis and examples of MPR router. OLSRv2 allows all parameters to be changed dynamically,
selection algorithms is given in [MPR]. and to be set independently for each OLSRv2 router or OLSRv2
interface, as appropriate.
A router may independently determine and advertise its willingness to o Extensions to the Information Bases specified in [NHDP], and new
be selected as an MPR. A router may advertise that it always should Topology Information Base and Processing and Forwarding
be selected as an MPR or that it should never be selected as an MPR. Information Base.
In the latter case, the router will neither relay control messages,
nor will that router be included as an intermediate router in any
routing table calculations. Use of variable willingness is most
effective in dense networks.
In OLSRv2, actual efficiency gains are based on the sizes of each o An Address Block TLV, to be included within the HELLO messages of
router's Relay Set, the set of symmetric 1-hop neighbors for which it [NHDP], allowing a router to signal MPR selection.
is to relay broadcast traffic, and its Advertised Neighbor Set, the
set of symmetric 1-hop neighbors for which it is to advertise link
state information into the network in TC messages. Each of these
sets MUST contain all MPR selectors, and MAY contain additional
routers. If the Advertised Neighbor Set is empty, TC messages are
not generated by that router, unless needed for gateway reporting, or
for a short period to accelerate the removal of outdated link state
information.
OLSRv2 is designed to work in a completely distributed manner and o A Message TLV, to be included within the HELLO messages of [NHDP],
does not depend on any central entity. The protocol does not require allowing a router to indicate its willingness to be an MPR.
reliable transmission of control messages; each router sends control
messages periodically, and can therefore sustain a reasonable loss of
some such messages. Such losses may occur frequently in radio
networks due to collisions or other transmission problems. OLSRv2
MAY use "jitter", randomized adjustments to message transmission
times, to reduce the incidence of collisions [RFC5148].
OLSRv2 does not require sequenced delivery of messages. Each TC o The MPR flooding mechanism.
message contains a sequence number which is incremented for each
message. Thus the recipient of a TC message can, if required, easily
identify which information is more recent - even if messages have
been re-ordered while in transmission.
OLSRv2 only interacts with IP through routing table management. o The format of the TC message that is used for MANET wide
OLSRv2 sends its control messages as described in [RFC5444] and signaling.
o The generation of TC messages from the appropriate information in
the Information Bases.
o The updating of the Information Bases according to received TC
messages.
o The response to other events, such as the expiration of
information in the Information Bases.
OLSRv2 inherits the stability of a link state algorithm and has the
advantage of having routes immediately available when needed due to
its proactive nature.
OLSRv2 only interacts with IP through routing table management, and
the use of the sending IP address for IP datagrams containing OLSRv2
messages.
4.1. Routers and Interfaces
In order for a router to participate in a MANET, it MUST have at
least one, and possibly more, OLSRv2 interfaces. Each OLSRv2
interface:
o Is configured with one or more addresses, as specified in [NHDP].
These addresses MUST be unique within the MANET.
o Has a number of interface parameters, adding to those specified in
[NHDP].
o Has an Interface Information Base, extending that specified in
[NHDP].
o Generates and processes HELLO messages according to [NHDP],
extended as specified in Section 9 and Section 10.
In addition to a set of MANET interfaces as described above, each
router:
o Has a number of router parameters, adding to those specified in
[NHDP].
o Has a Local Information Base, extending that specified in [NHDP].
o Has a Neighbor Information Base, extending that specified in
[NHDP]. [NHDP].
o Has a Topology Information Base, recording information required
for generation and processing of TC messages.
o Has a Processing and Forwarding Information Base, recording
information required for MPR flooding, and to ensure that each TC
message is only processed once by a router.
o Generates and processes TC messages.
4.2. Information Base Overview
Each router maintains the Information Bases described in the
following sections. These are used for describing the protocol in
this document. An implementation of this protocol MAY maintain this
information in the indicated form, or in any other organization which
offers access to this information. In particular, note that it is
not necessary to remove Tuples from Sets at the exact time indicated,
only to behave as if the Tuples were removed at that time.
4.2.1. Local Information Base
The Local Information Base is specified in [NHDP] and contains a
router's local configuration. It is extended in this specification
to also contain a router's:
o Originator Set, containing addresses that were recently used as
this router's originator address.
o Local Attached Network Set, containing addresses of networks to
which this router can act as a gateway.
The Originator Set is used to enable a router to recognize and
discard control traffic which was originated by the router itself.
The Local Attached Network Set is used to enable a router to include
advertisement of reachability to a network, for which the router can
act as a gateway, when generating TC messages.
4.2.2. Interface Information Bases
The Interface Information Bases, one for each OLSRv2 interface, are
specified in [NHDP]. In addition to the uses in [NHDP], information
recorded in the Interface Information Bases is used for completing
the Routing Set.
4.2.3. Neighbor Information Base
The Neighbor Information Base is specified in [NHDP], and is extended
to also record the willingness of each neighbor to be an MPR, as well
as this router's MPR relationships with each neighbor. Specifically,
each Neighbor Tuple is extended to record whether that neighbor is an
MPR and/or MPR selector of this router, as well as the neighbor's
willingness to be an MPR.
In addition to the uses in [NHDP], information recorded in the
Neighbor Information Base is used to determine inclusion of the MPR
Address Block TLV, defined in this document, as well as for
populating the Advertised Neighbor Set and the Relay Sets of a
router.
4.2.4. Topology Information Base
The Topology Information Base contains:
o An Advertised Neighbor Set, describing the symmetric 1-hop
neighbors of this router that are to be advertised in TC messages.
This set contains at least the MPR selectors of this router, and
is associated with an Advertised Neighbor Sequence Number (ANSN),
which is incremented for each change made to this Advertised
Neighbor Set.
o An Advertising Remote Router Set, describing each other router
from which TC messages have been received.
o A Topology Set, recording links between routers in the MANET, as
described by received TC messages.
o An Attached Network Set, recording networks to which a remote
router has advertised that it may act as a gateway.
o A Routing Set, calculated based on the Interface Information
Bases, the Neighbor Information Base, and the Topology Information
Base to record routes from this router to all available
destinations, The routing table is to be updated from this Routing
Set. (A router MAY choose to use any or all destination addresses
in the Routing Set to update the routing table, this selection is
outside the scope of OLSRv2.)
The Advertised Neighbor Set is used for when generating TC messages;
the Advertised Neighbor Sequence Number is included in each TC
message, thereby allowing a receiving router to identify if a TC
message contains fresh or outdated information.
The Advertising Remote Router Set, the Topology Set and the Attached
Network Set are all updated upon receipt of TC messages, and are used
when determining the contents of the Routing Set.
4.2.5. Processing and Forwarding Information Base
The Processing and Forwarding Information Base contains:
o A Received Set, describing TC messages received 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 Relay Set for each OLSRv2 interface, describing the set of
neighbor routers from which received traffic is to be relayed (if
otherwise appropriate).
The Processing and Forwarding Information Base serves the MPR
flooding mechanism by enabling that received messages are forwarded
at most once, by a router. and also ensures that received messages
are processed exactly once.
4.3. Signaling Overview
OLSRv2 uses the neighborhood discovery protocol [NHDP], and generates
and processes HELLO messages according to [NHDP], extended according
to Section 9 and Section 10.
OLSRv2 specifies a single message type, the TC message.
OLSRv2 does not require reliable transmission of TC messages; each
router sends TC messages periodically, and can therefore sustain a
reasonable loss of some such messages. Such losses may occur
frequently in wireless networks due to collisions or other
transmission problems. OLSRv2 MAY use "jitter", randomized
adjustments to message transmission times, to reduce the incidence of
collisions as specified in [RFC5148].
OLSRv2 does not require sequenced delivery of TC messages. Each TC
message contains a sequence number which is incremented when the
message contents change. Thus the recipient of a TC message can, if
required, easily identify which information is more recent, even if
messages have been re-ordered while in transmission.
TC messages may be "complete" or "incomplete". A complete TC message
contains at least the set of addresses of the originating router's
MPR selectors. Complete TC messages are generated periodically (and
also, optionally, in response to neighborhood changes). Incomplete
TC messages may be used to report additions to advertised information
without repeating unchanged information.
TC messages are MPR flooded throughout the MANET. A router
retransmits a TC message only if it is received from (i.e.,
originated from or was last relayed by) one of that router's MPR
selectors.
Some TC messages may be MPR flooded over only part of the network,
allowing a router to ensure that nearer routers are kept more up to
date than distant routers, such as is used in Fisheye State Routing
[FSR] and Fuzzy Sighted Link State routing [FSLS]. This is enabled
in OLSRv2 by using [RFC5497].
5. Protocol Parameters and Constants 5. Protocol Parameters and Constants
The parameters and constants used in this specification are those The parameters and constants used in this specification are those
defined in [NHDP] plus those defined in this section. The separation defined in [NHDP] plus those defined in this section. The separation
in [NHDP] into interface parameters, router parameters and constants in [NHDP] into interface parameters, router parameters and constants
is also used in OLSRv2, however all but one (RX_HOLD_TIME) of the is also used in OLSRv2, however all but one (RX_HOLD_TIME) of the
parameters added by OLSRv2 are router parameters. Parameters may be parameters added by OLSRv2 are router parameters. Parameters may be
classified into the following categories: classified into the following categories:
o Local history times o Local history times
skipping to change at page 11, line 27 skipping to change at page 14, line 47
o Willingness o Willingness
In addition, constants for particular cases of a router's willingness In addition, constants for particular cases of a router's willingness
to be an MPR are defined. These parameters and constants are to be an MPR are defined. These parameters and constants are
detailed in the following sections. As for the parameters in [NHDP], detailed in the following sections. As for the parameters in [NHDP],
parameters defined in this document may be changed dynamically by a parameters defined in this document may be changed dynamically by a
router, and need not be the same on different routers, even in the router, and need not be the same on different routers, even in the
same MANET, or on different interfaces of the same router (for same MANET, or on different interfaces of the same router (for
interface parameters). interface parameters).
5.1. Local History Times 5.1. Protocol and Port Numbers
This protocol specifies TC messages, which are included in packets as
defined by [RFC5444]. These packets may be sent either using the
"manet" protocol number or the "manet" well-known UDP port number, as
specified in [RFC5498].
TC messages and HELLO messages [NHDP] SHOULD, in a given deployment
of OLSRv2, both 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 [RFC5444] packet.
5.2. Multicast Address
This protocol specifies HELLO messages, which are included in packets
as defined by [RFC5444]. These packets may be locally transmitted
using the link local multicast address "LL-MANET-Routers", as
specified in [RFC5498].
5.3. 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 - is used to define the time for which a recently used O_HOLD_TIME - is used to define the time for which a recently used
and replaced originator address is used to recognize the router's and replaced originator address is used to recognize the router's
own messages. own messages.
The following constraint applies to this parameter: The following constraint applies to this parameter:
o O_HOLD_TIME >= 0 o O_HOLD_TIME >= 0
5.2. Message Intervals 5.4. Message Intervals
The following router parameters regulate TC message transmissions by The following router parameters regulate TC message transmissions by
a router. TC messages are usually sent periodically, but MAY also be a router. TC messages are usually sent periodically, but MAY also be
sent in response to changes in the router's Advertised Neighbor Set sent in response to changes in the router's Advertised Neighbor Set
and Local Attached Network Set. With a larger value of the parameter and Local Attached Network Set. With a larger value of the parameter
TC_INTERVAL, and a smaller value of the parameter TC_MIN_INTERVAL, TC TC_INTERVAL, and a smaller value of the parameter TC_MIN_INTERVAL, TC
messages may more often be transmitted in response to changes in a messages may more often be transmitted in response to changes in a
highly dynamic network. However because a router has no knowledge highly dynamic network. However because a router has no knowledge
of, for example, routers remote to it (i.e. beyond 2 hops away) of, for example, routers remote to it (i.e. beyond 2 hops away)
joining the network, TC messages MUST NOT be sent purely joining the network, TC messages MUST NOT be sent purely
skipping to change at page 12, line 24 skipping to change at page 16, line 17
MAY be modified by jitter, as specified in [RFC5148].) MAY be modified by jitter, as specified in [RFC5148].)
The following constraints apply to these parameters: The following constraints apply to these parameters:
o TC_INTERVAL > 0 o TC_INTERVAL > 0
o TC_MIN_INTERVAL >= 0 o TC_MIN_INTERVAL >= 0
o TC_INTERVAL >= TC_MIN_INTERVAL o TC_INTERVAL >= TC_MIN_INTERVAL
o If INTERVAL_TIME TLVs as defined in [timetlv] are included in TC o If INTERVAL_TIME TLVs as defined in [RFC5497] are included in TC
messages, then TC_INTERVAL MUST be representable as described in messages, then TC_INTERVAL MUST be representable as described in
[timetlv]. [RFC5497].
5.3. Advertised Information Validity Times 5.5. Advertised Information Validity Times
The following router parameters manage the validity time of The following router parameters manage the validity time of
information advertised in TC messages: information advertised in TC messages:
T_HOLD_TIME - is used to define the minimum value in the T_HOLD_TIME - is used to define the minimum Value in the
VALIDITY_TIME TLV included in all TC messages sent by this router. VALIDITY_TIME TLV included in all TC messages sent by this router.
If a single value of parameter TC_HOP_LIMIT (see Section 5.6) is If a single value of parameter TC_HOP_LIMIT (see Section 5.8) is
used then this will be the only value in that TLV. used then this will be the only Value in that TLV.
A_HOLD_TIME - is the period during which TC messages are sent after A_HOLD_TIME - is the period during which TC messages are sent after
they no longer have any advertised information to report, but are they no longer have any advertised information to report, but are
sent in order to accelerate outdated information removal by other sent in order to accelerate outdated information removal by other
routers. routers.
The following constraints apply to these parameters: The following constraints apply to these parameters:
o T_HOLD_TIME > 0 o T_HOLD_TIME > 0
o A_HOLD_TIME >= 0 o A_HOLD_TIME >= 0
o T_HOLD_TIME >= TC_INTERVAL o T_HOLD_TIME >= TC_INTERVAL
o If TC messages can be lost, then both T_HOLD_TIME and A_HOLD_TIME o If TC messages can be lost, then both T_HOLD_TIME and A_HOLD_TIME
SHOULD be significantly greater than TC_INTERVAL; a value >= 3 x SHOULD be significantly greater than TC_INTERVAL; a value >= 3 x
TC_INTERVAL is RECOMMENDED. TC_INTERVAL is RECOMMENDED.
o T_HOLD_TIME MUST be representable as described in [timetlv]. o T_HOLD_TIME MUST be representable as described in [RFC5497].
5.4. Received Message Validity Times 5.6. Received Message Validity Times
The following parameters manage the validity time of recorded The following parameters manage the validity time of recorded
received message information: received message information:
RX_HOLD_TIME - is an interface parameter, and is the period after RX_HOLD_TIME - is an interface parameter, and is the period after
receipt of a message by the appropriate OLSRv2 interface of this receipt of a message by the appropriate OLSRv2 interface of this
router for which that information is recorded, in order that the router for which that information is recorded, in order that the
message is recognized as having been previously received on this message is recognized as having been previously received on this
OLSRv2 interface. OLSRv2 interface.
skipping to change at page 13, line 42 skipping to change at page 17, line 39
o P_HOLD_TIME > 0 o P_HOLD_TIME > 0
o F_HOLD_TIME > 0 o F_HOLD_TIME > 0
o All of these parameters SHOULD be greater than the maximum o All of these parameters SHOULD be greater than the maximum
difference in time that a message may take to traverse the MANET, difference in time that a message may take to traverse the MANET,
taking into account any message forwarding jitter as well as taking into account any message forwarding jitter as well as
propagation, queuing, and processing delays. propagation, queuing, and processing delays.
5.5. Jitter 5.7. Jitter
If jitter, as defined in [RFC5148], is used then these parameters are If jitter, as defined in [RFC5148], is used then these parameters are
as follows: as follows:
TP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] TP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
for periodically generated TC messages sent by this router. for periodically generated TC messages sent by this router.
TT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] TT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
for externally triggered TC messages sent by this router. for externally triggered TC messages sent by this router.
F_MAXJITTER - represents the default value of MAXJITTER used in F_MAXJITTER - represents the default value of MAXJITTER used in
[RFC5148] for messages forwarded by this router. However before [RFC5148] for messages forwarded by this router. However before
using F_MAXJITTER a router MAY attempt to deduce a more using F_MAXJITTER a router MAY attempt to deduce a more
appropriate value of MAXJITTER, for example based on any appropriate value of MAXJITTER, for example based on any
INTERVAL_TIME or VALIDITY_TIME TLVs contained in the message to be INTERVAL_TIME or VALIDITY_TIME TLVs contained in the message to be
forwarded. forwarded.
For constraints on these parameters see [RFC5148]. For constraints on these parameters see [RFC5148].
5.6. Hop Limit Parameter 5.8. Hop Limit Parameter
The parameter TC_HOP_LIMIT is the hop limit set in each TC message. The parameter TC_HOP_LIMIT is the hop limit set in each TC message.
TC_HOP_LIMIT MAY be a single fixed value, or MAY be different in TC TC_HOP_LIMIT MAY be a single fixed value, or MAY be different in TC
messages sent by the same router. However each other router, at any messages sent by the same router. However each other router, at any
hop count distance, SHOULD see a regular pattern of TC messages, in hop count distance, SHOULD see a regular pattern of TC messages, in
order that meaningful values of INTERVAL_TIME and VALIDITY_TIME TLVs order that meaningful Values of INTERVAL_TIME and VALIDITY_TIME TLVs
at each hop count distance can be included as defined in [timetlv]. at each hop count distance can be included as defined in [RFC5497].
Thus the pattern of TC_HOP_LIMIT SHOULD be defined to have this Thus the pattern of TC_HOP_LIMIT SHOULD be defined to have this
property. For example the repeating pattern (255 4 4) satisfies this property. For example the repeating pattern (255 4 4) satisfies this
property (having period TC_INTERVAL at hop counts up to 4, inclusive, property (having period TC_INTERVAL at hop counts up to 4, inclusive,
and 3 x TC_INTERVAL at hop counts greater than 4), but the repeating and 3 x TC_INTERVAL at hop counts greater than 4), but the repeating
pattern (255 255 4 4) does not satisfy this property because at hop pattern (255 255 4 4) does not satisfy this property because at hop
counts greater than 4, message intervals are alternately TC_INTERVAL counts greater than 4, message intervals are alternately TC_INTERVAL
and 3 x TC_INTERVAL. and 3 x TC_INTERVAL.
The following constraints apply to this parameter: The following constraints apply to this parameter:
o The maximum value of TC_HOP_LIMIT >= the network diameter in hops, o The maximum value of TC_HOP_LIMIT >= the network diameter in hops,
a value of 255 is RECOMMENDED. a value of 255 is RECOMMENDED.
o All values of TC_HOP_LIMIT >= 2. o All values of TC_HOP_LIMIT >= 2.
5.7. Willingness 5.9. Willingness
Each router has a WILLINGNESS parameter, which MUST be in the range Each router has a WILLINGNESS parameter, which MUST be in the range
WILL_NEVER to WILL_ALWAYS, inclusive, and represents its willingness WILL_NEVER to WILL_ALWAYS, inclusive, and represents its willingness
to be an MPR, and hence its willingness to forward messages and be an to be an MPR, and hence its willingness to forward messages and be an
intermediate router on routes. If a router has WILLINGNESS = intermediate router on routes. If a router has WILLINGNESS =
WILL_NEVER it does not perform these tasks. A MANET using OLSRv2 WILL_NEVER it does not perform these tasks. A MANET using OLSRv2
with too many routers with WILLINGNESS = WILL_NEVER will not with too many routers with WILLINGNESS = WILL_NEVER will not
function; it MUST be ensured, by administrative or other means, that function; it MUST be ensured, by administrative or other means, that
this does not happen. this does not happen.
Routers MAY have different WILLINGNESS values; however the three Routers MAY have different WILLINGNESS values; however the three
constants WILL_NEVER, WILL_DEFAULT and WILL_ALWAYS MUST have the constants WILL_NEVER, WILL_DEFAULT and WILL_ALWAYS MUST have the
values defined in Section 5.7. (Use of WILLINGNESS = WILL_DEFAULT values defined in Section 17. (Use of WILLINGNESS = WILL_DEFAULT
allows a router to avoid including an MPR_WILLING TLV in its TC allows a router to avoid including an MPR_WILLING TLV in its TC
messages, use of WILLINGNESS = WILL_ALWAYS means that a router will messages, use of WILLINGNESS = WILL_ALWAYS means that a router will
always be selected as an MPR by all symmetric 1-hop neighbors.) always be selected as an MPR by all symmetric 1-hop neighbors.)
The following constraints apply to this parameter: The following constraints apply to this parameter:
o WILLINGNESS >= WILL_NEVER o WILLINGNESS >= WILL_NEVER
o WILLINGNESS <= WILL_ALWAYS o WILLINGNESS <= WILL_ALWAYS
5.8. Parameter Change Constraints 5.10. Parameter Change Constraints
This section presents guidelines, applicable if protocol parameters This section presents guidelines, applicable if protocol parameters
are changed dynamically. are changed dynamically.
O_HOLD_TIME O_HOLD_TIME
* If O_HOLD_TIME for a router changes, then O_time for all * If O_HOLD_TIME for a router changes, then O_time for all
Originator Tuples MAY be changed. Originator Tuples MAY be changed.
TC_INTERVAL TC_INTERVAL
skipping to change at page 16, line 36 skipping to change at page 20, line 31
TC_HOP_LIMIT TC_HOP_LIMIT
* If TC_HOP_LIMIT changes, and the router uses multiple values * If TC_HOP_LIMIT changes, and the router uses multiple values
after the change, then message intervals and validity times after the change, then message intervals and validity times
included in TC messages MUST be respected. The simplest way to included in TC messages MUST be respected. The simplest way to
do this is to start any new repeating pattern of TC_HOP_LIMIT do this is to start any new repeating pattern of TC_HOP_LIMIT
values with its largest value. values with its largest value.
6. Information Bases 6. Information Bases
Each router maintains the Information Bases described in the
following sections. These are used for describing the protocol in
this document. An implementation of this protocol MAY maintain this
information in the indicated form, or in any other organization which
offers access to this information. In particular note that it is not
necessary to remove Tuples from Sets at the exact time indicated,
only to behave as if the Tuples were removed at that time.
The purpose of OLSRv2 is to determine the Routing Set, which may be The purpose of OLSRv2 is to determine the Routing Set, which may be
used to update IP's Routing Table, providing "next hop" routing used to update IP's Routing Table, providing "next hop" routing
information for IP datagrams. OLSRv2 maintains the following information for IP datagrams. OLSRv2 maintains the following
Information Bases: Information Bases:
Local Information Base - as defined in [NHDP], extended by the Local Information Base - as defined in [NHDP], extended by the
addition of an Originator Set, defined in Section 6.1.1 and a addition of an Originator Set, defined in Section 6.1.1 and a
Local Attached Network Set, defined in Section 6.1.2. Local Attached Network Set, defined in Section 6.1.2.
Interface Information Bases - as defined in [NHDP], one Interface Interface Information Bases - as defined in [NHDP], one Interface
skipping to change at page 18, line 29 skipping to change at page 22, line 15
specified in [NHDP], rather than being added to the Local Attached specified in [NHDP], rather than being added to the Local Attached
Network Set. Network Set.
An attached network MAY also be attached to other routers. An attached network MAY also be attached to other routers.
It is not the responsibility of OLSRv2 to maintain routes from this It is not the responsibility of OLSRv2 to maintain routes from this
router to networks recorded in the Local Attached Network Set. router to networks recorded in the Local Attached Network Set.
Local Attached Neighbor Tuples are removed from the Local Attached Local Attached Neighbor Tuples are removed from the Local Attached
Network Set only when the routers' local attached network Network Set only when the routers' local attached network
configuration changes, i.e. they are not subject to timer-based configuration changes, i.e., they are not subject to timer-based
expiration or changes due to received messages. expiration or changes due to received messages.
6.2. Neighbor Information Base 6.2. Neighbor Information Base
Each Neighbor Tuple in the Neighbor Set, defined in [NHDP], has these Each Neighbor Tuple in the Neighbor Set, defined in [NHDP], has these
additional elements: additional elements:
N_willingness is the router's willingness to be selected as an MPR, N_willingness is the router's willingness to be selected as an MPR,
in the range from WILL_NEVER to WILL_ALWAYS, both inclusive; in the range from WILL_NEVER to WILL_ALWAYS, both inclusive;
N_mpr is a boolean flag, describing if this neighbor is selected as N_mpr is a boolean flag, describing if this neighbor is selected as
an MPR by this router; an MPR by this router;
N_mpr_selector is a boolean flag, describing if this neighbor has N_mpr_selector is a boolean flag, describing if this neighbor has
selected this router as an MPR, i.e. is an MPR selector of this selected this router as an MPR, i.e., is an MPR selector of this
router. router.
6.3. Topology Information Base 6.3. Topology Information Base
The Topology Information Base stores information required for the The Topology Information Base stores information required for the
generation and processing of TC messages, and information received in generation and processing of TC messages, and information received in
TC messages. The Advertised Neighbor Set contains interface TC messages. The Advertised Neighbor Set contains addresses of
addresses of symmetric 1-hop neighbors which are to be reported in TC symmetric 1-hop neighbors which are to be reported in TC messages.
messages. The Advertising Remote Router Set, the Topology Set and The Advertising Remote Router Set, the Topology Set and the Attached
the Attached Network Set record information received in TC messages. Network Set record information received in TC messages.
Additionally, a Routing Set is maintained, derived from the Additionally, a Routing Set is maintained, derived from the
information recorded in the Neighborhood Information Base, Topology information recorded in the Neighborhood Information Base, Topology
Set, Attached Network Set and Advertising Remote Router Set. Set, Attached Network Set and Advertising Remote Router Set.
6.3.1. Advertised Neighbor Set 6.3.1. Advertised Neighbor Set
A router's Advertised Neighbor Set contains interface addresses of A router's Advertised Neighbor Set contains addresses of symmetric
symmetric 1-hop neighbors which are to be advertised through TC 1-hop neighbors which are to be advertised through TC messages. It
messages. It consists of Advertised Neighbor Tuples: consists of Advertised Neighbor Tuples:
(A_neighbor_iface_addr) (A_neighbor_addr)
In addition, an Advertised Neighbor Set Sequence Number (ANSN) is In addition, an Advertised Neighbor Set Sequence Number (ANSN) is
maintained. Each time the Advertised Neighbor Set is updated, the maintained. Each time the Advertised Neighbor Set is updated, the
ANSN MUST be incremented. The ANSN MUST also be incremented if there ANSN MUST be incremented. The ANSN MUST also be incremented if there
is a change to the set of Local Attached Network Tuples that are to is a change to the set of Local Attached Network Tuples that are to
be advertised in the router's TC messages. be advertised in the router's TC messages.
The Advertised Neighbor Set for a router is derived from the Neighbor The Advertised Neighbor Set for a router is derived from the Neighbor
Set of that same router, and so Advertised Neighbor Tuples are Set of that same router, specifically, each address in the
removed when, for example, the corresponding Neighbor Tuples in the N_neighbor_addr_list of a Neighbor Tuple MUST be an A_neighbor_addr
Neighbor Set are removed. Advertised Neighbor Tuples are not subject if the corresponding N_mpr_selector = true, and MAY be an
to timer-based expiration. A_neighbor_addr if the corresponding N_mpr_selector = false. No
other address may be an A_neighbor_addr. The Advertised Neighbor Set
MUST therefore be updated when the Neighbor Set changes, see
Section 13. Advertised Neighbor Tuples are not subject to timer-
based expiration.
6.3.2. Advertising Remote Router Set 6.3.2. Advertising Remote Router Set
A router's Advertising Remote Router Set records information A router's Advertising Remote Router Set records information
describing each remote router in the network that transmits TC describing each remote router in the network that transmits TC
messages. It consists of Advertising Remote Router Tuples: messages. It consists of Advertising Remote Router Tuples:
(AR_orig_addr, AR_seq_number, AR_iface_addr_list, AR_time) (AR_orig_addr, AR_seq_number, AR_addr_list, AR_time)
where: where:
AR_orig_addr is the originator address of a received TC message, AR_orig_addr is the originator address of a received TC message,
note that this does not include a prefix length; note that this does not include a prefix length;
AR_seq_number is the greatest ANSN in any TC message received which AR_seq_number is the greatest ANSN in any TC message received which
originated from the router with originator address AR_orig_addr originated from the router with originator address AR_orig_addr
(i.e. which contributed to the information contained in this (i.e., which contributed to the information contained in this
Tuple); Tuple);
AR_iface_addr_list is an unordered list of the interface addresses
of the router with originator address AR_orig_addr; AR_addr_list is an unordered list of the addresses of the router
with originator address AR_orig_addr;
AR_time is the time at which this Tuple expires and MUST be removed. AR_time is the time at which this Tuple expires and MUST be removed.
6.3.3. Topology Set 6.3.3. Topology Set
A router's Topology Set records topology information about the A router's Topology Set records topology information about the
network. It consists of Topology Tuples: network. It consists of Topology Tuples:
(T_dest_iface_addr, T_orig_addr, T_seq_number, T_time) (T_dest_addr, T_orig_addr, T_seq_number, T_time)
where: where:
T_dest_iface_addr is an interface address of a destination router, T_dest_addr is an address of a destination router, which may be
which may be reached in one hop from the router with originator reached in one hop from the router with originator address
address T_orig_addr; T_orig_addr;
T_orig_addr is the originator address of a router which is the last T_orig_addr is the originator address of a router which is the last
hop on a path towards the router with interface address hop on a path towards the router with address T_dest_addr, note
T_dest_iface_addr, note that this does not include a prefix that this does not include a prefix length;
length;
T_seq_number is the greatest ANSN in any TC message received which T_seq_number is the greatest ANSN in any TC message received which
originated from the router with originator address T_orig_addr originated from the router with originator address T_orig_addr
(i.e. which contributed to the information contained in this (i.e., which contributed to the information contained in this
Tuple); Tuple);
T_time specifies the time at which this Tuple expires and MUST be T_time specifies the time at which this Tuple expires and MUST be
removed. removed.
6.3.4. Attached Network Set 6.3.4. Attached Network Set
A router's Attached Network Set records information about networks A router's Attached Network Set records information about networks
attached to other routers. It consists of Attached Network Tuples: attached to other routers. It consists of Attached Network Tuples:
skipping to change at page 21, line 4 skipping to change at page 24, line 37
(AN_net_addr, AN_orig_addr, AN_dist, AN_seq_number, AN_time) (AN_net_addr, AN_orig_addr, AN_dist, AN_seq_number, AN_time)
where: where:
AN_net_addr is the network address of an attached network, which may AN_net_addr is the network address of an attached network, which may
be reached via the router with originator address AN_orig_addr; be reached via the router with originator address AN_orig_addr;
AN_orig_addr is the originator address of a router which can act as AN_orig_addr is the originator address of a router which can act as
gateway to the network with address AN_net_addr, note that this gateway to the network with address AN_net_addr, note that this
does not include a prefix length; does not include a prefix length;
AN_dist is the number of hops to the network with address AN_dist is the number of hops to the network with address
AN_net_addr from the router with originator address AN_orig_addr; AN_net_addr from the router with originator address AN_orig_addr;
AN_seq_number is the greatest ANSN in any TC message received which AN_seq_number is the greatest ANSN in any TC message received which
originated from the router with originator address AN_orig_addr originated from the router with originator address AN_orig_addr
(i.e. which contributed to the information contained in this (i.e., which contributed to the information contained in this
Tuple); Tuple);
AN_time specifies the time at which this Tuple expires and MUST be AN_time specifies the time at which this Tuple expires and MUST be
removed. removed.
6.3.5. Routing Set 6.3.5. Routing Set
A router's Routing Set records the selected path to each destination A router's Routing Set records the selected path to each destination
for which a route is known. It consists of Routing Tuples: for which a route is known. It consists of Routing Tuples:
(R_dest_addr, R_next_iface_addr, R_dist, R_local_iface_addr) (R_dest_addr, R_next_iface_addr, R_dist, R_local_iface_addr)
where: where:
R_dest_addr is the address of the destination, either the address of R_dest_addr is the address of the destination, either the address of
an interface of a destination router, or the network address of an an interface of a destination router, or the network address of an
attached network; attached network;
R_next_iface_addr is the OLSRv2 interface address of the "next hop" R_next_iface_addr is the address of the "next hop" on the selected
on the selected path to the destination; path to the destination;
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_local_iface_addr is the address of the local OLSRv2 interface over R_local_iface_addr is the address of the local OLSRv2 interface over
which a packet MUST be sent to reach the destination by the which a packet MUST be sent to reach the destination by the
selected path. selected path.
The Routing Set for a router is derived from the contents of the The Routing Set for a router is derived from the contents of the
other sets of the router, and is updated (Routing Tuples added or other sets of the router, and is updated (Routing Tuples added or
skipping to change at page 23, line 11 skipping to change at page 27, line 4
(F_type, F_orig_addr, F_seq_number, F_time) (F_type, F_orig_addr, F_seq_number, F_time)
where: where:
F_type is the forwarded Message Type; F_type is the forwarded Message Type;
F_orig_addr is the originator address of the forwarded message; F_orig_addr is the originator address of the forwarded message;
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.
6.4.4. Relay Set 6.4.4. Relay Set
A router has a Relay Set per local OLSRv2 interface. Each Relay Set A router has a Relay Set per local OLSRv2 interface. Each Relay Set
records the OLSRv2 interface addresses of symmetric 1-hop neighbors, records the addresses of symmetric 1-hop neighbors, such that the
such that the router is to forward messages received from those router is to forward messages received from those neighbors' OLSRv2
neighbors' OLSRv2 interfaces, on that local OLSRv2 interface, if not interfaces, on that local OLSRv2 interface, if not otherwise excluded
otherwise excluded from forwarding that message (e.g. by it having from forwarding that message (e.g., by it having been previously
been previously forwarded). It consists of Relay Tuples: forwarded). It consists of Relay Tuples:
(RY_neighbor_iface_addr) (RY_neighbor_iface_addr)
The Relay Set for an interface is derived from the Link Set for the The Relay Set for an interface is derived from the Link Set for the
same interface, and so Relay Tuples are removed when the same interface, and so Relay Tuples are removed when the
corresponding Link Tuples in the Link Set of this interface are corresponding Link Tuples in the Link Set of this interface are
removed, or when processing otherwise suggests their removal. Relay removed, or when processing otherwise suggests their removal. Relay
Tuples are not subject to timer-based expiration. Tuples are not subject to timer-based expiration.
7. Message Processing and Forwarding 7. Message Processing and Forwarding
skipping to change at page 24, line 16 skipping to change at page 28, line 9
the Message Body even if the message is forwarded (but not the Message Body even if the message is forwarded (but not
processed). An implementation MAY either only parse the Message Body processed). An implementation MAY either only parse the Message Body
if necessary, or MAY always parse the Message Body. An if necessary, or MAY always parse the Message Body. An
implementation MUST discard the message silently if it is unable to implementation MUST discard the message silently if it is unable to
parse the Message Header or (if attempted) the Message Body. parse the Message Header or (if attempted) the Message Body.
OLSRv2 does not require any part of the Packet Header. OLSRv2 does not require any part of the Packet Header.
7.1. Actions when Receiving a Message 7.1. Actions when Receiving a Message
If the router receives a HELLO message from NHDP, then the message is If the router receives a HELLO message from [NHDP], then the message
processed according to Section 10. is processed according to Section 10.
A router MUST perform the following tasks for each received TC A router MUST perform the following tasks for each received TC
message or other Message Type defined by an extension to OLSRv2 and message or other Message Type defined by an extension to OLSRv2 and
specified to use this process: specified to use this process:
1. If the router recognizes from the originator address of the 1. If the router recognizes from the originator address of the
message that the message is one which the receiving router itself message that the message is one which the receiving router itself
originated (i.e. is the current originator address of the router, originated (i.e. is the current originator address of the router,
or is an O_orig_addr in an Originator Tuple) then the message or is an O_orig_addr in an Originator Tuple) then the message
MUST be silently discarded. MUST be silently discarded.
skipping to change at page 25, line 44 skipping to change at page 29, line 31
+ P_time := current time + P_HOLD_TIME. + P_time := current time + P_HOLD_TIME.
2. Process the current message according to its type. For a TC 2. Process the current message according to its type. For a TC
message this is as defined in Section 12. message this is as defined in Section 12.
7.3. Message Considered for Forwarding 7.3. Message Considered for Forwarding
If a message (the "current message") is considered for forwarding, If a message (the "current message") is considered for forwarding,
then the following tasks MUST be performed: then the following tasks MUST be performed:
1. If the sending interface address (the source address of the IP 1. If the sending address (i.e., the source address of the IP
datagram containing the current message) does not match (taking datagram containing the current message) does not match (taking
into account any address prefix) an OLSRv2 interface address in into account any address prefix) an address in an
an L_neighbor_iface_addr_list of a Link Tuple, with L_status = L_neighbor_iface_addr_list of a Link Tuple, with L_status =
SYMMETRIC, in the Link Set for the OLSRv2 interface on which the SYMMETRIC, in the Link Set for the OLSRv2 interface on which the
current message was received (the "receiving interface") then the current message was received (the "receiving interface") then the
current message MUST be silently discarded. current message MUST be silently discarded.
2. Otherwise: 2. Otherwise:
1. If a Received Tuple exists in the Received Set for the 1. If a Received Tuple exists in the Received Set for the
receiving interface, with: receiving interface, with:
+ RX_type = the Message Type of the current message, AND; + RX_type = the Message Type of the current message, AND;
skipping to change at page 26, line 47 skipping to change at page 30, line 33
- F_type = the Message Type of the current message, AND; - F_type = the Message Type of the current message, AND;
- F_orig_addr = the originator address of the current - F_orig_addr = the originator address of the current
message, AND; message, AND;
- F_seq_number = the sequence number of the current - F_seq_number = the sequence number of the current
message. message.
then the current message MUST be silently discarded. then the current message MUST be silently discarded.
3. Otherwise if the sending interface address matches 3. Otherwise if the sending address matches (taking account
(taking account of any address prefix) an of any address prefix) an RY_neighbor_iface_addr in the
RY_neighbor_iface_addr in the Relay Set for the receiving Relay Set for the receiving interface, then:
interface, then:
1. Create a Forwarded Tuple with: 1. Create a Forwarded Tuple with:
o F_type := the Message Type of the current message; o F_type := the Message Type of the current message;
o F_orig_addr := originator address of the current o F_orig_addr := originator address of the current
message; message;
o F_seq_number := sequence number of the current o F_seq_number := sequence number of the current
message; message;
skipping to change at page 28, line 30 skipping to change at page 32, line 15
extension which is neither zero as so assumed, nor a specifically extension which is neither zero as so assumed, nor a specifically
indicated non-zero type extension, are ignored. indicated non-zero type extension, are ignored.
8.1. HELLO Messages 8.1. HELLO Messages
A HELLO message in OLSRv2 is generated as specified in [NHDP]. In A HELLO message in OLSRv2 is generated as specified in [NHDP]. In
addition, an OLSRv2 router MUST be able to modify such messages, addition, an OLSRv2 router MUST be able to modify such messages,
prior to these being sent on an OLSRv2 interface, so that such HELLO prior to these being sent on an OLSRv2 interface, so that such HELLO
messages: messages:
o MUST include TLV(s) with Type := MPR associated with all OLSRv2 o MUST include TLV(s) with Type := MPR associated with all addresses
interface addresses that: that:
* are included in the HELLO message associated with a TLV with * are included in the HELLO message associated with a TLV with
Type = LINK_STATUS and Value = SYMMETRIC; AND Type = LINK_STATUS and Value = SYMMETRIC; AND
* are included in a Neighbor Tuple with N_mpr = true. * are included in a Neighbor Tuple with N_mpr = true.
o MUST NOT include any TLVs with Type = MPR associated with any o MUST NOT include any TLVs with Type = MPR associated with any
other addresses. other addresses.
o MAY include a message TLV with Type := MPR_WILLING, indicating the o MAY include a message TLV with Type := MPR_WILLING, indicating the
skipping to change at page 29, line 45 skipping to change at page 33, line 30
8.2. TC Messages 8.2. TC Messages
A TC message MUST contain: A TC message MUST contain:
o <msg-orig-addr>, <msg-seq-num> and <msg-hop-limit> elements in its o <msg-orig-addr>, <msg-seq-num> and <msg-hop-limit> elements in its
Message Header, as specified in [RFC5444]. Message Header, as specified in [RFC5444].
o A <msg-hop-count> element in its Message Header if the message o A <msg-hop-count> element in its Message Header if the message
contains a TLV with either Type = VALIDITY_TIME or Type = contains a TLV with either Type = VALIDITY_TIME or Type =
INTERVAL_TIME indicating more than one time value according to INTERVAL_TIME indicating more than one time value according to
distance. distance. (A TC message MAY contain <msg-hop-count> even if it
does not need to.)
o A single Message TLV with Type := CONT_SEQ_NUM, and Type Extension o A single Message TLV with Type := CONT_SEQ_NUM, and Type Extension
:= COMPLETE or Type Extension := INCOMPLETE, as specified in := COMPLETE or Type Extension := INCOMPLETE, as specified in
Section 8.2.1 (for complete and incomplete TC messages, Section 8.2.1 (for complete and incomplete TC messages,
respectively). respectively).
o A Message TLV with Type := VALIDITY_TIME, as specified in o A Message TLV with Type := VALIDITY_TIME, as specified in
[timetlv]. The options included in [timetlv] for representing [RFC5497]. The options included in [RFC5497] for representing
zero and infinite times MUST NOT be used. zero and infinite times MUST NOT be used.
o All of the router's interface addresses. These MUST be included o All of the router's addresses. These MUST be included in the
in the message's Address Blocks, unless: message's Address Blocks, unless:
* the router has a single interface, with a single interface * the router has a single interface, with a single address with
address with maximum prefix length; AND maximum prefix length; AND
* that address is the router's originator address. * that address is the router's originator address.
In this exceptional case, the address will be included as the In this exceptional case, the address will be included as the
message's originator address, and MAY be omitted from the message's originator address, and MAY be omitted from the
message's Address Blocks. message's Address Blocks.
o TLV(s) with Type := LOCAL_IF and Value := UNSPEC_IF associated o TLV(s) with Type := LOCAL_IF and Value := UNSPEC_IF associated
with all of the router's interface addresses. with all of the router's addresses.
o If the TC message is complete, all addresses in the Advertised o If the TC message is complete, all addresses in the Advertised
Address Set and all addresses in the Local Attached Network Set, Address Set and all addresses in the Local Attached Network Set,
the latter (only) with associated GATEWAY Address Block TLV(s), as the latter (only) with associated GATEWAY Address Block TLV(s), as
specified in Section 8.2.2. specified in Section 8.2.2.
A TC message MAY contain: A TC message MAY contain:
o If the TC message is incomplete, any addresses in the Advertised o If the TC message is incomplete, any addresses in the Advertised
Address Set and any addresses in the Local Attached Network Set, Address Set and any addresses in the Local Attached Network Set,
the latter (only) with associated GATEWAY Address Block TLV(s), as the latter (only) with associated GATEWAY Address Block TLV(s), as
specified in Section 8.2.2. specified in Section 8.2.2.
o A Message TLV with Type := INTERVAL_TIME, as specified in o A Message TLV with Type := INTERVAL_TIME, as specified in
[timetlv]. The options included in [timetlv] for representing [RFC5497]. The options included in [RFC5497] for representing
zero and infinite times MUST NOT be used. zero and infinite times MUST NOT be used.
8.2.1. TC Message TLVs 8.2.1. TC Message TLVs
In a TC message, a router MUST include a single CONT_SEQ_NUM Message In a TC message, a router MUST include a single CONT_SEQ_NUM Message
TLV, as specified in Table 3, and with Type Extension = COMPLETE or TLV, as specified in Table 3, and with Type Extension = COMPLETE or
Type Extension = INCOMPLETE, according to whether the TC message is Type Extension = INCOMPLETE, according to whether the TC message is
complete or incomplete. complete or incomplete.
+--------------+--------------+-------------------------------------+ +--------------+--------------+-------------------------------------+
skipping to change at page 31, line 34 skipping to change at page 35, line 28
An OLSRv2 HELLO message is composed and generated as defined in An OLSRv2 HELLO message is composed and generated as defined in
[NHDP], with the following additions: [NHDP], with the following additions:
o A Message TLV with Type := MPR_WILLING and Value := WILLINGNESS o A Message TLV with Type := MPR_WILLING and Value := WILLINGNESS
MUST be included, unless WILLINGNESS = WILL_DEFAULT (in which case MUST be included, unless WILLINGNESS = WILL_DEFAULT (in which case
it MAY be included). it MAY be included).
o For each address which is included in the message with an o For each address which is included in the message with an
associated TLV with Type = LINK_STATUS and Value = SYMMETRIC, and associated TLV with Type = LINK_STATUS and Value = SYMMETRIC, and
is of an MPR (i.e. the address is in the is of an MPR (i.e. the address is in the N_neighbor_addr_list of a
N_neighbor_iface_addr_list of a Neighbor Tuple with N_mpr = true), Neighbor Tuple with N_mpr = true), that address (including a
that address (including a different copy of that address, in the different copy of that address, in the same or a different Address
same or a different Address Block) MUST be associated with an Block) MUST be associated with an Address Block TLV with Type :=
Address Block TLV with Type := MPR. MPR.
o For each address which is included in the message and is not o For each address which is included in the message and is not
associated with a TLV with Type = LINK_STATUS and Value = associated with a TLV with Type = LINK_STATUS and Value =
SYMMETRIC, or is not of an MPR (i.e. the address is not in the SYMMETRIC, or is not of an MPR (i.e. the address is not in the
N_neighbor_iface_addr_list of a Neighbor Tuple with N_mpr = true), N_neighbor_addr_list of a Neighbor Tuple with N_mpr = true), that
that address (including different copies of that address, in the address (including different copies of that address, in the same
same or different Address Blocks) MUST NOT be associated with an or different Address Blocks) MUST NOT be associated with an
Address Block TLV with Type := MPR. Address Block TLV with Type := MPR.
o An additional HELLO message MAY be sent when the router's set of o An additional HELLO message MAY be sent when the router's set of
MPRs changes, in addition to the cases specified in [NHDP], and MPRs changes, in addition to the cases specified in [NHDP], and
subject to the same constraints. subject to the same constraints.
9.1. HELLO Message: Transmission 9.1. HELLO Message: Transmission
HELLO messages are included in packets as specified in [RFC5444]. HELLO messages are included in packets as specified in [RFC5444].
These packets may contain other messages, including TC messages. These packets may contain other messages, including TC messages.
10. HELLO Message Processing 10. HELLO Message Processing
All HELLO message processing, including determination of whether a All HELLO message processing, including determination of whether a
message is invalid, considers only TLVs with Type Extension = 0. message is invalid, considers only TLVs with Type Extension = 0.
TLVs with any other type extension are ignored. All references to, TLVs with any other type extension are ignored. All references to,
for example, a TLV with Type = MPR_WILLING refer to a TLV with Type = for example, a TLV with Type = MPR_WILLING refer to a TLV with Type =
MPR_WILLING and Type Extension = 0. MPR_WILLING and Type Extension = 0.
In addition to the reasons specified in [NHDP], a HELLO message MUST In addition to the reasons specified in [NHDP], for discarding a
NOT: HELLO message on reception, a HELLO message MUST NOT:
o Have more than one TLV with Type = MPR_WILLING in its Message TLV o Have more than one TLV with Type = MPR_WILLING in its Message TLV
Block, where TLVs have different Values. Block, where TLVs have different Values.
o Contain any address associated with a TLV with Type = MPR, where o Contain any address associated with a TLV with Type = MPR, where
that address (including a different copy of that address, in the that address (including a different copy of that address, in the
same or a different Address Block) which is not also associated same or a different Address Block) which is not also associated
with the single value SYMMETRIC by a TLV with Type = LINK_STATUS with the single Value SYMMETRIC by a TLV with Type = LINK_STATUS
or Type = OTHER_NEIGHB. or Type = OTHER_NEIGHB.
Such a HELLO message MAY be discarded before processing. If it is Such a HELLO message MAY be discarded before processing. If it is
not then all TLVs with the type(s) for which an error was indicated not then all TLVs with the type(s) for which an error was indicated
MUST be ignored (treated as not present) in the following processing. MUST be ignored (treated as not present) in the following processing.
HELLO messages are first processed as specified in [NHDP]. The HELLO messages are first processed as specified in [NHDP]. The
router MUST identify the Neighbor Tuple corresponding to the router MUST identify the Neighbor Tuple corresponding to the
originator of the HELLO message (the "current Neighbor Tuple") and originator of the HELLO message (the "current Neighbor Tuple") and
update its N_willingness as described in Section 10.1 and its update its N_willingness as described in Section 10.1 and its
N_mpr_selector as described in Section 10.2. Following these, the N_mpr_selector as described in Section 10.2. Following these, the
router MUST also perform the processing defined in Section 10.3. router MUST also perform the processing defined in Section 10.3.
10.1. Updating Willingness 10.1. Updating Willingness
N_willingness in the current Neighbor Tuple is updated as follows: N_willingness in the current Neighbor Tuple is updated as follows:
1. If the HELLO message contains a Message TLV with Type = 1. If the HELLO message contains a Message TLV with Type =
MPR_WILLING then N_willingness := the value of that TLV; MPR_WILLING then N_willingness := the Value of that TLV;
2. Otherwise, N_willingness := WILL_DEFAULT. 2. Otherwise, N_willingness := WILL_DEFAULT.
10.2. Updating MPR Selectors 10.2. Updating MPR Selectors
N_mpr_selector is updated as follows: N_mpr_selector is updated as follows:
1. If a router finds any of its local OLSRv2 interface addresses 1. If a router finds any of its local addresses with an associated
with an associated TLV with Type = MPR in the HELLO message TLV with Type = MPR in the HELLO message (indicating that the
(indicating that the originator router has selected the receiving originator router has selected the receiving router as an MPR)
router as an MPR) then, for the current Neighbor Tuple: then, for the current Neighbor Tuple:
* N_mpr_selector := true * N_mpr_selector := true
2. Otherwise, if a router finds any of its own interface addresses 2. Otherwise, if a router finds any of its own addresses with an
with an associated TLV with Type = LINK_STATUS and Value = associated TLV with Type = LINK_STATUS and Value = SYMMETRIC in
SYMMETRIC in the HELLO message, then for the current Neighbor the HELLO message, then for the current Neighbor Tuple:
Tuple:
* N_mpr_selector := false * N_mpr_selector := false
10.3. Symmetric 1-Hop and 2-Hop Neighborhood Changes 10.3. Symmetric 1-Hop and 2-Hop Neighborhood Changes
A router MUST also perform the following: A router MUST also perform the following:
1. If N_symmetric of a Neighbor Tuple changes from true to false, 1. If N_symmetric of a Neighbor Tuple changes from true to false,
for that Neighbor Tuple: for that Neighbor Tuple:
skipping to change at page 34, line 29 skipping to change at page 38, line 19
11. TC Message Generation 11. TC Message Generation
A router with one or more OLSRv2 interfaces, and with a non-empty A router with one or more OLSRv2 interfaces, and with a non-empty
Advertised Neighbor Set or a non-empty Local Attached Network Set Advertised Neighbor Set or a non-empty Local Attached Network Set
MUST generate TC messages. A router with an empty Advertised MUST generate TC messages. A router with an empty Advertised
Neighbor Set and empty Local Attached Network Set SHOULD also Neighbor Set and empty Local Attached Network Set SHOULD also
generate "empty" TC messages for a period A_HOLD_TIME after it last generate "empty" TC messages for a period A_HOLD_TIME after it last
generated a non-empty TC message. TC messages (non-empty and empty) generated a non-empty TC message. TC messages (non-empty and empty)
are generated according to the following: are generated according to the following:
1. The message hop count, if included, MUST be set to zero. 1. The message originator address MUST be set to the router's
originator address.
2. The message hop limit MUST be set to a value greater than 1. A 2. The message hop count, if included, MUST be set to zero.
3. The message hop limit MUST be set to a value greater than 1. A
router MAY use the same hop limit TC_HOP_LIMIT in all TC router MAY use the same hop limit TC_HOP_LIMIT in all TC
messages, or use different values of the hop limit TC_HOP_LIMIT messages, or use different values of the hop limit TC_HOP_LIMIT
in TC messages, see Section 5.6. in TC messages, see Section 5.8.
3. The message MUST contain a Message TLV with Type := CONT_SEQ_NUM 4. The message MUST contain a Message TLV with Type := CONT_SEQ_NUM
and Value := ANSN from the Advertised Neighbor Set. If the TC and Value := ANSN from the Advertised Neighbor Set. If the TC
message is complete then this Message TLV MUST have Type message is complete then this Message TLV MUST have Type
Extension := COMPLETE, otherwise it MUST have Type Extension := Extension := COMPLETE, otherwise it MUST have Type Extension :=
INCOMPLETE. INCOMPLETE.
4. The message MUST contain a Message TLV with Type := 5. The message MUST contain a Message TLV with Type :=
VALIDITY_TIME, as specified in [timetlv]. If all TC messages are VALIDITY_TIME, as specified in [RFC5497]. If all TC messages are
sent with the same hop limit then this TLV MUST have Value := sent with the same hop limit then this TLV MUST have Value :=
T_HOLD_TIME. If TC messages are sent with different hop limits T_HOLD_TIME. If TC messages are sent with different hop limits
(more than one value of TC_HOP_LIMIT) then this TLV MUST specify (more than one value of TC_HOP_LIMIT) then this TLV MUST specify
times which vary with the number of hops distance appropriate to times which vary with the number of hops distance appropriate to
the chosen pattern of TC message hop limits, as specified in the chosen pattern of TC message hop limits, as specified in
[timetlv], these times SHOULD be appropriate multiples of [RFC5497], these times SHOULD be appropriate multiples of
T_HOLD_TIME. T_HOLD_TIME.
5. The message MAY contain a Message TLV with Type := INTERVAL_TIME, 6. The message MAY contain a Message TLV with Type := INTERVAL_TIME,
as specified in [timetlv]. If all TC messages are sent with the as specified in [RFC5497]. If all TC messages are sent with the
same hop limit then this TLV MUST have Value := TC_INTERVAL. If same hop limit then this TLV MUST have Value := TC_INTERVAL. If
TC messages are sent with different hop limits, then this TLV TC messages are sent with different hop limits, then this TLV
MUST specify times which vary with the number of hops distance MUST specify times which vary with the number of hops distance
appropriate to the chosen pattern of TC message hop limits, as appropriate to the chosen pattern of TC message hop limits, as
specified in [timetlv], these times SHOULD be appropriate specified in [RFC5497], these times SHOULD be appropriate
multiples of TC_INTERVAL. multiples of TC_INTERVAL.
6. Unless the router has a single interface, with a single interface 7. Unless the router has a single interface, with a single address
address with maximum prefix length, and that address is the with maximum prefix length, and that address is the router's
router's originator address, the message MUST contain all of the originator address, the message MUST contain all of the router's
router's interface addresses (i.e. all addresses in an addresses (i.e. all addresses in an I_local_iface_addr_list) in
I_local_iface_addr_list) in its Address Blocks. its Address Blocks.
7. All addresses of the router's interfaces that are included in an 8. All addresses of the router's interfaces that are included in an
Address Block MUST each be associated with a TLV with Type := Address Block MUST each be associated with a TLV with Type :=
LOCAL_IF and Value := UNSPEC_IF. LOCAL_IF and Value := UNSPEC_IF.
8. A complete message MUST include, and an incomplete message MAY 9. A complete message MUST include, and an incomplete message MAY
include, in its Address Blocks: include, in its Address Blocks:
1. Each A_neighbor_iface_addr from the Advertised Neighbor Set; 1. Each A_neighbor_addr from the Advertised Neighbor Set;
2. AL_net_addr from each Local Attached Neighbor Tuple, each 2. AL_net_addr from each Local Attached Neighbor Tuple, each
associated with a TLV with Type := GATEWAY and Value := associated with a TLV with Type := GATEWAY and Value :=
AL_dist. AL_dist.
11.1. TC Message: Transmission 11.1. TC Message: Transmission
Complete TC messages are generated and transmitted periodically on Complete TC messages are generated and transmitted periodically on
all OLSRv2 interfaces, with a default interval between two all OLSRv2 interfaces, with a default interval between two
consecutive TC transmissions by the same router of TC_INTERVAL. consecutive TC transmissions by the same router of TC_INTERVAL.
skipping to change at page 36, line 40 skipping to change at page 40, line 33
are ignored. All references to, for example, a TLV with Type = are ignored. All references to, for example, a TLV with Type =
VALIDITY_TIME refer to a TLV with Type = VALIDITY_TIME and Type VALIDITY_TIME refer to a TLV with Type = VALIDITY_TIME and Type
Extension = 0. Extension = 0.
12.1. Invalid Message 12.1. Invalid Message
A received TC message is invalid for processing by this router if any A received TC message is invalid for processing by this router if any
of the following conditions are true. of the following conditions are true.
o The Message Header does not include an originator address, a o The Message Header does not include an originator address, a
message sequence number, and at least one of a hop limit and a hop message sequence number, and a hop limit.
count.
o The message does not have a TLV with Type = VALIDITY_TIME in its o The Message Header a hop count, and contains a multi-value TLV
Message TLV Block. with Type = VALIDITY_TIME or Type == INTERVAL_TIME, as defined in
[RFC5497].
o The message has more than one TLV with Type = VALIDITY_TIME in its o The message does not have a single TLV with Type = VALIDITY_TIME
Message TLV Block, and these TLVs indicate different validity in its Message TLV Block.
times, as specified by [timetlv].
o The message has more than one TLV with Type = INTERVAL_TIME in its o The message has more than one TLV with Type = INTERVAL_TIME in its
Message TLV Block, and these TLVs indicate different interval Message TLV Block.
times, as specified by [timetlv].
o The message does not have a TLV with Type = CONT_SEQ_NUM and Type o The message does not have a TLV with Type = CONT_SEQ_NUM and Type
Extension = COMPLETE or Type Extension = INCOMPLETE in its Message Extension = COMPLETE or Type Extension = INCOMPLETE in its Message
TLV Block. TLV Block.
o The message has more than one TLV with Type = CONT_SEQ_NUM and o The message has more than one TLV with Type = CONT_SEQ_NUM and
Type Extension = COMPLETE or Type Extension = INCOMPLETE in its Type Extension = COMPLETE or Type Extension = INCOMPLETE in its
Message TLV Block, and these do not have the same type extension Message TLV Block, and these do not have the same type extension
and the same Value. and the same Value.
o The message has any Address Block TLV(s) with Type = LOCAL_IF and o The message has any Address Block TLV(s) with Type = LOCAL_IF and
any single value(s) which are not equal to UNSPEC_IF. any single Value(s) which are not equal to UNSPEC_IF.
o Any address associated with a TLV with Type = LOCAL_IF is one of o Any address associated with a TLV with Type = LOCAL_IF is one of
the receiving router's current or recently used interface the receiving router's current or recently used addresses (i.e. is
addresses (i.e. is in any I_local_iface_addr_list in the Local in any I_local_iface_addr_list in the Local Interface Set or is
Interface Set or is equal to any IR_local_iface_addr in the equal to any IR_local_iface_addr in the Removed Interface Address
Removed Interface Address Set). Set).
o Any address (including different copies of an address, in the same o Any address (including different copies of an address, in the same
or different Address Blocks) is associated with more than one or different Address Blocks) is associated with more than one
single value by one or more TLV(s) with Type = GATEWAY. single Value by one or more TLV(s) with Type = GATEWAY.
An invalid message MUST be silently discarded, without updating the A router MAY recognize additional reasons for identifying that a
router's Information Bases. A router MAY recognize additional message is invalid. An invalid message MUST be silently discarded,
reasons for identifying that a message is badly formed and discard without updating the router's Information Bases.
such messages.
12.2. Initial TC Message Processing 12.2. Initial TC Message Processing
When, according to Section 7.2, a TC message is to be "processed When, according to Section 7.2, a TC message is to be "processed
according to its type", this means that: according to its type", this means that:
o If the TC message contains a Message TLV with Type = CONT_SEQ_NUM o If the TC message contains a Message TLV with Type = CONT_SEQ_NUM
and Type Extension = COMPLETE, then processing according to and Type Extension = COMPLETE, then processing according to
Section 12.3 and then according to Section 12.4 is carried out. Section 12.3 and then according to Section 12.4 is carried out.
o If the TC message contains a Message TLV with Type = CONT_SEQ_NUM o If the TC message contains a Message TLV with Type = CONT_SEQ_NUM
and Type Extension = INCOMPLETE, then only processing according to and Type Extension = INCOMPLETE, then only processing according to
Section 12.3 is carried out. Section 12.3 is carried out.
For the purposes of this section: For the purposes of this section:
o "originator address" refers to the originator address in the TC o "originator address" refers to the originator address in the TC
Message Header. Message Header.
o "validity time" is calculated from a VALIDITY_TIME Message TLV in o "validity time" is calculated from a VALIDITY_TIME Message TLV in
the TC message according to the specification in [timetlv]. All the TC message according to the specification in [RFC5497]. All
information in the TC message has the same validity time. information in the TC message has the same validity time.
o "ANSN" is defined as being the Value of a Message TLV with Type = o "ANSN" is defined as being the Value of a Message TLV with Type =
CONT_SEQ_NUM. CONT_SEQ_NUM.
o "sending address list" refers to the list of addresses in all o "sending address list" refers to the list of addresses in all
Address Blocks which have associated TLV(s) with Type = LOCAL_IF Address Blocks which have associated TLV(s) with Type = LOCAL_IF
and Value = UNSPEC_IF. If the sending address list is otherwise and Value = UNSPEC_IF. If the sending address list is otherwise
empty, then the message's originator address is added to the empty, then the message's originator address is added to the
sending address list, with maximum prefix length. sending address list, with maximum prefix length.
skipping to change at page 39, line 12 skipping to change at page 42, line 50
+ AR_orig_addr := originator address. + AR_orig_addr := originator address.
2. This Advertising Remote Router Tuple (existing or new, the 2. This Advertising Remote Router Tuple (existing or new, the
"current tuple") is then modified as follows: "current tuple") is then modified as follows:
+ AR_seq_number := ANSN; + AR_seq_number := ANSN;
+ AR_time := current time + validity time. + AR_time := current time + validity time.
+ AR_iface_addr_list := sending address list + AR_addr_list := sending address list
3. For each other Advertising Remote Router Tuple (with a 3. For each other Advertising Remote Router Tuple (with a
different AR_orig_addr, the "other tuple") whose different AR_orig_addr, the "other tuple") whose AR_addr_list
AR_iface_addr_list contains any address in the contains any address in the AR_addr_list of the current
AR_iface_addr_list of the current tuple: tuple:
1. remove all Topology Tuples with T_orig_addr = 1. remove all Topology Tuples with T_orig_addr =
AR_orig_addr of the other tuple; AR_orig_addr of the other tuple;
2. remove all Attached Network Tuples with AN_orig_addr = 2. remove all Attached Network Tuples with AN_orig_addr =
AR_orig_addr of the other tuple; AR_orig_addr of the other tuple;
3. remove the other tuple. 3. remove the other tuple.
12.3.2. Populating the Topology Set 12.3.2. Populating the Topology Set
The router MUST update its Topology Set as follows: The router MUST update its Topology Set as follows:
1. For each address (henceforth advertised address) in an Address 1. For each address (henceforth advertised address) in an Address
Block that does not have an associated TLV with Type = LOCAL_IF, Block that does not have an associated TLV with Type = LOCAL_IF,
or an associated TLV with Type = GATEWAY: or an associated TLV with Type = GATEWAY:
1. If there is no Topology Tuple such that: 1. If there is no Topology Tuple such that:
+ T_dest_iface_addr = advertised address; AND + T_dest_addr = advertised address; AND
+ T_orig_addr = originator address + T_orig_addr = originator address
then create a new Topology Tuple with: then create a new Topology Tuple with:
+ T_dest_iface_addr := advertised address; + T_dest_addr := advertised address;
+ T_orig_addr := originator address. + T_orig_addr := originator address.
2. This Topology Tuple (existing or new) is then modified as 2. This Topology Tuple (existing or new) is then modified as
follows: follows:
+ T_seq_number := ANSN; + T_seq_number := ANSN;
+ T_time := current time + validity time. + T_time := current time + validity time.
12.3.3. Populating the Attached Network Set 12.3.3. Populating the Attached Network Set
The router MUST update its Attached Network Set as follows: The router MUST update its Attached Network Set as follows:
1. For each address (henceforth network address) in an Address Block 1. For each address (henceforth network address) in an Address Block
that does not have an associated TLV with Type = LOCAL_IF, and that does not have an associated TLV with Type = LOCAL_IF, and
does have an associated TLV with Type = GATEWAY: does have an associated TLV with Type = GATEWAY:
skipping to change at page 40, line 29 skipping to change at page 44, line 20
then create a new Attached Network Tuple with: then create a new Attached Network Tuple with:
+ AN_net_addr := network address; + AN_net_addr := network address;
+ AN_orig_addr := originator address + AN_orig_addr := originator address
2. This Attached Network Tuple (existing or new) is then 2. This Attached Network Tuple (existing or new) is then
modified as follows: modified as follows:
+ AN_dist := the value of the associated GATEWAY TLV; + AN_dist := the Value of the associated GATEWAY TLV;
+ AN_seq_number := ANSN; + AN_seq_number := ANSN;
+ AN_time := current time + validity time. + AN_time := current time + validity time.
12.4. Completing TC Message Processing 12.4. Completing TC Message Processing
The TC message is processed as follows: The TC message is processed as follows:
1. The Topology Set is updated according to Section 12.4.1. 1. The Topology Set is updated according to Section 12.4.1.
skipping to change at page 41, line 37 skipping to change at page 45, line 28
then create an Originator Tuple with: then create an Originator Tuple with:
* O_orig_addr := old originator address * O_orig_addr := old originator address
This Originator Tuple (existing or new) is then modified as This Originator Tuple (existing or new) is then modified as
follows: follows:
* O_time := current time + O_HOLD_TIME * O_time := current time + O_HOLD_TIME
2. The Topology Information Base MUST be changed when an Advertising 2. The Advertised Neighbor Set in the Topology Information Base MUST
Remote Router Tuple expires (AR_time is reached). The following be changed when the Neighbor Set changes. The following changes
changes are required before the Advertising Remote Router Tuple are required:
is removed:
1. If an address in an N_neighbor_addr_list in a Neighbor Tuple
is removed (including when that Neighbor Tuple is removed)
and that address is also an A_neighbor_addr in an Advertised
Neighbor Tuple, then that Advertised Neighbor Tuple MUST be
removed.
2. If an address is added to an N_neighbor_addr_list in a
Neighbor Tuple with N_mpr_selector = true (including when
such a Neighbor Tuple is added) or for each address in an
N_neighbor_addr_list in a Neighbor Tuple whose N_mpr_selector
has changed from false to true, and that address is not
already an A_neighbor_addr in an Advertised Neighbor Tuple,
then an Advertised Neighbor Tuple MUST be added to the
Advertised Neighbor Set with A_neighbor_addr equal to that
address.
Other changes to the Advertised Neighbor Set MAY be made when the
Neighbor Set changes, in particular if the N_mpr_selector of a
Neighbor Tuple changes from true to false, then the Advertised
Neighbor Tuples whose A_neighbor_addr are addresses in the
N_neighbor_addr_list of that Neighbor Tuple MAY be removed.
3. The Topology Set and the Attached Network Set in the Topology
Information Base MUST be changed when an Advertising Remote
Router Tuple expires (AR_time is reached). The following changes
are required before the Advertising Remote Router Tuple is
removed:
1. All Topology Tuples with: 1. All Topology Tuples with:
+ T_orig_addr = AR_orig_addr of the Advertising Remote + T_orig_addr = AR_orig_addr of the Advertising Remote
Router Tuple Router Tuple
are removed. are removed.
2. All Attached Network Tuples with: 2. All Attached Network Tuples with:
skipping to change at page 44, line 11 skipping to change at page 48, line 28
contain only addresses of OLSRv2 interfaces with which this OLSRv2 contain only addresses of OLSRv2 interfaces with which this OLSRv2
interface has a symmetric link. This set MUST include all such interface has a symmetric link. This set MUST include all such
addresses of all such OLSRv2 interfaces of routers which are MPR addresses of all such OLSRv2 interfaces of routers which are MPR
selectors of this router. selectors of this router.
The Relay Set for an OLSRv2 interface of this router is thus created The Relay Set for an OLSRv2 interface of this router is thus created
by: by:
1. For each Link Tuple in the Link Set for this OLSRv2 interface 1. For each Link Tuple in the Link Set for this OLSRv2 interface
with L_status = SYMMETRIC, and the corresponding Neighbor Tuple with L_status = SYMMETRIC, and the corresponding Neighbor Tuple
with N_neighbor_iface_addr_list containing with N_neighbor_addr_list containing L_neighbor_iface_addr_list:
L_neighbor_iface_addr_list:
1. All addresses from L_neighbor_iface_addr_list MUST be 1. All addresses from L_neighbor_iface_addr_list MUST be
included in the Relay Set of this OLSRv2 interface if included in the Relay Set of this OLSRv2 interface if
N_mpr_selector = true, and otherwise MAY be so included. N_mpr_selector = true, and otherwise MAY be so included.
15.2. Populating the Advertised Neighbor Set 15.2. Populating the Advertised Neighbor Set
The Advertised Neighbor Set of a router contains all interface The Advertised Neighbor Set of a router contains all addresses of
addresses of those symmetric 1-hop neighbors to which the router those symmetric 1-hop neighbors to which the router advertises a link
advertises a link in its TC messages. This set MUST include all in its TC messages. This set MUST include all addresses in all MPR
addresses in all MPR selector of this router. selector of this router.
The Advertised Neighbor Set for this router is thus created by: The Advertised Neighbor Set for this router is thus created by:
1. For each Neighbor Tuple with N_symmetric = true: 1. For each Neighbor Tuple with N_symmetric = true:
1. All addresses from N_neighbor_iface_addr_list MUST be 1. All addresses from N_neighbor_addr_list MUST be included in
included in the Advertised Neighbor Set if N_mpr_selector = the Advertised Neighbor Set if N_mpr_selector = true, and
true, and otherwise MAY be so included. otherwise MAY be so included.
Whenever address(es) are added to or removed from the Advertised Whenever address(es) are added to or removed from the Advertised
Neighbor Set, its ANSN MUST be incremented. Neighbor Set, its ANSN MUST be incremented.
16. Routing Set Calculation 16. Routing Set Calculation
The Routing Set of a router is populated with Routing Tuples that The Routing Set of a router is populated with Routing Tuples that
represent paths from that router to all destinations in the network. represent paths from that router to all destinations in the network.
These paths are calculated based on the Network Topology Graph, which These paths are calculated based on the Network Topology Graph, which
is constructed from information in the Information Bases, obtained is constructed from information in the Information Bases, obtained
skipping to change at page 45, line 21 skipping to change at page 49, line 38
Tuple in the corresponding (to the OLSRv2 interface of that Tuple in the corresponding (to the OLSRv2 interface of that
I_local_iface_addr_list) Link Set which has L_status = I_local_iface_addr_list) Link Set which has L_status =
SYMMETRIC. SYMMETRIC.
o 2-hop symmetric links - all arcs Y -> Z such that: o 2-hop symmetric links - all arcs Y -> Z such that:
* Y is an address in the L_neighbor_iface_addr_list of a Link * Y is an address in the L_neighbor_iface_addr_list of a Link
Tuple, in any of the router's Link Sets, which has L_status = Tuple, in any of the router's Link Sets, which has L_status =
SYMMETRIC, AND; SYMMETRIC, AND;
* the Neighbor Tuple with Y in its N_neighbor_iface_addr_list has * the Neighbor Tuple with Y in its N_neighbor_addr_list has
N_willingness not equal to WILL_NEVER, AND; N_willingness not equal to WILL_NEVER, AND;
* Z is the N2_2hop_iface_addr of a 2-Hop Tuple in the 2-Hop Set * Z is the N2_2hop_addr of a 2-Hop Tuple in the 2-Hop Set
corresponding to the OLSRv2 interface of the chosen Link Set. corresponding to the OLSRv2 interface of the chosen Link Set.
o Advertised symmetric links - all arcs U -> V such that there o Advertised symmetric links - all arcs U -> V such that there
exists a Topology Tuple and a corresponding Advertising Remote exists a Topology Tuple and a corresponding Advertising Remote
Router Tuple (i.e. with AR_orig_addr = T_orig_addr) with: Router Tuple (i.e. with AR_orig_addr = T_orig_addr) with:
* U is in the AR_iface_addr_list of the Advertising Remote Router * U is in the AR_addr_list of the Advertising Remote Router
Tuple, AND; Tuple, AND;
* V is the T_dest_iface_addr of the Topology Tuple. * V is the T_dest_addr of the Topology Tuple.
o Symmetric 1-hop neighbor addresses - all arcs Y -> W such that: o Symmetric 1-hop neighbor addresses - all arcs Y -> W such that:
* Y is, and W is not, an address in the * Y is, and W is not, an address in the
L_neighbor_iface_addr_list of a Link Tuple, in any of the L_neighbor_iface_addr_list of a Link Tuple, in any of the
router's Link Sets, which has L_status = SYMMETRIC, AND; router's Link Sets, which has L_status = SYMMETRIC, AND;
* W and Y are included in the same N_neighbor_iface_addr_list * W and Y are included in the same N_neighbor_addr_list (i.e. the
(i.e. the one in the Neighbor Tuple whose one in the Neighbor Tuple whose N_neighbor_addr_list contains
N_neighbor_iface_addr_list contains the the L_neighbor_iface_addr_list that includes Y).
L_neighbor_iface_addr_list that includes Y).
o Attached network addresses - all arcs U -> T such that there o Attached network addresses - all arcs U -> T such that there
exists an Attached Network Tuple and a corresponding Advertising exists an Attached Network Tuple and a corresponding Advertising
Remote Router Tuple (i.e. with AR_orig_addr = AN_orig_addr) with: Remote Router Tuple (i.e. with AR_orig_addr = AN_orig_addr) with:
* U is in the AR_iface_addr_list of the Advertising Remote Router * U is in the AR_addr_list of the Advertising Remote Router
Tuple, AND; Tuple, AND;
* T is the AN_net_addr of the Attached Network Tuple. * T is the AN_net_addr of the Attached Network Tuple.
All links in the first three cases above have a hop count of one, the All links in the first three cases above have a hop count of one, the
symmetric 1-hop neighbor addresses have a hop count of zero, and the symmetric 1-hop neighbor addresses have a hop count of zero, and the
attached network addresses have a hop count given by the appropriate attached network addresses have a hop count given by the appropriate
value of AN_dist. value of AN_dist.
16.2. Populating the Routing Set 16.2. Populating the Routing Set
The Routing Set MUST contain the shortest paths for all destinations The Routing Set MUST contain the shortest paths for all destinations
skipping to change at page 46, line 21 skipping to change at page 50, line 39
16.2. Populating the Routing Set 16.2. Populating the Routing Set
The Routing Set MUST contain the shortest paths for all destinations The Routing Set MUST contain the shortest paths for all destinations
from all local OLSRv2 interfaces using the Network Topology Graph. from all local OLSRv2 interfaces using the Network Topology Graph.
This calculation MAY use any algorithm, including any means of This calculation MAY use any algorithm, including any means of
choosing between paths of equal length. choosing between paths of equal length.
Using the notation of Section 16.1, each path will have as its first Using the notation of Section 16.1, each path will have as its first
arc a local symmetric link X -> Y. There will be a path for each arc a local symmetric link X -> Y. There will be a path for each
terminating Y, Z, V, W and T which can be connected to local OLSRv2 terminating Y, Z, V, W and T which can be connected to local OLSRv2
interface address X using the indicated arcs. The corresponding address X using the indicated arcs. The corresponding Routing Tuple
Routing Tuple for this path will have: for this path will have:
o R_dest_addr := the terminating Y, Z, V, W or T; o R_dest_addr := the terminating Y, Z, V, W or T;
o R_next_iface_addr := the first arc's Y; o R_next_iface_addr := the first arc's Y;
o R_dist := the total hop count of the path; o R_dist := the total hop count of the path;
o R_local_iface_addr := the first arc's X. o R_local_iface_addr := the first arc's X.
An example algorithm for calculating the Routing Set of a router is An example algorithm for calculating the Routing Set of a router is
skipping to change at page 49, line 42 skipping to change at page 54, line 13
of these TLVs are in Section 8.1.1 and Section 8.2.1. of these TLVs are in Section 8.1.1 and Section 8.2.1.
+-------------+------+-----------+----------------------------------+ +-------------+------+-----------+----------------------------------+
| Name | Type | Type | Description | | Name | Type | Type | Description |
| | | extension | | | | | extension | |
+-------------+------+-----------+----------------------------------+ +-------------+------+-----------+----------------------------------+
| MPR_WILLING | TBD2 | 0 | Specifies the originating | | MPR_WILLING | TBD2 | 0 | Specifies the originating |
| | | | router's willingness to act as a | | | | | router's willingness to act as a |
| | | | relay and to partake in network | | | | | relay and to partake in network |
| | | | formation | | | | | formation |
| | | 1-255 | Expert Review | | Unassigned | TBD2 | 1-255 | Expert Review |
+-------------+------+-----------+----------------------------------+ +-------------+------+-----------+----------------------------------+
Table 6 Table 6
+--------------+------+----------------+----------------------------+ +--------------+------+----------------+----------------------------+
| Name | Type | Type extension | Description | | Name | Type | Type extension | Description |
+--------------+------+----------------+----------------------------+ +--------------+------+----------------+----------------------------+
| CONT_SEQ_NUM | TBD3 | 0 (COMPLETE) | Specifies a content | | CONT_SEQ_NUM | TBD3 | 0 (COMPLETE) | Specifies a content |
| | | | sequence number for this | | | | | sequence number for this |
| | | | complete message | | | | | complete message |
| | | 1 (INCOMPLETE) | Specifies a content | | CONT_SEQ_NUM | TBD3 | 1 (INCOMPLETE) | Specifies a content |
| | | | sequence number for this | | | | | sequence number for this |
| | | | incomplete message | | | | | incomplete message |
| | | 2-255 | Expert Review | | Unassigned | TBD3 | 2-255 | Expert Review |
+--------------+------+----------------+----------------------------+ +--------------+------+----------------+----------------------------+
Table 7 Table 7
Type extensions indicated as Expert Review SHOULD be allocated as Type extensions indicated as Expert Review SHOULD be allocated as
described in [RFC5444], based on Expert Review as defined in described in [RFC5444], based on Expert Review as defined in
[RFC5226]. [RFC5226].
19.3. Address Block TLV Types 19.3. Address Block TLV Types
This specification defines two Address Block TLV Types, which must be This specification defines two Address Block TLV Types, which must be
allocated from the "Address Block TLV Types" namespace defined in allocated from the "Address Block TLV Types" namespace defined in
[RFC5444]. IANA are requested to make allocations in the 8-127 range [RFC5444]. IANA are requested to make allocations in the 8-127 range
for these types. This will create two new type extension registries for these types. This will create two new type extension registries
with assignments as specified in Table 8 and Table 9. Specifications with assignments as specified in Table 8 and Table 9. Specifications
of these TLVs are in Section 8.1.2 and Section 8.2.2. of these TLVs are in Section 8.1.2 and Section 8.2.2.
+------+------+-----------+-----------------------------------------+ +------------+------+-----------+-----------------------------------+
| Name | Type | Type | Description | | Name | Type | Type | Description |
| | | extension | | | | | extension | |
+------+------+-----------+-----------------------------------------+ +------------+------+-----------+-----------------------------------+
| MPR | TBD4 | 0 | Specifies that a given address is of a | | MPR | TBD4 | 0 | Specifies that a given address is |
| | | | router selected as an MPR | | | | | of a router selected as an MPR |
| | | 1-255 | Expert Review | | Unassigned | TBD4 | 1-255 | Expert Review |
+------+------+-----------+-----------------------------------------+ +------------+------+-----------+-----------------------------------+
Table 8 Table 8
+---------+------+-----------+--------------------------------------+ +------------+------+-----------+-----------------------------------+
| Name | Type | Type | Description | | Name | Type | Type | Description |
| | | extension | | | | | extension | |
+---------+------+-----------+--------------------------------------+ +------------+------+-----------+-----------------------------------+
| GATEWAY | TBD5 | 0 | Specifies that a given address is | | GATEWAY | TBD5 | 0 | Specifies that a given address is |
| | | | reached via a gateway on the | | | | | reached via a gateway on the |
| | | | originating router | | | | | originating router |
| | | 1-255 | Expert Review | | Unassigned | TBD5 | 1-255 | Expert Review |
+---------+------+-----------+--------------------------------------+ +------------+------+-----------+-----------------------------------+
Table 9 Table 9
Type extensions indicated as Expert Review SHOULD be allocated as Type extensions indicated as Expert Review SHOULD be allocated as
described in [RFC5444], based on Expert Review as defined in described in [RFC5444], based on Expert Review as defined in
[RFC5226]. [RFC5226].
The Address Block TLV with Type = LOCAL_IF defined in [NHDP] is The Address Block TLV with Type = LOCAL_IF defined in [NHDP] is
extended to also permit inclusion of the value UNSPEC_IF = 2, extended to also permit inclusion of the Value UNSPEC_IF = 2,
representing a local interface address which may or may not be that representing a local address which may or may not be that of the
on which this message is transmitted. interface on which this message is transmitted.
20. Security Considerations 20. Security Considerations
Currently, OLSRv2 does not specify any special security measures. As Currently, OLSRv2 does not specify any special security measures. As
a proactive routing protocol, OLSRv2 makes a target for various a proactive routing protocol, OLSRv2 makes a target for various
attacks. The various possible vulnerabilities are discussed in this attacks. The various possible vulnerabilities are discussed in this
section. section.
20.1. Confidentiality 20.1. Confidentiality
skipping to change at page 54, line 25 skipping to change at page 58, line 50
specification and its components (listed alphabetically): Khaldoun Al specification and its components (listed alphabetically): Khaldoun Al
Agha (LRI), Song-Yean Cho (LIX), Alan Cullen (BAE Systems), Louise Agha (LRI), Song-Yean Cho (LIX), Alan Cullen (BAE Systems), Louise
Lamont (CRC), Li Li (CRC), Joe Macker (NRL), Richard Ogier (SRI), Lamont (CRC), Li Li (CRC), Joe Macker (NRL), Richard Ogier (SRI),
Charles E. Perkins (WiChorus), Shubhranshu Singh (Samsung AIT), and Charles E. Perkins (WiChorus), Shubhranshu Singh (Samsung AIT), and
the entire IETF MANET working group. the entire IETF MANET working group.
23. References 23. References
23.1. Normative References 23.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
considerations in MANETs", RFC 5148, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, BCP 26,
May 2008.
[RFC5444] Clausen, T., Dean, J., Dearlove, C., and C. Adjih, [RFC5444] Clausen, T., Dean, J., Dearlove, C., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized MANET Packet/Message Format", RFC 5444,
February 2009. February 2009.
[timetlv] Clausen, T. and C. Dearlove, "Representing multi-value [RFC5497] Clausen, T. and C. Dearlove, "Representing multi-value
time in MANETs", Work In time in MANETs", RFC 5497, March 2009.
Progress draft-ietf-manet-timetlv-08.txt,
September 2008.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [RFC5498] Chakeres, I., "IANA Allocations for MANET Protocols",
considerations in MANETs", RFC 5148, February 2008. RFC 5498, March 2009.
[NHDP] Clausen, T., Dean, J., and C. Dearlove, "MANET [NHDP] Clausen, T., Dean, J., and C. Dearlove, "MANET
Neighborhood Discovery Protocol (NHDP)", work in Neighborhood Discovery Protocol (NHDP)", work in
progress draft-ietf-manet-nhdp-08.txt, February 2009. progress draft-ietf-manet-nhdp-10.txt, July 2009.
[manet-iana] Chakeres, I., "IANA Allocations for MANET Protocols",
Work In Progress draft-ietf-manet-iana-07.txt,
November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 5226,
BCP 26, May 2008.
23.2. Informative References 23.2. Informative References
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and (MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999. Evaluation Considerations", RFC 2501, January 1999.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
skipping to change at page 56, line 38 skipping to change at page 61, line 7
selected MPRs without that router still satisfies the necessary selected MPRs without that router still satisfies the necessary
conditions, for all OLSRv2 interfaces, then that router MAY be conditions, for all OLSRv2 interfaces, then that router MAY be
removed from the set of MPRs. This process MAY be repeated until removed from the set of MPRs. This process MAY be repeated until
no MPRs are removed. Routers MAY be considered in order of no MPRs are removed. Routers MAY be considered in order of
increasing N_willingness. increasing N_willingness.
Symmetric 1-hop neighbor routers with N_willingness = WILL_NEVER MUST Symmetric 1-hop neighbor routers with N_willingness = WILL_NEVER MUST
NOT be selected as MPRs, and MUST be ignored in the following NOT be selected as MPRs, and MUST be ignored in the following
algorithm, as MUST be symmetric 2-hop neighbor routers which are also algorithm, as MUST be symmetric 2-hop neighbor routers which are also
symmetric 1-hop neighbor routers (i.e. when considering 2-Hop Tuples, symmetric 1-hop neighbor routers (i.e. when considering 2-Hop Tuples,
ignore any 2-Hop Tuples whose N2_2hop_iface_addr is in the ignore any 2-Hop Tuples whose N2_2hop_addr is in the
N_neighbor_iface_addr_list of any Neighbor Tuple, or whose N_neighbor_addr_list of any Neighbor Tuple, or whose
N2_neighbor_iface_addr_list is included in the N2_neighbor_iface_addr_list is included in the N_neighbor_addr_list
N_neighbor_iface_addr_list of any Neighbor Tuple with N_willingness = of any Neighbor Tuple with N_willingness = WILL_NEVER).
WILL_NEVER).
B.1. Terminology B.1. Terminology
The following terminology will be used when selecting MPRs for the The following terminology will be used when selecting MPRs for the
OLSRv2 interface I: OLSRv2 interface I:
N(I) - The set of symmetric 1-hop neighbors which have a symmetric N(I) - The set of symmetric 1-hop neighbors which have a symmetric
link to I. link to I.
N2(I) - The set of addresses of interfaces of a router with a N2(I) - The set of addresses of interfaces of a router with a
symmetric link to a router in N(I); this MAY be restricted to symmetric link to a router in N(I); this MAY be restricted to
considering only information received over I (in which case N2(I) considering only information received over I (in which case N2(I)
is the set of N2_2hop_iface_addr in 2-Hop Tuples in the 2-Hop Set is the set of N2_2hop_addr in 2-Hop Tuples in the 2-Hop Set for
for OLSRv2 interface I). OLSRv2 interface I).
Connected to I via Y - An address A in N2(I) is connected to I via a Connected to I via Y - An address A in N2(I) is connected to I via a
router Y in N(I) if A is an address of an interface of a symmetric router Y in N(I) if A is an address of an interface of a symmetric
1-hop neighbor of Y (i.e. A is the N2_2hop_iface_addr in a 2-Hop 1-hop neighbor of Y (i.e. A is the N2_2hop_addr in a 2-Hop Tuple
Tuple in the 2-Hop Set for OLSRv2 interface I, and whose in the 2-Hop Set for OLSRv2 interface I, and whose
N2_neighbor_iface_addr_list is contained in the set of interface N2_neighbor_iface_addr_list is contained in the set of interface
addresses of Y). addresses of Y).
D(Y, I) - For a router Y in N(I), the number of addresses in N2(I) D(Y, I) - For a router Y in N(I), the number of addresses in N2(I)
which are connected to I via Y. which are connected to I via Y.
R(Y, I): - For a router Y in N(I), the number of addresses in N2(I) R(Y, I): - For a router Y in N(I), the number of addresses in N2(I)
which are connected to I via Y, but are not connected to I via any which are connected to I via Y, but are not connected to I via any
router which has already been selected as an MPR. router which has already been selected as an MPR.
skipping to change at page 58, line 35 skipping to change at page 63, line 5
Tuple with: Tuple with:
- R_dest_addr := current address; - R_dest_addr := current address;
- R_next_iface_addr := current address; - R_next_iface_addr := current address;
- R_dist := 1; - R_dist := 1;
- R_local_iface_addr := local address. - R_local_iface_addr := local address.
2. For each Neighbor Tuple whose N_neighbor_iface_addr_list contains 2. For each Neighbor Tuple whose N_neighbor_addr_list contains the
the R_dest_addr of a Routing Tuple (the "previous Tuple"): R_dest_addr of a Routing Tuple (the "previous Tuple"):
1. For each address (the "current address") in 1. For each address (the "current address") in
N_neighbor_iface_addr_list, if there is no Routing Tuple with N_neighbor_addr_list, if there is no Routing Tuple with
R_dest_addr = current address, then add a Routing Tuple with: R_dest_addr = current address, then add a Routing Tuple with:
+ R_dest_addr := current address; + R_dest_addr := current address;
+ R_next_iface_addr := R_dest_addr of the previous Tuple; + R_next_iface_addr := R_dest_addr of the previous Tuple;
+ R_dist := 1; + R_dist := 1;
+ R_local_iface_addr := R_local_iface_addr of the previous + R_local_iface_addr := R_local_iface_addr of the previous
Tuple. Tuple.
C.2. Add Remote Symmetric Links C.2. Add Remote Symmetric Links
The following procedure, which adds Routing Tuples for destination The following procedure, which adds Routing Tuples for destination
routers h+1 hops away, MUST be executed for each value of h, starting routers h+1 hops away, MUST be executed for each value of h, starting
with h := 1 and incrementing by 1 for each iteration. The execution with h := 1 and incrementing by 1 for each iteration. The execution
MUST stop if no new Routing Tuples are added in an iteration. MUST stop if no new Routing Tuples are added in an iteration.
1. For each Topology Tuple, if: 1. For each Topology Tuple, if:
* T_dest_iface_addr is not equal to R_dest_addr of any Routing * T_dest_addr is not equal to R_dest_addr of any Routing Tuple,
Tuple, AND; AND;
* for the Advertising Remote Router Tuple with AR_orig_addr = * for the Advertising Remote Router Tuple with AR_orig_addr =
T_orig_addr, there is an address in the AR_iface_addr_list T_orig_addr, there is an address in the AR_addr_list which is
which is equal to the R_dest_addr of a Routing Tuple (the equal to the R_dest_addr of a Routing Tuple (the "previous
"previous Routing Tuple") whose R_dist = h Routing Tuple") whose R_dist = h
then add a new Routing Tuple, with: then add a new Routing Tuple, with:
* R_dest_addr := T_dest_iface_addr; * R_dest_addr := T_dest_addr;
* R_next_iface_addr := R_next_iface_addr of the previous Routing * R_next_iface_addr := R_next_iface_addr of the previous Routing
Tuple; Tuple;
* R_dist := h+1; * R_dist := h+1;
* R_local_iface_addr := R_local_iface_addr of the previous * R_local_iface_addr := R_local_iface_addr of the previous
Routing Tuple. Routing Tuple.
More than one Topology Tuple may be usable to select the next hop More than one Topology Tuple may be usable to select the next hop
R_next_iface_addr for reaching the address R_dest_addr. Ties R_next_iface_addr for reaching the address R_dest_addr. Ties
should be broken such that routers with greater willingness are should be broken such that routers with greater willingness are
preferred, and between routers of equal willingness, MPR preferred, and between routers of equal willingness, MPR
selectors are preferred over non-MPR selectors. selectors are preferred over non-MPR selectors.
2. After the above iteration has completed, if h = 1, for each 2-Hop 2. After the above iteration has completed, if h = 1, for each 2-Hop
Neighbor Tuple where: Neighbor Tuple where:
* N2_2hop_iface_addr is not equal to R_dest_addr of any Routing * N2_2hop_addr is not equal to R_dest_addr of any Routing Tuple,
Tuple, AND; AND;
* The Neighbor Tuple whose N_neighbor_iface_addr_list contains * The Neighbor Tuple whose N_neighbor_addr_list contains
N2_neighbor_iface_addr_list has N_willingness not equal to N2_neighbor_iface_addr_list has N_willingness not equal to
WILL_NEVER WILL_NEVER
select a Routing Tuple (the "previous Routing Tuple") whose select a Routing Tuple (the "previous Routing Tuple") whose
R_dest_addr is contained in N2_neighbor_iface_addr_list, and add R_dest_addr is contained in N2_neighbor_iface_addr_list, and add
a new Routing Tuple with: a new Routing Tuple with:
* R_dest_addr := N2_2hop_iface_addr; * R_dest_addr := N2_2hop_addr;
* R_next_iface_addr := R_next_iface_addr of the previous Routing * R_next_iface_addr := R_next_iface_addr of the previous Routing
Tuple; Tuple;
* R_dist := 2; * R_dist := 2;
* R_local_iface_addr := R_local_iface_addr of the previous * R_local_iface_addr := R_local_iface_addr of the previous
Routing Tuple. Routing Tuple.
More than one 2-Hop Neighbor Tuple may be usable to select the More than one 2-Hop Neighbor Tuple may be usable to select the
next hop R_next_iface_addr for reaching the address R_dest_addr. next hop R_next_iface_addr for reaching the address R_dest_addr.
Ties should be broken such that routers with greater willingness Ties should be broken such that routers with greater willingness
are preferred, and between routers of equal willingness, MPR are preferred, and between routers of equal willingness, MPR
selectors are preferred over non-MPR selectors. selectors are preferred over non-MPR selectors.
C.3. Add Attached Networks C.3. Add Attached Networks
1. For each Attached Network Tuple, if for the Advertising Remote 1. For each Attached Network Tuple, if for the Advertising Remote
Router Tuple with AR_orig_addr = AN_orig_addr, there is an Router Tuple with AR_orig_addr = AN_orig_addr, there is an
address in the AR_iface_addr_list which is equal to the address in the AR_addr_list which is equal to the R_dest_addr of
R_dest_addr of a Routing Tuple (the "previous Routing Tuple"), a Routing Tuple (the "previous Routing Tuple"), then:
then:
1. If there is no Routing Tuple with R_dest_addr = AN_net_addr, 1. If there is no Routing Tuple with R_dest_addr = AN_net_addr,
then add a new Routing Tuple with: then add a new Routing Tuple with:
+ R_dest_addr := AN_net_addr; + R_dest_addr := AN_net_addr;
+ R_next_iface_addr := R_next_iface_addr of the previous + R_next_iface_addr := R_next_iface_addr of the previous
Routing Tuple; Routing Tuple;
+ R_dist := (R_dist of the previous Routing Tuple) + + R_dist := (R_dist of the previous Routing Tuple) +
AN_dist; AN_dist;
+ R_local_iface_addr := R_local_iface_addr of the previous + R_local_iface_addr := R_local_iface_addr of the previous
Routing Tuple. Routing Tuple.
2. Otherwise if the Routing Tuple with R_dest_addr = AN_net_addr 2. Otherwise if the Routing Tuple with R_dest_addr = AN_net_addr
(the "current Routing Tuple") has R_dist > (R_dist of the (the "current Routing Tuple") has R_dist > (R_dist of the
previous Routing Tuple) + AN_dist, then modify the current previous Routing Tuple) + AN_dist, then modify the current
Routing Tuple by: Routing Tuple by:
skipping to change at page 61, line 4 skipping to change at page 65, line 20
2. Otherwise if the Routing Tuple with R_dest_addr = AN_net_addr 2. Otherwise if the Routing Tuple with R_dest_addr = AN_net_addr
(the "current Routing Tuple") has R_dist > (R_dist of the (the "current Routing Tuple") has R_dist > (R_dist of the
previous Routing Tuple) + AN_dist, then modify the current previous Routing Tuple) + AN_dist, then modify the current
Routing Tuple by: Routing Tuple by:
+ R_next_iface_addr := R_next_iface_addr of the previous + R_next_iface_addr := R_next_iface_addr of the previous
Routing Tuple; Routing Tuple;
+ R_dist := (R_dist of the previous Routing Tuple) + + R_dist := (R_dist of the previous Routing Tuple) +
AN_dist; AN_dist;
+ R_local_iface_addr := R_local_iface_addr of the previous + R_local_iface_addr := R_local_iface_addr of the previous
Routing Tuple. Routing Tuple.
Appendix D. Example Message Layout Appendix D. Example Message Layout
An example TC message is as follows. The message has full Message An example TC message is as follows. The message has full Message
Header (four bit flags field value is 15). Its four bit Message Header (four bit Flags field value is 15). Its four bit Message
Address Length field has value 3 and hence addresses in the message Address Length field has value 3 and hence addresses in the message
have length four octets, here being IPv4 addresses. The overall have length four octets, here being IPv4 addresses. The overall
message length is 65 octets. message length is 65 octets.
The message has a Message TLV Block with content length 13 octets The message has a Message TLV Block with content length 13 octets
containing three TLVs. The first two TLVs are interval and validity containing three TLVs. The first two TLVs are interval and validity
times for the message. The third TLV is the content sequence number times for the message. The third TLV is the content sequence number
TLV used to carry the 2 octet ANSN, and (with default type extension TLV used to carry the 2 octet ANSN, and (with default type extension
zero, i.e. COMPLETE) indicating that the TC message is complete. zero, i.e. COMPLETE) indicating that the TC message is complete.
Each TLV uses a TLV with flags octet value 16, indicating that it has Each TLV uses a TLV with Flags octet value 16, indicating that it has
a value, but no type extension or start and stop indexes. The first a Value, but no type extension or start and stop indexes. The first
two TLVs have a value length of 1 octet, the last has a value length two TLVs have a Value Length of 1 octet, the last has a Value Length
of 2 octets. of 2 octets.
The message has two Address Blocks. The first Address Block contains The message has two Address Blocks. The first Address Block contains
6 addresses, with flags octet value 128, hence with a Head section, 6 addresses, with Flags octet value 128, hence with a Head section,
(with length 2 octets) but no Tail section, and hence Mid sections (with length 2 octets) but no Tail section, and hence Mid sections
with length two octets. The following TLV Block (content length 6 with length two octets. The following TLV Block (content length 6
octets) contains a single LOCAL_IF TLV (flags octet value 48) octets) contains a single LOCAL_IF TLV (Flags octet value 48)
indicating that the first three addresses (indexes 0 to 2) are indicating that the first three addresses (indexes 0 to 2) are
associated with the value (length 1 octet) UNSPEC_IF, i.e. they are associated with the Value (with Value Length 1 octet) UNSPEC_IF, i.e.
the originating router's local interface addresses. The remaining they are the originating router's local addresses. The remaining
three addresses have no associated TLV, they are the interface three addresses have no associated TLV, they are the addresses of
addresses of advertised neighbors. advertised neighbors.
The second Address Block contains 1 address, with flags octet 176 The second Address Block contains 1 address, with Flags octet 176
indicating that there is a Head section (with length 2 octets), that indicating that there is a Head section (with length 2 octets), that
the Tail section (length 2 octets) consists of zero valued octets the Tail section (length 2 octets) consists of zero valued octets
(not included), and that there is a single prefix length, which is (not included), and that there is a single prefix length, which is
16. The network address is thus Head.0.0/16. The following TLV 16. The network address is thus Head.0.0/16. The following TLV
Block (content length 8 octets) includes one TLV that indicates that Block (content length 8 octets) includes one TLV that indicates that
the originating router is a gateway to this network, at a given the originating router is a gateway to this network, at a given
number of hops distance (value length 1 octet). The TLV flags octet number of hops distance (Value Length 1 octet). The TLV Flags octet
value of 16 indicates that no indexes are needed. value of 16 indicates that no indexes are needed.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TC |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1| | TC |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number | | Hop Limit | Hop Count | Message Sequence Number |
skipping to change at page 63, line 25 skipping to change at page 67, line 34
any Removed Interface Address Tuple. any Removed Interface Address Tuple.
o AL_dist MUST NOT be less than zero. o AL_dist MUST NOT be less than zero.
In each Link Tuple: In each Link Tuple:
o L_neighbor_iface_addr_list MUST NOT contain the AL_net_addr of any o L_neighbor_iface_addr_list MUST NOT contain the AL_net_addr of any
Local Attached Network Tuple. Local Attached Network Tuple.
o If L_status = SYMMETRIC and the Neighbor Tuple whose o If L_status = SYMMETRIC and the Neighbor Tuple whose
N_neighbor_iface_addr_list contains L_neighbor_iface_addr_list has N_neighbor_addr_list contains L_neighbor_iface_addr_list has
N_mpr_selector = true, then, for each address in this N_mpr_selector = true, then, for each address in this
L_neighbor_iface_addr_list, there MUST be an equal L_neighbor_iface_addr_list, there MUST be an equal
RY_neighbor_iface_addr in the Relay Set associated with the same RY_neighbor_iface_addr in the Relay Set associated with the same
OLSRv2 interface. OLSRv2 interface.
In each Neighbor Tuple: In each Neighbor Tuple:
o N_neighbor_iface_addr_list MUST NOT contain the AL_net_addr of any o N_neighbor_addr_list MUST NOT contain the AL_net_addr of any Local
Local Attached Network Tuple. Attached Network Tuple.
o If N_willingness MUST be in the range from WILL_NEVER to o If N_willingness MUST be in the range from WILL_NEVER to
WILL_ALWAYS, inclusive. WILL_ALWAYS, inclusive.
o If N_mpr = true, then N_symmetric MUST be true and N_willingness o If N_mpr = true, then N_symmetric MUST be true and N_willingness
MUST NOT equal WILL_NEVER. MUST NOT equal WILL_NEVER.
o If N_symmetric = true and N_mpr = false, then N_willingness MUST o If N_symmetric = true and N_mpr = false, then N_willingness MUST
NOT equal WILL_ALWAYS. NOT equal WILL_ALWAYS.
o If N_mpr_selector = true, then N_symmetric MUST be true. o If N_mpr_selector = true, then N_symmetric MUST be true.
o If N_mpr_selector = true, then, for each address in this o If N_mpr_selector = true, then, for each address in this
N_neighbor_iface_addr_list, there MUST be an equal N_neighbor_addr_list, there MUST be an equal A_neighbor_addr in
A_neighbor_iface_addr in the Advertised Neighbor Set. the Advertised Neighbor Set.
In each Lost Neighbor Tuple: In each Lost Neighbor Tuple:
o NL_neighbor_iface_addr MUST NOT equal the AL_net_addr of any Local o NL_neighbor_addr MUST NOT equal the AL_net_addr of any Local
Attached Network Tuple. Attached Network Tuple.
In each 2-Hop Tuple: In each 2-Hop Tuple:
o N2_2hop_iface_addr MUST NOT equal the AL_net_addr of any Local o N2_2hop_addr MUST NOT equal the AL_net_addr of any Local Attached
Attached Network Tuple. Network Tuple.
In each Received Tuple: In each Received Tuple:
o RX_orig_addr MUST NOT equal this router's originator address or o RX_orig_addr MUST NOT equal this router's originator address or
any O_orig_addr. any O_orig_addr.
o Each ordered triple (RX_type, RX_orig_addr, RX_seq_number) MUST o Each ordered triple (RX_type, RX_orig_addr, RX_seq_number) MUST
NOT equal the corresponding triple in any other Received Tuple in NOT equal the corresponding triple in any other Received Tuple in
the same Received Set. the same Received Set.
skipping to change at page 64, line 48 skipping to change at page 69, line 7
In each Relay Tuple: In each Relay Tuple:
o RY_neighbor_iface_addr MUST NOT equal the RY_neighbor_iface_addr o RY_neighbor_iface_addr MUST NOT equal the RY_neighbor_iface_addr
in any other Relay Tuple in the same Relay Set. in any other Relay Tuple in the same Relay Set.
o RY_neighbor_iface_addr MUST be in the L_neighbor_iface_addr_list o RY_neighbor_iface_addr MUST be in the L_neighbor_iface_addr_list
of a Link Tuple with L_status = SYMMETRIC. of a Link Tuple with L_status = SYMMETRIC.
In the Advertised Neighbor Set: In the Advertised Neighbor Set:
o Each A_neighbor_iface_addr MUST NOT equal any other o Each A_neighbor_addr MUST NOT equal any other A_neighbor_addr.
A_neighbor_iface_addr.
o Each A_neighbor_iface_addr MUST be in the o Each A_neighbor_addr MUST be in the N_neighbor_addr_list of a
N_neighbor_iface_addr_list of a Neighbor Tuple with N_symmetric = Neighbor Tuple with N_symmetric = true.
true.
In each Advertising Remote Router Tuple: In each Advertising Remote Router Tuple:
o AR_orig_addr MUST NOT equal this router's originator address or o AR_orig_addr MUST NOT equal this router's originator address or
any O_orig_addr. any O_orig_addr.
o AR_orig_addr MUST NOT equal the AR_orig_addr in any other ANSN o AR_orig_addr MUST NOT equal the AR_orig_addr in any other ANSN
History Tuple. History Tuple.
o AR_iface_addr_list MUST NOT be empty. o AR_addr_list MUST NOT be empty.
o AR_iface_addr_list MUST NOT contain any duplicated addresses. o AR_addr_list MUST NOT contain any duplicated addresses.
o AR_iface_addr_list MUST NOT contain any address which is in the o AR_addr_list MUST NOT contain any address which is in the
I_local_iface_addr_list of any Local Interface Tuple or be equal I_local_iface_addr_list of any Local Interface Tuple or be equal
to the IR_local_iface_addr of any Removed Interface Address Tuple. to the IR_local_iface_addr of any Removed Interface Address Tuple.
o AR_iface_addr_list MUST NOT contain any address which is the o AR_addr_list MUST NOT contain any address which is the AL_net_addr
AL_net_addr of any Local Attached Network Tuple. of any Local Attached Network Tuple.
In each Topology Tuple: In each Topology Tuple:
o T_dest_iface_addr MUST NOT be in the I_local_iface_addr_list of o T_dest_addr MUST NOT be in the I_local_iface_addr_list of any
any Local Interface Tuple or be equal to the IR_local_iface_addr Local Interface Tuple or be equal to the IR_local_iface_addr of
of any Removed Interface Address Tuple. any Removed Interface Address Tuple.
o T_dest_iface_addr MUST NOT equal the AL_net_addr of any Local o T_dest_addr MUST NOT equal the AL_net_addr of any Local Attached
Attached Network Tuple. Network Tuple.
o There MUST be an Advertising Remote Router Tuple with AR_orig_addr o There MUST be an Advertising Remote Router Tuple with AR_orig_addr
= T_orig_addr. = T_orig_addr.
o T_dest_iface_addr MUST NOT be in the AR_iface_addr_list of the o T_dest_addr MUST NOT be in the AR_addr_list of the Advertising
Advertising Remote Router Tuple with AR_orig_addr = T_orig_addr. Remote Router Tuple with AR_orig_addr = T_orig_addr.
o T_seq_number MUST NOT be greater than AR_seq_number of the o T_seq_number MUST NOT be greater than AR_seq_number of the
Advertising Remote Router Tuple with AR_orig_addr = T_orig_addr. Advertising Remote Router Tuple with AR_orig_addr = T_orig_addr.
o The ordered pair (T_dest_iface_addr, T_orig_addr) MUST NOT equal o The ordered pair (T_dest_addr, T_orig_addr) MUST NOT equal the
the corresponding pair in any other Topology Tuple. corresponding pair in any other Topology Tuple.
In each Attached Network Tuple: In each Attached Network Tuple:
o AN_net_addr MUST NOT be in the I_local_iface_addr_list of any o AN_net_addr MUST NOT be in the I_local_iface_addr_list of any
Local Interface Tuple or be equal to the IR_local_iface_addr of Local Interface Tuple or be equal to the IR_local_iface_addr of
any Removed Interface Address Tuple. any Removed Interface Address Tuple.
o AN_net_addr MUST NOT equal the AL_net_addr of any Local Attached o AN_net_addr MUST NOT equal the AL_net_addr of any Local Attached
Network Tuple. Network Tuple.
 End of changes. 188 change blocks. 
550 lines changed or deleted 756 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/