draft-ietf-manet-olsrv2-06.txt   draft-ietf-manet-olsrv2-07.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France Internet-Draft LIX, Ecole Polytechnique, France
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: December 8, 2008 BAE Systems Advanced Technology Expires: January 11, 2009 BAE Systems Advanced Technology
Centre Centre
P. Jacquet P. Jacquet
Project Hipercom, INRIA Project Hipercom, INRIA
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
June 6, 2008 July 10, 2008
The Optimized Link State Routing Protocol version 2 The Optimized Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-06 draft-ietf-manet-olsrv2-07
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 8, 2008. This Internet-Draft will expire on January 11, 2009.
Abstract Abstract
This document describes version 2 of the Optimized Link State Routing This document describes version 2 of the Optimized Link State Routing
(OLSRv2) protocol. The protocol embodies an optimization of the (OLSRv2) protocol. The protocol embodies an optimization of the
classical link state algorithm tailored to the requirements of a classical link state algorithm tailored to the requirements of a
Mobile Ad hoc NETwork (MANET). Mobile Ad hoc NETwork (MANET).
The key optimization in OLSRv2 is that of multipoint relays (MPRs), The key optimization in OLSRv2 is that of multipoint relays (MPRs),
providing an efficient mechanism for network-wide broadcast of link providing an efficient mechanism for network-wide broadcast of link
skipping to change at page 3, line 26 skipping to change at page 3, line 26
7. Packet Processing and Message Forwarding . . . . . . . . . . . 26 7. Packet Processing and Message Forwarding . . . . . . . . . . . 26
7.1. Actions when Receiving an OLSRv2 Packet . . . . . . . . . 26 7.1. Actions when Receiving an OLSRv2 Packet . . . . . . . . . 26
7.2. Actions when Receiving an OLSRv2 Message . . . . . . . . . 26 7.2. Actions when Receiving an OLSRv2 Message . . . . . . . . . 26
7.3. Message Considered for Processing . . . . . . . . . . . . 27 7.3. Message Considered for Processing . . . . . . . . . . . . 27
7.4. Message Considered for Forwarding . . . . . . . . . . . . 28 7.4. Message Considered for Forwarding . . . . . . . . . . . . 28
8. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 31 8. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 31
8.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 31 8.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 31
8.1.1. HELLO Message TLVs . . . . . . . . . . . . . . . . . . 32 8.1.1. HELLO Message TLVs . . . . . . . . . . . . . . . . . . 32
8.1.2. HELLO Message Address Block TLVs . . . . . . . . . . . 32 8.1.2. HELLO Message Address Block TLVs . . . . . . . . . . . 32
8.2. TC Messages . . . . . . . . . . . . . . . . . . . . . . . 32 8.2. TC Messages . . . . . . . . . . . . . . . . . . . . . . . 32
8.2.1. TC Message TLVs . . . . . . . . . . . . . . . . . . . 34 8.2.1. TC Message TLVs . . . . . . . . . . . . . . . . . . . 33
8.2.2. TC Message Address Block TLVs . . . . . . . . . . . . 34 8.2.2. TC Message Address Block TLVs . . . . . . . . . . . . 34
9. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 35 9. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 35
9.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 35 9.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 35
10. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 36 10. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 36
10.1. Updating Willingness . . . . . . . . . . . . . . . . . . . 36 10.1. Updating Willingness . . . . . . . . . . . . . . . . . . . 36
10.2. Updating MPR Selectors . . . . . . . . . . . . . . . . . . 36 10.2. Updating MPR Selectors . . . . . . . . . . . . . . . . . . 36
10.3. Symmetric 1-Hop and 2-Hop Neighborhood Changes . . . . . . 36 10.3. Symmetric 1-Hop and 2-Hop Neighborhood Changes . . . . . . 36
11. TC Message Generation . . . . . . . . . . . . . . . . . . . . 38 11. TC Message Generation . . . . . . . . . . . . . . . . . . . . 38
11.1. TC Message: Transmission . . . . . . . . . . . . . . . . . 39 11.1. TC Message: Transmission . . . . . . . . . . . . . . . . . 39
12. TC Message Processing . . . . . . . . . . . . . . . . . . . . 40 12. TC Message Processing . . . . . . . . . . . . . . . . . . . . 40
skipping to change at page 4, line 20 skipping to change at page 4, line 20
17.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . . 51 17.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . . 51
17.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 51 17.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 51
17.7. Willingness Parameter and Constants . . . . . . . . . . . 52 17.7. Willingness Parameter and Constants . . . . . . . . . . . 52
18. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 53 18. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 53
19. Security Considerations . . . . . . . . . . . . . . . . . . . 54 19. Security Considerations . . . . . . . . . . . . . . . . . . . 54
19.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 54 19.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 54
19.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 54 19.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 54
19.3. Interaction with External Routing Domains . . . . . . . . 55 19.3. Interaction with External Routing Domains . . . . . . . . 55
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
20.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 57 20.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 57
20.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 57 20.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 57
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 20.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 58
21.1. Normative References . . . . . . . . . . . . . . . . . . . 59 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
21.2. Informative References . . . . . . . . . . . . . . . . . . 59 21.1. Normative References . . . . . . . . . . . . . . . . . . . 60
Appendix A. Node Configuration . . . . . . . . . . . . . . . . . 61 21.2. Informative References . . . . . . . . . . . . . . . . . . 60
Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 62 Appendix A. Node Configuration . . . . . . . . . . . . . . . . . 62
B.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 62 Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 63
B.2. MPR Selection Algorithm for each OLSRv2 Interface . . . . 63 B.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 63
Appendix C. Example Algorithm for Calculating the Routing Set . . 64 B.2. MPR Selection Algorithm for each OLSRv2 Interface . . . . 64
C.1. Add Local Symmetric Links . . . . . . . . . . . . . . . . 64 Appendix C. Example Algorithm for Calculating the Routing Set . . 65
C.2. Add Remote Symmetric Links . . . . . . . . . . . . . . . . 65 C.1. Add Local Symmetric Links . . . . . . . . . . . . . . . . 65
C.3. Add Attached Networks . . . . . . . . . . . . . . . . . . 66 C.2. Add Remote Symmetric Links . . . . . . . . . . . . . . . . 66
Appendix D. Example Message Layout . . . . . . . . . . . . . . . 67 C.3. Add Attached Networks . . . . . . . . . . . . . . . . . . 67
Appendix E. Constraints . . . . . . . . . . . . . . . . . . . . . 69 Appendix D. Example Message Layout . . . . . . . . . . . . . . . 68
Appendix F. Flow and Congestion Control . . . . . . . . . . . . . 73 Appendix E. Constraints . . . . . . . . . . . . . . . . . . . . . 70
Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 74 Appendix F. Flow and Congestion Control . . . . . . . . . . . . . 74
Appendix H. Acknowledgements . . . . . . . . . . . . . . . . . . 75 Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 75
Appendix H. Acknowledgements . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
The Optimized Link State Routing protocol version 2 (OLSRv2) is an The Optimized Link State Routing protocol version 2 (OLSRv2) is an
update to OLSRv1 as published in [RFC3626]. Compared to RFC3626, update to OLSRv1 as published in [RFC3626]. Compared to RFC3626,
OLSRv2 retains the same basic mechanisms and algorithms, while OLSRv2 retains the same basic mechanisms and algorithms, while
providing a more flexible signaling framework and some simplification providing a more flexible signaling framework and some simplification
of the messages being exchanged. Also, OLSRv2 accommodates either of the messages being exchanged. Also, OLSRv2 accommodates either
IPv4 and IPv6 addresses in a compact manner. IPv4 and IPv6 addresses in a compact manner.
skipping to change at page 6, line 8 skipping to change at page 6, line 8
OLSRv2 may use link layer information and notifications when OLSRv2 may use link layer information and notifications when
available and applicable, as described in [nhdp]. available and applicable, as described in [nhdp].
OLSRv2, as OLSRv1, inherits its concept of forwarding and relaying OLSRv2, as OLSRv1, inherits its concept of forwarding and relaying
from HIPERLAN (a MAC layer protocol) which is standardized by ETSI from HIPERLAN (a MAC layer protocol) which is standardized by ETSI
[HIPERLAN], [HIPERLAN2]. [HIPERLAN], [HIPERLAN2].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
MANET specific terminology is to be interpreted as described in MANET specific terminology is to be interpreted as described in
[packetbb] and [nhdp]. [packetbb] and [nhdp].
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Node - A MANET router which implements the Optimized Link State Node - A MANET router which implements the Optimized Link State
Routing protocol version 2 as specified in this document. Routing protocol version 2 as specified in this document.
OLSRv2 interface - A MANET interface, running OLSRv2. Note that all OLSRv2 interface - A MANET interface, running OLSRv2. Note that all
skipping to change at page 10, line 5 skipping to change at page 9, line 7
Information Bases describing the node's 1-hop and symmetric 2-hop Information Bases describing the node's 1-hop and symmetric 2-hop
neighbors. This neighborhood discovery protocol, which also uses neighbors. This neighborhood discovery protocol, which also uses
[packetbb], is extended in this document by the addition of MPR [packetbb], is extended in this document by the addition of MPR
information. information.
OLSRv2 does not make any assumption about node addresses, other than OLSRv2 does not make any assumption about node addresses, other than
that each node is assumed to have at least one unique and routable IP that each node is assumed to have at least one unique and routable IP
address for each interface that it has which participates in the address for each interface that it has which participates in the
MANET. MANET.
OLSRv2 can, as does [nhdp], use the link local multicast address "LL-
MANET-Routers", and either the "manet" UDP port or the "manet" IP
protocol number, all as specified in [manet-iana].
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
OLSRv2 is a proactive routing protocol for mobile ad hoc networks. OLSRv2 is a proactive routing protocol for mobile ad hoc networks.
The protocol inherits the stability of a link state algorithm and has The protocol inherits the stability of a link state algorithm and has
the advantage of having routes immediately available when needed due the advantage of having routes immediately available when needed due
to its proactive nature. OLSRv2 is an optimization of the classical to its proactive nature. OLSRv2 is an optimization of the classical
link state protocol, tailored for mobile ad hoc networks. The main link state protocol, tailored for mobile ad hoc networks. The main
tailoring and optimizations of OLSRv2 are: tailoring and optimizations of OLSRv2 are:
o Unacknowledged transmission of all control messages; control o Unacknowledged transmission of all control messages; control
skipping to change at page 27, line 11 skipping to change at page 27, line 11
Originator Tuple) then the message MUST be silently discarded. Originator Tuple) then the message MUST be silently discarded.
2. Otherwise: 2. Otherwise:
1. If the message is a HELLO message, then the message is 1. If the message is a HELLO message, then the message is
processed according to Section 10. processed according to Section 10.
2. Otherwise: 2. Otherwise:
1. Define the "dependent message type" of the message to 1. Define the "dependent message type" of the message to
equal the message type if the mistypedep bit of the equal the message type if the mistypedep flag bit in the
message semantics octet in the message header is set message header is set ('1'), or otherwise to equal a
('1'), or to equal 0 otherwise. value "type-independent" which is not in the range 0 to
255.
2. If the message is of a known type, including being a TC 2. If the message is of a known type, including being a TC
message, then the message is considered for processing message, then the message is considered for processing
according to Section 7.3, AND; according to Section 7.3, AND;
3. If for the message: 3. If for the message:
- <hop-limit> is present and <hop-limit> > 1, AND; - <hop-limit> is present and <hop-limit> > 1, AND;
- <hop-count> is not present or <hop-count> < 255 - <hop-count> is not present or <hop-count> < 255
skipping to change at page 31, line 28 skipping to change at page 31, line 28
o OLSRv2 packets MAY include packet TLVs, however OLSRv2 itself does o OLSRv2 packets MAY include packet TLVs, however OLSRv2 itself does
not specify any packet TLVs. not specify any packet TLVs.
o All references in this specification to TLVs that do not indicate o All references in this specification to TLVs that do not indicate
a type extension, assume Type Extension == 0. TLVs in processed a type extension, assume Type Extension == 0. TLVs in processed
messages with a type extension which is neither zero as so messages with a type extension which is neither zero as so
assumed, nor a specifically indicated non-zero type extension, are assumed, nor a specifically indicated non-zero type extension, are
ignored. ignored.
Other options defined in [packetbb] may be freely used, in particular Other options defined in [packetbb] may be freely used, in particular
any other values of <pkt-semantics>, <msg-semantics>, <addr- any other values of <pkt-flags>, <msg-flags>, <addr-flags> or <tlv-
semantics> or <tlv-semantics> consistent with their specifications. flags> consistent with their specifications.
The remainder of this section defines, within the framework of The remainder of this section defines, within the framework of
[packetbb], message types and TLVs specific to OLSRv2. [packetbb], message types and TLVs specific to OLSRv2.
8.1. HELLO Messages 8.1. HELLO Messages
A HELLO message in OLSRv2 is generated as specified in [nhdp]. A HELLO message in OLSRv2 is generated as specified in [nhdp].
Additionally, an OLSRv2 node: Additionally, an OLSRv2 node:
o MUST include TLV(s) with Type == MPR associated with all OLSRv2 o MUST include TLV(s) with Type == MPR associated with all OLSRv2
skipping to change at page 32, line 15 skipping to change at page 32, line 15
o MAY include a message TLV with Type == MPR_WILLING, indicating the o MAY include a message TLV with Type == MPR_WILLING, indicating the
node's willingness to be selected as an MPR. node's willingness to be selected as an MPR.
8.1.1. HELLO Message TLVs 8.1.1. HELLO Message TLVs
In a HELLO message, a node MUST include an MPR_WILLING message TLV as In a HELLO message, a node MUST include an MPR_WILLING message TLV as
specified in Table 1, unless WILLINGNESS == WILL_DEFAULT (in which specified in Table 1, unless WILLINGNESS == WILL_DEFAULT (in which
case it MAY be included). A node MUST NOT include more than one case it MAY be included). A node MUST NOT include more than one
MPR_WILLING message TLV. MPR_WILLING message TLV.
+-------------+--------+--------------------------------------------+ +-------------+--------------+--------------------------------------+
| Type | Value | Value | | Type | Value Length | Value |
| | Length | | +-------------+--------------+--------------------------------------+
+-------------+--------+--------------------------------------------+ | MPR_WILLING | 1 octet | Node parameter WILLINGNESS; unused |
| MPR_WILLING | 8 bits | Node parameter WILLINGNESS; unused bits | | | | bits (based on the maximum |
| | | (based on the maximum willingness value | | | | willingness value WILL_ALWAYS) are |
| | | WILL_ALWAYS) are RESERVED and SHOULD be | | | | RESERVED and SHOULD be set to zero. |
| | | set to zero. | +-------------+--------------+--------------------------------------+
+-------------+--------+--------------------------------------------+
Table 1 Table 1
If a node does not advertise an MPR_WILLING TLV in a HELLO message, If a node does not advertise an MPR_WILLING TLV in a HELLO message,
then the node MUST be assumed to have WILLINGNESS equal to then the node MUST be assumed to have WILLINGNESS equal to
WILL_DEFAULT. WILL_DEFAULT.
8.1.2. HELLO Message Address Block TLVs 8.1.2. HELLO Message Address Block TLVs
In a HELLO message, a node MAY include MPR address block TLV(s) as In a HELLO message, a node MAY include MPR address block TLV(s) as
specified in Table 2. specified in Table 2.
+------+--------------+-------+ +------+--------------+-------+
| Type | Value Length | Value | | Type | Value Length | Value |
+------+--------------+-------+ +------+--------------+-------+
| MPR | 0 bits | None. | | MPR | 0 octets | None. |
+------+--------------+-------+ +------+--------------+-------+
Table 2 Table 2
8.2. TC Messages 8.2. TC Messages
A TC message MUST contain: A TC message MUST contain:
o <msg-orig-addr>, <msg-seq-num> and <msg-hop-limit> elements in its o <msg-orig-addr>, <msg-seq-num> and <msg-hop-limit> elements in its
message header, as specified in [packetbb]. message header, as specified in [packetbb].
skipping to change at page 33, line 35 skipping to change at page 33, line 34
message's address blocks. message's address blocks.
o TLV(s) with Type == LOCAL_IF and Value == UNSPEC_IF associated o TLV(s) with Type == LOCAL_IF and Value == UNSPEC_IF associated
with all of the node's interface addresses. with all of the node's interface addresses.
o If the TC message is complete, all addresses in the Advertised o If the TC message is complete, all addresses in the Advertised
Address Set and all addresses in the Local Attached Network Set, Address Set and all addresses in the Local Attached Network Set,
the latter (only) with associated GATEWAY address block TLV(s), as the latter (only) with associated GATEWAY address block TLV(s), as
specified in Section 8.2.2. specified in Section 8.2.2.
A TC message SHOULD have the mistypedep bit of <msg-semantics>, as A TC message SHOULD have the mistypedep bit of <msg-flags>, as
defined in [packetbb], cleared ('0'). defined in [packetbb], cleared ('0').
A TC message MAY contain: A TC message MAY contain:
o If the TC message is incomplete, any addresses in the Advertised o If the TC message is incomplete, any addresses in the Advertised
Address Set and any addresses in the Local Attached Network Set, Address Set and any addresses in the Local Attached Network Set,
the latter (only) with associated GATEWAY address block TLV(s), as the latter (only) with associated GATEWAY address block TLV(s), as
specified in Section 8.2.2. specified in Section 8.2.2.
o A message TLV with Type == INTERVAL_TIME, as specified in o A message TLV with Type == INTERVAL_TIME, as specified in
[timetlv]. The options included in [timetlv] for representing [timetlv]. The options included in [timetlv] for representing
zero and infinite times MUST NOT be used. zero and infinite times MUST NOT be used.
8.2.1. TC Message TLVs 8.2.1. TC Message TLVs
In a TC message, a node MUST include a single CONT_SEQ_NUM message In a TC message, a node MUST include a single CONT_SEQ_NUM message
TLV, as specified in Table 3, and with Type Extension == COMPLETE or TLV, as specified in Table 3, and with Type Extension == COMPLETE or
Type Extension == INCOMPLETE, according to whether the TC message is Type Extension == INCOMPLETE, according to whether the TC message is
complete or incomplete. complete or incomplete.
+--------------+------------+---------------------------------------+ +--------------+--------------+-------------------------------------+
| Type | Value | Value | | Type | Value Length | Value |
| | Length | | +--------------+--------------+-------------------------------------+
+--------------+------------+---------------------------------------+ | CONT_SEQ_NUM | 1 octet | The ANSN contained in the |
| CONT_SEQ_NUM | 8 bits | The ANSN contained in the Advertised | | | | Advertised Neighbor Set. |
| | | Neighbor Set. | +--------------+--------------+-------------------------------------+
+--------------+------------+---------------------------------------+
Table 3 Table 3
8.2.2. TC Message Address Block TLVs 8.2.2. TC Message Address Block TLVs
In a TC message, a node MAY include GATEWAY address block TLV(s) as In a TC message, a node MAY include GATEWAY address block TLV(s) as
specified in Table 4. specified in Table 4.
+---------+--------------+-------------------------------------+ +---------+--------------+-------------------------------------+
| Type | Value Length | Value | | Type | Value Length | Value |
+---------+--------------+-------------------------------------+ +---------+--------------+-------------------------------------+
| GATEWAY | 8 bits | Number of hops to attached network. | | GATEWAY | 1 octet | Number of hops to attached network. |
+---------+--------------+-------------------------------------+ +---------+--------------+-------------------------------------+
Table 4 Table 4
GATEWAY address block TLV(s) MUST be associated with all attached GATEWAY address block TLV(s) MUST be associated with all attached
network addresses, and MUST NOT be associated with any other network addresses, and MUST NOT be associated with any other
addresses. addresses.
9. HELLO Message Generation 9. HELLO Message Generation
skipping to change at page 57, line 9 skipping to change at page 57, line 9
domain to an OLSRv2 routed MANET is to assign an IP prefix (under the domain to an OLSRv2 routed MANET is to assign an IP prefix (under the
authority of the nodes/gateways connecting the MANET with the exiting authority of the nodes/gateways connecting the MANET with the exiting
routing domain) exclusively to the OLSRv2 MANET area, and to routing domain) exclusively to the OLSRv2 MANET area, and to
configure the gateways statically to advertise routes to that IP configure the gateways statically to advertise routes to that IP
sequence to nodes in the existing routing domain. sequence to nodes in the existing routing domain.
20. IANA Considerations 20. IANA Considerations
20.1. Message Types 20.1. Message Types
OLSRv2 defines one message type, which must be allocated from the This specification defines one message type, to be allocated from the
"Assigned Message Types" repository of [packetbb]. 0-223 range of the "Message Types" namespace defined in [packetbb],
as specified in Table 5.
+------+------+-----------------------------------------+ +------+------+-----------------------------------------+
| Name | Type | Description | | Name | Type | Description |
+------+------+-----------------------------------------+ +------+------+-----------------------------------------+
| TC | TBD1 | Topology Control (MANET-wide signaling) | | TC | TBD1 | Topology Control (MANET-wide signaling) |
+------+------+-----------------------------------------+ +------+------+-----------------------------------------+
Table 5 Table 5
20.2. TLV Types 20.2. Message TLV Types
OLSRv2 defines two message TLV types, which must be allocated from This specification defines two message TLV types, which must be
the "Assigned message TLV Types" repository of [packetbb]. allocated from the "Message TLV Types" namespace defined in
[packetbb]. IANA are requested to make allocations in the 8-127
range for these types. This will create two new type extension
registries with assignments as specified in Table 6 and Table 7.
Specifications of these TLVs are in Section 8.1.1 and Section 8.2.1.
+-------------+------+-----------+----------------------------------+
| Name | Type | Type | Description |
| | | extension | |
+-------------+------+-----------+----------------------------------+
| MPR_WILLING | TBD2 | 0 | Specifies the originating node's |
| | | | willingness to act as a relay |
| | | | and to partake in network |
| | | | formation |
| | | | |
| | | 1-255 | Expert Review |
+-------------+------+-----------+----------------------------------+
Table 6
+--------------+------+----------------+----------------------------+ +--------------+------+----------------+----------------------------+
| Name | Type | Type extension | Description | | Name | Type | Type extension | Description |
+--------------+------+----------------+----------------------------+ +--------------+------+----------------+----------------------------+
| MPR_WILLING | TBD2 | 0 | Specifies the originating |
| | | | node's willingness to act |
| | | | as a relay and to partake |
| | | | in network formation |
| | | | |
| | | 1-255 | RESERVED |
| | | | |
| CONT_SEQ_NUM | TBD3 | 0 (COMPLETE) | Specifies a content | | CONT_SEQ_NUM | TBD3 | 0 (COMPLETE) | Specifies a content |
| | | | sequence number for this | | | | | sequence number for this |
| | | | complete message | | | | | complete message |
| | | | | | | | | |
| | | 1 (INCOMPLETE) | Specifies a content | | | | 1 (INCOMPLETE) | Specifies a content |
| | | | sequence number for this | | | | | sequence number for this |
| | | | incomplete message | | | | | incomplete message |
| | | | | | | | | |
| | | 2-255 | RESERVED | | | | 2-255 | Expert Review |
+--------------+------+----------------+----------------------------+ +--------------+------+----------------+----------------------------+
Table 6 Table 7
Type extensions indicated as RESERVED may be allocated by standards Type extensions indicated as Expert Review SHOULD be allocated as
action, as specified in [RFC2434]. described in [packetbb], based on Expert Review as defined in
[RFC5226].
OLSRv2 defines two Address Block TLV types, which must be allocated 20.3. Address Block TLV Types
from the "Assigned address block TLV Types" repository of [packetbb].
This specification defines two address block TLV types, which must be
allocated from the "Address Block TLV Types" namespace defined in
[packetbb]. IANA are requested to make allocations in the 8-127
range for these types. This will create two new type extension
registries with assignments as specified in Table 8 and Table 9.
Specifications of these TLVs are in Section 8.1.2 and Section 8.2.2.
+------+------+-----------+-----------------------------------------+
| Name | Type | Type | Description |
| | | extension | |
+------+------+-----------+-----------------------------------------+
| MPR | TBD4 | 0 | Specifies that a given address is of a |
| | | | node selected as an MPR |
| | | | |
| | | 1-255 | Expert Review |
+------+------+-----------+-----------------------------------------+
Table 8
+---------+------+-----------+--------------------------------------+ +---------+------+-----------+--------------------------------------+
| Name | Type | Type | Description | | Name | Type | Type | Description |
| | | extension | | | | | extension | |
+---------+------+-----------+--------------------------------------+ +---------+------+-----------+--------------------------------------+
| MPR | TBD4 | 0 | Specifies that a given address is of |
| | | | a node selected as an MPR |
| | | | |
| | | 1-255 | RESERVED |
| | | | |
| GATEWAY | TBD5 | 0 | Specifies that a given address is | | GATEWAY | TBD5 | 0 | Specifies that a given address is |
| | | | reached via a gateway on the | | | | | reached via a gateway on the |
| | | | originating node | | | | | originating node |
| | | | | | | | | |
| | | 1-255 | RESERVED | | | | 1-255 | Expert Review |
+---------+------+-----------+--------------------------------------+ +---------+------+-----------+--------------------------------------+
Table 7 Table 9
Type extensions indicated as RESERVED may be allocated by standards Type extensions indicated as Expert Review SHOULD be allocated as
action, as specified in [RFC2434]. described in [packetbb], based on Expert Review as defined in
[RFC5226].
21. References 21. References
21.1. Normative References 21.1. Normative References
[packetbb] Clausen, T., Dean, J., Dearlove, C., and C. Adjih, [packetbb] Clausen, T., Dean, J., Dearlove, C., and C. Adjih,
"Generalized MANET Packet/Message Format", work in "Generalized MANET Packet/Message Format", work in
progress draft-ietf-manet-packetbb-12.txt, March 2008. progress draft-ietf-manet-packetbb-13.txt, June 2008.
[timetlv] Clausen, T. and C. Dearlove, "Representing multi-value [timetlv] Clausen, T. and C. Dearlove, "Representing multi-value
time in MANETs", Work In time in MANETs", Work In
Progress draft-ietf-manet-timetlv-04.txt, November 2007. Progress draft-ietf-manet-timetlv-05.txt, July 2008.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
considerations in MANETs", RFC 5148, February 2008. considerations in MANETs", RFC 5148, February 2008.
[nhdp] Clausen, T., Dean, J., and C. Dearlove, "MANET [nhdp] Clausen, T., Dean, J., and C. Dearlove, "MANET
Neighborhood Discovery Protocol (NHDP)", work in Neighborhood Discovery Protocol (NHDP)", work in
progress draft-ietf-manet-nhdp-06.txt, March 2008. progress draft-ietf-manet-nhdp-07.txt, July 2008.
[manet-iana] Chakeres, I., "IANA Allocations for MANET Protocols",
Work In Progress draft-ietf-manet-iana-07.txt,
November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", RFC 2434, BCP 26, an IANA Considerations Section in RFCs", RFC 5226,
October 1998. BCP 26, May 2008.
21.2. Informative References 21.2. Informative References
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, [RFC4880] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP message format", RFC 4880, November 2007. "OpenPGP message format", RFC 4880, November 2007.
[HIPERLAN] ETSI, "ETSI STC-RES10 Committee. Radio equipment and [HIPERLAN] ETSI, "ETSI STC-RES10 Committee. Radio equipment and
systems: HIPERLAN type 1, functional specifications ETS systems: HIPERLAN type 1, functional specifications ETS
300-652", June 1996. 300-652", June 1996.
[HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N. [HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N.
Rivierre, "Increasing reliability in cable free radio Rivierre, "Increasing reliability in cable free radio
LANs: Low level forwarding in HIPERLAN.", 1996. LANs: Low level forwarding in HIPERLAN.", 1996.
[MPR] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint [MPR] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint
relaying: An efficient technique for flooding in mobile relaying: An efficient technique for flooding in mobile
wireless networks.", 2001. wireless networks.", 2001.
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999.
[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. Node Configuration Appendix A. Node Configuration
OLSRv2 does not make any assumption about node addresses, other than OLSRv2 does not make any assumption about node addresses, other than
skipping to change at page 67, line 10 skipping to change at page 68, line 10
+ R_dist = (R_dist of the previous Routing Tuple) + AN_dist; + R_dist = (R_dist of the previous Routing Tuple) + AN_dist;
+ R_local_iface_addr = R_local_iface_addr of the previous + R_local_iface_addr = R_local_iface_addr of the previous
Routing Tuple. Routing Tuple.
Appendix D. Example Message Layout Appendix D. Example Message Layout
An example TC message, using IPv4 (four octet) addresses, is as An example TC message, using IPv4 (four octet) addresses, is as
follows. The overall message length is 65 octets. follows. The overall message length is 65 octets.
The message has semantics octet 30, and hence all required message The message has flags octet value 240, and hence a complete message
header fields. It has a message TLV block with content length 13 header. It has a message TLV block with content length 13 octets
octets containing three TLVs. The first two TLVs are validity and containing three TLVs. The first two TLVs are validity and interval
interval times for the message. The third TLV is the content times for the message. The third TLV is the content sequence number
sequence number TLV used to carry the 2 octet ANSN, and (with default TLV used to carry the 2 octet ANSN, and (with default type extension
type extension zero, i.e. COMPLETE) indicating that the TC message zero, i.e. COMPLETE) indicating that the TC message is complete.
is complete. Each TLV uses a TLV with semantics value 8, indicating Each TLV uses a TLV with flags octet value 16, indicating that it has
that it has a value, but no type extension or start and stop indexes. a value, but no type extension or start and stop indexes. The first
The first two TLVs have a value length of 1 octet, the last has a two TLVs have a value length of 1 octet, the last has a value length
value length of 2 octets. of 2 octets.
The message has two address blocks. The first address block contains The message has two address blocks. The first address block contains
6 addresses, with semantics octet 1, hence with a head section, (with 6 addresses, with flags octet value 128, hence with a head section,
length 2 octets) but no tail section, and hence mid sections with (with length 2 octets) but no tail section, and hence mid sections
length two octets. The following TLV block (content length 6 octets) with length two octets. The following TLV block (content length 6
contains a single LOCAL_IF TLV (semantics value 12) indicating that octets) contains a single LOCAL_IF TLV (flags octet value 48)
the first three addresses (indexes 0 to 2) are associated with the indicating that the first three addresses (indexes 0 to 2) are
value (length 1 octet) UNSPEC_IF, i.e. they are the originating associated with the value (length 1 octet) UNSPEC_IF, i.e. they are
node's local interface addresses. The remaining three addresses have the originating node's local interface addresses. The remaining
no associated TLV, they are the interface addresses of advertised three addresses have no associated TLV, they are the interface
neighbors. addresses of advertised neighbors.
The second address block contains 1 address, with semantics octet 13 The second address block contains 1 address, with flags octet 176
indicating that there is a head section (with length 2 octets), that indicating that there is a head section (with length 2 octets), that
the tail section (length 2 octets) consists of zero valued octets the tail section (length 2 octets) consists of zero valued octets
(not included), and that there is a single prefix length, which is (not included), and that there is a single prefix length, which is
16. The network address is thus Head.0.0/16. The following TLV 16. The network address is thus Head.0.0/16. The following TLV
block (content length 8 octets) includes one TLV that indicates that block (content length 8 octets) includes one TLV that indicates that
the originating node is a gateway to this network, at a given number the originating node is a gateway to this network, at a given number
of hops distance (value length 1 octet). The TLV semantics value of of hops distance (value length 1 octet). The TLV flags octet value
8 indicates that no indexes are needed. of 16 indicates that no indexes are needed.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TC |0 0 0 1 1 1 1 0|0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1| | TC |1 1 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number | | Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1| VALIDITY_TIME |0 0 0 0 1 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1| VALIDITY_TIME |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Value | INTERVAL_TIME |0 0 0 0 1 0 0 0| |0 0 0 0 0 0 0 1| Value | INTERVAL_TIME |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Value | CONT_SEQ_NUM |0 0 0 0 1 0 0 0| |0 0 0 0 0 0 0 1| Value | CONT_SEQ_NUM |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Value (ANSN) |0 0 0 0 0 1 1 0| |0 0 0 0 0 0 1 0| Value (ANSN) |0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0| Head | |1 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Mid | | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Mid | | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Mid | | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0| LOCAL_IF |0 0 0 0 1 1 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0| LOCAL_IF |0 0 1 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1| UNSPEC_IF | |0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1| UNSPEC_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 1 1 0 1|0 0 0 0 0 0 1 0| Head | |0 0 0 0 0 0 0 1|1 0 1 1 0 0 0 0|0 0 0 0 0 0 1 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) |0 0 0 0 0 0 1 0|0 0 0 1 0 0 0 0|0 0 0 0 0 0 0 0| | Head (cont) |0 0 0 0 0 0 1 0|0 0 0 1 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| GATEWAY |0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 1| |0 0 0 0 0 1 0 0| GATEWAY |0 0 0 1 0 0 0 0|0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Hops | | Number Hops |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Appendix E. Constraints Appendix E. Constraints
Any process which updates the Local Information Base, the Any process which updates the Local Information Base, the
Neighborhood Information Base or the Topology Information Base MUST Neighborhood Information Base or the Topology Information Base MUST
ensure that all constraints specified in this appendix are ensure that all constraints specified in this appendix are
maintained, as well as those specified in [nhdp]. maintained, as well as those specified in [nhdp].
skipping to change at page 75, line 14 skipping to change at page 76, line 14
Appendix H. Acknowledgements Appendix H. Acknowledgements
The authors would like to acknowledge the team behind OLSRv1, The authors would like to acknowledge the team behind OLSRv1,
specified in RFC3626, including Anis Laouiti (INT, Paris), Pascale specified in RFC3626, including Anis Laouiti (INT, Paris), Pascale
Minet (INRIA, France), Laurent Viennot (INRIA, France), and Amir Minet (INRIA, France), Laurent Viennot (INRIA, France), and Amir
Qayyum (M.A. Jinnah University, Islamabad) for their contributions. Qayyum (M.A. Jinnah University, Islamabad) 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: Li Li (CRC), Louise Lamont (CRC), specification and its components (listed alphabetically): Khaldoun Al
Joe Macker (NRL), Alan Cullen (BAE Systems), Khaldoun Al Agha (LRI), Agha (LRI), Song-Yean Cho (LIX), Alan Cullen (BAE Systems), Louise
Richard Ogier (SRI), Song-Yean Cho (LIX), Shubhranshu Singh (Samsung Lamont (CRC), Li Li (CRC), Joe Macker (NRL), Richard Ogier (SRI),
AIT), Charles E. Perkins, and the entire IETF MANET working group. Charles E. Perkins (WiChorus), Shubhranshu Singh (Samsung AIT), and
the entire IETF MANET working group.
Authors' Addresses Authors' Addresses
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique, France LIX, Ecole Polytechnique, France
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/
 End of changes. 48 change blocks. 
119 lines changed or deleted 154 lines changed or added

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