draft-ietf-manet-olsrv2-16.txt   draft-ietf-manet-olsrv2-17.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: April 5, 2013 BAE Systems ATC Expires: April 17, 2013 BAE Systems ATC
P. Jacquet P. Jacquet
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
U. Herberg U. Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
October 2, 2012 October 14, 2012
The Optimized Link State Routing Protocol version 2 The Optimized Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-16 draft-ietf-manet-olsrv2-17
Abstract Abstract
This specification describes version 2 of the Optimized Link State This specification describes version 2 of the Optimized Link State
Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 5, 2013. This Internet-Draft will expire on April 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Routers and Interfaces . . . . . . . . . . . . . . . . . 13 4.2. Routers and Interfaces . . . . . . . . . . . . . . . . . 13
4.3. Information Base Overview . . . . . . . . . . . . . . . . 14 4.3. Information Base Overview . . . . . . . . . . . . . . . . 14
4.3.1. Local Information Base . . . . . . . . . . . . . . . 14 4.3.1. Local Information Base . . . . . . . . . . . . . . . 14
4.3.2. Interface Information Bases . . . . . . . . . . . . . 14 4.3.2. Interface Information Bases . . . . . . . . . . . . . 14
4.3.3. Neighbor Information Base . . . . . . . . . . . . . . 14 4.3.3. Neighbor Information Base . . . . . . . . . . . . . . 15
4.3.4. Topology Information Base . . . . . . . . . . . . . . 15 4.3.4. Topology Information Base . . . . . . . . . . . . . . 15
4.3.5. Received Message Information Base . . . . . . . . . . 16 4.3.5. Received Message Information Base . . . . . . . . . . 16
4.4. Signaling Overview . . . . . . . . . . . . . . . . . . . 16 4.4. Signaling Overview . . . . . . . . . . . . . . . . . . . 16
4.5. Link Metrics . . . . . . . . . . . . . . . . . . . . . . 18 4.5. Link Metrics . . . . . . . . . . . . . . . . . . . . . . 18
4.6. Routing Set Use . . . . . . . . . . . . . . . . . . . . . 19 4.6. Flooding MPRs and Routing MPR . . . . . . . . . . . . . . 19
4.7. Routing Set Use . . . . . . . . . . . . . . . . . . . . . 19
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 19 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 19
5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 19 5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 20
5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 20 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 20
5.3. Interface Parameters . . . . . . . . . . . . . . . . . . 20 5.3. Interface Parameters . . . . . . . . . . . . . . . . . . 20
5.3.1. Received Message Validity Time . . . . . . . . . . . 20 5.3.1. Received Message Validity Time . . . . . . . . . . . 20
5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 20 5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 21
5.4.1. Local History Times . . . . . . . . . . . . . . . . . 20 5.4.1. Local History Times . . . . . . . . . . . . . . . . . 21
5.4.2. Link Metric Parameters . . . . . . . . . . . . . . . 21 5.4.2. Link Metric Parameters . . . . . . . . . . . . . . . 21
5.4.3. Message Intervals . . . . . . . . . . . . . . . . . . 21 5.4.3. Message Intervals . . . . . . . . . . . . . . . . . . 21
5.4.4. Advertised Information Validity Times . . . . . . . . 22 5.4.4. Advertised Information Validity Times . . . . . . . . 22
5.4.5. Processing and Forwarding Validity Times . . . . . . 22 5.4.5. Processing and Forwarding Validity Times . . . . . . 23
5.4.6. Jitter . . . . . . . . . . . . . . . . . . . . . . . 23 5.4.6. Jitter . . . . . . . . . . . . . . . . . . . . . . . 23
5.4.7. Hop Limit . . . . . . . . . . . . . . . . . . . . . . 23 5.4.7. Hop Limit . . . . . . . . . . . . . . . . . . . . . . 24
5.4.8. Willingness . . . . . . . . . . . . . . . . . . . . . 24 5.4.8. Willingness . . . . . . . . . . . . . . . . . . . . . 24
5.5. Parameter Change Constraints . . . . . . . . . . . . . . 25 5.5. Parameter Change Constraints . . . . . . . . . . . . . . 25
5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 27 5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 27
5.6.1. Link Metric Constants . . . . . . . . . . . . . . . . 27 5.6.1. Link Metric Constants . . . . . . . . . . . . . . . . 27
5.6.2. Willingness Constants . . . . . . . . . . . . . . . . 27 5.6.2. Willingness Constants . . . . . . . . . . . . . . . . 27
6. Link Metric Values . . . . . . . . . . . . . . . . . . . . . 27 5.6.3. Time Constant . . . . . . . . . . . . . . . . . . . . 28
6.1. Link Metric Representation . . . . . . . . . . . . . . . 27 6. Link Metric Values . . . . . . . . . . . . . . . . . . . . . 28
6.2. Link Metric Compressed Form . . . . . . . . . . . . . . . 28 6.1. Link Metric Representation . . . . . . . . . . . . . . . 28
7. Local Information Base . . . . . . . . . . . . . . . . . . . 28 6.2. Link Metric Compressed Form . . . . . . . . . . . . . . . 29
7.1. Originator Set . . . . . . . . . . . . . . . . . . . . . 29 7. Local Information Base . . . . . . . . . . . . . . . . . . . 29
7.2. Local Attached Network Set . . . . . . . . . . . . . . . 29 7.1. Originator Set . . . . . . . . . . . . . . . . . . . . . 30
8. Interface Information Base . . . . . . . . . . . . . . . . . 30 7.2. Local Attached Network Set . . . . . . . . . . . . . . . 30
8.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . 30 8. Interface Information Base . . . . . . . . . . . . . . . . . 31
8.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . 31
9. Neighbor Information Base . . . . . . . . . . . . . . . . . . 31 8.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 32
10. Topology Information Base . . . . . . . . . . . . . . . . . . 33 9. Neighbor Information Base . . . . . . . . . . . . . . . . . . 32
10.1. Advertising Remote Router Set . . . . . . . . . . . . . . 33 10. Topology Information Base . . . . . . . . . . . . . . . . . . 34
10.1. Advertising Remote Router Set . . . . . . . . . . . . . . 34
10.2. Router Topology Set . . . . . . . . . . . . . . . . . . . 34 10.2. Router Topology Set . . . . . . . . . . . . . . . . . . . 34
10.3. Routable Address Topology Set . . . . . . . . . . . . . . 34 10.3. Routable Address Topology Set . . . . . . . . . . . . . . 35
10.4. Attached Network Set . . . . . . . . . . . . . . . . . . 35 10.4. Attached Network Set . . . . . . . . . . . . . . . . . . 36
10.5. Routing Set . . . . . . . . . . . . . . . . . . . . . . . 36 10.5. Routing Set . . . . . . . . . . . . . . . . . . . . . . . 36
11. Received Message Information Base . . . . . . . . . . . . . . 36 11. Received Message Information Base . . . . . . . . . . . . . . 37
11.1. Received Set . . . . . . . . . . . . . . . . . . . . . . 37 11.1. Received Set . . . . . . . . . . . . . . . . . . . . . . 37
11.2. Processed Set . . . . . . . . . . . . . . . . . . . . . . 37 11.2. Processed Set . . . . . . . . . . . . . . . . . . . . . . 38
11.3. Forwarded Set . . . . . . . . . . . . . . . . . . . . . . 37 11.3. Forwarded Set . . . . . . . . . . . . . . . . . . . . . . 38
12. Information Base Properties . . . . . . . . . . . . . . . . . 38 12. Information Base Properties . . . . . . . . . . . . . . . . . 39
12.1. Corresponding Protocol Tuples . . . . . . . . . . . . . . 38 12.1. Corresponding Protocol Tuples . . . . . . . . . . . . . . 39
12.2. Address Ownership . . . . . . . . . . . . . . . . . . . . 39 12.2. Address Ownership . . . . . . . . . . . . . . . . . . . . 40
13. Packets and Messages . . . . . . . . . . . . . . . . . . . . 40 13. Packets and Messages . . . . . . . . . . . . . . . . . . . . 40
13.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . 40 13.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . 41
13.2. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 40 13.2. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 41
13.3. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 41 13.3. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 42
13.3.1. Message TLVs . . . . . . . . . . . . . . . . . . . . 41 13.3.1. Message TLVs . . . . . . . . . . . . . . . . . . . . 42
13.3.2. Address Block TLVs . . . . . . . . . . . . . . . . . 41 13.3.2. Address Block TLVs . . . . . . . . . . . . . . . . . 42
14. Message Processing and Forwarding . . . . . . . . . . . . . . 43 14. Message Processing and Forwarding . . . . . . . . . . . . . . 44
14.1. Actions when Receiving a Message . . . . . . . . . . . . 44 14.1. Actions when Receiving a Message . . . . . . . . . . . . 45
14.2. Message Considered for Processing . . . . . . . . . . . . 45 14.2. Message Considered for Processing . . . . . . . . . . . . 46
14.3. Message Considered for Forwarding . . . . . . . . . . . . 46 14.3. Message Considered for Forwarding . . . . . . . . . . . . 47
15. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . 47 15. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . 49
15.1. HELLO Message Generation . . . . . . . . . . . . . . . . 48 15.1. HELLO Message Generation . . . . . . . . . . . . . . . . 49
15.2. HELLO Message Transmission . . . . . . . . . . . . . . . 50 15.2. HELLO Message Transmission . . . . . . . . . . . . . . . 51
15.3. HELLO Message Processing . . . . . . . . . . . . . . . . 50 15.3. HELLO Message Processing . . . . . . . . . . . . . . . . 51
15.3.1. HELLO Message Discarding . . . . . . . . . . . . . . 50 15.3.1. HELLO Message Discarding . . . . . . . . . . . . . . 51
15.3.2. HELLO Message Usage . . . . . . . . . . . . . . . . . 51 15.3.2. HELLO Message Usage . . . . . . . . . . . . . . . . . 52
16. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 54 16. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 55
16.1. TC Message Generation . . . . . . . . . . . . . . . . . . 54 16.1. TC Message Generation . . . . . . . . . . . . . . . . . . 55
16.2. TC Message Transmission . . . . . . . . . . . . . . . . . 56 16.2. TC Message Transmission . . . . . . . . . . . . . . . . . 57
16.3. TC Message Processing . . . . . . . . . . . . . . . . . . 57 16.3. TC Message Processing . . . . . . . . . . . . . . . . . . 58
16.3.1. TC Message Discarding . . . . . . . . . . . . . . . . 57 16.3.1. TC Message Discarding . . . . . . . . . . . . . . . . 58
16.3.2. TC Message Processing Definitions . . . . . . . . . . 59 16.3.2. TC Message Processing Definitions . . . . . . . . . . 60
16.3.3. Initial TC Message Processing . . . . . . . . . . . . 59 16.3.3. Initial TC Message Processing . . . . . . . . . . . . 61
16.3.4. Completing TC Message Processing . . . . . . . . . . 63 16.3.4. Completing TC Message Processing . . . . . . . . . . 64
17. Information Base Changes . . . . . . . . . . . . . . . . . . 64 17. Information Base Changes . . . . . . . . . . . . . . . . . . 65
17.1. Originator Address Changes . . . . . . . . . . . . . . . 64 17.1. Originator Address Changes . . . . . . . . . . . . . . . 65
17.2. Link State Changes . . . . . . . . . . . . . . . . . . . 64 17.2. Link State Changes . . . . . . . . . . . . . . . . . . . 66
17.3. Neighbor State Changes . . . . . . . . . . . . . . . . . 65 17.3. Neighbor State Changes . . . . . . . . . . . . . . . . . 66
17.4. Advertised Neighbor Changes . . . . . . . . . . . . . . . 65 17.4. Advertised Neighbor Changes . . . . . . . . . . . . . . . 67
17.5. Advertising Remote Router Tuple Expires . . . . . . . . . 66 17.5. Advertising Remote Router Tuple Expires . . . . . . . . . 67
17.6. Neighborhood Changes and MPR Updates . . . . . . . . . . 66 17.6. Neighborhood Changes and MPR Updates . . . . . . . . . . 68
17.7. Routing Set Updates . . . . . . . . . . . . . . . . . . . 68 17.7. Routing Set Updates . . . . . . . . . . . . . . . . . . . 70
18. Selecting MPRs . . . . . . . . . . . . . . . . . . . . . . . 69 18. Selecting MPRs . . . . . . . . . . . . . . . . . . . . . . . 70
18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 69 18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 71
18.2. Neighbor Graph . . . . . . . . . . . . . . . . . . . . . 70 18.2. Neighbor Graph . . . . . . . . . . . . . . . . . . . . . 72
18.3. MPR Properties . . . . . . . . . . . . . . . . . . . . . 71 18.3. MPR Properties . . . . . . . . . . . . . . . . . . . . . 73
18.4. Flooding MPRs . . . . . . . . . . . . . . . . . . . . . . 72 18.4. Flooding MPRs . . . . . . . . . . . . . . . . . . . . . . 73
18.5. Routing MPRs . . . . . . . . . . . . . . . . . . . . . . 74 18.5. Routing MPRs . . . . . . . . . . . . . . . . . . . . . . 75
18.6. Calculating MPRs . . . . . . . . . . . . . . . . . . . . 75 18.6. Calculating MPRs . . . . . . . . . . . . . . . . . . . . 77
19. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 75 19. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 77
19.1. Network Topology Graph . . . . . . . . . . . . . . . . . 76 19.1. Network Topology Graph . . . . . . . . . . . . . . . . . 77
19.2. Populating the Routing Set . . . . . . . . . . . . . . . 78 19.2. Populating the Routing Set . . . . . . . . . . . . . . . 79
20. Proposed Values for Parameters . . . . . . . . . . . . . . . 79 20. Proposed Values for Parameters . . . . . . . . . . . . . . . 80
20.1. Local History Time Parameters . . . . . . . . . . . . . . 79 20.1. Local History Time Parameters . . . . . . . . . . . . . . 81
20.2. Message Interval Parameters . . . . . . . . . . . . . . . 79 20.2. Message Interval Parameters . . . . . . . . . . . . . . . 81
20.3. Advertised Information Validity Time Parameters . . . . . 79 20.3. Advertised Information Validity Time Parameters . . . . . 81
20.4. Received Message Validity Time Parameters . . . . . . . . 79 20.4. Received Message Validity Time Parameters . . . . . . . . 81
20.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . 80 20.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . 81
20.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 80 20.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 81
20.7. Willingness Parameter . . . . . . . . . . . . . . . . . . 80 20.7. Willingness Parameter . . . . . . . . . . . . . . . . . . 82
21. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 80 21. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 82
22. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 81 22. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 82
23. Security Considerations . . . . . . . . . . . . . . . . . . . 81 23. Security Considerations . . . . . . . . . . . . . . . . . . . 83
23.1. Security Architecture . . . . . . . . . . . . . . . . . . 82 23.1. Security Architecture . . . . . . . . . . . . . . . . . . 83
23.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 82 23.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 84
23.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 84 23.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 86
23.4. Interaction with External Routing Domains . . . . . . . . 84 23.4. Interaction with External Routing Domains . . . . . . . . 86
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85 24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87
24.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 85 24.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 87
24.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 85 24.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 87
24.3. Message-Type-Specific TLV Type Registries . . . . . . . . 85 24.3. Message-Type-Specific TLV Type Registries . . . . . . . . 87
24.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 86 24.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 88
24.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 88 24.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 89
24.6. NBR_ADDR_TYPE and MPR Values . . . . . . . . . . . . . . 90 24.6. NBR_ADDR_TYPE and MPR Values . . . . . . . . . . . . . . 92
25. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 91 25. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 92
26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 91 26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 93
27. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 93
27.1. Normative References . . . . . . . . . . . . . . . . . . 92 27.1. Normative References . . . . . . . . . . . . . . . . . . 93
27.2. Informative References . . . . . . . . . . . . . . . . . 92 27.2. Informative References . . . . . . . . . . . . . . . . . 94
Appendix A. Example Algorithm for Calculating MPRs . . . . . . . 93
A.1. Additional Notation . . . . . . . . . . . . . . . . . . . 93 Appendix A. Constraints . . . . . . . . . . . . . . . . . . . . 95
A.2. MPR Selection Algorithm . . . . . . . . . . . . . . . . . 93 Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 99
Appendix B. Example Algorithm for Calculating the Routing Set . 94 B.1. Additional Notation . . . . . . . . . . . . . . . . . . . 99
B.1. Local Interfaces and Neighbors . . . . . . . . . . . . . 94 B.2. MPR Selection Algorithm . . . . . . . . . . . . . . . . . 100
B.2. Add Neighbor Routers . . . . . . . . . . . . . . . . . . 95 Appendix C. Example Algorithm for Calculating the Routing Set . 100
B.3. Add Remote Routers . . . . . . . . . . . . . . . . . . . 96 C.1. Local Interfaces and Neighbors . . . . . . . . . . . . . 100
B.4. Add Neighbor Addresses . . . . . . . . . . . . . . . . . 97 C.2. Add Neighbor Routers . . . . . . . . . . . . . . . . . . 102
B.5. Add Remote Routable Addresses . . . . . . . . . . . . . . 98 C.3. Add Remote Routers . . . . . . . . . . . . . . . . . . . 102
B.6. Add Attached Networks . . . . . . . . . . . . . . . . . . 98 C.4. Add Neighbor Addresses . . . . . . . . . . . . . . . . . 103
B.7. Add 2-Hop Neighbors . . . . . . . . . . . . . . . . . . . 99 C.5. Add Remote Routable Addresses . . . . . . . . . . . . . . 104
Appendix C. TC Message Example . . . . . . . . . . . . . . . . . 100 C.6. Add Attached Networks . . . . . . . . . . . . . . . . . . 104
Appendix D. Constraints . . . . . . . . . . . . . . . . . . . . 102 C.7. Add 2-Hop Neighbors . . . . . . . . . . . . . . . . . . . 105
Appendix E. Flow and Congestion Control . . . . . . . . . . . . 107 Appendix D. TC Message Example . . . . . . . . . . . . . . . . . 106
Appendix E. Flow and Congestion Control . . . . . . . . . . . . 108
1. Introduction 1. Introduction
The Optimized Link State Routing protocol version 2 (OLSRv2) is the The Optimized Link State Routing protocol version 2 (OLSRv2) is the
successor to OLSR (version 1) as published in [RFC3626]. Compared to successor to OLSR (version 1) as published in [RFC3626]. Compared to
[RFC3626], OLSRv2 retains the same basic mechanisms and algorithms, [RFC3626], OLSRv2 retains the same basic mechanisms and algorithms,
enhanced by the ability to use a link metric other than hop count in enhanced by the ability to use a link metric other than hop count in
the selection of shortest routes. OLSRv2 also uses a more flexible the selection of shortest routes. OLSRv2 also uses a more flexible
and efficient signaling framework, and includes some simplification and efficient signaling framework, and includes some simplification
of the messages being exchanged. of the messages being exchanged.
skipping to change at page 8, line 14 skipping to change at page 8, line 14
Router: Router:
A MANET router which implements this protocol. A MANET router which implements this protocol.
OLSRv2 interface: OLSRv2 interface:
A MANET interface running this protocol. A router running this A MANET interface running this protocol. A router running this
protocol MUST have at least one OLSRv2 interface. protocol MUST have at least one OLSRv2 interface.
Routable address: Routable address:
A network address which may be used as the destination of a data A network address which may be used as the destination of a data
packet. A router MUST be able to distinguish a routable address packet. A router which implements this protocol will need to
from a non-routable address by direct inspection of the network distinguish a routable address from a non-routable address by
address, based on global scope address allocations by IANA and/or direct inspection of the network address, based on global scope
administrative configuration. Broadcast and multicast addresses, address allocations by IANA and/or administrative configuration
and addresses which are limited in scope to less than the entire (consistently across the MANET). Broadcast and multicast
MANET, MUST NOT be considered as routable addresses. Anycast addresses, and addresses which are limited in scope to less than
addresses may be considered as routable addresses. the entire MANET, MUST NOT be considered as routable addresses.
Anycast addresses may be considered as routable addresses.
Originator address: Originator address:
An address which is unique (within the MANET) to a router. A An address which is unique (within the MANET) to a router. A
router MUST select an originator address; it MAY choose one of its router MUST select an originator address; it MAY choose one of its
interface addresses as its originator address; it MAY select interface addresses as its originator address; it MAY select
either a routable or non-routable address. A broadcast, multicast either a routable or non-routable address. A broadcast, multicast
or anycast address MUST NOT be chosen as an originator address. or anycast address MUST NOT be chosen as an originator address.
If the router selects a routable address then this MUST be one If the router selects a routable address then this MUST be one
which the router will accept as destination. An originator which the router will accept as destination. An originator
address MUST NOT have a prefix length, except for when included in address MUST NOT have a prefix length, except for when included in
skipping to change at page 9, line 28 skipping to change at page 9, line 28
MPR selector: MPR selector:
A router, Y, is a flooding/routing MPR selector of router X if A router, Y, is a flooding/routing MPR selector of router X if
router Y has selected router X as a flooding/routing MPR. router Y has selected router X as a flooding/routing MPR.
MPR flooding: MPR flooding:
The optimized MANET-wide information distribution mechanism, The optimized MANET-wide information distribution mechanism,
employed by this protocol, in which a message is relayed by only a employed by this protocol, in which a message is relayed by only a
reduced subset of the routers in the network. MPR flooding is the reduced subset of the routers in the network. MPR flooding is the
mechanism by which flooding reduction is achieved. mechanism by which flooding reduction is achieved.
EXPIRED:
Indicates that a timer is set to a value clearly preceding the
current time (e.g., current time - 1).
This specification employs the same notational conventions as in This specification employs the same notational conventions as in
[RFC5444] and [RFC6130]. [RFC5444] and [RFC6130].
3. Applicability Statement 3. Applicability Statement
This protocol: This document specifies OLSRv2, a proactive routing protocol intended
for use in mobile ad hoc networks (MANETs) [RFC2501]. The protocol's
o Is a proactive routing protocol for mobile ad hoc networks applicability is determined by its characteristics, which are that
(MANETs) [RFC2501]. this protocol:
o Is designed to work in networks with a dynamic topology, and in o Is designed to work in networks with a dynamic topology, and in
which messages may be lost, such as due to collisions over which messages may be lost, such as due to collisions over
wireless media. wireless media.
o Supports routers that each have one or more participating OLSRv2 o Supports routers that each have one or more participating OLSRv2
interfaces, which will consist of some or all of its MANET interfaces, which will consist of some or all of its MANET
interfaces using [RFC6130]. The set of a router's OLSRv2 interfaces using [RFC6130]. The set of a router's OLSRv2
interfaces, and the sets of its other MANET and non-MANET interfaces, and the sets of its other MANET and non-MANET
interfaces, may change over time. Each interface may have one or interfaces, may change over time. Each interface may have one or
skipping to change at page 11, line 29 skipping to change at page 11, line 32
outgoing link metrics may be reported, the former determined by outgoing link metrics may be reported, the former determined by
the advertising router. the advertising router.
o Selecting flooding MPRs and routing MPRs from among its willing o Selecting flooding MPRs and routing MPRs from among its willing
symmetric 1-hop neighbors such that, for each set of MPRs, all symmetric 1-hop neighbors such that, for each set of MPRs, all
symmetric 2-hop neighbors are reachable either directly or via at symmetric 2-hop neighbors are reachable either directly or via at
least one selected MPR, using a path of appropriate minimum total least one selected MPR, using a path of appropriate minimum total
metric for at least routing MPR selection. An analysis and metric for at least routing MPR selection. An analysis and
examples of MPR selection algorithms are given in [MPR]; a examples of MPR selection algorithms are given in [MPR]; a
suggested algorithm, appropriately adapted for each set of MPRs, suggested algorithm, appropriately adapted for each set of MPRs,
is included in Appendix A of this specification. Note that it is is included in Appendix B of this specification. Note that it is
not necessary for routers to use the same algorithm in order to not necessary for routers to use the same algorithm in order to
interoperate in the same MANET, but each such algorithm must have interoperate in the same MANET, but each such algorithm must have
the appropriate properties, described in Section 18. the appropriate properties, described in Section 18.
o Signaling its flooding MPR and routing MPR selections, by o Signaling its flooding MPR and routing MPR selections, by
extending the HELLO messages defined in [RFC6130] to report this extending the HELLO messages defined in [RFC6130] to report this
information by the addition of MPR Address Block TLV(s) associated information by the addition of MPR Address Block TLV(s) associated
with the appropriate network addresses. with the appropriate network addresses.
o Extracting its flooding MPR selectors and routing MPR selectors o Extracting its flooding MPR selectors and routing MPR selectors
skipping to change at page 16, line 18 skipping to change at page 16, line 23
graph representing the routers in the MANET, and the connectivity graph representing the routers in the MANET, and the connectivity
between them, is constructed from the Local Information Base, the between them, is constructed from the Local Information Base, the
Neighbor Information Base and the Router Topology Set. Second, this Neighbor Information Base and the Router Topology Set. Second, this
graph is "decorated" with additional destination network addresses graph is "decorated" with additional destination network addresses
using the Local Information Base, the Routable Address Topology Set using the Local Information Base, the Routable Address Topology Set
and the Attached Network Set. and the Attached Network Set.
The Topology Graph does not need to be recorded in the Topology The Topology Graph does not need to be recorded in the Topology
Information Base, it can either be constructed as required when the Information Base, it can either be constructed as required when the
Routing Set is to be changed, or need not be explicitly constructed Routing Set is to be changed, or need not be explicitly constructed
(as illustrated in Appendix B). An implementation may however (as illustrated in Appendix C). An implementation may however
construct and retain the Topology Graph if preferred. construct and retain the Topology Graph if preferred.
4.3.5. Received Message Information Base 4.3.5. Received Message Information Base
The Received Message Information Base in each router contains: The Received Message Information Base in each router contains:
o A Received Set for each OLSRv2 interface, describing TC messages o A Received Set for each OLSRv2 interface, describing TC messages
received by this router on that OLSRv2 interface. received by this router on that OLSRv2 interface.
o A Processed Set, describing TC messages processed by this router. o A Processed Set, describing TC messages processed by this router.
skipping to change at page 19, line 7 skipping to change at page 19, line 11
routers to determine if they can interoperate. If link metrics routers to determine if they can interoperate. If link metrics
require additional signaling to determine their values, whether in require additional signaling to determine their values, whether in
HELLO messages or otherwise, then this is permitted but is outside HELLO messages or otherwise, then this is permitted but is outside
the scope of this specification. the scope of this specification.
Careful consideration should be given to how to use link metrics. In Careful consideration should be given to how to use link metrics. In
particular it is advisable to not simply default to use of all links particular it is advisable to not simply default to use of all links
with equal metrics (i.e., hop count) for routing without careful with equal metrics (i.e., hop count) for routing without careful
consideration of whether that is appropriate or not. consideration of whether that is appropriate or not.
4.6. Routing Set Use 4.6. Flooding MPRs and Routing MPR
This specification uses two sets of MPRs: flooding MPRs and routing
MPRs. These are selected separately, because:
o Flooding MPRs may use metrics, routing MPRs must use metrics.
o When flooding MPRs use metrics, these are outgoing link metrics,
routing MPRs use incoming neighbor metrics.
o Flooding MPRs need not be selected per OLSRv2 interface, routing
MPRs must be selected per OLSRv2 interface.
4.7. Routing Set Use
The purpose of the Routing Set is to determine and record routes The purpose of the Routing Set is to determine and record routes
(local interface network address and next hop interface network (local interface network address and next hop interface network
address) to all possible routable addresses advertised by this address) to all possible routable addresses advertised by this
protocol, as well as of all destinations that are local, i.e., within protocol, as well as of all destinations that are local, i.e., within
one hop, to the router (whether using routable addresses or not). one hop, to the router (whether using routable addresses or not).
Only symmetric links are used in such routes. Only symmetric links are used in such routes.
It is intended that the Routing Set can be used for IP packet It is intended that the Routing Set can be used for IP packet
routing, by using its contents to update the IP routing table. That routing, by using its contents to update the IP routing table. That
skipping to change at page 19, line 46 skipping to change at page 20, line 15
and constants is also used in this specification. and constants is also used in this specification.
As for the parameters in [RFC6130], parameters defined in this As for the parameters in [RFC6130], parameters defined in this
specification MAY be changed dynamically by a router, and need not be specification MAY be changed dynamically by a router, and need not be
the same on different routers, even in the same MANET, or, for the same on different routers, even in the same MANET, or, for
interface parameters, on different interfaces of the same router. interface parameters, on different interfaces of the same router.
5.1. Protocol and Port Numbers 5.1. Protocol and Port Numbers
This protocol specifies TC messages, which are included in packets as This protocol specifies TC messages, which are included in packets as
defined by [RFC5444]. These packets MAY be sent either using the defined by [RFC5444]. These packets MUST be sent either using the
"manet" protocol number or the "manet" UDP well-known port number, as "manet" protocol number or the "manet" UDP well-known port number, as
specified in [RFC5498]. specified in [RFC5498].
TC messages and HELLO messages [RFC6130] MUST, in a given MANET, both TC messages and HELLO messages [RFC6130] MUST, in a given MANET,
be using the same of either of IP or UDP, in order that it is either both be using IP or both be using UDP, in order that it is
possible to combine messages of both protocols into the same possible to combine messages of both protocols into the same
[RFC5444] packet for transmission. [RFC5444] packet for transmission.
5.2. Multicast Address 5.2. Multicast Address
This protocol specifies TC messages, which are included in packets as This protocol specifies TC messages, which are included in packets as
defined by [RFC5444]. These packets MAY be transmitted using the defined by [RFC5444]. These packets MAY be transmitted using the
Link-Local multicast address "LL-MANET-Routers", as specified in Link-Local multicast address "LL-MANET-Routers", as specified in
[RFC5498]. [RFC5498].
skipping to change at page 21, line 49 skipping to change at page 22, line 14
TC_MIN_INTERVAL: TC_MIN_INTERVAL:
The minimum interval between transmission of two successive TC The minimum interval between transmission of two successive TC
messages by this router. (This minimum interval MAY be modified messages by this router. (This minimum interval MAY be modified
by jitter, as specified in [RFC5148].) 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 0 <= TC_MIN_INTERVAL <= TC_INTERVAL
o TC_INTERVAL >= TC_MIN_INTERVAL
o If TLVs with Type = INTERVAL_TIME, as defined in [RFC5497], are o If TLVs with Type = INTERVAL_TIME, as defined in [RFC5497], are
included in TC messages, then TC_INTERVAL MUST be representable as included in TC messages, then TC_INTERVAL MUST be representable by
described in [RFC5497]. way of the exponent-mantissa notation described in Section 5 of
[RFC5497].
5.4.4. Advertised Information Validity Times 5.4.4. Advertised Information Validity Times
The following parameters manage the validity time of information The following parameters manage the validity time of information
advertised in TC messages: advertised in TC messages:
T_HOLD_TIME: T_HOLD_TIME:
Used as the minimum value in the TLV with Type = VALIDITY_TIME Used as the minimum value in the TLV with Type = VALIDITY_TIME
included in all TC messages sent by this router. If a single included in all TC messages sent by this router. If a single
value of parameter TC_HOP_LIMIT (see Section 5.4.7) is used then value of parameter TC_HOP_LIMIT (see Section 5.4.7) is used then
skipping to change at page 22, line 36 skipping to change at page 22, line 49
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 [RFC5497]. o T_HOLD_TIME MUST be representable by way of the exponent-mantissa
notation described in Section 5 of [RFC5497].
5.4.5. Processing and Forwarding Validity Times 5.4.5. Processing and Forwarding Validity Times
The following parameters manage the processing and forwarding The following parameters manage the processing and forwarding
validity time of recorded message information: validity time of recorded message information:
P_HOLD_TIME: P_HOLD_TIME:
The period after receipt of a message that is processed by this The period after receipt of a message that is processed by 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 not processed again if received again. message is not processed again if received again.
skipping to change at page 24, line 36 skipping to change at page 24, line 51
routing MPR and hence to be an intermediate router on routes. routing MPR and hence to be an intermediate router on routes.
In either case, the higher the value, the greater the router's In either case, the higher the value, the greater the router's
willingness to be a flooding or routing MPR, respectively. If a willingness to be a flooding or routing MPR, respectively. If a
router has a willingness value of WILL_NEVER (the lowest possible router has a willingness value of WILL_NEVER (the lowest possible
value) it does not perform the corresponding task. A MANET using value) it does not perform the corresponding task. A MANET using
this protocol with too many routers having either willingness value this protocol with too many routers having either willingness value
equal to WILL_NEVER will not function; it MUST be ensured, by equal to WILL_NEVER will not function; it MUST be ensured, by
administrative or other means, that this does not happen. administrative or other means, that this does not happen.
Note that how many routers having either willingness value equal to
WILL_NEVER is "too many" depends on the network topology - which, in
a MANET may change dynamically. Willingness is intended to enable
that certain routers (e.g., routers that have generous resources,
such as a permanent power supply) can be configured to assume more of
the network operation, while others (e.g., routers that have lesser
resources, such as are battery operated) can avoid such tasks. A
general guideline would be that only if a router is not actually able
to assume the task (flooding or routing) should it be configured with
the corresponding willingness WILL_NEVER.
If a router has a willingness value equal to WILL_ALWAYS (the highest If a router has a willingness value equal to WILL_ALWAYS (the highest
possible value) then it will always be selected as a flooding or possible value) then it will always be selected as a flooding or
routing MPR, respectively, by all symmetric 1-hop neighbors. routing MPR, respectively, by all symmetric 1-hop neighbors.
In a MANET in which all routers have WILL_FLOODING = WILL_ALWAYS, In a MANET in which all routers have WILL_FLOODING = WILL_ALWAYS,
flooding reduction will effectively be disabled, and flooding will flooding reduction will effectively be disabled, and flooding will
perform as blind flooding. perform as blind flooding.
In a MANET in which all routers have WILL_ROUTING = WILL_ALWAYS, In a MANET in which all routers have WILL_ROUTING = WILL_ALWAYS,
topology reduction will effectively be disabled, and all routers will topology reduction will effectively be disabled, and all routers will
skipping to change at page 25, line 10 skipping to change at page 25, line 34
A router that has WILL_ROUTING = WILL_NEVER will not act as an A router that has WILL_ROUTING = WILL_NEVER will not act as an
intermediate router in the MANET. Such a router can, act as a intermediate router in the MANET. Such a router can, act as a
source, destination or gateway to another routing domain. source, destination or gateway to another routing domain.
Different routers MAY have different values for WILL_FLOODING and/or Different routers MAY have different values for WILL_FLOODING and/or
WILL_ROUTING. WILL_ROUTING.
The following constraints apply to these parameters: The following constraints apply to these parameters:
o WILL_FLOODING >= WILL_NEVER o WILL_NEVER <= WILL_FLOODING <= WILL_ALWAYS
o WILL_FLOODING <= WILL_ALWAYS
o WILL_ROUTING >= WILL_NEVER
o WILL_ROUTING <= WILL_ALWAYS o WILL_NEVER <= WILL_ROUTING <= WILL_ALWAYS
5.5. Parameter Change Constraints 5.5. Parameter Change Constraints
If protocol parameters are changed dynamically, then the constraints If protocol parameters are changed dynamically, then the constraints
in this section apply. in this section apply.
RX_HOLD_TIME RX_HOLD_TIME
* If RX_HOLD_TIME for an OLSRv2 interface changes, then the * If RX_HOLD_TIME for an OLSRv2 interface changes, then the
expiry time for all Received Tuples for that OLSRv2 interface expiry time for all Received Tuples for that OLSRv2 interface
skipping to change at page 26, line 49 skipping to change at page 27, line 21
Section 17 and [RFC6130]. Section 17 and [RFC6130].
+ For each Link Tuple in any Link Set for an OLSRv2 interface, + For each Link Tuple in any Link Set for an OLSRv2 interface,
either update L_in_metric (the value MAXIMUM_METRIC MAY be either update L_in_metric (the value MAXIMUM_METRIC MAY be
used) or remove the Link Tuple from the Link Set. used) or remove the Link Tuple from the Link Set.
+ For each Link Tuple that is not removed, set: + For each Link Tuple that is not removed, set:
- L_out_metric := UNKNOWN_METRIC; - L_out_metric := UNKNOWN_METRIC;
- L_SYM_time := expired; - L_SYM_time := EXPIRED;
- L_MPR_selector := false. - L_MPR_selector := false.
+ Remove all Router Topology Tuples, Routable Address Topology + Remove all Router Topology Tuples, Routable Address Topology
Tuples, Attached Network Tuples and Routing Tuples from Tuples, Attached Network Tuples and Routing Tuples from
their respective Protocol Sets in the Topology Information their respective Protocol Sets in the Topology Information
Base. Base.
5.6. Constants 5.6. Constants
skipping to change at page 27, line 37 skipping to change at page 28, line 11
The constant minimum, RECOMMENDED default, and maximum, willingness The constant minimum, RECOMMENDED default, and maximum, willingness
values are defined by: values are defined by:
o WILL_NEVER := 0 o WILL_NEVER := 0
o WILL_DEFAULT := 7 o WILL_DEFAULT := 7
o WILL_ALWAYS := 15 o WILL_ALWAYS := 15
5.6.3. Time Constant
The constant C (time granularity) is used as specified in [RFC5497].
It MUST be the same as is used by [RFC6130], with RECOMMENDED value:
o C := 1/1024 second
Note that this parameter is used in the representation of time
intervals. Time values (such as are stored in Protocol Tuples) are
not so represented. A resolution of C in such values is sufficient
(but not necessary) for such values.
6. Link Metric Values 6. Link Metric Values
A router records a link metric value for each direction of a link of A router records a link metric value for each direction of a link of
which it has knowledge. These link metric values are used to create which it has knowledge. These link metric values are used to create
metrics for routes by the addition of link metric values. metrics for routes by the addition of link metric values.
6.1. Link Metric Representation 6.1. Link Metric Representation
Link metrics are reported in messages using a compressed Link metrics are reported in messages using a compressed
representation that occupies 12 bits, a 4 bit field and an 8 bit representation that occupies 12 bits, consisting of a 4 bit field and
field. The compressed representation represents positive integer an 8 bit field. The compressed representation represents positive
values with a minimum value of 1 and a maximum value that is slightly integer values with a minimum value of 1 and a maximum value that is
smaller than the maximum 24 bit value. Only those values that have slightly smaller than the maximum 24 bit value. Only those values
exact representation in the compressed form are used. Route metrics that have exact representation in the compressed form are used.
are the summation of no more than 255 link metric values, and can Route metrics are the summation of no more than 255 link metric
therefore be represented using no more than 32 bits. values, and can therefore be represented using no more than 32 bits.
Link and route metrics used in the Information Bases defined in this Link and route metrics used in the Information Bases defined in this
specification refer to the uncompressed values, and arithmetic specification refer to the uncompressed values, and arithmetic
involving them does likewise, and assumes full precision in the involving them does likewise, and assumes full precision in the
result. (How an implementation records the values is not part of result. (How an implementation records the values is not part of
this specification, as long as it behaves as if recording this specification, as long as it behaves as if recording
uncompressed values. An implementation can, for example, use 32 bit uncompressed values. An implementation can, for example, use 32 bit
values for all link and route metrics.) values for all link and route metrics.)
In some cases a link metric value may be unknown. This is indicated In some cases a link metric value may be unknown. This is indicated
skipping to change at page 29, line 34 skipping to change at page 30, line 25
O_orig_addr is a recently used originator address; note that this O_orig_addr is a recently used originator address; note that this
does not include a prefix length. does not include a prefix length.
O_time specifies the time at which this Tuple expires and MUST be O_time specifies the time at which this Tuple expires and MUST be
removed. removed.
7.2. Local Attached Network Set 7.2. Local Attached Network Set
A router's Local Attached Network Set records its local non-OLSRv2 A router's Local Attached Network Set records its local non-OLSRv2
interfaces via which it can act as gateways to other networks. The interfaces via which it can act as a gateway to other networks. The
Local Attached Network Set is not modified by this protocol. This Local Attached Network Set MUST be provided to this protocol and MUST
protocol MAY respond to changes to the Local Attached Network Set, reflect any changes in the router's status. (In cases where the
which MUST reflect corresponding changes in the router's status. It router's configuration is static, the Local Attached Network Set will
consists of Local Attached Network Tuples: be constant; in cases where the router has no non-OLSRv2 interfaces,
the Local Attached Network Set will be empty.) The Local Attached
Network Set is not modified by this protocol. This protocol will
respond to (externally provided) changes to the Local Attached
Network Set. It consists of Local Attached Network Tuples:
(AL_net_addr, AL_dist, AL_metric) (AL_net_addr, AL_dist, AL_metric)
where: where:
AL_net_addr is the network address of an attached network which AL_net_addr is the network address of an attached network which
can be reached via this router. This SHOULD be a routable can be reached via this router. This SHOULD be a routable
address. It is constrained as described below. address. It is constrained as described below.
AL_dist is the number of hops to the network with network address AL_dist is the number of hops to the network with network address
skipping to change at page 38, line 40 skipping to change at page 39, line 30
Information Base. The latter Protocol Tuple is referred to as Information Base. The latter Protocol Tuple is referred to as
"corresponding" to the former Protocol Tuple. "corresponding" to the former Protocol Tuple.
Specific examples of corresponding Protocol Tuples include: Specific examples of corresponding Protocol Tuples include:
o There is a Local Interface Tuple corresponding to each Link Tuple, o There is a Local Interface Tuple corresponding to each Link Tuple,
where the Link Tuple is in the Link Set for a MANET interface, and where the Link Tuple is in the Link Set for a MANET interface, and
the Local Interface Tuple represents that MANET interface. the Local Interface Tuple represents that MANET interface.
o There is a Neighbor Tuple corresponding to each Link Tuple which o There is a Neighbor Tuple corresponding to each Link Tuple which
has L_HEARD_time not expired, such that N_neighbor_addr_list has L_HEARD_time not EXPIRED, such that N_neighbor_addr_list
contains L_neighbor_iface_addr_list. contains L_neighbor_iface_addr_list.
o There is a Link Tuple (in the Link Set in the same Interface o There is a Link Tuple (in the Link Set in the same Interface
Information Base) corresponding to each 2-Hop Tuple such that Information Base) corresponding to each 2-Hop Tuple such that
L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list. L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list.
o There is a Neighbor Tuple corresponding to each 2-Hop Tuple, such o There is a Neighbor Tuple corresponding to each 2-Hop Tuple, such
that N_neighbor_addr_list contains N2_neighbor_iface_addr_list. that N_neighbor_addr_list contains N2_neighbor_iface_addr_list.
(This is the Neighbor Tuple corresponding to the Link Tuple (This is the Neighbor Tuple corresponding to the Link Tuple
corresponding to the 2-Hop Tuple.) corresponding to the 2-Hop Tuple.)
skipping to change at page 47, line 48 skipping to change at page 48, line 48
o Decrement <msg-hop-limit> in the Message Header by o Decrement <msg-hop-limit> in the Message Header by
1; AND 1; AND
o If present, increment <msg-hop-count> in the o If present, increment <msg-hop-count> in the
Message Header by 1. Message Header by 1.
3. The message is transmitted over all OLSRv2 3. The message is transmitted over all OLSRv2
interfaces, as described in Section 13. interfaces, as described in Section 13.
4. Otherwise, the current message MUST be silently
discarded.
15. HELLO Messages 15. HELLO Messages
The HELLO Message Type is owned by [RFC6130], and thus HELLO messages The HELLO Message Type is owned by [RFC6130], and thus HELLO messages
are generated, transmitted, received and processed by [RFC6130]. are generated, transmitted, received and processed by [RFC6130].
This protocol, as permitted by [RFC6130], also uses HELLO messages, This protocol, as permitted by [RFC6130], also uses HELLO messages,
including adding to HELLO message generation, and implementing including adding to HELLO message generation, and implementing
additional processing based on received HELLO messages. HELLO additional processing based on received HELLO messages. HELLO
messages are not forwarded by [RFC6130] or by this specification. messages are not forwarded by [RFC6130] or by this specification.
15.1. HELLO Message Generation 15.1. HELLO Message Generation
skipping to change at page 57, line 11 skipping to change at page 58, line 13
schedule. Alternatively, a router MAY send an incomplete TC message schedule. Alternatively, a router MAY send an incomplete TC message
with at least the newly advertised network addresses (i.e., not with at least the newly advertised network addresses (i.e., not
previously, but now, an N_orig_addr or in an N_neighbor_addr_list in previously, but now, an N_orig_addr or in an N_neighbor_addr_list in
a Neighbor Tuple with N_advertised = true, or an AL_net_addr) in its a Neighbor Tuple with N_advertised = true, or an AL_net_addr) in its
Address Blocks, with associated Address Block TLV(s). Note that a Address Blocks, with associated Address Block TLV(s). Note that a
router cannot report removal of advertised content using an router cannot report removal of advertised content using an
incomplete TC message. incomplete TC message.
When sending a TC message in response to a change of advertised When sending a TC message in response to a change of advertised
network addresses, a router MUST respect a minimum interval of network addresses, a router MUST respect a minimum interval of
TC_MIN_INTERVAL between generated TC messages. Sending an incomplete TC_MIN_INTERVAL between sending TC messages (complete or incomplete),
TC message MUST NOT cause the interval between complete TC messages and a maximum interval of TC_INTERVAL between sending complete TC
to be increased, and thus a router MUST NOT send an incomplete TC messages. Thus a router MUST NOT send an incomplete TC message if
message if within TC_MIN_INTERVAL of the next scheduled complete TC within TC_MIN_INTERVAL of the next scheduled time to send a complete
message. TC message.
The generation of TC messages, whether scheduled or triggered by a The generation of TC messages, whether scheduled or triggered by a
change of contents, MAY be jittered as described in [RFC5148]. The change of contents, MAY be jittered as described in [RFC5148]. The
values of MAXJITTER used MUST be: values of MAXJITTER used MUST be:
o TP_MAXJITTER for periodic TC message generation; o TP_MAXJITTER for periodic TC message generation;
o TT_MAXJITTER for responsive TC message generation. o TT_MAXJITTER for responsive TC message generation.
16.3. TC Message Processing 16.3. TC Message Processing
skipping to change at page 59, line 13 skipping to change at page 60, line 14
TLV(s) with Type = GATEWAY. TLV(s) with Type = GATEWAY.
o Associates any address object (including different copies of an o Associates any address object (including different copies of an
address object, in the same or different Address Blocks) with address object, in the same or different Address Blocks) with
Address Block TLVs with Type = NBR_ADDR_TYPE and Type = GATEWAY. Address Block TLVs with Type = NBR_ADDR_TYPE and Type = GATEWAY.
A router MAY recognize additional reasons for identifying that a A router MAY recognize additional reasons for identifying that a
message is invalid. An invalid message MUST be silently discarded, message is invalid. An invalid message MUST be silently discarded,
without updating the router's Information Bases. without updating the router's Information Bases.
Note that a router that acts inconsistently, for example rejecting TC
messages "at random", may cause parts of the network to not be able
to communicate with other parts of the network. It is RECOMMENDED
that such "additional reasons for identifying that a message is
invalid" be a consistent network-wide policy (e.g., as part of a
security policy), implemented on all participating routers.
16.3.2. TC Message Processing Definitions 16.3.2. TC Message Processing Definitions
When, according to Section 14.2, a TC message is to be "processed When, according to Section 14.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 16.3.3 and then according to Section 16.3.4 is carried Section 16.3.3 and then according to Section 16.3.4 is carried
out. out.
skipping to change at page 65, line 6 skipping to change at page 66, line 18
The consistency of a Link Tuple MUST be maintained according to the The consistency of a Link Tuple MUST be maintained according to the
following rules, in addition to those in [RFC6130]: following rules, in addition to those in [RFC6130]:
o If L_status = HEARD or L_status = SYMMETRIC, then L_in_metric MUST o If L_status = HEARD or L_status = SYMMETRIC, then L_in_metric MUST
be set (by a process outside this specification). be set (by a process outside this specification).
o If L_status != SYMMETRIC, then set L_mpr_selector := false. o If L_status != SYMMETRIC, then set L_mpr_selector := false.
o If L_out_metric = UNKNOWN_METRIC, then L_status MUST NOT equal o If L_out_metric = UNKNOWN_METRIC, then L_status MUST NOT equal
SYMMETRIC; set L_SYM_time := expired if this would otherwise be SYMMETRIC; set L_SYM_time := EXPIRED if this would otherwise be
the case. the case.
17.3. Neighbor State Changes 17.3. Neighbor State Changes
The consistency of a Neighbor Tuple MUST be maintained according to The consistency of a Neighbor Tuple MUST be maintained according to
the following rules, in addition to those in [RFC6130]: the following rules, in addition to those in [RFC6130]:
1. If N_symmetric = true, then N_in_metric MUST equal the minimum 1. If N_symmetric = true, then N_in_metric MUST equal the minimum
value of all L_in_metric of corresponding Link Tuples with value of all L_in_metric of corresponding Link Tuples with
L_status = SYMMETRIC and L_in_metric != UNKNOWN_METRIC. If there L_status = SYMMETRIC and L_in_metric != UNKNOWN_METRIC. If there
skipping to change at page 70, line 10 skipping to change at page 71, line 27
18.1. Overview 18.1. Overview
MPRs are selected according to the following steps, defined in the MPRs are selected according to the following steps, defined in the
following sections: following sections:
o A data structure known as a Neighbor Graph is defined. o A data structure known as a Neighbor Graph is defined.
o The properties of an MPR Set derived from a Neighbor Graph are o The properties of an MPR Set derived from a Neighbor Graph are
defined. Any algorithm that creates an MPR Set that satisfies defined. Any algorithm that creates an MPR Set that satisfies
these properties is a valid MPR selection algorithm. An example these properties is a valid MPR selection algorithm. An example
algorithm that creates such an MPR Set is given in Appendix A. algorithm that creates such an MPR Set is given in Appendix B.
o How to create a Neighbor Graph for each interface based on the o How to create a Neighbor Graph for each interface based on the
corresponding Interface Information Base is defined, and how to corresponding Interface Information Base is defined, and how to
combine the resulting MPR Sets to determine the router's flooding combine the resulting MPR Sets to determine the router's flooding
MPRs and record those in the router's Neighbor Set. MPRs and record those in the router's Neighbor Set.
o How to create a single Neighbor Graph based on all Interface o How to create a single Neighbor Graph based on all Interface
Information Bases and the Neighbor Information Base is defined, Information Bases and the Neighbor Information Base is defined,
and how to record the resulting MPR Set as the router's routing and how to record the resulting MPR Set as the router's routing
MPRs in the router's Neighbor Set. MPRs in the router's Neighbor Set.
skipping to change at page 74, line 16 skipping to change at page 75, line 34
flooding MPRs is the union of the sets of flooding MPRs for all flooding MPRs is the union of the sets of flooding MPRs for all
OLSRv2 interfaces. OLSRv2 interfaces.
A router MAY select its flooding MPRs for each OLSRv2 interface A router MAY select its flooding MPRs for each OLSRv2 interface
independently, or it MAY coordinate its MPR selections across its independently, or it MAY coordinate its MPR selections across its
OLSRv2 interfaces, as long as the required condition is satisfied for OLSRv2 interfaces, as long as the required condition is satisfied for
each OLSRv2 interface. One such coordinated approach is to process each OLSRv2 interface. One such coordinated approach is to process
the OLSRv2 interfaces sequentially, and for each OLSRv2 interface the OLSRv2 interfaces sequentially, and for each OLSRv2 interface
start with flooding MPRs selected (and not removable) if the neighbor start with flooding MPRs selected (and not removable) if the neighbor
has been already selected as an MPR for an OLSRv2 interface that has has been already selected as an MPR for an OLSRv2 interface that has
already been processed. The algorithm specified in Appendix A can be already been processed. The algorithm specified in Appendix B can be
used in this way. used in this way.
18.5. Routing MPRs 18.5. Routing MPRs
Whenever routing MPRs are to be calculated, an implementation MUST Whenever routing MPRs are to be calculated, an implementation MUST
determine and record a set of routing MPRs that is equivalent to one determine and record a set of routing MPRs that is equivalent to one
calculated as described in this section. calculated as described in this section.
Define a single Neighbor Graph as defined in Section 18.2 according Define a single Neighbor Graph as defined in Section 18.2 according
to the following: to the following:
skipping to change at page 79, line 14 skipping to change at page 80, line 35
o R_dest_addr := U, V, T or Z; o R_dest_addr := U, V, T or Z;
o R_dist := the total hop count of all edges in the path; o R_dist := the total hop count of all edges in the path;
o R_metric := the total metric of all edges in the path. o R_metric := the total metric of all edges in the path.
Finally, Routing Tuples of the second type whose R_dest_addr is not Finally, Routing Tuples of the second type whose R_dest_addr is not
routable MAY be discarded. routable MAY be discarded.
An example algorithm for calculating the Routing Set of a router is An example algorithm for calculating the Routing Set of a router is
given in Appendix B. given in Appendix C.
20. Proposed Values for Parameters 20. Proposed Values for Parameters
This protocol uses all parameters defined in [RFC6130] and additional This protocol uses all parameters defined in [RFC6130] and additional
parameters and defined in this specification. All but one parameters and defined in this specification. All but one
(RX_HOLD_TIME) of these additional parameters are router parameters (RX_HOLD_TIME) of these additional parameters are router parameters
as defined in [RFC6130]. The proposed values of the additional as defined in [RFC6130]. The proposed values of the additional
parameters defined in the following sections are appropriate to the parameters defined in the following sections are appropriate to the
case where all parameters (including those defined in [RFC6130]) have case where all parameters (including those defined in [RFC6130]) have
a single value. Proposed values for parameters defined in [RFC6130] a single value. Proposed values for parameters defined in [RFC6130]
are given in that specification. are given in that specification.
The following proposed values are based on experience with [RFC3626]
deployments (such as documented in [McCabe]), and are considered
typical. They can be changed to accommodate different deployment
requirements - for example, a network with capacity-limited network
interfaces would be expected to use greater values for message
intervals, whereas a highly mobile network would be expected to use
lower values for message intervals. When determining these values,
the constraints specified in Section 5 MUST be respected.
Note that routers in a MANET need not all use the same set of
parameters, and those parameters that are indicated as interface
parameters need not be the same on all OLSRv2 interfaces of a single
router.
20.1. Local History Time Parameters 20.1. Local History Time Parameters
o O_HOLD_TIME := 30 seconds o O_HOLD_TIME := 30 seconds
20.2. Message Interval Parameters 20.2. Message Interval Parameters
o TC_INTERVAL := 5 seconds o TC_INTERVAL := 5 seconds
o TC_MIN_INTERVAL := TC_INTERVAL/4 o TC_MIN_INTERVAL := TC_INTERVAL/4
skipping to change at page 81, line 13 skipping to change at page 82, line 49
most recent information. most recent information.
22. Extensions 22. Extensions
An extension to this protocol will need to interact with this An extension to this protocol will need to interact with this
specification, and possibly also with [RFC6130]. This protocol is specification, and possibly also with [RFC6130]. This protocol is
designed to permit such interactions, in particular: designed to permit such interactions, in particular:
o Through accessing, and possibly extending, the information in the o Through accessing, and possibly extending, the information in the
Information Bases. All updates to the elements specified in this Information Bases. All updates to the elements specified in this
specification are subject to the constraints specified in specification are subject to the normative constraints specified
[RFC6130] and Appendix D. in [RFC6130] and Appendix A. Note that the processing specified
in this document ensures that these constraints are satisfied.
o Through accessing an outgoing message prior to it being o Through accessing an outgoing message prior to it being
transmitted over any OLSRv2 interface, and to add information to transmitted over any OLSRv2 interface, and to add information to
it as specified in [RFC5444]. This MAY include Message TLVs it as specified in [RFC5444]. This MAY include Message TLVs
and/or network addresses with associated Address Block TLVs. and/or network addresses with associated Address Block TLVs.
(Network addresses without new associated TLVs SHOULD NOT be added (Network addresses without new associated TLVs SHOULD NOT be added
to messages.) This may, for example, be to allow a security to messages.) This may, for example, be to allow a security
protocol, as suggested in Section 23, to add a TLV containing a protocol, as suggested in Section 23, to add a TLV containing a
cryptographic signature to the message. cryptographic signature to the message.
skipping to change at page 82, line 11 skipping to change at page 83, line 45
architecture for OLSRv2, and gives guidelines on how to provide architecture for OLSRv2, and gives guidelines on how to provide
integrity, confidentiality, and integration into external routing integrity, confidentiality, and integration into external routing
domains. domains.
23.1. Security Architecture 23.1. Security Architecture
OLSRv2 integrates into the architecture specified in Appendix A of OLSRv2 integrates into the architecture specified in Appendix A of
[RFC5444], in [RFC5498], and in Section 16 of [RFC6130], the latter [RFC5444], in [RFC5498], and in Section 16 of [RFC6130], the latter
by using and extending its messages and Information Bases. by using and extending its messages and Information Bases.
As part of this architecture, OLSRv2, and NHDP, recognize that there As part of this architecture, OLSRv2, and [RFC6130], recognize that
may be external reasons for rejecting messages that would be there may be external reasons for rejecting messages that would be
considered "badly formed" or "insecure", e.g., if a digital signature considered "badly formed" or "insecure", e.g., if a digital signature
included in a message by an external mechanism cannot be verified. included in a message by an external mechanism cannot be verified.
This architecture allows options as to whether and how to implement This architecture allows options as to whether and how to implement
security features, reflecting the situation that MANET routing security features, reflecting the situation that MANET routing
protocol deployment domains have varying security requirements, protocol deployment domains have varying security requirements,
ranging from "practically unbreakable" to "virtually none". This ranging from "practically unbreakable" to "virtually none". This
approach allows MANET routing protocol specifications to remain approach allows MANET routing protocol specifications to remain
generic, with extensions to them, and/or extensions to the generic, with extensions to them, and/or extensions to the
multiplexing and demultiplexing process described in Appendix A of multiplexing and demultiplexing process described in Appendix A of
[RFC5444], providing security mechanisms appropriate to a given [RFC5444], providing security mechanisms appropriate to a given
skipping to change at page 83, line 49 skipping to change at page 85, line 34
[RFC6622] specifies a common exchange format for cryptographic [RFC6622] specifies a common exchange format for cryptographic
information in the form of Packet TLVs, Message TLVs, and Address information in the form of Packet TLVs, Message TLVs, and Address
Block TLVs, as specified in [RFC5444]. These may be used (and Block TLVs, as specified in [RFC5444]. These may be used (and
shared) among MANET routing protocol security extensions. In shared) among MANET routing protocol security extensions. In
particular, [RFC6622] specifies the format of TLVs for containing particular, [RFC6622] specifies the format of TLVs for containing
Integrity Check Values (ICVs), i.e., signatures, for providing Integrity Check Values (ICVs), i.e., signatures, for providing
integrity, as well as TLVs for containing temporal information for integrity, as well as TLVs for containing temporal information for
preventing replay attacks. [RFC6622] specifies registries for using preventing replay attacks. [RFC6622] specifies registries for using
different ciphers and formats of temporal information. Failure to different ciphers and formats of temporal information. Failure to
verify an ICV included can be used as a reason to reject an incoming verify an ICV included can be used as a reason to reject an incoming
message or packet as "valid", according to Section 12.1 of [RFC6130], message or packet as "invalid", according to Section 12.1 of
and according to Section 16.3.1 of this specification, when using the [RFC6130], and according to Section 16.3.1 of this specification,
multiplexing and demultiplexing process described in Appendix A of when using the multiplexing and demultiplexing process described in
Appendix A of [RFC5444].
[RFC5444].
Any security extension that uses [RFC6622] must specify how to insert Any security extension that uses [RFC6622] must specify how to insert
IVCs in generated messages, how to verify incoming messages, and to IVCs in generated messages, how to verify incoming messages, and to
reject "insecure" messages (i.e., messages without an ICV or with an reject "insecure" messages (i.e., messages without an ICV or with an
ICV that cannot be verified) when operating in a secure mode. ICV that cannot be verified) when operating in a secure mode.
Different MANET deployments may, as a result of their purpose for Different MANET deployments may, as a result of their purpose for
which they are used and the possibility and nature of their which they are used and the possibility and nature of their
configuration, require different ICV algorithms and timestamps, and configuration, require different ICV algorithms and timestamps, and
thus a security extension may use any of the different options thus a security extension may use any of the different options
provided in [RFC6622]. provided in [RFC6622].
skipping to change at page 91, line 45 skipping to change at page 93, line 21
26. Acknowledgments 26. Acknowledgments
The authors would like to acknowledge the team behind OLSRv1, as The authors would like to acknowledge the team behind OLSRv1, as
listed in RFC3626, including Anis Laouiti (INT), Pascale Minet listed in RFC3626, including Anis Laouiti (INT), Pascale Minet
(INRIA), Paul Muhlethaler (INRIA), Amir Qayyum (M.A. Jinnah (INRIA), Paul Muhlethaler (INRIA), Amir Qayyum (M.A. Jinnah
University), and Laurent Viennot (INRIA) for their contributions. University), and Laurent Viennot (INRIA) for their contributions.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components (listed alphabetically): Khaldoun Al specification and its components (listed alphabetically): Khaldoun Al
Agha (LRI), Teco Boot (Infinity Networks), Song-Yean Cho (Samsung), Agha (LRI), Teco Boot (Infinity Networks), Ross Callon (Juniper),
Alan Cullen (BAE Systems), Louise Lamont (CRC), Li Li (CRC), Joseph Song-Yean Cho (Samsung), Alan Cullen (BAE Systems), Louise Lamont
Macker (NRL), Richard Ogier (SRI), Charles E. Perkins (Futurewei), (CRC), Li Li (CRC), Joseph Macker (NRL), Richard Ogier (SRI), Charles
Henning Rogge (Frauenhofer FKIE), and the entire IETF MANET Working E. Perkins (Futurewei), Henning Rogge (Frauenhofer FKIE), and the
Group. entire IETF MANET Working Group.
Finally, the authors would like to express their gratitude to the
Area Directors for providing valuable review comments during the IESG
evaluation, in particular (listed alphabetically) Benoit Claise,
Adrian Farrel, Stephen Farrell, Barry Leiba, Pete Resnick, and Martin
Stiemerling.
27. References 27. References
27.1. Normative References 27.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
Considerations in Mobile Ad Hoc Networks (MANETs)", Considerations in Mobile Ad Hoc Networks (MANETs)",
RFC 5148, February 2008. RFC 5148, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
skipping to change at page 93, line 16 skipping to change at page 94, line 46
relaying: An efficient technique for flooding in mobile relaying: An efficient technique for flooding in mobile
wireless networks.", 2001. wireless networks.", 2001.
[FSR] Pei, G., Gerla, M., and T. Chen, "Fisheye state routing [FSR] Pei, G., Gerla, M., and T. Chen, "Fisheye state routing
in mobile ad hoc networks", 2000. in mobile ad hoc networks", 2000.
[FSLS] Santivanez, C., Ramanathan, R., and I. Stavrakakis, [FSLS] Santivanez, C., Ramanathan, R., and I. Stavrakakis,
"Making link-state routing scale for ad hoc networks", "Making link-state routing scale for ad hoc networks",
2000. 2000.
Appendix A. Example Algorithm for Calculating MPRs [McCabe] McCabe, A., Dearlove, C., Fredin, M., and L. Axelsson,
"Scalability Modelling of Ad Hoc Routing Protocols - A
Comparison of OLSR and DSR", 2004.
Appendix A. Constraints
Updates to the Local Information Base, the Neighborhood Information
Base or the Topology Information Base MUST ensure that all
constraints specified in this appendix are maintained, as well as
those specified in [RFC6130]. This is the case for the processing,
specified in this document. Any protocol extension or outside
process, which updates the Neighborhood Information Base or the
Topology Information Base, MUST also ensure that these constraints
are maintained.
In each Originator Tuple:
o O_orig_addr MUST NOT equal any other O_orig_addr.
o O_orig_addr MUST NOT equal this router's originator address.
In each Local Attached Network Tuple:
o AL_net_addr MUST NOT equal any other AL_net_addr.
o AL_net_addr MUST NOT equal or be a sub-range of any network
address in the I_local_iface_addr_list of any Local Interface
Tuple.
o AL_net_addr MUST NOT equal this router's originator address, or
equal the O_orig_addr in any Originator Tuple.
o AL_dist MUST NOT be less than zero.
In each Link Tuple:
o L_neighbor_iface_addr_list MUST NOT contain any network address
that AL_net_addr of any Local Attached Network Tuple equals or is
a sub-range of.
o if L_in_metric != UNKNOWN_METRIC then L_in_metric MUST be
representable in the defined compressed form.
o if L_out_metric != UNKNOWN_METRIC then L_out_metric MUST be
representable in the defined compressed form.
o If L_mpr_selector = true, then L_status = SYMMETRIC.
In each Neighbor Tuple:
o N_orig_addr MUST NOT be changed to unknown.
o N_orig_addr MUST NOT equal this router's originator address, or
equal O_orig_addr in any Originator Tuple.
o N_orig_addr MUST NOT equal the AL_net_addr in any Local Attached
Network Tuple.
o If N_orig_addr != unknown, then N_orig_addr MUST NOT equal the
N_orig_addr in any other Neighbor Tuple.
o N_neighbor_addr_list MUST NOT contain any network address which
includes this router's originator address, the O_orig_addr in any
Originator Tuple, or equal or have as a sub-range the AL_net_addr
in any Local Attached Network Tuple.
o If N_orig_addr = unknown, then N_will_flooding = WILL_NEVER,
N_will_routing = WILL_NEVER, N_flooding_mpr, N_routing_mpr =
false, N_mpr_selector = false, and N_advertised = false.
o N_in_metric MUST equal the minimum value of the L_in_metric values
of all corresponding Link Tuples with L_status = SYMMETRIC and
L_in_metric != UNKNOWN_METRIC, if any, otherwise N_in_metric =
UNKNOWN_METRIC.
o N_out_metric MUST equal the minimum value of the L_out_metric
values of all corresponding Link Tuples with L_status = SYMMETRIC
and L_out_metric != UNKNOWN_METRIC, if any, otherwise N_out_metric
= UNKNOWN_METRIC.
o N_will_flooding and N_will_routing MUST be in the range from
WILL_NEVER to WILL_ALWAYS, inclusive.
o If N_flooding_mpr = true, then N_symmetric MUST be true,
N_out_metric MUST NOT equal UNKNOWN_METRIC and N_will_flooding
MUST NOT equal WILL_NEVER.
o If N_routing_mpr = true, then N_symmetric MUST be true,
N_in_metric MUST NOT equal UNKNOWN_METRIC and N_will_routing MUST
NOT equal WILL_NEVER.
o If N_symmetric = true and N_flooding_mpr = false, then
N_will_flooding MUST NOT equal WILL_ALWAYS.
o If N_symmetric = true and N_routing_mpr = false, then
N_will_routing MUST NOT equal WILL_ALWAYS.
o If N_mpr_selector = true, then N_advertised MUST be true.
o If N_advertised = true, then N_symmetric MUST be true and
N_out_metric MUST NOT equal UNKNOWN_METRIC.
In each Lost Neighbor Tuple:
o NL_neighbor_addr MUST NOT include this router's originator
address, the O_orig_addr in any Originator Tuple, or equal or have
as a sub-range the AL_net_addr in any Local Attached Network
Tuple.
In each 2-Hop Tuple:
o N2_2hop_addr MUST NOT equal this router's originator address,
equal the O_orig_addr in any Originator Tuple, or equal or have as
a sub-range the AL_net_addr in any Local Attached Network Tuple.
o if N2_in_metric != UNKNOWN_METRIC then N2_in_metric MUST be
representable in the defined compressed form.
o if N2_out_metric != UNKNOWN_METRIC then N2_out_metric MUST be
representable in the defined compressed form.
In each Advertising Remote Router Tuple:
o AR_orig_addr MUST NOT be in any network address in the
I_local_iface_addr_list in any Local Interface Tuple or be in the
IR_local_iface_addr in any Removed Interface Address Tuple.
o AR_orig_addr MUST NOT equal this router's originator address or
equal the O_orig_addr in any Originator Tuple.
o AR_orig_addr MUST NOT be in the AL_net_addr in any Local Attached
Network Tuple.
o AR_orig_addr MUST NOT equal the AR_orig_addr in any other
Advertising Remote Router Tuple.
In each Router Topology Tuple:
o There MUST be an Advertising Remote Router Tuple with AR_orig_addr
= TR_from_orig_addr.
o TR_to_orig_addr MUST NOT be in any network address in the
I_local_iface_addr_list in any Local Interface Tuple or be in the
IR_local_iface_addr in any Removed Interface Address Tuple.
o TR_to_orig_addr MUST NOT equal this router's originator address or
equal the O_orig_addr in any Originator Tuple.
o TR_to_orig_addr MUST NOT be in the AL_net_addr in any Local
Attached Network Tuple.
o The ordered pair (TR_from_orig_addr, TR_to_orig_addr) MUST NOT
equal the corresponding pair for any other Router Topology Tuple.
o TR_seq_number MUST NOT be greater than AR_seq_number in the
Advertising Remote Router Tuple with AR_orig_addr =
TR_from_orig_addr.
o TR_metric MUST be representable in the defined compressed form.
In each Routable Address Topology Tuple:
o There MUST be an Advertising Remote Router Tuple with AR_orig_addr
= TA_from_orig_addr.
o TA_dest_addr MUST be routable.
o TA_dest_addr MUST NOT overlap any network address in the
I_local_iface_addr_list in any Local Interface Tuple or overlap
the IR_local_iface_addr in any Removed Interface Address Tuple.
o TA_dest_addr MUST NOT include this router's originator address or
include the O_orig_addr in any Originator Tuple.
o TA_dest_addr MUST NOT equal or have as a sub-range the AL_net_addr
in any Local Attached Network Tuple.
o The ordered pair (TA_from_orig_addr, TA_dest_addr) MUST NOT equal
the corresponding pair for any other Attached Network Tuple.
o TA_seq_number MUST NOT be greater than AR_seq_number in the
Advertising Remote Router Tuple with AR_orig_addr =
TA_from_orig_addr.
o TA_metric MUST be representable in the defined compressed form.
In each Attached Network Tuple:
o There MUST be an Advertising Remote Router Tuple with AR_orig_addr
= AN_orig_addr.
o AN_net_addr MUST NOT equal or be a sub-range of any network
address in the I_local_iface_addr_list in any Local Interface
Tuple or be a sub-range of the IR_local_iface_addr in any Removed
Interface Address Tuple.
o AN_net_addr MUST NOT equal this router's originator address or
equal the O_orig_addr in any Originator Tuple.
o AN_net_addr MUST NOT equal the AL_net_addr in any Local Attached
Network Tuple.
o The ordered pair (AN_orig_addr, AN_net_addr) MUST NOT equal the
corresponding pair for any other Attached Network Tuple.
o AN_seq_number MUST NOT be greater than AR_seq_number in the
Advertising Remote Router Tuple with AR_orig_addr = AN_orig_addr.
o AN_dist MUST NOT be less than zero.
o AN_metric MUST be representable in the defined compressed form.
Appendix B. Example Algorithm for Calculating MPRs
The following specifies an algorithm which MAY be used to select an The following specifies an algorithm which MAY be used to select an
MPR Set given a Neighbor Graph, as defined in Section 18.2 and MPR Set given a Neighbor Graph, as defined in Section 18.2 and
Section 18.3. Section 18.3.
This algorithm selects an MPR Set M that is a subset of the set N1 This algorithm selects an MPR Set M that is a subset of the set N1
that is part of the Neighbor Graph. This algorithm assumes that a that is part of the Neighbor Graph. This algorithm assumes that a
subset I of N1 is pre-selected as MPRs, i.e., that M will contain I. subset I of N1 is pre-selected as MPRs, i.e., that M will contain I.
A.1. Additional Notation B.1. Additional Notation
The following additional notation, in addition to that in The following additional notation, in addition to that in
Section 18.2 will be used by this algorithm: Section 18.2 will be used by this algorithm:
N: N:
A subset of N2, consisting of those elements y in N2 such that A subset of N2, consisting of those elements y in N2 such that
either d1(y) is not defined, or there is at least one x in N1 such either d1(y) is not defined, or there is at least one x in N1 such
that d(x,y) is defined and d(x,y) < d1(y). that d(x,y) is defined and d(x,y) < d1(y).
D(x): D(x):
For an element x in N1, the number of elements y in N for which For an element x in N1, the number of elements y in N for which
d(x,y) is defined and has minimal value among the d(z,y) for all z d(x,y) is defined and has minimal value among the d(z,y) for all z
in N1. in N1.
R(x,M): R(x,M):
For an element x in N1, the number of elements y in N for which For an element x in N1, the number of elements y in N for which
d(x,y) is defined, has minimal value among the d(z,y) for all z in d(x,y) is defined, has minimal value among the d(z,y) for all z in
N1, and no such minimal values have z in M. (Note that, denoting N1, and no such minimal values have z in M. (Note that, denoting
the empty set by 0, D(x) = R(x,0).) the empty set by 0, D(x) = R(x,0).)
A.2. MPR Selection Algorithm B.2. MPR Selection Algorithm
To create the MPR Set M, starting with M := I: To create the MPR Set M, starting with M := I:
1. Add all elements x in N1 that have W(x) = WILL_ALWAYS to M. 1. Add all elements x in N1 that have W(x) = WILL_ALWAYS to M.
2. For each element y in N for which there is only one element x in 2. For each element y in N for which there is only one element x in
N1 such that d2(x,y) is defined, add that element x to M. N1 such that d2(x,y) is defined, add that element x to M.
3. While there exists any element x in N1 with R(x,M) > 0: 3. While there exists any element x in N1 with R(x,M) > 0:
skipping to change at page 94, line 33 skipping to change at page 100, line 39
information freshness, or MAY prefer a neighbor based on information freshness, or MAY prefer a neighbor based on
length of time previously selected as an MPR) or MAY be length of time previously selected as an MPR) or MAY be
random. random.
4. OPTIONAL: consider each element x in M, but not in I, in turn and 4. OPTIONAL: consider each element x in M, but not in I, in turn and
if x can be removed from M while still leaving it satisfying the if x can be removed from M while still leaving it satisfying the
definition of an MPR Set, then remove that element x from M. definition of an MPR Set, then remove that element x from M.
Elements MAY be considered in any order, e.g., in order of Elements MAY be considered in any order, e.g., in order of
increasing W(x). increasing W(x).
Appendix B. Example Algorithm for Calculating the Routing Set Appendix C. Example Algorithm for Calculating the Routing Set
The following procedure is given as an example for calculating the The following procedure is given as an example for calculating the
Routing Set using a variation of Dijkstra's algorithm. First all Routing Set using a variation of Dijkstra's algorithm. First all
Routing Tuples are removed, and then, using the selections and Routing Tuples are removed, and then, using the selections and
definitions in Appendix B.1, the procedures in the following sections definitions in Appendix C.1, the procedures in the following sections
(each considered a "stage" of the processing) are applied in turn. (each considered a "stage" of the processing) are applied in turn.
B.1. Local Interfaces and Neighbors C.1. Local Interfaces and Neighbors
The following selections and definitions are made: The following selections and definitions are made:
1. For each Local Interface Tuple, select a network address from its 1. For each Local Interface Tuple, select a network address from its
I_local_iface_addr_list, this is defined as the selected address I_local_iface_addr_list, this is defined as the selected address
for this Local Interface Tuple. for this Local Interface Tuple.
2. For each Link Tuple, the selected address of its corresponding 2. For each Link Tuple, the selected address of its corresponding
Local Interface Tuple is defined as the selected local address Local Interface Tuple is defined as the selected local address
for this Local Interface Tuple. for this Local Interface Tuple.
skipping to change at page 95, line 48 skipping to change at page 102, line 5
* For greater N_will_routing. * For greater N_will_routing.
* For N_mpr_selector = true over N_mpr_selector = false. * For N_mpr_selector = true over N_mpr_selector = false.
Note that preferred Routing Tuples SHOULD be used. Routing Note that preferred Routing Tuples SHOULD be used. Routing
Tuples with minimum R_metric MUST be used, this is specified Tuples with minimum R_metric MUST be used, this is specified
outside the definition of preference. An implementation MAY outside the definition of preference. An implementation MAY
modify this definition of preference (including for minimum modify this definition of preference (including for minimum
R_dist) without otherwise affecting this algorithm. R_dist) without otherwise affecting this algorithm.
B.2. Add Neighbor Routers C.2. Add Neighbor Routers
The following procedure is executed once. The following procedure is executed once.
1. For each Neighbor Tuple with N_symmetric = true and N_out_metric 1. For each Neighbor Tuple with N_symmetric = true and N_out_metric
!= UNKNOWN_METRIC, add a Routing Tuple with: != UNKNOWN_METRIC, add a Routing Tuple with:
* R_dest_addr := N_orig_addr; * R_dest_addr := N_orig_addr;
* R_next_iface_addr := selected link address for N_orig_addr; * R_next_iface_addr := selected link address for N_orig_addr;
* R_local_iface_addr := selected local address for N_orig_addr; * R_local_iface_addr := selected local address for N_orig_addr;
* R_metric := N_out_metric; * R_metric := N_out_metric;
* R_dist := 1. * R_dist := 1.
B.3. Add Remote Routers C.3. Add Remote Routers
The following procedure is executed once. The following procedure is executed once.
1. Add a label that may be "used" or "unused" to each Routing Tuple, 1. Add a label that may be "used" or "unused" to each Routing Tuple,
with all initial values equal to unused. (Note that this label with all initial values equal to unused. (Note that this label
is only required during this algorithm.) is only required during this algorithm.)
2. If there are no unused Routing Tuples then this stage is 2. If there are no unused Routing Tuples then this stage is
complete, otherwise repeat the following until that is the case. complete, otherwise repeat the following until that is the case.
skipping to change at page 97, line 30 skipping to change at page 103, line 37
- R_next_iface_addr := R_next_iface_addr of the current - R_next_iface_addr := R_next_iface_addr of the current
Routing Tuple; Routing Tuple;
- R_local_iface_addr := R_local_iface_addr of the - R_local_iface_addr := R_local_iface_addr of the
current Routing Tuple; current Routing Tuple;
- R_metric := new_metric; - R_metric := new_metric;
- R_dist := new_dist. - R_dist := new_dist.
B.4. Add Neighbor Addresses C.4. Add Neighbor Addresses
The following procedure is executed once. The following procedure is executed once.
1. For each Neighbor Tuple with N_symmetric = true and N_out_metric 1. For each Neighbor Tuple with N_symmetric = true and N_out_metric
!= UNKNOWN_METRIC: != UNKNOWN_METRIC:
1. For each network address (the "neighbor address") in 1. For each network address (the "neighbor address") in
N_neighbor_addr_list, if the neighbor address is not equal to N_neighbor_addr_list, if the neighbor address is not equal to
the R_dest_addr of any Routing Tuple, then add a new Routing the R_dest_addr of any Routing Tuple, then add a new Routing
Tuple, with: Tuple, with:
skipping to change at page 98, line 4 skipping to change at page 104, line 9
+ R_dest_addr := neighbor address; + R_dest_addr := neighbor address;
+ R_next_iface_addr := selected link address for the + R_next_iface_addr := selected link address for the
neighbor address; neighbor address;
+ R_local_iface_addr := selected local address for the + R_local_iface_addr := selected local address for the
neighbor address; neighbor address;
+ R_metric := N_out_metric; + R_metric := N_out_metric;
+ R_dist := 1. + R_dist := 1.
B.5. Add Remote Routable Addresses C.5. Add Remote Routable Addresses
The following procedure is executed once. The following procedure is executed once.
1. For each Routable Address Topology Tuple, if: 1. For each Routable Address Topology Tuple, if:
* TA_dest_addr is not equal to the R_dest_addr of any Routing * TA_dest_addr is not equal to the R_dest_addr of any Routing
Tuple added in an earlier stage; AND Tuple added in an earlier stage; AND
* TA_from_orig_addr is equal to the R_dest_addr of a Routing * TA_from_orig_addr is equal to the R_dest_addr of a Routing
Tuple (the "previous Routing Tuple"), Tuple (the "previous Routing Tuple"),
skipping to change at page 98, line 39 skipping to change at page 104, line 45
TA_metric. TA_metric.
* R_dist := R_dist of the previous Routing Tuple + 1. * R_dist := R_dist of the previous Routing Tuple + 1.
There may be more than one Routing Tuple that may be added for an There may be more than one Routing Tuple that may be added for an
R_dest_addr in this stage. If so, then, for each such R_dest_addr in this stage. If so, then, for each such
R_dest_addr, a Routing Tuple with minimum R_metric MUST be R_dest_addr, a Routing Tuple with minimum R_metric MUST be
selected, otherwise a Routing Tuple which is preferred SHOULD be selected, otherwise a Routing Tuple which is preferred SHOULD be
added. added.
B.6. Add Attached Networks C.6. Add Attached Networks
The following procedure is executed once. The following procedure is executed once.
1. For each Attached Network Tuple, if: 1. For each Attached Network Tuple, if:
* AN_net_addr is not equal to the R_dest_addr of any Routing * AN_net_addr is not equal to the R_dest_addr of any Routing
Tuple added in an earlier stage; AND Tuple added in an earlier stage; AND
* AN_orig_addr is equal to the R_dest_addr of a Routing Tuple * AN_orig_addr is equal to the R_dest_addr of a Routing Tuple
(the "previous Routing Tuple), (the "previous Routing Tuple),
skipping to change at page 99, line 24 skipping to change at page 105, line 29
AN_metric; AN_metric;
* R_dist := R_dist of the previous Routing Tuple + AN_dist. * R_dist := R_dist of the previous Routing Tuple + AN_dist.
There may be more than one Routing Tuple that may be added for an There may be more than one Routing Tuple that may be added for an
R_dest_addr in this stage. If so, then, for each such R_dest_addr in this stage. If so, then, for each such
R_dest_addr, a Routing Tuple with minimum R_metric MUST be R_dest_addr, a Routing Tuple with minimum R_metric MUST be
selected, otherwise a Routing Tuple which is preferred SHOULD be selected, otherwise a Routing Tuple which is preferred SHOULD be
added. added.
B.7. Add 2-Hop Neighbors C.7. Add 2-Hop Neighbors
The following procedure is executed once. The following procedure is executed once.
1. For each 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC, if: 1. For each 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC, if:
* N2_2hop_addr is a routable address; AND * N2_2hop_addr is a routable address; AND
* N2_2hop_addr is not equal to the R_dest_addr of any Routing * N2_2hop_addr is not equal to the R_dest_addr of any Routing
Tuple added in an earlier stage; AND Tuple added in an earlier stage; AND
skipping to change at page 100, line 13 skipping to change at page 106, line 16
N_out_metric of the corresponding Neighbor Tuple; N_out_metric of the corresponding Neighbor Tuple;
* R_dist := 2. * R_dist := 2.
There may be more than one Routing Tuple that may be added for an There may be more than one Routing Tuple that may be added for an
R_dest_addr in this stage. If so, then, for each such R_dest_addr in this stage. If so, then, for each such
R_dest_addr, a Routing Tuple with minimum R_metric MUST be R_dest_addr, a Routing Tuple with minimum R_metric MUST be
selected, otherwise a Routing Tuple which is preferred SHOULD be selected, otherwise a Routing Tuple which is preferred SHOULD be
added. added.
Appendix C. TC Message Example Appendix D. TC Message Example
TC messages are instances of [RFC5444] messages. This specification TC messages are instances of [RFC5444] messages. This specification
requires that TC messages contain <msg-hop-limit> and <msg-orig-addr> requires that TC messages contain <msg-hop-limit> and <msg-orig-addr>
fields. It supports TC messages with any combination of remaining fields. It supports TC messages with any combination of remaining
message header options and address encodings, enabled by [RFC5444] message header options and address encodings, enabled by [RFC5444]
that convey the required information. As a consequence, there is no that convey the required information. As a consequence, there is no
single way to represent how all TC messages look. This appendix single way to represent how all TC messages look. This appendix
illustrates a TC message, the exact values and content included are illustrates a TC message, the exact values and content included are
explained in the following text. explained in the following text.
skipping to change at page 102, line 47 skipping to change at page 108, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head | Tail Len = 2 | Pref Len = 16 | | Head | Tail Len = 2 | Pref Len = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address TLV Block Length = 9 | GATEWAY | ATLVF = 16 | | Address TLV Block Length = 9 | GATEWAY | ATLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Hops) | LINK_METRIC | ATLVF = 16 | | Value Len = 1 | Value (Hops) | LINK_METRIC | ATLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 2 |0|0|0|1| Metric | | Value Len = 2 |0|0|0|1| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix D. Constraints
Any process which updates the Local Information Base, the
Neighborhood Information Base or the Topology Information Base MUST
ensure that all constraints specified in this appendix are
maintained, as well as those specified in [RFC6130].
In each Originator Tuple:
o O_orig_addr MUST NOT equal any other O_orig_addr.
o O_orig_addr MUST NOT equal this router's originator address.
In each Local Attached Network Tuple:
o AL_net_addr MUST NOT equal any other AL_net_addr.
o AL_net_addr MUST NOT equal or be a sub-range of any network
address in the I_local_iface_addr_list of any Local Interface
Tuple.
o AL_net_addr MUST NOT equal this router's originator address, or
equal the O_orig_addr in any Originator Tuple.
o AL_dist MUST NOT be less than zero.
In each Link Tuple:
o L_neighbor_iface_addr_list MUST NOT contain any network address
that AL_net_addr of any Local Attached Network Tuple equals or is
a sub-range of.
o if L_in_metric != UNKNOWN_METRIC then L_in_metric MUST be
representable in the defined compressed form.
o if L_out_metric != UNKNOWN_METRIC then L_out_metric MUST be
representable in the defined compressed form.
o If L_mpr_selector = true, then L_status = SYMMETRIC.
In each Neighbor Tuple:
o N_orig_addr MUST NOT be changed to unknown.
o N_orig_addr MUST NOT equal this router's originator address, or
equal O_orig_addr in any Originator Tuple.
o N_orig_addr MUST NOT equal the AL_net_addr in any Local Attached
Network Tuple.
o If N_orig_addr != unknown, then N_orig_addr MUST NOT equal the
N_orig_addr in any other Neighbor Tuple.
o N_neighbor_addr_list MUST NOT contain any network address which
includes this router's originator address, the O_orig_addr in any
Originator Tuple, or equal or have as a sub-range the AL_net_addr
in any Local Attached Network Tuple.
o If N_orig_addr = unknown, then N_will_flooding = WILL_NEVER,
N_will_routing = WILL_NEVER, N_flooding_mpr, N_routing_mpr =
false, N_mpr_selector = false, and N_advertised = false.
o N_in_metric MUST equal the minimum value of the L_in_metric values
of all corresponding Link Tuples with L_status = SYMMETRIC and
L_in_metric != UNKNOWN_METRIC, if any, otherwise N_in_metric =
UNKNOWN_METRIC.
o N_out_metric MUST equal the minimum value of the L_out_metric
values of all corresponding Link Tuples with L_status = SYMMETRIC
and L_out_metric != UNKNOWN_METRIC, if any, otherwise N_out_metric
= UNKNOWN_METRIC.
o N_will_flooding and N_will_routing MUST be in the range from
WILL_NEVER to WILL_ALWAYS, inclusive.
o If N_flooding_mpr = true, then N_symmetric MUST be true,
N_out_metric MUST NOT equal UNKNOWN_METRIC and N_will_flooding
MUST NOT equal WILL_NEVER.
o If N_routing_mpr = true, then N_symmetric MUST be true,
N_in_metric MUST NOT equal UNKNOWN_METRIC and N_will_routing MUST
NOT equal WILL_NEVER.
o If N_symmetric = true and N_flooding_mpr = false, then
N_will_flooding MUST NOT equal WILL_ALWAYS.
o If N_symmetric = true and N_routing_mpr = false, then
N_will_routing MUST NOT equal WILL_ALWAYS.
o If N_mpr_selector = true, then N_advertised MUST be true.
o If N_advertised = true, then N_symmetric MUST be true and
N_out_metric MUST NOT equal UNKNOWN_METRIC.
In each Lost Neighbor Tuple:
o NL_neighbor_addr MUST NOT include this router's originator
address, the O_orig_addr in any Originator Tuple, or equal or have
as a sub-range the AL_net_addr in any Local Attached Network
Tuple.
In each 2-Hop Tuple:
o N2_2hop_addr MUST NOT equal this router's originator address,
equal the O_orig_addr in any Originator Tuple, or equal or have as
a sub-range the AL_net_addr in any Local Attached Network Tuple.
o if N2_in_metric != UNKNOWN_METRIC then N2_in_metric MUST be
representable in the defined compressed form.
o if N2_out_metric != UNKNOWN_METRIC then N2_out_metric MUST be
representable in the defined compressed form.
In each Advertising Remote Router Tuple:
o AR_orig_addr MUST NOT be in any network address in the
I_local_iface_addr_list in any Local Interface Tuple or be in the
IR_local_iface_addr in any Removed Interface Address Tuple.
o AR_orig_addr MUST NOT equal this router's originator address or
equal the O_orig_addr in any Originator Tuple.
o AR_orig_addr MUST NOT be in the AL_net_addr in any Local Attached
Network Tuple.
o AR_orig_addr MUST NOT equal the AR_orig_addr in any other
Advertising Remote Router Tuple.
In each Router Topology Tuple:
o There MUST be an Advertising Remote Router Tuple with AR_orig_addr
= TR_from_orig_addr.
o TR_to_orig_addr MUST NOT be in any network address in the
I_local_iface_addr_list in any Local Interface Tuple or be in the
IR_local_iface_addr in any Removed Interface Address Tuple.
o TR_to_orig_addr MUST NOT equal this router's originator address or
equal the O_orig_addr in any Originator Tuple.
o TR_to_orig_addr MUST NOT be in the AL_net_addr in any Local
Attached Network Tuple.
o The ordered pair (TR_from_orig_addr, TR_to_orig_addr) MUST NOT
equal the corresponding pair for any other Router Topology Tuple.
o TR_seq_number MUST NOT be greater than AR_seq_number in the
Advertising Remote Router Tuple with AR_orig_addr =
TR_from_orig_addr.
o TR_metric MUST be representable in the defined compressed form.
In each Routable Address Topology Tuple:
o There MUST be an Advertising Remote Router Tuple with AR_orig_addr
= TA_from_orig_addr.
o TA_dest_addr MUST be routable.
o TA_dest_addr MUST NOT overlap any network address in the
I_local_iface_addr_list in any Local Interface Tuple or overlap
the IR_local_iface_addr in any Removed Interface Address Tuple.
o TA_dest_addr MUST NOT include this router's originator address or
include the O_orig_addr in any Originator Tuple.
o TA_dest_addr MUST NOT equal or have as a sub-range the AL_net_addr
in any Local Attached Network Tuple.
o The ordered pair (TA_from_orig_addr, TA_dest_addr) MUST NOT equal
the corresponding pair for any other Attached Network Tuple.
o TA_seq_number MUST NOT be greater than AR_seq_number in the
Advertising Remote Router Tuple with AR_orig_addr =
TA_from_orig_addr.
o TA_metric MUST be representable in the defined compressed form.
In each Attached Network Tuple:
o There MUST be an Advertising Remote Router Tuple with AR_orig_addr
= AN_orig_addr.
o AN_net_addr MUST NOT equal or be a sub-range of any network
address in the I_local_iface_addr_list in any Local Interface
Tuple or be a sub-range of the IR_local_iface_addr in any Removed
Interface Address Tuple.
o AN_net_addr MUST NOT equal this router's originator address or
equal the O_orig_addr in any Originator Tuple.
o AN_net_addr MUST NOT equal the AL_net_addr in any Local Attached
Network Tuple.
o The ordered pair (AN_orig_addr, AN_net_addr) MUST NOT equal the
corresponding pair for any other Attached Network Tuple.
o AN_seq_number MUST NOT be greater than AR_seq_number in the
Advertising Remote Router Tuple with AR_orig_addr = AN_orig_addr.
o AN_dist MUST NOT be less than zero.
o AN_metric MUST be representable in the defined compressed form.
Appendix E. Flow and Congestion Control Appendix E. Flow and Congestion Control
Due to its proactive nature, this protocol has a natural control over Due to its proactive nature, this protocol has a natural control over
the flow of its control traffic. Routers transmit control messages the flow of its control traffic. Routers transmit control messages
at predetermined rates specified and bounded by message intervals. at predetermined rates specified and bounded by message intervals.
This protocol employs [RFC6130] for local signaling, embedding MPR This protocol employs [RFC6130] for local signaling, embedding MPR
selection advertisement through a simple Address Block TLV, and selection advertisement through a simple Address Block TLV, and
router willingness advertisement (if any) as a single Message TLV. router willingness advertisement (if any) as a single Message TLV.
Local signaling, therefore, shares the characteristics and Local signaling, therefore, shares the characteristics and
skipping to change at page 108, line 5 skipping to change at page 109, line 36
Since the control traffic is continuous and periodic, it keeps the Since the control traffic is continuous and periodic, it keeps the
quality of the links used in routing more stable. However, using quality of the links used in routing more stable. However, using
some options, some control messages (HELLO messages or TC messages) some options, some control messages (HELLO messages or TC messages)
may be intentionally sent in advance of their deadline in order to may be intentionally sent in advance of their deadline in order to
increase the responsiveness of the protocol to topology changes. increase the responsiveness of the protocol to topology changes.
This may cause a small, temporary, and local increase of control This may cause a small, temporary, and local increase of control
traffic, however this is at all times bounded by the use of minimum traffic, however this is at all times bounded by the use of minimum
message intervals. message intervals.
A router that recognizes that the network is suffering from
congestion can increase its message interval parameters. If this is
done by most or all routers in the network, then the overall control
traffic in the network will be reduced. Routers will have to take
care in using this capability not to increase message interval
parameters such that they cannot cope with network topology changes.
Note that routers can make such decisions independently, it is not
necessary for all routers to be using the same parameter values, nor
is it necessary that all routers decide to change their intervals at
the same time.
Authors' Addresses Authors' Addresses
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/ URI: http://www.ThomasClausen.org/
Christopher Dearlove Christopher Dearlove
 End of changes. 64 change blocks. 
395 lines changed or deleted 491 lines changed or added

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