draft-ietf-roll-aodv-rpl-04.txt | draft-ietf-roll-aodv-rpl-05.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: January 3, 2019 Huawei Technologies | Expires: April 21, 2019 Huawei Technologies | |||
AR. Sangi | ||||
Huaiyin Institute of Technology | ||||
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 | |||
July 2, 2018 | October 18, 2018 | |||
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-04 | draft-ietf-roll-aodv-rpl-05 | |||
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 46 ¶ | 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 January 3, 2019. | This Internet-Draft will expire on April 21, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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 2, line 47 ¶ | skipping to change at page 2, line 47 ¶ | |||
6.3.2. RREP-DIO for Asymmetric Route . . . . . . . . . . . . 16 | 6.3.2. RREP-DIO for Asymmetric Route . . . . . . . . . . . . 16 | |||
6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 16 | 6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 16 | |||
6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 17 | 6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 17 | |||
7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 18 | 7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 19 | 8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 19 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 21 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 | |||
Appendix A. Example: ETX/RSSI Values to select S bit . . . . . . 21 | 13.2. Informative References . . . . . . . . . . . . . . . . . 22 | |||
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 22 | Appendix A. Example: ETX/RSSI Values to select S bit . . . . . . 22 | |||
B.1. Changes to version 02 . . . . . . . . . . . . . . . . . . 22 | Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 23 | |||
B.1. Changes to version 02 . . . . . . . . . . . . . . . . . . 23 | ||||
B.2. Changes to version 03 . . . . . . . . . . . . . . . . . . 23 | B.2. Changes to version 03 . . . . . . . . . . . . . . . . . . 23 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | B.3. Changes to version 04 . . . . . . . . . . . . . . . . . . 24 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 | ||||
1. Introduction | 1. Introduction | |||
RPL[RFC6550] is a IPv6 distance vector routing protocol for Low-power | RPL[RFC6550] is a IPv6 distance vector routing protocol for Low-power | |||
and Lossy Networks (LLNs), and is designed to support multiple | and Lossy Networks (LLNs), and is designed to support multiple | |||
traffic flows through a root-based Destination-Oriented Directed | traffic flows through a root-based Destination-Oriented Directed | |||
Acyclic Graph (DODAG). Typically, a router does not have routing | Acyclic Graph (DODAG). Typically, a router does not have routing | |||
information for most other routers. Consequently, for traffic | information for most other routers. Consequently, for traffic | |||
between routers within the DODAG (i.e., Point-to-Point (P2P) traffic) | between routers within the DODAG (i.e., Point-to-Point (P2P) traffic) | |||
data packets either have to traverse the root in non-storing mode, or | data packets either have to traverse the root in non-storing mode, or | |||
skipping to change at page 6, line 20 ¶ | skipping to change at page 6, line 20 ¶ | |||
TargNode | TargNode | |||
The IPv6 router (Target Node) for which OrigNode requires a route | The IPv6 router (Target Node) for which OrigNode requires a route | |||
and initiates Route Discovery within the LLN network. | and initiates Route Discovery within the LLN network. | |||
Upward Direction | Upward Direction | |||
The direction from the TargNode to the OrigNode. | The direction from the TargNode to the OrigNode. | |||
Upward Route | Upward Route | |||
A route in the upward direction. | A route in the upward direction. | |||
ART option | ||||
AODV-RPL Target option: a target option defined in this document. | ||||
3. Overview of AODV-RPL | 3. Overview of AODV-RPL | |||
With AODV-RPL, routes from OrigNode to TargNode within the LLN | With AODV-RPL, routes from OrigNode to TargNode within the LLN | |||
network established are "on-demand". In other words, the route | network established are "on-demand". In other words, the route | |||
discovery mechanism in AODV-RPL is invoked reactively when OrigNode | discovery mechanism in AODV-RPL is invoked reactively when OrigNode | |||
has data for delivery to the TargNode but existing routes do not | has data for delivery to the TargNode but existing routes do not | |||
satisfy the application's requirements. The routes discovered by | satisfy the application's requirements. The routes discovered by | |||
AODV-RPL are not constrained to traverse a common ancestor. Unlike | AODV-RPL are not constrained to traverse a common ancestor. Unlike | |||
RPL [RFC6550] and P2P-RPL [RFC6997], AODV-RPL can enable asymmetric | RPL [RFC6550] and P2P-RPL [RFC6997], AODV-RPL can enable asymmetric | |||
communication paths in networks with bidirectional asymmetric links. | communication paths in networks with bidirectional asymmetric links. | |||
skipping to change at page 8, line 19 ¶ | skipping to change at page 8, line 23 ¶ | |||
2-bit unsigned integer determining the duration that a node is | 2-bit unsigned integer determining the duration that a node is | |||
able to belong to the temporary DAG in RREQ-Instance, including | able to belong to the temporary DAG in RREQ-Instance, including | |||
the OrigNode and the TargNode. Once the time is reached, a node | the OrigNode and the TargNode. Once the time is reached, a node | |||
MUST leave the DAG and stop sending or receiving any more DIOs for | MUST leave the DAG and stop sending or receiving any more DIOs for | |||
the temporary DODAG. The definition for the "L" bit is similar to | the temporary DODAG. The definition for the "L" bit is similar to | |||
that found in [RFC6997], except that the values are adjusted to | that found in [RFC6997], except that the values are adjusted to | |||
enable arbitrarily long route lifetime. | enable arbitrarily long route lifetime. | |||
* 0x00: No time limit imposed. | * 0x00: No time limit imposed. | |||
* 0x01: 2 seconds | * 0x01: 16 seconds | |||
* 0x02: 16 seconds | * 0x02: 64 seconds | |||
* 0x03: 64 seconds | * 0x03: 256 seconds | |||
L is independent from the route lifetime, which is defined in the | L is independent from the route lifetime, which is defined in the | |||
DODAG configuration option. The route entries in hop-by-hop | DODAG configuration option. The route entries in hop-by-hop | |||
routing and states of source routing can still be maintained even | routing and states of source routing can still be maintained even | |||
after the DAG expires. | after the DAG expires. | |||
MaxRank | MaxRank | |||
This field indicates the upper limit on the integer portion of the | This field indicates the upper limit on the integer portion of the | |||
rank (calculated using the DAGRank() macro defined in [RFC6550]). | rank (calculated using the DAGRank() macro defined in [RFC6550]). | |||
A value of 0 in this field indicates the limit is infinity. | A value of 0 in this field indicates the limit is infinity. | |||
skipping to change at page 10, line 25 ¶ | skipping to change at page 10, line 25 ¶ | |||
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 Option is defined based on the Target Option in | The AODV-RPL Target (ART) Option is defined based on the Target | |||
core RPL [RFC6550]: the Destination Sequence Number of the TargNode | Option in core RPL [RFC6550]: the Destination Sequence Number of the | |||
is added. | TargNode is added. | |||
A RREQ-DIO message MUST carry at least one AODV-RPL Target Options. | A RREQ-DIO message MUST carry at least one ART Options. A RREP-DIO | |||
A RREP-DIO message MUST carry exactly one AODV-RPL Target 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 | |||
skipping to change at page 11, line 20 ¶ | skipping to change at page 11, line 20 ¶ | |||
| | | | | | |||
+ | | + | | |||
| Target Prefix (Variable Length) | | | Target Prefix (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 AODV-RPL Target Option | The type assigned to the ART Option | |||
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. | |||
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, | |||
skipping to change at page 13, line 39 ¶ | skipping to change at page 13, line 39 ¶ | |||
6. AODV-RPL Operation | 6. AODV-RPL Operation | |||
6.1. Route Request Generation | 6.1. Route Request Generation | |||
The route discovery process is initiated when an application at the | The route discovery process is initiated when an application at the | |||
OrigNode has data to be transmitted to the TargNode, but does not | OrigNode has data to be transmitted to the TargNode, but does not | |||
have a route for the target that fulfills the requirements of the | have a route for the target that fulfills the requirements of the | |||
data transmission. In this case, the OrigNode builds a local | data transmission. In this case, the OrigNode builds a local | |||
RPLInstance and a DODAG rooted at itself. Then it transmits a DIO | RPLInstance and a DODAG rooted at itself. Then it transmits a DIO | |||
message containing exactly one RREQ option (see Section 4.1) via | message containing exactly one RREQ option (see Section 4.1) via | |||
link-local multicast. The DIO MUST contain at least one AODV-RPL | link-local multicast. The DIO MUST contain at least one ART Option | |||
Target Option (see Section 4.3). The 'S' bit in RREQ-DIO sent out by | (see Section 4.3). The 'S' bit in RREQ-DIO sent out by the OrigNode | |||
the OrigNode is set to 1. | is set to 1. | |||
The OrigNode maintains its Sequence Number as defined in AODV | Each node maintains a sequence number, which rolls over like a | |||
[RFC3561]. Namely, the OrigNode increments its Sequence number each | lollipop counter [Perlman83], detailed operation can refer to the | |||
time it initiate a new route discovery operation by transmitting a | section 7.2 of [RFC6550]. When the OrigNode initiates a route | |||
new RREQ message. Similarly, TargNode increments its Sequence number | discovery process, it MUST increse its own sequence number to avoid | |||
each time it transmits a RREP message in response to a new RREQ | conflicts with previous established routes. The increased number is | |||
message (one with an incremented Sequence Number for OrigNode). | carried in the OrigSeqNo field of the RREQ option. | |||
The address in the AODV-RPL Target Option can be a unicast IPv6 | The address in the ART Option can be a unicast IPv6 address or a | |||
address, or a prefix. The OrigNode can initiate the route discovery | prefix. The OrigNode can initiate the route discovery process for | |||
process for multiple targets simultaneously by including multiple | multiple targets simultaneously by including multiple ART Options, | |||
AODV-RPL Target Options, and within a RREQ-DIO the requirements for | and within a RREQ-DIO the requirements for the routes to different | |||
the routes to different TargNodes MUST be the same. | TargNodes MUST be the same. | |||
OrigNode can maintain different RPLInstances to discover routes with | OrigNode can maintain different RPLInstances to discover routes with | |||
different requirements to the same targets. Using the InstanceID | different requirements to the same targets. Using the InstanceID | |||
pairing mechanism (see Section 6.3.3), route replies (RREP-DIOs) for | pairing mechanism (see Section 6.3.3), route replies (RREP-DIOs) for | |||
different RPLInstances can be distinguished. | different RPLInstances can be distinguished. | |||
The transmission of RREQ-DIO obeys the Trickle timer. If the | The transmission of RREQ-DIO obeys the Trickle timer. If the | |||
duration specified by the "L" bit has elapsed, the OrigNode MUST | duration specified by the "L" bit has elapsed, the OrigNode MUST | |||
leave the DODAG and stop sending RREQ-DIOs in the related | leave the DODAG and stop sending RREQ-DIOs in the related | |||
RPLInstance. | RPLInstance. | |||
skipping to change at page 14, line 49 ¶ | skipping to change at page 14, line 49 ¶ | |||
is selected as the preferred parent. Later, other RREQ-DIO | is selected as the preferred parent. Later, other RREQ-DIO | |||
messages might be received. How to maintain the parent set, | messages might be received. How to maintain the parent set, | |||
select the preferred parent, and update the router's rank obeys | select the preferred parent, and update the router's rank obeys | |||
the core RPL and the OFs defined in ROLL WG. In case that the | the core RPL and the OFs defined in ROLL WG. In case that the | |||
constraint or the MaxRank limit is not fulfilled, the router MUST | constraint or the MaxRank limit is not fulfilled, the router MUST | |||
discard the received RREQ-DIO and MUST NOT join the DODAG. | discard the received RREQ-DIO and MUST NOT join the DODAG. | |||
Step 2: | Step 2: | |||
Then the router checks if one of its addresses is included in one | Then the router checks if one of its addresses is included in one | |||
of the AODV-RPL Target Options. If so, this router is one of the | of the ART Options. If so, this router is one of the TargNodes. | |||
TargNodes. Otherwise, it is an intermediate router. | Otherwise, it is an intermediate router. | |||
Step 3: | Step 3: | |||
If the 'H' bit is set to 1, then the router (TargNode or | If the 'H' bit is set to 1, then the router (TargNode or | |||
intermediate) MUST build the upward route entry accordingly. The | intermediate) MUST build the upward route entry accordingly. The | |||
route entry MUST include at least the following items: Source | route entry MUST include at least the following items: Source | |||
Address, InstanceID, Destination Address, Next Hop and Lifetime. | Address, InstanceID, Destination Address, Next Hop, Lifetime, and | |||
The Destination Address and the InstanceID can be respectively | Sequence Number. The Destination Address and the InstanceID can | |||
learned from the DODAGID and the RPLInstanceID of the RREQ-DIO, | be respectively learned from the DODAGID and the RPLInstanceID of | |||
and the Source Address is copied from the AODV-RPL Target Option. | the RREQ-DIO, and the Source Address is copied from the ART | |||
The next hop is the preferred parent. And the lifetime is set | Option. The next hop is the preferred parent. And the lifetime | |||
according to DODAG configuration and can be extended when the | is set according to DODAG configuration and can be extended when | |||
route is actually used. | the route is actually used. The sequence number represents the | |||
freshness of the route entry, and it is copied from the Orig SeqNo | ||||
field of the RREQ option. A route entry with same source and | ||||
destination address, same InstanceID, but stale sequence number, | ||||
SHOULD be deleted. | ||||
If the 'H' bit is set to 0, an intermediate router MUST include | If the 'H' bit is set to 0, an intermediate router MUST include | |||
the address of the interface receiving the RREQ-DIO into the | the address of the interface receiving the RREQ-DIO into the | |||
address vector. | address vector. | |||
Step 4: | Step 4: | |||
An intermediate router transmits a RREQ-DIO via link-local | An intermediate router transmits a RREQ-DIO via link-local | |||
multicast. TargNode prepares a RREP-DIO. | multicast. TargNode prepares a RREP-DIO. | |||
skipping to change at page 15, line 46 ¶ | skipping to change at page 15, line 50 ¶ | |||
An intermediate router could receive several RREQ-DIOs from routers | An intermediate router could receive several RREQ-DIOs from routers | |||
with lower ranks in the same RREQ-instance but have different lists | with lower ranks in the same RREQ-instance but have different lists | |||
of Target Options. When rebroadcasting the RREQ-DIO, the | of Target Options. When rebroadcasting the RREQ-DIO, the | |||
intersection of these lists SHOULD be included. For example, suppose | intersection of these lists SHOULD be included. For example, suppose | |||
two RREQ-DIOs are received with the same RPLInstance and OrigNode. | two RREQ-DIOs are received with the same RPLInstance and OrigNode. | |||
Suppose further that the first RREQ has (T1, T2) as the targets, and | Suppose further that the first RREQ has (T1, T2) as the targets, and | |||
the second one has (T2, T4) as targets. Then only T2 needs to be | the second one has (T2, T4) as targets. Then only T2 needs to be | |||
included in the generated RREQ-DIO. If the intersection is empty, it | included in the generated RREQ-DIO. If the intersection is empty, it | |||
means that all the targets have been reached, and the router SHOULD | means that all the targets have been reached, and the router SHOULD | |||
NOT send out any RREQ-DIO. Any RREQ-DIO message with different AODV- | NOT send out any RREQ-DIO. Any RREQ-DIO message with different ART | |||
RPL Target Options coming from a router with higher rank is ignored. | Options coming from a router with higher rank is ignored. | |||
6.3. Generating Route Reply (RREP) at TargNode | 6.3. Generating Route Reply (RREP) at TargNode | |||
6.3.1. RREP-DIO for Symmetric route | 6.3.1. RREP-DIO for Symmetric route | |||
If a RREQ-DIO arrives at TargNode with the 'S' bit set to 1, there is | If a RREQ-DIO arrives at TargNode with the 'S' bit set to 1, there is | |||
a symmetric route along which both directions can fulfill the | a symmetric route along which both directions can fulfill the | |||
requirements. Other RREQ-DIOs might later provide asymmetric upward | requirements. Other RREQ-DIOs might later provide asymmetric upward | |||
routes (i.e. S=0). Selection between a qualified symmetric route | routes (i.e. S=0). Selection between a qualified symmetric route | |||
and an asymmetric route that might have better performance is | and an asymmetric route that might have better performance is | |||
implementation-specific and out of scope. If the implementation uses | implementation-specific and out of scope. If the implementation uses | |||
the symmetric route, the TargNode MAY delay transmitting the RREP-DIO | the symmetric route, the TargNode MAY delay transmitting the RREP-DIO | |||
for duration RREP_WAIT_TIME to await a better symmetric route. | for duration RREP_WAIT_TIME to await a better symmetric route. | |||
For a symmetric route, the RREP-DIO message is unicast to the next | For a symmetric route, the RREP-DIO message is unicast to the next | |||
hop according to the accumulated address vector (H=0) or the route | hop according to the accumulated address vector (H=0) or the route | |||
entry (H=1). Thus the DODAG in RREP-Instance does not need to be | entry (H=1). Thus the DODAG in RREP-Instance does not need to be | |||
built. The RPLInstanceID in the RREP-Instance is paired as defined | built. The RPLInstanceID in the RREP-Instance is paired as defined | |||
in Section 6.3.3. In case the 'H' bit is set to 0, the address | in Section 6.3.3. In case the 'H' bit is set to 0, the address | |||
vector received in the RREQ-DIO MUST be included in the RREP-DIO. | vector received in the RREQ-DIO MUST be included in the RREP-DIO. | |||
The address of the OrigNode MUST be encapsulated in an AODV-RPL | The sequence number of the TargNode is updated to the maximum of its | |||
Target Option and included in this RREP-DIO message, and the Dest | current sequence number and the Dest SeqNo in the ART option of the | |||
SeqNo is incremented, as is done in AODV [RFC3561]. | RREQ-DIO, using a mechanism similar to that used in [RFC3561]. This | |||
updated sequence number is then copied to the Dest SeqNo field of the | ||||
ART option. The address of the OrigNode MUST be encapsulated in the | ||||
ART Option and included in this RREP-DIO message. | ||||
6.3.2. RREP-DIO for Asymmetric Route | 6.3.2. RREP-DIO for Asymmetric Route | |||
When a RREQ-DIO arrives at a TargNode with the 'S' bit set to 0, the | When a RREQ-DIO arrives at a TargNode with the 'S' bit set to 0, the | |||
TargNode MUST build a DODAG in the RREP-Instance rooted at itself in | TargNode MUST build a DODAG in the RREP-Instance rooted at itself in | |||
order to discover the downstream route from the OrigNode to the | order to discover the downstream route from the OrigNode to the | |||
TargNode. The RREP-DIO message MUST be re-transmitted via link-local | TargNode. The RREP-DIO message MUST be re-transmitted via link-local | |||
multicast until the OrigNode is reached or MaxRank is exceeded. | multicast until the OrigNode is reached or MaxRank is exceeded. | |||
The settings of the fields in RREP option are the same as in | The settings of the fields in RREP option and ART option are the same | |||
symmetric route except for the 'S' bit. | as for the symmetric route, except for the 'S' bit. | |||
6.3.3. RPLInstanceID Pairing | 6.3.3. RPLInstanceID Pairing | |||
Since the RPLInstanceID is assigned locally (i.e., there is no | Since the RPLInstanceID is assigned locally (i.e., there is no | |||
coordination between routers in the assignment of RPLInstanceID), the | coordination between routers in the assignment of RPLInstanceID), the | |||
tuple (OrigNode, TargNode, RPLInstanceID) is needed to uniquely | tuple (OrigNode, TargNode, RPLInstanceID) is needed to uniquely | |||
identify a discovered route. The upper layer applications may have | identify a discovered route. The upper layer applications may have | |||
different requirements and they can initiate the route discoveries | different requirements and they can initiate the route discoveries | |||
simultaneously. Thus between the same pair of OrigNode and TargNode, | simultaneously. Thus between the same pair of OrigNode and TargNode, | |||
there can be multiple AODV-RPL instances. To avoid any mismatch, the | there can be multiple AODV-RPL instances. To avoid any mismatch, the | |||
skipping to change at page 17, line 45 ¶ | skipping to change at page 17, line 48 ¶ | |||
update the router's rank obeys the core RPL and the OFs defined in | update the router's rank obeys the core RPL and the OFs defined in | |||
ROLL WG. | ROLL WG. | |||
If the constraints are not fulfilled, the router MUST NOT join the | If the constraints are not fulfilled, the router MUST NOT join the | |||
DODAG; the router MUST discard the RREQ-DIO, and does not execute | DODAG; the router MUST discard the RREQ-DIO, and does not execute | |||
the remaining steps in this section. | the remaining steps in this section. | |||
Step 2: | Step 2: | |||
The router next checks if one of its addresses is included in the | The router next checks if one of its addresses is included in the | |||
AODV-RPL Target Option. If so, this router is the OrigNode of the | ART Option. If so, this router is the OrigNode of the route | |||
route discovery. Otherwise, it is an intermediate router. | discovery. Otherwise, it is an intermediate router. | |||
Step 3: | Step 3: | |||
If the 'H' bit is set to 1, then the router (OrigNode or | If the 'H' bit is set to 1, then the router (OrigNode or | |||
intermediate) MUST build a downward route entry. The route entry | intermediate) MUST build a downward route entry. The route entry | |||
SHOULD include at least the following items: OrigNode Address, | SHOULD include at least the following items: OrigNode Address, | |||
InstanceID, TargNode Address as destination, Next Hop and | InstanceID, TargNode Address as destination, Next Hop, Lifetime | |||
Lifetime. For a symmetric route, the next hop in the route entry | and Sequence Number. For a symmetric route, the next hop in the | |||
is the router from which the RREP-DIO is received. For an | route entry is the router from which the RREP-DIO is received. | |||
asymmetric route, the next hop is the preferred parent in the | For an asymmetric route, the next hop is the preferred parent in | |||
DODAG of RREQ-Instance. The InstanceID in the route entry MUST be | the DODAG of RREQ-Instance. The InstanceID in the route entry | |||
the original RPLInstanceID (after subtracting the Shift field | MUST be the original RPLInstanceID (after subtracting the Shift | |||
value). The source address is learned from the AODV-RPL Target | field value). The source address is learned from the ART Option, | |||
Option, and the destination address is learned from the DODAGID. | and the destination address is learned from the DODAGID. The | |||
The lifetime is set according to DODAG configuration and can be | lifetime is set according to DODAG configuration and can be | |||
extended when the route is actually used. | extended when the route is actually used. The sequence number | |||
represents the freshness of the route entry, and is copied from | ||||
the Dest SeqNo field of the ART option of the RREP-DIO. A route | ||||
entry with same source and destination address, same InstanceID, | ||||
but stale sequence number, SHOULD be deleted. | ||||
If the 'H' bit is set to 0, for an asymmetric route, an | If the 'H' bit is set to 0, for an asymmetric route, an | |||
intermediate router MUST include the address of the interface | intermediate router MUST include the address of the interface | |||
receiving the RREP-DIO into the address vector; for a symmetric | receiving the RREP-DIO into the address vector; for a symmetric | |||
route, there is nothing to do in this step. | route, there is nothing to do in this step. | |||
Step 4: | Step 4: | |||
If the receiver is the OrigNode, it can start transmitting the | If the receiver is the OrigNode, it can start transmitting the | |||
application data to TargNode along the path as provided in RREP- | application data to TargNode along the path as provided in RREP- | |||
Instance, and processing for the RREP-DIO is complete. Otherwise, | Instance, and processing for the RREP-DIO is complete. Otherwise, | |||
in case of an asymmetric route, the intermediate router transmits | in case of an asymmetric route, the intermediate router transmits | |||
the RREP-DIO via link-local multicast. In case of a symmetric | the RREP-DIO via link-local multicast. In case of a symmetric | |||
route, the RREP-DIO message is unicast to the next hop according | route, the RREP-DIO message is unicast to the next hop according | |||
to the address vector in the RREP-DIO (H=0) or the local route | to the address vector in the RREP-DIO (H=0) or the local route | |||
entry (H=1). The RPLInstanceID in the transmitted RREP-DIO is the | entry (H=1). The RPLInstanceID in the transmitted RREP-DIO is the | |||
same as the value in the received RREP-DIO. | same as the value in the received RREP-DIO. The local knowledge | |||
for the TargNode's sequence number SHOULD be updated. | ||||
7. Gratuitous RREP | 7. Gratuitous RREP | |||
In some cases, an Intermediate router that receives a RREQ-DIO | In some cases, an Intermediate router that receives a RREQ-DIO | |||
message MAY transmit a "Gratuitous" RREP-DIO message back to OrigNode | message MAY transmit a "Gratuitous" RREP-DIO message back to OrigNode | |||
instead of continuing to multicast the RREQ-DIO towards TargNode. | instead of continuing to multicast the RREQ-DIO towards TargNode. | |||
The intermediate router effectively builds the RREP-Instance on | The intermediate router effectively builds the RREP-Instance on | |||
behalf of the actual TargNode. The 'G' bit of the RREP option is | behalf of the actual TargNode. The 'G' bit of the RREP option is | |||
provided to distinguish the Gratuitous RREP-DIO (G=1) sent by the | provided to distinguish the Gratuitous RREP-DIO (G=1) sent by the | |||
Intermediate node from the RREP-DIO sent by TargNode (G=0). | Intermediate node from the RREP-DIO sent by TargNode (G=0). | |||
The gratuitous RREP-DIO can be sent out when an intermediate router R | The gratuitous RREP-DIO can be sent out when an intermediate router R | |||
receives a RREQ-DIO for a TargNode T, and R happens to have both | receives a RREQ-DIO for a TargNode T, and R happens to have a more | |||
downward and upward routes to T which also fulfill the requirements. | recent (larger destination sequence number) pair of downward and | |||
upward routes to T which also fulfill the requirements. | ||||
In case of source routing, the intermediate router R MUST unicast the | In case of source routing, the intermediate router R MUST unicast the | |||
received RREQ-DIO to TargNode T including the address vector between | received RREQ-DIO to TargNode T including the address vector between | |||
the OrigNode O and the router R. Thus T can have a complete upward | the OrigNode O and the router R. Thus T can have a complete upward | |||
route address vector from itself to O. Then R MUST send out the | route address vector from itself to O. Then R MUST send out the | |||
gratuitous RREP-DIO including the address vector from R to T. | gratuitous RREP-DIO including the address vector from R to T. | |||
In case of hop-by-hop routing, R MUST unicast the received RREQ-DIO | In case of hop-by-hop routing, R MUST unicast the received RREQ-DIO | |||
to T. The routers along the route SHOULD build new route entries | hop-by-hop to T. The routers along the route SHOULD build new route | |||
with the related RPLInstanceID and DODAGID in the downward direction. | entries with the related RPLInstanceID and DODAGID in the downward | |||
Then T MUST unicast the RREP-DIO to R, and the routers along the | direction. Then T MUST unicast the RREP-DIO hop-by-hop to R, and the | |||
route SHOULD build new route entries in the upward direction. Upon | routers along the route SHOULD build new route entries in the upward | |||
received the unicast RREP-DIO, R sends the gratuitous RREP-DIO to the | direction. Upon receiving the unicast RREP-DIO, R sends the | |||
OrigNode as the same way defined in Section 6.3. | gratuitous RREP-DIO to the OrigNode as defined in Section 6.3. | |||
8. Operation of Trickle Timer | 8. Operation of Trickle Timer | |||
The trickle timer operation to control RREQ-Instance/RREP-Instance | The trickle timer operation to control RREQ-Instance/RREP-Instance | |||
multicast is similar to that in P2P-RPL [RFC6997]. | multicast is similar to that in P2P-RPL [RFC6997]. | |||
9. IANA Considerations | 9. IANA Considerations | |||
9.1. New Mode of Operation: AODV-RPL | 9.1. New Mode of Operation: AODV-RPL | |||
skipping to change at page 19, line 38 ¶ | skipping to change at page 19, line 46 ¶ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-------------+---------------+---------------+ | +-------------+---------------+---------------+ | |||
| TBD1 (5) | AODV-RPL | This document | | | TBD1 (5) | AODV-RPL | This document | | |||
+-------------+---------------+---------------+ | +-------------+---------------+---------------+ | |||
Figure 6: Mode of Operation | Figure 6: Mode of Operation | |||
9.2. AODV-RPL Options: RREQ, RREP, and Target | 9.2. AODV-RPL Options: RREQ, RREP, and Target | |||
Three entries are required for new AODV-RPL options "RREQ", "RREP" | Three entries are required for new AODV-RPL options "RREQ", "RREP" | |||
and "AODV-RPL Target" with values of TBD2 (0x0A), TBD3 (0x0B) and | and "ART" with values of TBD2 (0x0A), TBD3 (0x0B) and TBD4 (0x0C) | |||
TBD4 (0x0C) from the "RPL Control Message Options" space [RFC6550]. | from the "RPL Control Message Options" space [RFC6550]. | |||
+-------------+------------------------+---------------+ | +-------------+------------------------+---------------+ | |||
| Value | Meaning | Reference | | | Value | Meaning | Reference | | |||
+-------------+------------------------+---------------+ | +-------------+------------------------+---------------+ | |||
| TBD2 (0x0A) | RREQ Option | This document | | | TBD2 (0x0A) | RREQ Option | This document | | |||
+-------------+------------------------+---------------+ | +-------------+------------------------+---------------+ | |||
| TBD3 (0x0B) | RREP Option | This document | | | TBD3 (0x0B) | RREP Option | This document | | |||
+-------------+------------------------+---------------+ | +-------------+------------------------+---------------+ | |||
| TBD3 (0x0C) | AODV-RPL Target Option | This document | | | TBD3 (0x0C) | ART Option | This document | | |||
+-------------+------------------------+---------------+ | +-------------+------------------------+---------------+ | |||
Figure 7: AODV-RPL Options | Figure 7: AODV-RPL Options | |||
10. Security Considerations | 10. Security Considerations | |||
This document does not introduce additional security issues compared | This document does not introduce additional security issues compared | |||
to base RPL. For general RPL security considerations, see [RFC6550]. | to base RPL. For general RPL security considerations, see [RFC6550]. | |||
11. Future Work | 11. Future Work | |||
skipping to change at page 20, line 27 ¶ | skipping to change at page 20, line 39 ¶ | |||
the future, RREQ and RREP messages could be equipped with new fields | the future, RREQ and RREP messages could be equipped with new fields | |||
for use in verifying link metrics. In particular, it is possible to | for use in verifying link metrics. In particular, it is possible to | |||
identify unidirectional links; an RREQ received across a | identify unidirectional links; an RREQ received across a | |||
unidirectional link has to be dropped, since the destination node | unidirectional link has to be dropped, since the destination node | |||
cannot make use of the received DODAG to route packets back to the | cannot make use of the received DODAG to route packets back to the | |||
source node that originated the route discovery operation. This is | source node that originated the route discovery operation. This is | |||
roughly the same as considering a unidirectional link to present an | roughly the same as considering a unidirectional link to present an | |||
infinite cost metric that automatically disqualifies it for use in | infinite cost metric that automatically disqualifies it for use in | |||
the reverse direction. | the reverse direction. | |||
12. References | 12. Contributors | |||
12.1. Normative References | Abdur Rashid Sangi | |||
Huaiyin Institute of Technology | ||||
No.89 North Beijing Road, Qinghe District | ||||
Huaian 223001 | ||||
P.R. China | ||||
Email: sangi_bahrian@yahoo.com | ||||
13. 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- | [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- | |||
Demand Distance Vector (AODV) Routing", RFC 3561, | Demand Distance Vector (AODV) Routing", RFC 3561, | |||
DOI 10.17487/RFC3561, July 2003, | DOI 10.17487/RFC3561, July 2003, | |||
<https://www.rfc-editor.org/info/rfc3561>. | <https://www.rfc-editor.org/info/rfc3561>. | |||
skipping to change at page 21, line 33 ¶ | skipping to change at page 22, line 11 ¶ | |||
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, | [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, | |||
"A Mechanism to Measure the Routing Metrics along a Point- | "A Mechanism to Measure the Routing Metrics along a Point- | |||
to-Point Route in a Low-Power and Lossy Network", | to-Point Route in a Low-Power and Lossy Network", | |||
RFC 6998, DOI 10.17487/RFC6998, August 2013, | RFC 6998, DOI 10.17487/RFC6998, August 2013, | |||
<https://www.rfc-editor.org/info/rfc6998>. | <https://www.rfc-editor.org/info/rfc6998>. | |||
12.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] | ||||
Perlman, R., "Fault-Tolerant Broadcast of Routing | ||||
Information", December 1983. | ||||
[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>. | |||
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 | |||
+-------------------------+----------------------------------------+ | +-------------------------+----------------------------------------+ | |||
| RSSI at NodeA for NodeB | Expected ETX at NodeA for NodeB->NodeA | | | RSSI at NodeA for NodeB | Expected ETX at NodeA for NodeB->NodeA | | |||
+-------------------------+----------------------------------------+ | +-------------------------+----------------------------------------+ | |||
| > -15 | 150 | | | > -60 | 150 | | |||
| -25 to -15 | 192 | | | -70 to -60 | 192 | | |||
| -35 to -25 | 226 | | | -80 to -70 | 226 | | |||
| -45 to -35 | 662 | | | -90 to -80 | 662 | | |||
| -55 to -45 | 993 | | | -100 to -90 | 993 | | |||
+-------------------------+----------------------------------------+ | +-------------------------+----------------------------------------+ | |||
Table 1: Selection of 'S' bit based on Expected ETX value | Table 1: Selection of 'S' bit based on Expected ETX value | |||
We tested the operations in this specification by making the | We tested the operations in this specification by making the | |||
following experiment, using the above parameters. In our experiment, | following experiment, using the above parameters. In our experiment, | |||
a communication link is considered as symmetric if the ETX value of | a communication link is considered as symmetric if the ETX value of | |||
NodeA->NodeB and NodeB->NodeA (See Figure.8) are, say, within 1:3 | NodeA->NodeB and NodeB->NodeA (See Figure.8) are, say, within 1:3 | |||
ratio. This ratio should be taken as a notional metric for deciding | ratio. This ratio should be taken as a notional metric for deciding | |||
link symmetric/asymmetric nature, and precise definition of the ratio | link symmetric/asymmetric nature, and precise definition of the ratio | |||
skipping to change at page 23, line 20 ¶ | skipping to change at page 24, line 5 ¶ | |||
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.3. Changes to version 04 | ||||
o Add description for sequence number operations. | ||||
o Extend the residence duration L in the section 4.1. | ||||
o Change AODV-RPL Target option to ART option. | ||||
Authors' Addresses | Authors' Addresses | |||
Satish Anamalamudi | Satish Anamalamudi | |||
SRM University-AP | SRM University-AP | |||
Amaravati Campus | Amaravati Campus | |||
Amaravati, Andhra Pradesh 522 502 | Amaravati, Andhra Pradesh 522 502 | |||
India | India | |||
Email: satishnaidu80@gmail.com | Email: satishnaidu80@gmail.com | |||
Mingui Zhang | Mingui Zhang | |||
Huawei Technologies | Huawei Technologies | |||
No. 156 Beiqing Rd. Haidian District | No. 156 Beiqing Rd. Haidian District | |||
Beijing 100095 | Beijing 100095 | |||
China | China | |||
Email: zhangmingui@huawei.com | Email: zhangmingui@huawei.com | |||
Abdur Rashid Sangi | ||||
Huaiyin Institute of Technology | ||||
No.89 North Beijing Road, Qinghe District | ||||
Huaian 223001 | ||||
P.R. China | ||||
Email: sangi_bahrian@yahoo.com | ||||
Charles E. Perkins | Charles E. Perkins | |||
Futurewei | Futurewei | |||
2330 Central Expressway | 2330 Central Expressway | |||
Santa Clara 95050 | Santa Clara 95050 | |||
Unites States | Unites States | |||
Email: charliep@computer.org | Email: charliep@computer.org | |||
S.V.R Anand | S.V.R Anand | |||
Indian Institute of Science | Indian Institute of Science | |||
End of changes. 33 change blocks. | ||||
91 lines changed or deleted | 120 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/ |