Internet DRAFT - draft-satish-6tisch-aodv-rpl
draft-satish-6tisch-aodv-rpl
6tisch S. Anamalamudi
Internet-Draft M. Zhang
Intended status: Standards Track Huawei Technologies
Expires: September 19, 2016 C. Perkins
Futurewei
D. Liu
China Telcom Co., Ltd
S.V.R.Anand
Indian Institute of Science
March 18, 2016
Asymmetrical AODV-P2P-RPL in 6tisch Networks
draft-satish-6tisch-aodv-rpl-00
Abstract
Asymmetrical link based time-sensitive traffic flows with highly
reliable shortest end-to-end route discovery is pre-requisite in IPv6
over the TSCH mode of IEEE 802.15.4e (6tisch) Networks. To achieve,
this document specifies a resource reservation based reactive P2P
route discovery mechanism for hop-by-hop routing (storing mode) based
on Ad Hoc On-demand Distance Vector Routing (AODV) RPL protocol for
6tisch Networks. Two separate instances are used to achieve
directional paths based on asymmetric links in between source and
destination.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 19, 2016.
Anamalamudi, et al. Expires September 19, 2016 [Page 1]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of AODV-RPL . . . . . . . . . . . . . . . . . . . . 5
4. AODV Route Discovery Mode . . . . . . . . . . . . . . . . . . 5
4.1. Route Discovery mode for DIO-RREQ-Instance-1 . . . . . . 8
4.2. Route Discovery mode for DIO-RREQ-Instance-2 . . . . . . 10
5. Resource reservation for P2P Communication at 6TOP . . . . . 12
5.1. Operation of Trickle TImer . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. Additions to Mode of Operation . . . . . . . . . . . . . 14
6.2. Additions to RPL Control Message Options . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. References . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Deterministic Networks enable time sensitive traffic flows that are
highly sensitive to jitter, quite sensitive to latency, and with a
high degree of operational criticality. This clearly depicts that
nodes in the Deterministic networks need to be scheduled to support
critical packet flows. To achieve this, 6TiSCH Working Group focus
on the Time Slotted Channel Hopping (TSCH) mode of the IEEE802.15.4e
standard to schedule traffic flows through Channel Distribution and
Usage (CDU) matrix. [I-D.ietf-6tisch-minimal] describes about
initial formation of 6tisch network during network bootstrap through
Enhanced Beacons (EB). RPL [RFC6550], the IPv6 distance vector
routing protocol for Low-power and Lossy Networks (LLNs), is used on
the resulting 6tisch network. RPL is designed to support multiple
Anamalamudi, et al. Expires September 19, 2016 [Page 2]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
traffic flows through a root-based Destination Oriented Directed
Acyclic Graph (DODAG). For Point-to-Point (P2P) traffic flows
(meaning that two routers within the RPL network need to
communicate), this mean that data packets either have to traverse the
root in non-storing mode (source routing), or traverse a common
ancestor in storing mode (hop-by-hop routing). Such P2P traffic
thereby flows along sub-optimal routes between arbitrary router pairs
and may suffer severe traffic congestion near the DAG root [RFC6997],
[RFC6998]. This sub-optimal paths in RPL[RFC6550] result in
increased resource reservation control overhead (6top control message
overhead) and in-efficient bandwidth allocation (cells) for P2P
traffic flows in 6tisch networks. To avoid this issue, it is
desirable for child node to acquire resources (cells) reactively from
its next hop neighbor (temporary parent) towards destination instead
of original parent of RPL. In addition, severe traffic congestion
near the DAG root MAY leads to increased packet drops that need to be
taken care more efficiently for time-sensitive traffic flows in
6tisch networks.
To overcome sub-optimal paths for P2P traffic flows in RPL, P2P-RPL
[RFC6997] is proposed with a temporary DODAG where the source acts as
temporary root. The source initiates "P2P Route Discovery mode (P2P-
RDO)" with "address vector" for both non-storing mode (H=0) and
storing mode (H=1). Subsequently, each intermediate router will add
its IP address and multicast the P2P-RDO message again, until it
reaches the destination. The destination will send "Discovery reply
option", using either "hop-by-hop routing" or "source routing", based
on "H" field in P2P-RDO. The proposed solution is efficient for
source routing, but much less efficient for hop-by-hop routing. This
is due to the extra address vector overhead in hop-by-hop routing.
In fact, when the P2P-RDO message is being multicast from the source
hop-by-hop, receiving nodes are able to figure out a next hop towards
the source in symmetric links. Subsequently, when the destination
replies to the source along the established routes, receiving nodes
can once again figure out the next hop towards the destination. In
other words, it is efficient to use only routing tables for P2P-RDO
message instead of "Address vector" for purely hop-by-hop routes
(H=1) in symmetrical links.
Both RPL and P2P-RPL is proposed for single DODAG where bi-
directional symmetrical links are assumed. But, application-specific
routing requirements that are defined in IETF ROLL Working Group
[RFC5548], [RFC5673], [RFC5826] and [RFC5867] may have routing
metrics and routing constraints that refer to links with bi-
directional asymmetric properties. To achieve this,
[I-D.thubert-roll-asymlink] describes about bi-directional
asymmetrical links for RPL [RFC6550] with Paired DODAGs where the DAG
root (DODAGID) is common for two Instances. This satisfies the
Anamalamudi, et al. Expires September 19, 2016 [Page 3]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
application-specific routing requirements for bi-directional
asymmetrical links in root based RPL [RFC6550]. However, P2P-RPL
[RFC6997] for Paired DODAGs may need to have two DAG roots: one for
the source and the other for the destination due to on-demand
temporary DODAG formation. Moreover, applications in deterministic
networks [I-D.grossman-detnet-use-cases] MAY also need to allocate
asymmetrical links for P2P traffic flows where resource reservation
(cell allocation) is different for bi-directional links. To achieve,
this document specifies P2P route discovery through AODV-RPL, given
the network supports bi-directional asymmetric links (See Section 4)
and describes how 6top reserves resources (See Section 5) required by
the discovered route [I-D.wang-6tisch-6top-sublayer]. This scenario
requires two multicast messages to discover routes for bi-directional
asymmetric links. With AODV-RPL, there is no "Address vector"
control overhead during route discovery for paired DODAG scenarios.
It is noteworthy that proposed AODV-RPL is designed on the top of the
RPL routing protocol[RFC6550].
The main objective of AODV-RPL with bi-directional asymmetric links
is to discover P2P routes reactively rather than those available
along a global DAG [I-D.thubert-roll-asymlink]. The discovered
routes of each bi-directional path must meet the application specific
metrics and constraints that are separately defined in each Objective
Function for each instance [RFC6552]. In this specification, all the
nodes within the constrained network are required to support both
instances to enable on-demand route establishment.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. Additionally, this document uses the following terms:
AODV
Ad Hoc On-demand Distance Vector Routing[RFC3561].
Source
The IPv6 router initiating the AODV-RPL route discovery.
Destination
The IPv6 router at the other end point of the P2P route(s) within
the LLN network.
Bi-directional Asymmetric Link
A link that can be used in both directions but with different link
characteristics. [I-D.thubert-roll-asymlink]
Anamalamudi, et al. Expires September 19, 2016 [Page 4]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
Instance-1
Instance used for control transmission from Source to Destination
and data transmission from Destination to Source.
Instance-2
Instance used for control transmission from Destination to Source
and data transmission from Source to Destination.
hop-by-hop routing
Routing when each node stores routing information about the next
hop towards Source or Destination.
Paired DODAGs
Two DODAGs for a single application.
P2P
Point-to-Point.
source routing
The mechanism by which the source supplies the complete route to
the destination along with each data packet [RFC6997].
3. Overview of AODV-RPL
With AODV-RPL, routes from Source to Destination within the LLN
network are "on-demand"; in other words, the route discovery
mechanism in AODV-RPL will be performed reactively when source has
data for delivery to the Destination but existing routes do not
satisfy the application's requirements. Unlike base RPL [RFC6550]
and P2P-RPL [RFC6997], AODV-RPL can determine routes in networks with
bi-directional asymmetric links. In other words, AODV-RPL is
designed to discover two routes namely one from Source to Destination
and other from Destination to Source. In addition, AODV-RPL can also
support purely symmetric links for Paired DODAGs through "A" bit that
is explained in Section 4.
4. AODV Route Discovery Mode
In AODV-RPL, route discovery is initiated by forming a temporary DAG
rooted at the Source. Paired DODAGs are used to achieve bi-
directional asymmetrical link formation in between Source and
Destination. AODV-RPL is designed to support two instances.
Instance-1 is used for the route control messages from Source to
Destination whereas Instance-2 is used for route control messages
from Destination to Source (as shown in Figure 2). Intermediate
routers join the Paired DODAGs based on the rank determined from the
DIO message. Henceforth in this document, the DIO-RREQ-Instance-1
message represents the Route Discovery message from Source to
Anamalamudi, et al. Expires September 19, 2016 [Page 5]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
Destination whereas DIO-RREQ-Instance-2 represents the Route
Discovery message from Destination to Source. Subsequently,
Instance-1 is used for data transmission from Destination to Source
and Instance-2 is used for Data transmission from Source to
Destination. The operation of the discovery mechanism resembles base
RPL, extended by a new option called AODV-RREQ in a modified DIO
message [I-D.thubert-roll-asymlink]. A new bit called Asymmetric bit
("A") is added to the base DIO message as shown in Figure 1. Source
will always set the "D" bit to 1 and "A" bit to 0 while initiating
the DIO-RREQ-Instance-1 message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |Version Number | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|D| MOP | Prf | DTSN | Flags |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
Figure 1: Modified DI0 to support asymmetric links
The "D" bit in the DIO message indicates the directional DODAG
information whereas "A" bit describes the link nature (Asymmetric or
Symmetric). Figure 2 describes about operation of "A" bit for
symmetrical and asymmetrical links.If the DIO-RREQ-Instance-1 arrives
over an interface (Intermediate router) that is known to be
symmetric, and the 'A' bit is set to 0, then it remains set at 0 (see
Figure 2(a)). If the DIO-RREQ-Instance-1 arrives over an interface
that is not known to be symmetric, or is known to be asymmetric, then
the 'A' bit is set to be 1. If the 'A' bit arrives already set to be
'1', it is set to be '1' on retransmission (Figure 2(b)). The 'A'
bit is set to mean that the route is asymmetric. If any Intermediate
router along the way believes that the incoming link is asymmetric,
then the "A" bit is set to be 1 and remains set to be 1 all the way
to the destination. Otherwise if there are no asymmetric links the
"A" bit remains set to zero. Based on the "A" bit received by
Destination in DIO-RREQ-Instance-1, link nature (Asymmetric or
Symmetric) is decided to transmit DIO-RREQ-Instance-2 message back to
Source.
Anamalamudi, et al. Expires September 19, 2016 [Page 6]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
--Instance-1 (Control:S->D;Data:D->S) ------>
A=0 A=0 A=0
<--> <--> <-->
R--------R--------R--------R
| | | |
| A=0 | | A=0 |
A=0 |<--> | | <--> | A=0 A=0
<--> | | | | <--> <-->
S--------R--------R--------R--------R--------R---------D
| | | | | |
| | | | | |
| | | | | |
R--------R--------R--------R--------R---------R
<--Instance-2(Control:D->S;Data:S->D)--------
(a). AODV-RPL with Symmetrical links
--Instance-1 (Control:S->D;Data:D->S) ------>
A=0 A=0 A=1
--> --> -->
R--------R--------R--------R
| | | |
|A=0 | | A=1 |
A=0 |--> | | --> | A=1 A=1
--> | | | ------ --> -->
S--------R--------R--------R--------R--------R---------D
| | | | | |
A=1 | | | | | |
<-- |A=1 | | | | |A=1
|<-- | | | | |<--
| | | | | |
R--------R--------R--------R--------R---------R
A=1 A=1 A=1 A=1 A=1
<-- <-- <-- <-- <--
<--Instance-2(Control:D->S;Data:S->D)--------
(b). AODV-RPL with Asymmetrical links
S :Source
R :Intermediate nodes
D :Destination
Figure 2: AODV-RPL with Paired Instances
Anamalamudi, et al. Expires September 19, 2016 [Page 7]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
The value of 'A' bit (Symmetric or Asymmetric) can be decided by the
available radio resources (cells) (See Section.5) during DIO-RREQ-
Instance-1 message. Based on the received number of cell requests
(NumCell) from ADDRequest in DIO-RREQ-Instance-1, Intermediate node
will decide to set 'A' bit to '1' or remain to set 'A' bit to '0'.
For example, if intermediate node has resource (cells) to transmit
data for only one direction then it set A bit to '1'. If it has
resources (cells) to support data in both directions then it can
remain the 'A' bit to '0'. Even if there is atleast one link along
the path of DIO-RREQ-Instance-1 that does not have cells for both
directions then 'A' bit is set to '1' and Destination will start to
multicast DIO-RREQ-Instance-2(see Figure 2(b)). If all the
Intermediate nodes have cells for both directions then 'A' bit will
be remain to '0' and DIO-RREQ-Instance-2 is unicast back in same path
of DIO-RREQ-Instance-1 (see Figure 2(a)).
4.1. Route Discovery mode for DIO-RREQ-Instance-1
The AODV-RPL Source specifies the following information in the DIO-
RREQ-Instance-1 message:
- D-bit
Directional bit in the DIO base object (D=1 for DIO-RREQ-
Instance-1 message)[I-D.thubert-roll-asymlink].
- A-bit
Asymmetric bit in the DIO base object (A=0 for DIO-RREQ-Instance-1
message).
- MOP bit
MOP operation in the DIO object MUST be set to "5(tbd)" by Source
for "AODV-RPL".
- RPLInstanceID
RPLInstanceID in the DIO object MUST be the InstanceID of
Instance-1.
- DODAGID
DODAGID in the DIO object MUST be the IPv6 address of the Source
that initiates the DIO-RREQ message of Instance-1.
- Rank
Anamalamudi, et al. Expires September 19, 2016 [Page 8]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
Rank in the DIO object MUST be the the rank of Instance-1.
- Metric Container Options
DIO-RREQ-Instance-1 message from Source MAY carry one or more
Metric Container options to specify the relevant routing metrics.
- Destination address
IPv6 address of the Destination that receives DIO-RREQ-Instance-1
message. This address MUST be in the modified RREQ option (see
Figure 3) of AODV [RFC3561].
- G bit
G(Gratuitous RREP flag) bit is set to "1" when Source has
Destination Sequence number. When an intermediate node has a
route towards destination with higher Destination Sequence number
then Gratuitous DIO-RREP messages are unicast from the
intermediate node to Destination. Note that Intermediate nodes
never reply unicast Gratuitous DIO-RREP messages back to Source in
Instance-1.
- J bit
Derived from [RFC3561].Out of scope for this specification.
- R bit
Derived from [RFC3561].Out of scope for this specification.
- D bit
Derived from [RFC3561].Out of scope for this specification.
- U bit
Derived from [RFC3561].Out of scope for this specification.
The Source in Figure 2 will multicast the DIO-RREQ-Instance-1 message
(see Figure 3) to its one-hop neighbours. Intermediate nodes will
compute the rank for Instance-1 and create a routing table entry for
path towards the source if the routing metrics/constraints are
satisfied. Subsequently, it checks for already existing path towards
destination by comparing the Destination Sequence Numbers. Whenever
the path exists from intermediate node to Destination, it unicast the
Gratuitous DIO-RREP towards destination and creates the path towards
Source for Instance-1. This helps to minimize the route control
Anamalamudi, et al. Expires September 19, 2016 [Page 9]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
message multicast overhead during Route Discovery process. The
message format of Gratuitous DIO-RREP is same as [RFC3561] with the
exception of the Source IP address which can be obtained through
DODAGID of DIO base (see Figure 1). If the path towards Destination
does not exist, the intermediate node has to re-multicast the DIO-
RREQ-Instance-1 message with updated rank to the next-hop neighbours
until the message reaches to Destination(Figure 2). Based on the "A"
bit in received DIO-RREQ_instance-1, Destination will decide to
unicast or multicast the DIO-RREQ-Instance-2 message back to Source.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |J|R|G|D|U| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Modified DIO-RREQ message format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|A| Reserved |Prefix Sz| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DIO-Gratuitous-RREP message format
4.2. Route Discovery mode for DIO-RREQ-Instance-2
The AODV-RPL Destination specifies the following information in the
DIO-RREQ-Instance-2 message:
- D-bit
Directional bit in the DIO base object (D=1 for DIO-RREQ-
Instance-2 message)[I-D.thubert-roll-asymlink].
Anamalamudi, et al. Expires September 19, 2016 [Page 10]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
- A-bit
Asymmetric bit in the DIO base object (value of "A" bit for DIO-
RREQ-Instance-2 is directly copied from "A" bit of DIO-RREQ-
Instance-1 message).
- MOP bit
MOP operation in the DIO object MUST be set to "5(tbd)" by
Destination for "AODV-RPL".
- RPLInstanceID
RPLInstanceID in the DIO object MUST be the InstanceID of
Instance-2.
- DODAGID
DODAGID in the DIO object MUST be the IPv6 address of the
Destination that initiates the DIO-RREQ message of Instance-2.
- Rank
Rank in the DIO object MUST be the the rank of Instance-2.
- Metric Container Options
DIO-RREQ-Instance-2 message from Destination MAY carry one or more
Metric Container options to specify the relevant routing metrics.
- Destination address
IPv6 address of the Source that receives DIO-RREQ-Instance-2
message. This address MUST be in the modified RREQ option (see
Figure 3) of AODV [RFC3561].
- G bit
G(Gratuitous RREP flag) bit is set to "1" when Destination has
Source Sequence number. When an Intermediate node has a route
towards Source with higher Source Sequence number then Gratuitous
DIO-RREP messages are unicast from Intermediate node to Source.
Note that Intermediate nodes never reply unicast DIO-RREP messages
back to Destination in Instance-2.
- J bit
Derived from [RFC3561].Out of scope for this specification.
Anamalamudi, et al. Expires September 19, 2016 [Page 11]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
- R bit
Derived from [RFC3561].Out of scope for this specification.
- D bit
Derived from [RFC3561].Out of scope for this specification.
- U bit
Derived from [RFC3561].Out of scope for this specification.
The Destination in Figure 2 start to multicast the DIO-RREQ-
Instance-2 message when the received "A" bit in DIO-RREQ-Instance-1
is set to 1. Intermediate nodes will create the routing tables for
the path towards the Destination during DIO-RREQ-Instance-2 messages
to Source. If the intermediate nodes have path towards the Source,
then it unicast the Gratuitous DIO-RREP towards the Source and
creates the path towards Destination for Instance-2. Once the route
control message is reached to Source, it will start transmitting the
application data packets to the Destination in the path that is
discovered through DIO-RREQ-Instance-2 messages. Similarly,
application data from Destination to Source is transmitted through
the path that is discovered from DIO-RREQ-Instance-1 message.
The Destination in Figure 2 start to unicast the DIO-RREQ-Instance-2
message when the received "A" bit in DIO-RREQ-Instance-1 is set to 0.
In this case, route control messages and application data in between
Source and Destination for both Instance-1 and Instance-2 are
transmitted in symmetrical links.
5. Resource reservation for P2P Communication at 6TOP
Whenever, Source has data to destination it runs the Bandwidth
Estimation Algorithm (BEA)[I-D.dujovne-6tisch-6top-sf0] to estimate
the application bandwidth requirement and map it to required number
of cells. Subsequently, 6P ADD Request
[I-D.wang-6tisch-6top-sublayer] is appended to the DIO-RREQ-
Instance-1 with NumCells equal to application bandwidth requirement
that is known through BEA. It is noteworthy that CellList
(slotoffset, channeloffset) and Container information in 6P ADD
Request is set to zero during DIO-RREQ-Instance-1 multicast from
Source. Once the DIO-RREQ-Instance-1 with 6P ADD Request is reached
to intermediate node, it checks the NumCells field. When an
Intermediate node is able to allocate its transmit and receive cells
that are equal to NumCells of 6P ADD Request, then it is eligible to
re-multicast the DIO-RREQ-Instance-1 with 6P ADD Request. At this
point, link nature (Symmetrical or Asymmetrical) is decided by
Anamalamudi, et al. Expires September 19, 2016 [Page 12]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
Intermediate node based on the available resources (cells). If an
Intermediate node has transmit and receive cells for both directions
that are greater than or equal to NumCells of 6P ADD Request then 'A'
bit is remain to set to '0'. If an intermediate node has cells
available only for one direction (Destination to Source) then 'A' bit
is set to '1' and it re-multicast the DIO-RREQ-Instance-1. Whenever,
the intermediate node has Destination Sequence number that is greater
than Sequence number specified in modified-RREQ then Gratuitous-RREP
is unicast with 6P ADD Request. It is assumed that Intermediate
nodes who know the path towards the Destination must be able to
allocate both transmit and receive cells that are specified in
NumCells to either single direction (Asymmetric) or both directions
(Symmetric). Once the DIO-RREQ-Instance-1 with 6P ADD Request
reaches to the Destination, it checks the 'A' bit to reply the DIO-
RREQ_Instance-2 messages.
For Asymmetrical links(A=1) to Instance-1, it is notable that Source
will allocate only receive cells, Destination will allocate only
transmit cells and Intermediate nodes that multicast route control
messages will allocate both transmit and receive cells to perform
data transmission from Destination to Source in Instance-1.
For asymmetrical links (A=1) to Instance-2, Destination will estimate
the application bandwidth requirement through BEA and map it to
Numcell for DIO-RREQ-Instance-2. It is noteworthy that
CellList(slotoffset, channeloffset) and Container information in 6P
ADD Request is set to zero during DIO-RREQ-Instance-2 multicast from
Destination. Intermediate nodes that are able to allocate it's both
transmit and receive cells of Numcell in 6P ADD Request will re-
multicast the DIO-RREQ-Instance-2 with 6P ADD Request until it
reaches to Source. In this case, 'A' bit is always set to '1'. From
this operation, it is notable that Source will allocate only transmit
cells, Destination will allocate only receive cells and Intermediate
nodes that multicast route control messages will allocate both
transmit and receive cells to perform data transmission from Source
to Destination in Instance-2.
Once the Source know the path towards the Destination in Instance-2,
it performs the actual 6P negotiation (6P ADD Request, 6P ADD
Response) [I-D.wang-6tisch-6top-sublayer] to request and allocates
the CellList (slotoffset, channeloffset) hop-by-hop for actual data
transmission. Similarly, Destination will perform 6P negotiation (6P
ADD Request, 6P ADD Response) [I-D.wang-6tisch-6top-sublayer] to
request and allocate the CellList(slotoffset, channeloffset) hop-by-
hop towards Source in Instance-1 for data transmission. The
cells(bundle) allocated for end-to-end path in Instance-1 is
associated with one TrackID and the cells allocated for end-to-end
path in Instance-2 is associated with another TrackID.
Anamalamudi, et al. Expires September 19, 2016 [Page 13]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
For asymmetrical links (A=1), allocation of transmit-receive cells
for Instance-1 and allocation of transmit-receive cells for
Instance-2 will be in different paths.
For symmetrical links (A=0), Source and Destination will use same
path for both Instance-1 and Instance-2 to transmit data. Hence,
allocation of transmit-receive cells for Instance-1 and allocation of
transmit-receive cells for Instance-2 need to be in same path.
With AODV-RPL, the address vector is not required and resource
reservation (cell allocation) is on-demand during reactive route-
discovery. This efficiently utilizes the control packet size and
radio resources that is most significant in 6tisch networks.
5.1. Operation of Trickle TImer
The operation of Trickle timer to control DIO-RREQ-Instance 1/
Instance-2 message is similar to P2P-RPL Trickle operation [RFC6997].
6. IANA Considerations
6.1. Additions to Mode of Operation
IANA is required to assign a new Mode of Operation, named "AODV-RPL"
for Point-to-Point(P2P) hop-by-hop routing under the RPL registry.
The value of tbd1 is assigned from the "Mode of Operation" space
[RFC6550].
+-------------+---------------+---------------+
| Value | Description | Reference |
+-------------+---------------+---------------+
| tbd1(5) | AODV-RPL | This document |
+-------------+---------------+---------------+
Figure 5: Mode of Operation
6.2. Additions to RPL Control Message Options
IANA is require to assign two entries for a new RPL options: "DIO-
RREQ-Instance-1" and "DIO-RREQ-Instance-1" values of tbd2 (0x0a) and
tbd3(0x0b) from the "RPL Control Message Options" space [RFC6550].
Anamalamudi, et al. Expires September 19, 2016 [Page 14]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
+-------------+----------------------+---------------+
| Value | Meaning | Reference |
+-------------+----------------------+---------------+
| tbd2(0x0a) | DIO-RREQ-Instance-1 | This document |
+-------------+----------------------+---------------+
| tbd3(0x0b) | DIO-RREQ-Instance-2 | This document |
+-------------+----------------------+---------------+
Figure 6: RPL Control Message Options
7. Security Considerations
This document does not introduce additional security issues to
[RFC6550]. For general RPL security considerations, see [RFC6550].
8. References
8.1. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://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,
<http://www.rfc-editor.org/info/rfc3561>.
[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and
D. Barthel, Ed., "Routing Requirements for Urban Low-Power
and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May
2009, <http://www.rfc-editor.org/info/rfc5548>.
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
2009, <http://www.rfc-editor.org/info/rfc5673>.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, DOI 10.17487/RFC5826, April 2010,
<http://www.rfc-editor.org/info/rfc5826>.
[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June
2010, <http://www.rfc-editor.org/info/rfc5867>.
Anamalamudi, et al. Expires September 19, 2016 [Page 15]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012,
<http://www.rfc-editor.org/info/rfc6552>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013,
<http://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,
<http://www.rfc-editor.org/info/rfc6998>.
8.2. Informative References
[I-D.dujovne-6tisch-6top-sf0]
Dujovne, D., Grieco, L., Palattella, M., and N. Accettura,
"6TiSCH 6top Scheduling Function Zero (SF0)", draft-
dujovne-6tisch-6top-sf0-00 (work in progress), October
2015.
[I-D.grossman-detnet-use-cases]
Grossman, E., Gunther, C., Thubert, P., Wetterwald, P.,
Raymond, J., Korhonen, J., Kaneko, Y., Das, S., and Y.
Zha, "Deterministic Networking Use Cases", draft-grossman-
detnet-use-cases-01 (work in progress), November 2015.
[I-D.ietf-6tisch-minimal]
Vilajosana, X. and K. Pister, "Minimal 6TiSCH
Configuration", draft-ietf-6tisch-minimal-15 (work in
progress), February 2016.
[I-D.thubert-roll-asymlink]
Thubert, P., "RPL adaptation for asymmetrical links",
draft-thubert-roll-asymlink-02 (work in progress),
December 2011.
Anamalamudi, et al. Expires September 19, 2016 [Page 16]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
[I-D.wang-6tisch-6top-sublayer]
Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer
(6top)", draft-wang-6tisch-6top-sublayer-04 (work in
progress), November 2015.
Authors' Addresses
Satish Anamalamudi
Huawei Technologies
No. 156 Beiqing Rd. Haidian District
Beijing 100095
China
Email: satish.anamalamudi@huawei.com
Mingui Zhang
Huawei Technologies
No. 156 Beiqing Rd. Haidian District
Beijing 100095
China
Email: zhangmingui@huawei.com
Charles E. Perkins
Futurewei
2330 Central Expressway
Santa Clara 95050
Unites States
Email: charliep@computer.org
Dongxin Liu
China Telcom Co., Ltd
109 West Zhongshan Ave, Tianhe District
Guangzhou 510630
China
Email: liudx@gsta.com
Anamalamudi, et al. Expires September 19, 2016 [Page 17]
Internet-Draft draft-satish-tisch-AODV-RPL March 2016
S.V.R Anand
Indian Institute of Science
Bangalore
560012
India
Email: anand@ece.iisc.ernet.in
Anamalamudi, et al. Expires September 19, 2016 [Page 18]
