draft-ietf-roll-routing-dispatch-03.txt   draft-ietf-roll-routing-dispatch-04.txt 
roll P. Thubert, Ed. roll P. Thubert, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track C. Bormann Intended status: Standards Track C. Bormann
Expires: April 28, 2017 Uni Bremen TZI Expires: April 29, 2017 Uni Bremen TZI
L. Toutain L. Toutain
IMT-TELECOM Bretagne IMT-TELECOM Bretagne
R. Cragie R. Cragie
ARM ARM
October 25, 2016 October 26, 2016
6LoWPAN Routing Header 6LoWPAN Routing Header
draft-ietf-roll-routing-dispatch-03 draft-ietf-roll-routing-dispatch-04
Abstract Abstract
This specification introduces a new 6LoWPAN dispatch type for use in This specification introduces a new 6LoWPAN dispatch type for use in
6LoWPAN Route-Over topologies, that initially covers the needs of RPL 6LoWPAN Route-Over topologies, that initially covers the needs of RPL
(RFC6550) data packets compression. Using this dispatch type, this (RFC6550) data packets compression. Using this dispatch type, this
specification defines a method to compress RPL Option (RFC6553) specification defines a method to compress RPL Option (RFC6553)
information and Routing Header type 3 (RFC6554), an efficient IP-in- information and Routing Header type 3 (RFC6554), an efficient IP-in-
IP technique and is extensible for more applications. IP technique and is extensible for more applications.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 April 28, 2017. This Internet-Draft will expire on April 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 1, line 134 skipping to change at page 1, line 134
Innovative Route-over techniques have been and are still being Innovative Route-over techniques have been and are still being
developed for routing inside a LLN. In a general fashion, such developed for routing inside a LLN. In a general fashion, such
techniques require additional information in the packet to provide techniques require additional information in the packet to provide
loop prevention and to indicate information such as flow loop prevention and to indicate information such as flow
identification, source routing information, etc. identification, source routing information, etc.
For reasons such as security and the capability to send ICMPv6 errors For reasons such as security and the capability to send ICMPv6 errors
(see "Internet Control Message Protocol (ICMPv6)" [RFC4443]) back to (see "Internet Control Message Protocol (ICMPv6)" [RFC4443]) back to
the source, an original packet must not be tampered with, and any the source, an original packet must not be tampered with, and any
information that must be inserted in or removed from an IPv6 packet information that must be inserted in or removed from an IPv6 packet
must be placed in an extra IP-in-IP encapsulation . must be placed in an extra IP-in-IP encapsulation.
This is the case when the additional routing information is inserted This is the case when the additional routing information is inserted
by a router on the path of a packet, for instance the root of a mesh, by a router on the path of a packet, for instance the root of a mesh,
as opposed to the source node, with the non-storing mode of the "IPv6 as opposed to the source node, with the non-storing mode of the "IPv6
Routing Protocol for Low-Power and Lossy Networks" [RFC6550] (RPL). Routing Protocol for Low-Power and Lossy Networks" [RFC6550] (RPL).
This is also the case when some routing information must be removed This is also the case when some routing information must be removed
from a packet that flows outside the LLN. from a packet that flows outside the LLN.
"When to use RFC 6553, RFC 6554 and IPv6-in-IPv6" "When to use RFC 6553, RFC 6554 and IPv6-in-IPv6"
skipping to change at page 1, line 201 skipping to change at page 1, line 201
in packets entering the domain and be removed from packets that leave in packets entering the domain and be removed from packets that leave
the domain. In both cases, this operation implies an IP-in-IP the domain. In both cases, this operation implies an IP-in-IP
encapsulation. encapsulation.
Additionally, in the case of the Non-Storing Mode of Operation (MOP), Additionally, in the case of the Non-Storing Mode of Operation (MOP),
RPL requires a Source Routing Header (SRH) in all packets that are RPL requires a Source Routing Header (SRH) in all packets that are
routed down a RPL graph. for that purpose, the "IPv6 Routing Header routed down a RPL graph. for that purpose, the "IPv6 Routing Header
for Source Routes with RPL" [RFC6554] specification defines the type for Source Routes with RPL" [RFC6554] specification defines the type
3 Routing Header for IPv6 (RH3). 3 Routing Header for IPv6 (RH3).
------+--------- ^ ------+--------- ^
| Internet | | Internet |
| | Native IPv6 | | Native IPv6
+-----+ | +-----+ |
| | Border Router (RPL Root) ^ | ^ | | Border Router (RPL Root) + | +
| | | | | | | | | |
+-----+ | | | IPv6 in +-----+ | | | tunneled
| | | | IPv6 | | | | using
o o o o | | | plus o o o o | | | IPv6-in-
o o o o o o o o o | | | RPL SRH o o o o o o o o o | | | IPv6 and
o o o o o o o o o o | | | o o o o o o o o o o | | | RPL SRH
o o o o o o o o o | | | o o o o o o o o o | | |
o o o o o o o o v v v o o o o o o o o | | |
o o o o o o o o + v +
LLN LLN
Figure 2: IP-in-IP Encapsulation within the LLN. Figure 2: IP-in-IP Encapsulation within the LLN.
With Non-Storing RPL, even if the source is a node in the same LLN, With Non-Storing RPL, even if the source is a node in the same LLN,
the packet must first reach up the graph to the root so that the root the packet must first reach up the graph to the root so that the root
can insert the SRH to go down the graph. In any fashion, whether the can insert the SRH to go down the graph. In any fashion, whether the
packet was originated in a node in the LLN or outside the LLN, and packet was originated in a node in the LLN or outside the LLN, and
regardless of whether the packet stays within the LLN or not, as long regardless of whether the packet stays within the LLN or not, as long
as the source of the packet is not the root itself, the source- as the source of the packet is not the root itself, the source-
routing operation also implies an IP-in-IP encapsulation at the root routing operation also implies an IP-in-IP encapsulation at the root
skipping to change at page 29, line 7 skipping to change at page 29, line 7
of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work
in progress), June 2016. in progress), June 2016.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "When to use Robles, I., Richardson, M., and P. Thubert, "When to use
RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
useofrplinfo-09 (work in progress), October 2016. useofrplinfo-09 (work in progress), October 2016.
[I-D.thubert-6lo-forwarding-fragments] [I-D.thubert-6lo-forwarding-fragments]
Thubert, P. and J. Hui, "LLN Fragment Forwarding and Thubert, P. and J. Hui, "LLN Fragment Forwarding and
Recovery", draft-thubert-6lo-forwarding-fragments-02 (work Recovery", draft-thubert-6lo-forwarding-fragments-03 (work
in progress), November 2014. in progress), October 2016.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>. <http://www.rfc-editor.org/info/rfc6775>.
[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, <http://www.rfc-editor.org/info/rfc7102>. 2014, <http://www.rfc-editor.org/info/rfc7102>.
skipping to change at page 32, line 12 skipping to change at page 32, line 12
the DODAG are assigned from a same /112 prefix and the last 2 octets the DODAG are assigned from a same /112 prefix and the last 2 octets
encoding an identifier such as a IEEE 802.15.4 short address. In encoding an identifier such as a IEEE 802.15.4 short address. In
that case, all addresses can be compressed to 2 octets, using the that case, all addresses can be compressed to 2 octets, using the
root address as reference. There will be one SRH_6LoRH header, with, root address as reference. There will be one SRH_6LoRH header, with,
in this example, 3 compressed addresses: in this example, 3 compressed addresses:
+-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|11110001|SRH-6LoRH| RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP |11110001|SRH-6LoRH| RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP
|Page 1 |Type1 S=2| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld |Page 1 |Type1 S=2| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+-+ ... +-+- ... -+-+-- ... -+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+-- ... -+-+-+ ... +-+-+ ... -+ ... +-...
<-8bytes-> <- RFC 6282 -> <-8bytes-> <- RFC 6282 ->
No RPL artifact No RPL artifact
Figure 20: Example Compressed Packet with SRH. Figure 20: Example Compressed Packet with SRH.
One may note that the RPI is provided. This is because the address One may note that the RPI is provided. This is because the address
of the root that is the source of the IP-in-IP header is elided and of the root that is the source of the IP-in-IP header is elided and
inferred from the RPLInstanceID in the RPI. Once found from a local inferred from the RPLInstanceID in the RPI. Once found from a local
context, that address is used as Compression Reference to expand context, that address is used as Compression Reference to expand
addresses in the SRH-6LoRH. addresses in the SRH-6LoRH.
 End of changes. 8 change blocks. 
23 lines changed or deleted 23 lines changed or added

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