< draft-ietf-6lo-minimal-fragment-01.txt   draft-ietf-6lo-minimal-fragment-02.txt >
6lo T. Watteyne, Ed. 6lo T. Watteyne, Ed.
Internet-Draft Analog Devices Internet-Draft Analog Devices
Intended status: Informational C. Bormann Intended status: Informational C. Bormann
Expires: September 12, 2019 Universitaet Bremen TZI Expires: December 26, 2019 Universitaet Bremen TZI
P. Thubert P. Thubert
Cisco Cisco
March 11, 2019 June 24, 2019
LLN Minimal Fragment Forwarding LLN Minimal Fragment Forwarding
draft-ietf-6lo-minimal-fragment-01 draft-ietf-6lo-minimal-fragment-02
Abstract Abstract
This document gives an overview of LLN Minimal Fragment Forwarding. This document gives an overview of LLN Minimal Fragment Forwarding.
When employing adaptation layer fragmentation in 6LoWPAN, it may be When employing adaptation layer fragmentation in 6LoWPAN, it may be
beneficial for a forwarder not to have to reassemble each packet in beneficial for a forwarder not to have to reassemble each packet in
its entirety before forwarding it. This has always been possible its entirety before forwarding it. This has always been possible
with the original fragmentation design of RFC4944. This document is with the original fragmentation design of RFC4944. This document is
a companion document to [I-D.ietf-lwig-6lowpan-virtual-reassembly], a companion document to [I-D.ietf-lwig-6lowpan-virtual-reassembly],
which details the virtual Reassembly Buffer (VRB) implementation which details the virtual Reassembly Buffer (VRB) implementation
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 September 12, 2019. This Internet-Draft will expire on December 26, 2019.
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 19 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview of 6LoWPAN Fragmentation . . . . . . . . . . . . . . 2 1. Overview of 6LoWPAN Fragmentation . . . . . . . . . . . . . . 2
2. Limits of Per-Hop Fragmentation and Reassembly . . . . . . . 4 2. Limits of Per-Hop Fragmentation and Reassembly . . . . . . . 4
2.1. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Memory Management and Reliability . . . . . . . . . . . . 4 2.2. Memory Management and Reliability . . . . . . . . . . . . 4
3. Virtual Reassembly Buffer (VRB) Implementation . . . . . . . 5 3. Virtual Reassembly Buffer (VRB) Implementation . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
7. Informative References . . . . . . . . . . . . . . . . . . . 6 7. Informative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Overview of 6LoWPAN Fragmentation 1. Overview of 6LoWPAN Fragmentation
6LoWPAN fragmentation is defined in [RFC4944]. Although [RFC6282] 6LoWPAN fragmentation is defined in [RFC4944]. Although [RFC6282]
updates [RFC4944], it does not redefine 6LoWPAN fragmentation. updates [RFC4944], it does not redefine 6LoWPAN fragmentation.
We use Figure 1 to illustrate 6LoWPAN fragmentation. We assume node We use Figure 1 to illustrate 6LoWPAN fragmentation. We assume node
A forwards a packet to node B, possibly as part of a multi-hop route A forwards a packet to node B, possibly as part of a multi-hop route
between IPv6 source and destination nodes which are neither A nor B. between IPv6 source and destination nodes which are neither A nor B.
skipping to change at page 3, line 32 skipping to change at page 3, line 32
form that makes it possible to detect when the whole packet has form that makes it possible to detect when the whole packet has
been received and can be processed or forwarded, been received and can be processed or forwarded,
o a timer that allows discarding a partially reassembled packet o a timer that allows discarding a partially reassembled packet
after some timeout. after some timeout.
A fragmentation header is added to each fragment; it indicates what A fragmentation header is added to each fragment; it indicates what
portion of the packet that fragment corresponds to. Section 5.3 of portion of the packet that fragment corresponds to. Section 5.3 of
[RFC4944] defines the format of the header for the first and [RFC4944] defines the format of the header for the first and
subsequent fragments. All fragments are tagged with a 16-bit subsequent fragments. All fragments are tagged with a 16-bit
"datagram_tag", used to identify which packet each fragment belongs "datagram_tag", used to identify which packet each fragment belongs
to. Each fragment can be uniquely identified by the source and to. Each datagram can be uniquely identified by the source and final
destination link-layer addresses of the frame that carries it, and destination link-layer addresses of the frame that carries it, the
the datagram_tag. The value of the datagram_tag only needs to be fragment size and the datagram_tag. Each fragment can be identified
locally unique to nodes A and B. within its datagram by the datagram-offset.
Node B's typical behavior, per [RFC4944], is as follows. Upon Node B's typical behavior, per [RFC4944], is as follows. Upon
receiving a fragment from node A with a datagram_tag previously receiving a fragment from node A with a datagram_tag previously
unseen from node A, node B allocates a buffer large enough to hold unseen from node A, node B allocates a buffer large enough to hold
the entire packet. The length of the packet is indicated in each the entire packet. The length of the packet is indicated in each
fragment (the datagram_size field), so node B can allocate the buffer fragment (the datagram_size field), so node B can allocate the buffer
even if the first fragment it receives is not fragment 1. As even if the first fragment it receives is not fragment 1. As
fragments come in, node B fills the buffer. When all fragments have fragments come in, node B fills the buffer. When all fragments have
been received, node B inflates the compressed header fields into an been received, node B inflates the compressed header fields into an
IPv6 header, and hands the resulting IPv6 packet to the IPv6 layer. IPv6 header, and hands the resulting IPv6 packet to the IPv6 layer.
skipping to change at page 4, line 23 skipping to change at page 4, line 23
When reassembling, a node needs to wait for all the fragments to be When reassembling, a node needs to wait for all the fragments to be
received before being able to generate the IPv6 packet, and possibly received before being able to generate the IPv6 packet, and possibly
forward it to the next hop. This repeats at every hop. forward it to the next hop. This repeats at every hop.
This may result in increased end-to-end latency compared to a case This may result in increased end-to-end latency compared to a case
where each fragment is forwarded without per-hop reassembly. where each fragment is forwarded without per-hop reassembly.
2.2. Memory Management and Reliability 2.2. Memory Management and Reliability
Constrained nodes have limited memory. Assuming 1 kB reassembly Constrained nodes have limited memory. Assuming 1 kB reassembly
buffers, typical nodes only have enough memory for 1-3 reassembly buffer, typical nodes only have enough memory for 1-3 reassembly
buffers. buffers.
Assuming the topology from Figure 2, where nodes A, B, C and D all To illustrate this we use the topology from Figure 2, where nodes A,
send packets through node E. We further assume that node E's memory B, C and D all send packets through node E. We further assume that
can only hold 3 reassembly buffers. node E's memory can only hold 3 reassembly buffers.
+---+ +---+ +---+ +---+
... --->| A |------>| B | ... --->| A |------>| B |
+---+ +---+\ +---+ +---+\
\ \
+---+ +---+ +---+ +---+
| E |--->| F | ... | E |--->| F | ...
+---+ +---+ +---+ +---+
/ /
/ /
skipping to change at page 5, line 12 skipping to change at page 5, line 12
D also sends a fragmented packet, node E has no option but to drop D also sends a fragmented packet, node E has no option but to drop
one of the packets, lowering end-to-end reliability. one of the packets, lowering end-to-end reliability.
3. Virtual Reassembly Buffer (VRB) Implementation 3. Virtual Reassembly Buffer (VRB) Implementation
Virtual Reassembly Buffer (VRB) is the implementation technique Virtual Reassembly Buffer (VRB) is the implementation technique
described in [I-D.ietf-lwig-6lowpan-virtual-reassembly] in which a described in [I-D.ietf-lwig-6lowpan-virtual-reassembly] in which a
forwarder does not reassemble each packet in its entirety before forwarder does not reassemble each packet in its entirety before
forwarding it. forwarding it.
VRB overcomes the limits listed in Section 2. Nodes don't wait for VRB overcomes the limits listed in Section 2. Nodes do not wait for
the last fragment before forwarding, reducing end-to-end latency. the last fragment before forwarding, reducing end-to-end latency.
Similarly, the memory footprint of VRB is just the VRB table, Similarly, the memory footprint of VRB is just the VRB table,
reducing the packet drop probability significantly. reducing the packet drop probability significantly.
There are, however, limits: There are, however, limits:
Non-zero Packet Drop Probability: Each VRB table entry can be 12 B Non-zero Packet Drop Probability: The abstract data in a VRB table
(assuming 16-bit link-layer addresses). This is a footprint 2 entry contains at a minimum the MAC address of the predecessor
orders of magnitude smaller compared to needing a 1280-byte and that of the successor, the datagram_tag used by the
reassembly buffer for each packet. Yet, the size of the VRB predecessor and the local datagram_tag that this node will swap
table necessarily remains finite. In the extreme case where a with it. The VRB may need to store a few octets from the last
node is required to concurrently forward more packets that it has fragment that may not have fit within MTU and that will be
entries in its VRB table, packets are dropped. prepended to the next fragment. This yields a small footprint
that is 2 orders of magnitude smaller compared to needing a
1280-byte reassembly buffer for each packet. Yet, the size of
the VRB table necessarily remains finite. In the extreme case
where a node is required to concurrently forward more packets
that it has entries in its VRB table, packets are dropped.
No Fragment Recovery: There is no mechanism in VRB for the node that No Fragment Recovery: There is no mechanism in VRB for the node that
reassembles a packet to request a single missing fragment. reassembles a packet to request a single missing fragment.
Dropping a fragment requires the whole packet to be resent. This Dropping a fragment requires the whole packet to be resent. This
causes unnecessary traffic, as fragments are forwarded even when causes unnecessary traffic, as fragments are forwarded even when
the destination node can never construct the original IPv6 the destination node can never construct the original IPv6
packet. packet.
No Per-Fragment Routing: All subsequent fragments follow the same No Per-Fragment Routing: All subsequent fragments follow the same
sequence of hops from the source to the destination node as sequence of hops from the source to the destination node as the
fragment 1. first fragment, because the IP header is required to route the
fragment and is only present in the first fragment. A side
effect is that the first fragment must always be forwarded first.
The severity and occurrence of these limits depends on the link-layer The severity and occurrence of these limits depends on the link-layer
used. Whether these limits are acceptable depends entirely on the used. Whether these limits are acceptable depends entirely on the
requirements the application places on the network. requirements the application places on the network.
If the limits are present and not acceptable for the application, If the limits are present and not acceptable for the application,
future specifications may define new protocols to overcome these future specifications may define new protocols to overcome these
limits. One example is [I-D.thubert-6lo-fragment-recovery] which limits. One example is [I-D.ietf-6lo-fragment-recovery] which
defines a protocol which allows fragment recovery. defines a protocol which allows fragment recovery.
4. Security Considerations 4. Security Considerations
An attacker can perform a DoS attack on a node implementing VRB by An attacker can perform a Denial-of-Service (DoS) attack on a node
generating a large number of bogus "fragment 1" fragments without implementing VRB by generating a large number of bogus "fragment 1"
sending subsequent fragments. This causes the VRB table to fill up. fragments without sending subsequent fragments. This causes the VRB
table to fill up. Note that the VRB does not need to remember the
full datagram as received so far but only possibly a few octets from
the last fragment that could not fit in it. It is expected that an
implementation protects itself to keep the number of VRBs within
capacity, and that old VRBs are protected by a timer of a reasonable
duration for the technology and destroyed upon timeout.
Secure joining and the link-layer security that it sets up protects Secure joining and the link-layer security that it sets up protects
against those attacks from network outsiders. against those attacks from network outsiders.
5. IANA Considerations 5. IANA Considerations
No requests to IANA are made by this document. No requests to IANA are made by this document.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank Yasuyuki Tanaka for his in-depth The authors would like to thank Yasuyuki Tanaka, for his in-depth
review of this document. review of this document. Also many thanks to Georgies Papadopoulos
and Dominique Barthel for their own reviews.
7. Informative References 7. Informative References
[ARTICLE] Tanaka, Y., Minet, P., and T. Watteyne, "6LoWPAN Fragment [ARTICLE] Tanaka, Y., Minet, P., and T. Watteyne, "6LoWPAN Fragment
Forwarding", IEEE Communications Standards Magazine , Forwarding", IEEE Communications Standards Magazine ,
2009. 2019.
[BOOK] Shelby, Z. and C. Bormann, "6LoWPAN", John Wiley & Sons, [BOOK] Shelby, Z. and C. Bormann, "6LoWPAN", John Wiley & Sons,
Ltd monograph, DOI 10.1002/9780470686218, November 2009. Ltd monograph, DOI 10.1002/9780470686218, November 2009.
[I-D.ietf-6lo-fragment-recovery]
Thubert, P., "6LoWPAN Selective Fragment Recovery", draft-
ietf-6lo-fragment-recovery-04 (work in progress), June
2019.
[I-D.ietf-lwig-6lowpan-virtual-reassembly] [I-D.ietf-lwig-6lowpan-virtual-reassembly]
Bormann, C. and T. Watteyne, "Virtual reassembly buffers Bormann, C. and T. Watteyne, "Virtual reassembly buffers
in 6LoWPAN", draft-ietf-lwig-6lowpan-virtual-reassembly-00 in 6LoWPAN", draft-ietf-lwig-6lowpan-virtual-reassembly-01
(work in progress), July 2018. (work in progress), March 2019.
[I-D.thubert-6lo-fragment-recovery]
Thubert, P., "6LoWPAN Selective Fragment Recovery", draft-
thubert-6lo-fragment-recovery-01 (work in progress), June
2018.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
 End of changes. 18 change blocks. 
38 lines changed or deleted 52 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/