RPL Storing Root Ack
draft-jadhav-roll-storing-rootack-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Rahul Jadhav | ||
| Last updated | 2020-04-20 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jadhav-roll-storing-rootack-00
ROLL R. Jadhav, Ed.
Internet-Draft Huawei
Intended status: Standards Track April 20, 2020
Expires: October 22, 2020
RPL Storing Root Ack
draft-jadhav-roll-storing-rootack-00
Abstract
This document explains problems with DAO-ACK handling in RPL Storing
MOP and provides updates to RFC6550 to solve those problems.
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 https://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 October 22, 2020.
Copyright Notice
Copyright (c) 2020 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
(https://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.
Jadhav Expires October 22, 2020 [Page 1]
Internet-Draft Storing Root Ack April 2020
Table of Contents
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Requirements Language and Terminology . . . . . . . . . . 3
3. Problems with DAO-ACK in Storing MOP . . . . . . . . . . . . 3
3.1. End to End Path Establishment Indication . . . . . . . . 4
3.2. Target node unaware if it needs to retry the DAO . . . . 5
4. Requirements for DAO-ACK handling in Storing MOP . . . . . . 5
5. DAO-ACK from Root . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Transit Information Option update in DAO message . . . . 6
5.2. Root sends DAO-ACK addressed to Target . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Motivation
The primary motivation for this draft is to enlist different issues
with RPL operation and invoke a discussion within the working group.
This draft by itself is not intended for RFC tracks but as a WG
discussion track. This draft may in turn result in other work items
taken up by the WG which may improvise on the issues mentioned
herewith.
2. Introduction
RPL [RFC6550] specifies a proactive distance-vector routing scheme
designed for LLNs (Low Power and Lossy Networks). RPL enables the
network to be formed as a DODAG and supports storing mode and non-
storing mode of operations. Non-storing mode allows reduced memory
resource usage on the nodes by allowing non-BR nodes to operate
without managing a routing table and involves use of source routing
by the Root to direct the traffic along a specific path. In storing
mode of operation the routing happens on hop-by-hop basis and
intermediate routers need to maintain routing tables.
DAO messaging helps to install downstream routing paths in the DODAG.
DAOs are generated on hop-by-hop basis. DAO may contain multiple RPL
Control Options. The Target Option identifies the address prefix for
which the route has to be installed and the corresponding Transit
Information Option identifies the parameters (such as lifetime,
freshness-counter, etc) for the target. The DAO base object contains
Jadhav Expires October 22, 2020 [Page 2]
Internet-Draft Storing Root Ack April 2020
the 'K' flag indicating that a DAO-ACK is sought by the sender. The
DAO, DAO-ACK progresses on hop-by-hop basis all the way till Root.
This draft highlights various issues with RPL DAO-ACK handling in
Storing MOP. The draft provides requirements to solve the issues and
provides an updates to RFC6550 based on these requirements.
2.1. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
MOP = Mode of Operation
NS-MOP = RPL Non-Storing Mode of Operation
S-MOP = RPL Storing Mode of Operation
This document uses terminology described in [RFC6550].
3. Problems with DAO-ACK in Storing MOP
Consider the following topology for the subsequent description:
(Root)
|
|
|
(A)
/ \
/ \
/ \
(B) -(C)
| / |
| / |
| / |
(D)- (E)
\ ;
\ ;
\ ;
(F)
/ \
/ \
/ \
(G) (H)
Figure 1: Sample topology
Jadhav Expires October 22, 2020 [Page 3]
Internet-Draft Storing Root Ack April 2020
3.1. End to End Path Establishment Indication
Nodes need to know whether the end to end path till the Root has been
established before they can initiate application traffic. In case of
NS-MOP, the DAO is addressed to the Root from the Target node and the
Root sends DAO-ACK directly addressed back to the target node. Thus
in case of NS-MOP, the node can make use of this DAO-ACK as an
indication whether the necessary routes have been installed.
However, in case of Storing MOP, the DAO/DAO-ACK signalling happens
at every hop.
Non-Storing MOP
| D ======== B ======== A ======== (Root)
| ---------------DAO------------>
| <-----------DAO-ACK------------
|
V
time
Figure 2: NS-MOP DAO/DAO-ACK handling
Storing MOP
| D ======== B ======== A ======== (Root)
| ---DAO--->
| <-DAO-ACK-
| ---DAO--->
| <-DAO-ACK-
| ---DAO--->
| <-DAO-ACK-
V
time
Figure 3: Storing MOP DAO/DAO-ACK handling
Consider Figure 1, when node D sends a DAO, the node B receives the
DAO and instantly sends back DAO-ACK. Node B then subsequently
generates the DAO with Target as Node D and sends it to node A. The
DAO with Target as Node D may take time (since the DAO is scheduled
with DAO_DELAY timer by every node) to finally reach the Root at
which point the end to end path is established. There is no way for
node D to know when the end to end path is established. This
information is needed for node D to initiate its application traffic.
Initiating application traffic prior to this might almost certainly
lead to application packet retries causing congestion in the network.
Jadhav Expires October 22, 2020 [Page 4]
Internet-Draft Storing Root Ack April 2020
3.2. Target node unaware if it needs to retry the DAO
It is possible that the intermediate 6LR goes down while attempting
to generate DAO on behalf of the target node. In this case, the
target node has no way of knowing to retry the DAO, in which case the
route installation may not happen until the target node's DAO
lifetime expires.
Consider Figure 1, assume that node A was generating DAO with Target
node D and sending it to Root. Node A reboots before attempting to
send DAO to Root. Node A has already sent DAO-ACK downstream to node
B. In this case, the target node D is not aware that sending DAO has
failed somewhere upstream. Note that as per RFC6550 upstream DAO is
scheduled based on DAO_DELAY but DAO_ACK is sent instantaneously on
DAO reception from downstream node.
4. Requirements for DAO-ACK handling in Storing MOP
Following are the requirements:
Indicate end to end path establishment The Target node must know
when to initiate the application traffic based on end to end path
establishment.
Handle multiple targets in DAOs A DAO message may contain multiple
Target Options. The DAO-ACK mechanism must handle multiple
targets in DAO.
Handle DAOs with address prefix RPL DAO Target Option may contain an
address prefix i.e., not the full address.
Provide suitable way for target node to retry The Target node must
have a way to know and retry the DAO in case the DAO transmission
fails enroute.
Backward compatible with current DAO-ACK The current per hop DAO-ACK
must function as it is. Legacy nodes should be able to operate
without any changes.
5. DAO-ACK from Root
The draft defines a way for the RPL Root to send the DAO-ACK back
directly addressed to the Target node. The Target node can receive
the DAO-ACK directly thus getting an indication that the end to end
path till the Root has been successfully established.
Jadhav Expires October 22, 2020 [Page 5]
Internet-Draft Storing Root Ack April 2020
5.1. Transit Information Option update in DAO message
The Target node indicates that it wishes to receive DAO-ACK directly
from Root by setting the newly defined 'K' flag in Transit
Information Option.
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 = 0x06 | Option Length |E|I|K| Flags | Path Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Updated Transit Information Option (New K flag added)
5.2. Root sends DAO-ACK addressed to Target
On receiving a DAO with Transit Information Option with 'K' flag set,
the Root MUST respond with a DAO-ACK immediately to the address
extracted from the corresponding Target Option.
The DAO-ACK MUST contain the Transit Information Option with
parameters copied from the DAO's Transit Information Option based on
which this DAO-ACK was generated. The PathSequence in the Transit
Information Option helps the Target node to identify for which DAO it
generated it has received the DAO-ACK. The DAOSequence in the base
DAO object is ignored by the Target node.
6. Acknowledgements
7. IANA Considerations
IANA is requested to allocate bit 2 from the Transit Information
Option Flags registry for the 'K' flag (Section 5.1).
8. Security Considerations
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Jadhav Expires October 22, 2020 [Page 6]
Internet-Draft Storing Root Ack April 2020
[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,
<https://www.rfc-editor.org/info/rfc6550>.
9.2. Informative References
[Perlman83]
Perlman, R., "Fault-Tolerant Broadcast of Routing
Information", North-Holland Computer Networks, Vol.7,
December 1983.
Author's Address
Rahul Arvind Jadhav (editor)
Huawei
Whitefield,
Bangalore, Karnataka 560037
India
Email: rahul.ietf@gmail.com
Jadhav Expires October 22, 2020 [Page 7]