< draft-ietf-roll-unaware-leaves-01.txt   draft-ietf-roll-unaware-leaves-02.txt >
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Updates: 6550, 8505 (if approved) July 2, 2019 Updates: 6550, 8505 (if approved) July 4, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: January 3, 2020 Expires: January 5, 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-01 draft-ietf-roll-unaware-leaves-02
Abstract Abstract
This specification leverages 6LoWPAN ND to provide a unicast and This specification leverages 6LoWPAN ND to provide a unicast and
multicast routing service in a RPL domain to 6LNs that do not multicast routing service in a RPL domain to 6LNs that do not
participate to RPL. participate to RPL.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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, 2020. This Internet-Draft will expire on January 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
7.4. RPL Root Operation . . . . . . . . . . . . . . . . . . . 13 7.4. RPL Root Operation . . . . . . . . . . . . . . . . . . . 13
7.5. 6LBR Operation . . . . . . . . . . . . . . . . . . . . . 14 7.5. 6LBR Operation . . . . . . . . . . . . . . . . . . . . . 14
8. Protocol Operations for Multicast Addresses . . . . . . . . . 15 8. Protocol Operations for Multicast Addresses . . . . . . . . . 15
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Example Compression . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The design of Low Power and Lossy Networks (LLNs) is generally The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, which is the most constrained resource of focused on saving energy, which is the most constrained resource of
all. Other design constraints, such as a limited memory capacity, all. Other design constraints, such as a limited memory capacity,
duty cycling of the LLN devices and low-power lossy transmissions, duty cycling of the LLN devices and low-power lossy transmissions,
derive from that primary concern. derive from that primary concern.
The IETF produced the "Routing Protocol for Low Power and Lossy The IETF produced the "Routing Protocol for Low Power and Lossy
skipping to change at page 9, line 12 skipping to change at page 9, line 12
This means in particular that an RPI with an Option Type of 0x23 This means in particular that an RPI with an Option Type of 0x23
[I-D.ietf-roll-useofrplinfo] is ignored when not understood. [I-D.ietf-roll-useofrplinfo] is ignored when not understood.
o An arbitrary 6LN is expected to process an unknown Routing Header o An arbitrary 6LN is expected to process an unknown Routing Header
Type as prescribed by section 4.4 of [RFC8200]. This means in Type as prescribed by section 4.4 of [RFC8200]. This means in
particular that Routing Header with a Routing Type of 3 [RFC6553] particular that Routing Header with a Routing Type of 3 [RFC6553]
is ignored when the Segments Left is zero, and dropped otherwise. is ignored when the Segments Left is zero, and dropped otherwise.
o When IP-in-IP is used and the outer headers terminate at the 6LR o When IP-in-IP is used and the outer headers terminate at the 6LR
that generated the DAO, then the 6LR decapsulates the packet to that generated the DAO, then the 6LR decapsulates the packet to
the 6LN. In that case the 6LN gets a packet that is free of RPL the 6LN ( see Appendix A for the format in Storing Mode). In that
artifacts. IP-in-IP to the 6LR MUST be used if the 6LN cannot case the 6LN gets a packet that is free of RPL artifacts. IP-in-
handle or ignore the RPL artifacts or the way they are compressed IP to the 6LR MUST be used if the 6LN cannot handle or ignore the
[RFC8138]. It SHOULD be used it there is a particular bandwidth RPL artifacts or the way they are compressed [RFC8138]. It SHOULD
or power constraint at the 6LN that justifies saving the be used it there is a particular bandwidth or power constraint at
encapsulation at the last hop. the 6LN that justifies saving the encapsulation at the last hop.
o In order to save the IP-in-IP encapsulation and to support Storing o In order to save the IP-in-IP encapsulation and to support Storing
Mode of operation, it is preferred that the 6LN can ignore an RPI Mode of operation, it is preferred that the 6LN can ignore an RPI
and consume a routing header in both the native and compressed and consume a routing header in both the native and compressed
forms. In order to enable IP-in-IP to a 6LN in Non-Storing Mode, forms. In order to enable IP-in-IP to a 6LN in Non-Storing Mode,
it is also of interest that the 6LN supports decapsulating IP-in- it is also of interest that the 6LN supports decapsulating IP-in-
IP in both forms. But since the preferred behaviour when using IP in both forms. But since the preferred behaviour when using
IP-in-IP is that the outter headers terminate at the 6LR, IP-in-IP is that the outter headers terminate at the 6LR,
supporting this capability is secondary. supporting this capability is secondary.
skipping to change at page 19, line 24 skipping to change at page 19, line 24
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-roll-efficient-npdao] [I-D.ietf-roll-efficient-npdao]
Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient
Route Invalidation", draft-ietf-roll-efficient-npdao-13 Route Invalidation", draft-ietf-roll-efficient-npdao-14
(work in progress), June 2019. (work in progress), July 2019.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPL Robles, I., Richardson, M., and P. Thubert, "Using RPL
Option Type, Routing Header for Source Routes and IPv6-in- Option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", draft-ietf- IPv6 encapsulation in the RPL Data Plane", draft-ietf-
roll-useofrplinfo-30 (work in progress), June 2019. roll-useofrplinfo-30 (work in progress), June 2019.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>.
[RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur, [RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur,
Ed., "Performance Evaluation of the Routing Protocol for Ed., "Performance Evaluation of the Routing Protocol for
Low-Power and Lossy Networks (RPL)", RFC 6687, Low-Power and Lossy Networks (RPL)", RFC 6687,
DOI 10.17487/RFC6687, October 2012, DOI 10.17487/RFC6687, October 2012,
<https://www.rfc-editor.org/info/rfc6687>. <https://www.rfc-editor.org/info/rfc6687>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>. 2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
RFC 8025, DOI 10.17487/RFC8025, November 2016,
<https://www.rfc-editor.org/info/rfc8025>.
Appendix A. Example Compression
Figure 6 illustrates the case in Storing mode where the packet is
received from the Internet, then the root encapsulates the packet to
insert the RPI and deliver to the 6LR that is the parent and last hop
to the final destination, which is not known to support [RFC8138].
The difference with the format presented in Figure 19 of [RFC8138] is
the addition of a SRH-6LoRH before the RPI-6LoRH to transpotr the
destination address of the outer IPv6 header.
+-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|11110001|SRH-6LoRH| RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP
|Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+-+ ... +-+- ... -+-+-- ... -+-+-+ ... +-+-+ ... -+ ... +-...
<-4bytes-> <- RFC 6282 ->
No RPL artifact
Figure 6: Encapsulation to Parent in Storing Mode
In Figure 6, the source of the IP-in-IP encapsulation is the Root, so
it is elided in the IP-in-IP 6LoRH. The destination is the parent
6LR of the destination of the inner packet so it cannot be elided.
In Storing Mode, it is placed as the single entry in an SRH-6LoRH as
the first 6LoRH. Since there is a single entry so the SRH-6LoRH Size
is 0. In this particular example, the 6LR address can be compressed
to 2 bytes so a Type of 1 is used. It results that the total length
of the SRH-6LoRH is 4 bytes.
In Non-Storing Mode, the encapsulation from the root would be similar
to that represented in Figure 6 with possibly more hops in the SRH-
6LoRH and possibly multiple SRH-6LoRHs if the various addresses in
the routing header are not compressed to the same format. Note that
on the last hop to the parent 6LR, the RH3 is consumed and removed
from the compressed form, so the use of Non-Storing Mode vs. Storing
Mode is indistinguishable from the packet format.
Follows the RPI-6LoRH and then the IP-in-IP 6LoRH. When the IP-in-IP
6LoRH is removed, all the router headers that precede it are also
removed.
The Paging Dispatch [RFC8025] may also be removed if there was no
previous Page change to a Page other than 0 or 1, since the
LOWPAN_IPHC is encoded in the same fashion in the default Page 0 and
in Page 1. The resulting packet to the destination is the inner
packet compressed with [RFC6282].
Author's Address Author's Address
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254 MOUGINS - Sophia Antipolis 06254
FRANCE FRANCE
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
 End of changes. 9 change blocks. 
13 lines changed or deleted 70 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/