draft-ietf-roll-aodv-rpl-06.txt   draft-ietf-roll-aodv-rpl-07.txt 
ROLL S. Anamalamudi ROLL S. Anamalamudi
Internet-Draft SRM University-AP Internet-Draft SRM University-AP
Intended status: Standards Track M. Zhang Intended status: Standards Track M. Zhang
Expires: September 8, 2019 Huawei Technologies Expires: October 14, 2019 Huawei Technologies
C. Perkins C. Perkins
Futurewei Futurewei
S.V.R.Anand S.V.R.Anand
Indian Institute of Science Indian Institute of Science
B. Liu B. Liu
Huawei Technologies Huawei Technologies
March 7, 2019 April 12, 2019
Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs) Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs)
draft-ietf-roll-aodv-rpl-06 draft-ietf-roll-aodv-rpl-07
Abstract Abstract
Route discovery for symmetric and asymmetric Point-to-Point (P2P) Route discovery for symmetric and asymmetric Point-to-Point (P2P)
traffic flows is a desirable feature in Low power and Lossy Networks traffic flows is a desirable feature in Low power and Lossy Networks
(LLNs). For that purpose, this document specifies a reactive P2P (LLNs). For that purpose, this document specifies a reactive P2P
route discovery mechanism for both hop-by-hop routing and source route discovery mechanism for both hop-by-hop routing and source
routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL
protocol. Paired Instances are used to construct directional paths, protocol. Paired Instances are used to construct directional paths,
in case some of the links between source and target node are in case some of the links between source and target node are
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2019. This Internet-Draft will expire on October 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 4 skipping to change at page 3, line 4
9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 19 9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 19
9.2. AODV-RPL Options: RREQ, RREP, and Target . . . . . . . . 19 9.2. AODV-RPL Options: RREQ, RREP, and Target . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Example: ETX/RSSI Values to select S bit . . . . . . 23 Appendix A. Example: ETX/RSSI Values to select S bit . . . . . . 23
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 24
B.1. Changes from version 05 to version 06 . . . . . . . . . . 24 B.1. Changes from version 06 to version 07 . . . . . . . . . . 24
B.2. Changes from version 04 to version 05 . . . . . . . . . . 24 B.2. Changes from version 05 to version 06 . . . . . . . . . . 24
B.3. Changes from version 03 to version 04 . . . . . . . . . . 24 B.3. Changes from version 04 to version 05 . . . . . . . . . . 24
B.4. Changes from version 02 to version 03 . . . . . . . . . . 24 B.4. Changes from version 03 to version 04 . . . . . . . . . . 24
B.5. Changes from version 02 to version 03 . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
RPL[RFC6550] (Routing Protocol for LLNs (Low-Power and Lossy RPL[RFC6550] (Routing Protocol for LLNs (Low-Power and Lossy
Networks)) is a IPv6 distance vector routing protocol designed to Networks)) is a IPv6 distance vector routing protocol designed to
support multiple traffic flows through a root-based Destination- support multiple traffic flows through a root-based Destination-
Oriented Directed Acyclic Graph (DODAG). Typically, a router does Oriented Directed Acyclic Graph (DODAG). Typically, a router does
not have routing information for most other routers. Consequently, not have routing information for most other routers. Consequently,
for traffic between routers within the DODAG (i.e., Point-to-Point for traffic between routers within the DODAG (i.e., Point-to-Point
(P2P) traffic) data packets either have to traverse the root in non- (P2P) traffic) data packets either have to traverse the root in non-
storing mode, or traverse a common ancestor in storing mode. Such storing mode, or traverse a common ancestor in storing mode. Such
P2P traffic is thereby likely to traverse longer routes and may P2P traffic is thereby likely to traverse longer routes and may
suffer severe congestion near the DAG root [RFC6997], [RFC6998]. suffer severe congestion near the DAG root (for more information see
[RFC6997], [RFC6998]).
To discover better paths for P2P traffic flows in RPL, P2P-RPL To discover better paths for P2P traffic flows in RPL, P2P-RPL
[RFC6997] specifies a temporary DODAG where the source acts as a [RFC6997] specifies a temporary DODAG where the source acts as a
temporary root. The source initiates DIOs encapsulating the P2P temporary root. The source initiates DIOs encapsulating the P2P
Route Discovery option (P2P-RDO) with an address vector for both hop- Route Discovery option (P2P-RDO) with an address vector for both hop-
by-hop mode (H=1) and source routing mode (H=0). Subsequently, each by-hop mode (H=1) and source routing mode (H=0). Subsequently, each
intermediate router adds its IP address and multicasts the P2P mode intermediate router adds its IP address and multicasts the P2P mode
DIOs, until the message reaches the Target Node, which then sends the DIOs, until the message reaches the Target Node, which then sends the
"Discovery Reply" object. P2P-RPL is efficient for source routing, "Discovery Reply" object. P2P-RPL is efficient for source routing,
but much less efficient for hop-by-hop routing due to the extra but much less efficient for hop-by-hop routing due to the extra
skipping to change at page 4, line 36 skipping to change at page 4, line 38
RPL messages, namely RREQ for Route Request, and RREP for Route RPL messages, namely RREQ for Route Request, and RREP for Route
Reply. AODV-RPL currently omits some features compared to AODV -- in Reply. AODV-RPL currently omits some features compared to AODV -- in
particular, flagging Route Errors, blacklisting unidirectional links, particular, flagging Route Errors, blacklisting unidirectional links,
multihoming, and handling unnumbered interfaces. multihoming, and handling unnumbered interfaces.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. This document uses the following terms: [RFC2119], [RFC8174]. This document uses the following terms:
AODV AODV
Ad Hoc On-demand Distance Vector Routing[RFC3561]. Ad Hoc On-demand Distance Vector Routing[RFC3561].
AODV-RPL Instance AODV-RPL Instance
Either the RREQ-Instance or RREP-Instance Either the RREQ-Instance or RREP-Instance
Asymmetric Route Asymmetric Route
The route from the OrigNode to the TargNode can traverse different The route from the OrigNode to the TargNode can traverse different
nodes than the route from the TargNode to the OrigNode. An nodes than the route from the TargNode to the OrigNode. An
skipping to change at page 10, line 33 skipping to change at page 10, line 33
Address Vector Address Vector
Only present when the 'H' bit is set to 0. For an asymmetric Only present when the 'H' bit is set to 0. For an asymmetric
route, the Address Vector represents the IPv6 addresses of the route, the Address Vector represents the IPv6 addresses of the
route that the RREP-DIO has passed. For a symmetric route, it is route that the RREP-DIO has passed. For a symmetric route, it is
the Address Vector when the RREQ-DIO arrives at the TargNode, the Address Vector when the RREQ-DIO arrives at the TargNode,
unchanged during the transmission to the OrigNode. unchanged during the transmission to the OrigNode.
4.3. AODV-RPL DIO Target Option 4.3. AODV-RPL DIO Target Option
The AODV-RPL Target (ART) Option is defined based on the Target The AODV-RPL Target (ART) Option is based on the Target Option in
Option in core RPL [RFC6550]: the Destination Sequence Number of the core RPL [RFC6550]. The Flags field is replaced by the Destination
TargNode is added. Sequence Number of the TargNode and the Prefix Length field is
reduced to 7 bits so that the value is limited to be no greater than
127.
A RREQ-DIO message MUST carry at least one ART Options. A RREP-DIO A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO
message MUST carry exactly one ART Option. message MUST carry exactly one ART Option.
OrigNode can include multiple TargNode addresses via multiple AODV- OrigNode can include multiple TargNode addresses via multiple AODV-
RPL Target Options in the RREQ-DIO, for routes that share the same RPL Target Options in the RREQ-DIO, for routes that share the same
constraints. This reduces the cost to building only one DODAG. constraints. This reduces the cost to building only one DODAG.
Furthermore, a single Target Option can be used for different Furthermore, a single Target Option can be used for different
TargNode addresses if they share the same prefix; in that case the TargNode addresses if they share the same prefix; in that case the
use of the destination sequence number is not defined in this use of the destination sequence number is not defined in this
document. document.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Option Length | Dest SeqNo | Prefix Length | | Type | Option Length | Dest SeqNo |r|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ | + |
| Target Prefix (Variable Length) | | Target Prefix / Address (Variable Length) |
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Target option format for AODV-RPL MoP Figure 3: Target option format for AODV-RPL MoP
Type Type
The type assigned to the ART Option The type assigned to the ART Option
Option Length
Length of the option in octets excluding the Type and Length
fields
Dest SeqNo Dest SeqNo
In RREQ-DIO, if nonzero, it is the last known Sequence Number for In RREQ-DIO, if nonzero, it is the last known Sequence Number for
TargNode for which a route is desired. In RREP-DIO, it is the TargNode for which a route is desired. In RREP-DIO, it is the
destination sequence number associated to the route. destination sequence number associated to the route.
r
A one-bit reserved field. This field MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Prefix Length
7-bit unsigned integer. Number of valid leading bits in the IPv6
Prefix. If Prefix Length is 0, then the value in the Target
Prefix / Address field represents an IPv6 address, not a prefix.
Target Prefix / Address
(variable-length field) An IPv6 destination address or prefix.
The Prefix Length field contains the number of valid leading bits
in the prefix. The bits in the Target Prefix / Address field
after the prefix length (if any) MUST be set to zero on
transmission and MUST be ignored on receipt.
5. Symmetric and Asymmetric Routes 5. Symmetric and Asymmetric Routes
In Figure 4 and Figure 5, BR is the Border Router, O is the OrigNode, In Figure 4 and Figure 5, BR is the Border Router, O is the OrigNode,
R is an intermediate router, and T is the TargNode. If the RREQ-DIO R is an intermediate router, and T is the TargNode. If the RREQ-DIO
arrives over an interface that is known to be symmetric, and the 'S' arrives over an interface that is known to be symmetric, and the 'S'
bit is set to 1, then it remains as 1, as illustrated in Figure 4. bit is set to 1, then it remains as 1, as illustrated in Figure 4.
If an intermediate router sends out RREQ-DIO with the 'S' bit set to If an intermediate router sends out RREQ-DIO with the 'S' bit set to
1, then all the one-hop links on the route from the OrigNode O to 1, then all the one-hop links on the route from the OrigNode O to
this router meet the requirements of route discovery, and the route this router meet the requirements of route discovery, and the route
can be used symmetrically. can be used symmetrically.
skipping to change at page 21, line 44 skipping to change at page 21, line 44
13. References 13. References
13.1. Normative References 13.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", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
DOI 10.17487/RFC3561, July 2003,
<https://www.rfc-editor.org/info/rfc3561>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)", Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012, RFC 6552, DOI 10.17487/RFC6552, March 2012,
<https://www.rfc-editor.org/info/rfc6552>. <https://www.rfc-editor.org/info/rfc6552>.
[RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
"A Mechanism to Measure the Routing Metrics along a Point- 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
to-Point Route in a Low-Power and Lossy Network", May 2017, <https://www.rfc-editor.org/info/rfc8174>.
RFC 6998, DOI 10.17487/RFC6998, August 2013,
<https://www.rfc-editor.org/info/rfc6998>.
13.2. Informative References 13.2. Informative References
[I-D.thubert-roll-asymlink] [I-D.thubert-roll-asymlink]
Thubert, P., "RPL adaptation for asymmetrical links", Thubert, P., "RPL adaptation for asymmetrical links",
draft-thubert-roll-asymlink-02 (work in progress), draft-thubert-roll-asymlink-02 (work in progress),
December 2011. December 2011.
[Perlman83] [Perlman83]
Perlman, R., "Fault-Tolerant Broadcast of Routing Perlman, R., "Fault-Tolerant Broadcast of Routing
Information", December 1983. Information", December 1983.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
DOI 10.17487/RFC3561, July 2003,
<https://www.rfc-editor.org/info/rfc3561>.
[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and
D. Barthel, Ed., "Routing Requirements for Urban Low-Power D. Barthel, Ed., "Routing Requirements for Urban Low-Power
and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May
2009, <https://www.rfc-editor.org/info/rfc5548>. 2009, <https://www.rfc-editor.org/info/rfc5548>.
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-Power and Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
2009, <https://www.rfc-editor.org/info/rfc5673>. 2009, <https://www.rfc-editor.org/info/rfc5673>.
skipping to change at page 23, line 11 skipping to change at page 23, line 11
"Building Automation Routing Requirements in Low-Power and "Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June
2010, <https://www.rfc-editor.org/info/rfc5867>. 2010, <https://www.rfc-editor.org/info/rfc5867>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997, in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013, DOI 10.17487/RFC6997, August 2013,
<https://www.rfc-editor.org/info/rfc6997>. <https://www.rfc-editor.org/info/rfc6997>.
[RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci,
"A Mechanism to Measure the Routing Metrics along a Point-
to-Point Route in a Low-Power and Lossy Network",
RFC 6998, DOI 10.17487/RFC6998, August 2013,
<https://www.rfc-editor.org/info/rfc6998>.
Appendix A. Example: ETX/RSSI Values to select S bit Appendix A. Example: ETX/RSSI Values to select S bit
We have tested the combination of "RSSI(downstream)" and "ETX We have tested the combination of "RSSI(downstream)" and "ETX
(upstream)" to determine whether the link is symmetric or asymmetric (upstream)" to determine whether the link is symmetric or asymmetric
at the intermediate nodes. The example of how the ETX and RSSI at the intermediate nodes. The example of how the ETX and RSSI
values are used in conjuction is explained below: values are used in conjuction is explained below:
Source---------->NodeA---------->NodeB------->Destination Source---------->NodeA---------->NodeB------->Destination
Figure 8: Communication link from Source to Destination Figure 8: Communication link from Source to Destination
skipping to change at page 24, line 7 skipping to change at page 24, line 11
models, one can determine a relationship between RSSI and ETX models, one can determine a relationship between RSSI and ETX
representable as an expression or a mapping table. Such a representable as an expression or a mapping table. Such a
relationship in turn can be used to estimate ETX value at nodeA for relationship in turn can be used to estimate ETX value at nodeA for
link NodeB--->NodeA from the received RSSI from NodeB. Whenever link NodeB--->NodeA from the received RSSI from NodeB. Whenever
nodeA determines that the link towards the nodeB is bi-directional nodeA determines that the link towards the nodeB is bi-directional
asymmetric then the "S" bit is set to "S=0". Later on, the link from asymmetric then the "S" bit is set to "S=0". Later on, the link from
NodeA to Destination is asymmetric with "S" bit remains to "0". NodeA to Destination is asymmetric with "S" bit remains to "0".
Appendix B. Changelog Appendix B. Changelog
B.1. Changes from version 05 to version 06 B.1. Changes from version 06 to version 07
o Added definitions for all fields of the ART option (see
Section 4.3). Modified definition of Prefix Length to prohibit
Prefix Length values greater than 127.
o Modified the language from [RFC6550] Target Option definition so
that the trailing zero bits of the Prefix Length are no longer
described as "reserved".
o Reclassified RFC 3561 and RFC 6998 as Informative.
o Added citation to RFC 8174 to Terminology section.
B.2. Changes from version 05 to version 06
o Added Security Considerations based on the security mechanisms o Added Security Considerations based on the security mechanisms
defined in RFC 6550. defined in RFC 6550.
o Clarified the nature of improvements due to P2P route discovery o Clarified the nature of improvements due to P2P route discovery
versus bidirectional asymmetric route discovery. versus bidirectional asymmetric route discovery.
o Editorial improvements and corrections. o Editorial improvements and corrections.
B.2. Changes from version 04 to version 05 B.3. Changes from version 04 to version 05
o Add description for sequence number operations. o Add description for sequence number operations.
o Extend the residence duration L in section 4.1. o Extend the residence duration L in section 4.1.
o Change AODV-RPL Target option to ART option. o Change AODV-RPL Target option to ART option.
B.3. Changes from version 03 to version 04 B.4. Changes from version 03 to version 04
o Updated RREP option format. Remove the 'T' bit in RREP option. o Updated RREP option format. Remove the 'T' bit in RREP option.
o Using the same RPLInstanceID for RREQ and RREP, no need to update o Using the same RPLInstanceID for RREQ and RREP, no need to update
[RFC6550]. [RFC6550].
o Explanation of Shift field in RREP. o Explanation of Shift field in RREP.
o Multiple target options handling during transmission. o Multiple target options handling during transmission.
B.4. Changes from version 02 to version 03 B.5. Changes from version 02 to version 03
o Include the support for source routing. o Include the support for source routing.
o Import some features from [RFC6997], e.g., choice between hop-by- o Import some features from [RFC6997], e.g., choice between hop-by-
hop and source routing, the "L" bit which determines the duration hop and source routing, the "L" bit which determines the duration
of residence in the DAG, MaxRank, etc. of residence in the DAG, MaxRank, etc.
o Define new target option for AODV-RPL, including the Destination o Define new target option for AODV-RPL, including the Destination
Sequence Number in it. Move the TargNode address in RREQ option Sequence Number in it. Move the TargNode address in RREQ option
and the OrigNode address in RREP option into ADOV-RPL Target and the OrigNode address in RREP option into ADOV-RPL Target
 End of changes. 21 change blocks. 
30 lines changed or deleted 72 lines changed or added

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