< draft-ietf-6lo-fragment-recovery-09.txt   draft-ietf-6lo-fragment-recovery-10.txt >
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 4944 (if approved) 4 February 2020 Updates: 4944 (if approved) 6 February 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 7 August 2020 Expires: 9 August 2020
6LoWPAN Selective Fragment Recovery 6LoWPAN Selective Fragment Recovery
draft-ietf-6lo-fragment-recovery-09 draft-ietf-6lo-fragment-recovery-10
Abstract Abstract
This draft updates RFC 4944 with a simple protocol to recover This draft updates RFC 4944 with a simple protocol to recover
individual fragments across a route-over mesh network, with a minimal individual fragments across a route-over mesh network, with a minimal
flow control to protect the network against bloat. flow control to protect the network against bloat.
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 7 August 2020. This Internet-Draft will expire on 9 August 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 5, line 39 skipping to change at page 5, line 39
expanding a 6LoWPAN header from/to a full IPv6 packet. The expanding a 6LoWPAN header from/to a full IPv6 packet. The
6LoWPAN endpoints are the points where fragmentation and 6LoWPAN endpoints are the points where fragmentation and
reassembly take place. reassembly take place.
Compressed Form: This specification uses the generic term Compressed Compressed Form: This specification uses the generic term Compressed
Form to refer to the format of a datagram after the action of Form to refer to the format of a datagram after the action of
[RFC6282] and possibly [RFC8138] for RPL [RFC6550] artifacts. [RFC6282] and possibly [RFC8138] for RPL [RFC6550] artifacts.
datagram_size: The size of the datagram in its Compressed Form datagram_size: The size of the datagram in its Compressed Form
before it is fragmented. The datagram_size is expressed in a unit before it is fragmented. The datagram_size is expressed in a unit
that depends on the MAC address layer technology, by default a that depends on the MAC layer technology, by default a byte.
byte.
datagram_tag: An identifier of a datagram that is locally unique to datagram_tag: An identifier of a datagram that is locally unique to
the Layer-2 sender. Associated with the MAC addressof the sender, the Layer-2 sender. Associated with the MAC address of the
this becomes a globally unique identifier for the datagram. sender, this becomes a globally unique identifier for the
datagram.
fragment_offset: The offset of a particular fragment of a datagram fragment_offset: The offset of a particular fragment of a datagram
in its Compressed Form. The fragment_offset is expressed in a in its Compressed Form. The fragment_offset is expressed in a
unit that depends on the MAC address layer technology and is by unit that depends on the MAC layer technology and is by default a
default a byte. byte.
RFRAG: Recoverable Fragment RFRAG: Recoverable Fragment
RFRAG-ACK: Recoverable Fragment Acknowledgement RFRAG-ACK: Recoverable Fragment Acknowledgement
RFRAG Acknowledgment Request: An RFRAG with the Acknowledgement RFRAG Acknowledgment Request: An RFRAG with the Acknowledgement
Request flag ('X' flag) set. Request flag ('X' flag) set.
NULL bitmap: Refers to a bitmap with all bits set to zero. NULL bitmap: Refers to a bitmap with all bits set to zero.
FULL bitmap: Refers to a bitmap with all bits set to one. FULL bitmap: Refers to a bitmap with all bits set to one.
skipping to change at page 7, line 16 skipping to change at page 7, line 16
[I-D.ietf-6lo-minimal-fragment] allows for refragmenting in [I-D.ietf-6lo-minimal-fragment] allows for refragmenting in
intermediate nodes, meaning that some bytes from a given fragment may intermediate nodes, meaning that some bytes from a given fragment may
be left in the VRB to be added to the next fragment. The reason for be left in the VRB to be added to the next fragment. The reason for
this happening would be the need for space in the outgoing fragment this happening would be the need for space in the outgoing fragment
that was not needed in the incoming fragment, for instance because that was not needed in the incoming fragment, for instance because
the 6LoWPAN Header Compression is not as efficient on the outgoing the 6LoWPAN Header Compression is not as efficient on the outgoing
link, e.g., if the Interface ID (IID) of the source IPv6 address is link, e.g., if the Interface ID (IID) of the source IPv6 address is
elided by the originator on the first hop because it matches the elided by the originator on the first hop because it matches the
source MAC address, but cannot be on the next hops because the source source MAC address, but cannot be on the next hops because the source
MAC addresschanges. MAC address changes.
This specification cannot allow this operation since fragments are This specification cannot allow this operation since fragments are
recovered end-to-end based on a sequence number. This means that the recovered end-to-end based on a sequence number. This means that the
fragments that contain a 6LoWPAN-compressed header MUST have enough fragments that contain a 6LoWPAN-compressed header MUST have enough
slack to enable a less efficient compression in the next hops that slack to enable a less efficient compression in the next hops that
still fits in one MAC address frame. For instance, if the IID of the still fits in one MAC frame. For instance, if the IID of the source
source IPv6 address is elided by the originator, then it MUST compute IPv6 address is elided by the originator, then it MUST compute the
the fragment_size as if the MTU was 8 bytes less. This way, the next fragment_size as if the MTU was 8 bytes less. This way, the next hop
hop can restore the source IID to the first fragment without can restore the source IID to the first fragment without impacting
impacting the second fragment. the second fragment.
4.2. Gap between frames 4.2. Gap between frames
This specification introduces a concept of an inter-frame gap, which This specification introduces a concept of an inter-frame gap, which
is a configurable interval of time between transmissions to a same is a configurable interval of time between transmissions to a same
next hop. In the case of half duplex interfaces, this inter-frame next hop. In the case of half duplex interfaces, this inter-frame
gap ensures that the next hop has completed processing of the gap ensures that the next hop has completed processing of the
previous frame and is capable of receiving the next one. previous frame and is capable of receiving the next one.
In the case of a mesh operating at a single frequency with In the case of a mesh operating at a single frequency with
skipping to change at page 8, line 23 skipping to change at page 8, line 23
provide an MTU up to 2048 bytes to the upper layer, which can be the provide an MTU up to 2048 bytes to the upper layer, which can be the
6LoWPAN Header Compression sublayer that is defined in the 6LoWPAN Header Compression sublayer that is defined in the
"Compression Format for IPv6 Datagrams" [RFC6282] specification. In "Compression Format for IPv6 Datagrams" [RFC6282] specification. In
order to achieve this, this specification enables the fragmentation order to achieve this, this specification enables the fragmentation
and the reliable transmission of fragments over a multihop 6LoWPAN and the reliable transmission of fragments over a multihop 6LoWPAN
mesh network. mesh network.
This specification provides a technique that is derived from MPLS to This specification provides a technique that is derived from MPLS to
forward individual fragments across a 6LoWPAN route-over mesh without forward individual fragments across a 6LoWPAN route-over mesh without
reassembly at each hop. The datagram_tag is used as a label; it is reassembly at each hop. The datagram_tag is used as a label; it is
locally unique to the node that owns the source MAC addressof the locally unique to the node that owns the source MAC address of the
fragment, so together the MAC addressand the label can identify the fragment, so together the MAC address and the label can identify the
fragment globally. A node may build the datagram_tag in its own fragment globally. A node may build the datagram_tag in its own
locally-significant way, as long as the chosen datagram_tag stays locally-significant way, as long as the chosen datagram_tag stays
unique to the particular datagram for the lifetime of that datagram. unique to the particular datagram for the lifetime of that datagram.
It results that the label does not need to be globally unique but It results that the label does not need to be globally unique but
also that it must be swapped at each hop as the source MAC also that it must be swapped at each hop as the source MAC address
addresschanges. changes.
This specification extends RFC 4944 [RFC4944] with 2 new Dispatch This specification extends RFC 4944 [RFC4944] with 2 new Dispatch
types, for Recoverable Fragment (RFRAG) and for the RFRAG types, for Recoverable Fragment (RFRAG) and for the RFRAG
Acknowledgment back. The new 6LoWPAN Dispatch types are taken from Acknowledgment back. The new 6LoWPAN Dispatch types are taken from
Page 0 [RFC8025] as indicated in Table 1 in Section 9. Page 0 [RFC8025] as indicated in Table 1 in Section 9.
In the following sections, a "datagram_tag" extends the semantics In the following sections, a "datagram_tag" extends the semantics
defined in [RFC4944] Section 5.3."Fragmentation Type and Header". defined in [RFC4944] Section 5.3."Fragmentation Type and Header".
The datagram_tag is a locally unique identifier for the datagram from The datagram_tag is a locally unique identifier for the datagram from
the perspective of the sender. This means that the datagram_tag the perspective of the sender. This means that the datagram_tag
skipping to change at page 10, line 6 skipping to change at page 10, line 6
individual bits that correspond to their sequence. individual bits that correspond to their sequence.
X: 1 bit; Ack-Request: when set, the sender requires an RFRAG X: 1 bit; Ack-Request: when set, the sender requires an RFRAG
Acknowledgment from the receiver. Acknowledgment from the receiver.
E: 1 bit; Explicit Congestion Notification; the "E" flag is reset by E: 1 bit; Explicit Congestion Notification; the "E" flag is reset by
the source of the fragment and set by intermediate routers to the source of the fragment and set by intermediate routers to
signal that this fragment experienced congestion along its path. signal that this fragment experienced congestion along its path.
Fragment_size: 10-bit unsigned integer; the size of this fragment in Fragment_size: 10-bit unsigned integer; the size of this fragment in
a unit that depends on the MAC address layer technology. Unless a unit that depends on the MAC layer technology. Unless
overridden by a more specific specification, that unit is the overridden by a more specific specification, that unit is the
octet, which allows fragments up to 512 bytes. octet, which allows fragments up to 512 bytes.
datagram_tag: 8 bits; an identifier of the datagram that is locally datagram_tag: 8 bits; an identifier of the datagram that is locally
unique to the sender. unique to the sender.
Sequence: 5-bit unsigned integer; the sequence number of the Sequence: 5-bit unsigned integer; the sequence number of the
fragment in the acknowledgement bitmap. Fragments are numbered fragment in the acknowledgement bitmap. Fragments are numbered
[0..N] where N is in [0..31]. A Sequence of 0 indicates the first [0..N] where N is in [0..31]. A Sequence of 0 indicates the first
fragment in a datagram, but non-zero values are not indicative of fragment in a datagram, but non-zero values are not indicative of
skipping to change at page 12, line 30 skipping to change at page 12, line 30
6. Fragments Recovery 6. Fragments Recovery
The Recoverable Fragment header RFRAG is used to transport a fragment The Recoverable Fragment header RFRAG is used to transport a fragment
and optionally request an RFRAG Acknowledgment that will confirm the and optionally request an RFRAG Acknowledgment that will confirm the
good reception of one or more fragments. An RFRAG Acknowledgment is good reception of one or more fragments. An RFRAG Acknowledgment is
carried as a standalone fragment header (i.e., with no 6LoWPAN carried as a standalone fragment header (i.e., with no 6LoWPAN
payload) in a message that is propagated back to the 6LoWPAN endpoint payload) in a message that is propagated back to the 6LoWPAN endpoint
that was the originator of the fragments. To achieve this, each hop that was the originator of the fragments. To achieve this, each hop
that performed an MPLS-like operation on fragments reverses that that performed an MPLS-like operation on fragments reverses that
operation for the RFRAG_ACK by sending a frame from the next hop to operation for the RFRAG_ACK by sending a frame from the next hop to
the previous hop as known by its MAC addressin the VRB. The the previous hop as known by its MAC address in the VRB. The
datagram_tag in the RFRAG_ACK is unique to the receiver and is enough datagram_tag in the RFRAG_ACK is unique to the receiver and is enough
information for an intermediate hop to locate the VRB that contains information for an intermediate hop to locate the VRB that contains
the datagram_tag used by the previous hop and the Layer-2 information the datagram_tag used by the previous hop and the Layer-2 information
associated to it (interface and MAC address). associated to it (interface and MAC address).
The 6LoWPAN endpoint that fragments the packets at the 6LoWPAN level The 6LoWPAN endpoint that fragments the packets at the 6LoWPAN level
(the sender) also controls the amount of acknowledgments by setting (the sender) also controls the amount of acknowledgments by setting
the Ack-Request flag in the RFRAG packets. The sender may set the the Ack-Request flag in the RFRAG packets. The sender may set the
Ack-Request flag on any fragment to perform congestion control by Ack-Request flag on any fragment to perform congestion control by
limiting the number of outstanding fragments, which are the fragments limiting the number of outstanding fragments, which are the fragments
skipping to change at page 15, line 22 skipping to change at page 15, line 22
and the associated LSP state for the tuple (source MAC address, and the associated LSP state for the tuple (source MAC address,
datagram_tag) and the fragment is forwarded along the IPv6 route that datagram_tag) and the fragment is forwarded along the IPv6 route that
matches the destination IPv6 address in the IPv6 header as prescribed matches the destination IPv6 address in the IPv6 header as prescribed
by [I-D.ietf-6lo-minimal-fragment], where the receiving endpoint by [I-D.ietf-6lo-minimal-fragment], where the receiving endpoint
allocates a reassembly buffer. allocates a reassembly buffer.
The LSP state enables to match the (previous MAC address, The LSP state enables to match the (previous MAC address,
datagram_tag) in an incoming fragment to the tuple (next MAC address, datagram_tag) in an incoming fragment to the tuple (next MAC address,
swapped datagram_tag) used in the forwarded fragment and points at swapped datagram_tag) used in the forwarded fragment and points at
the VRB. In addition, the router also forms a reverse LSP state the VRB. In addition, the router also forms a reverse LSP state
indexed by the MAC address address of the next hop and the swapped indexed by the MAC address of the next hop and the swapped
datagram_tag. This reverse LSP state also points at the VRB and datagram_tag. This reverse LSP state also points at the VRB and
enables matching the (next MAC address, swapped_datagram_tag) found enables matching the (next MAC address, swapped_datagram_tag) found
in an RFRAG Acknowledgment to the tuple (previous MAC address, in an RFRAG Acknowledgment to the tuple (previous MAC address,
datagram_tag) used when forwarding a Fragment Acknowledgment (RFRAG- datagram_tag) used when forwarding a Fragment Acknowledgment (RFRAG-
ACK) back to the sender endpoint. ACK) back to the sender endpoint.
The first fragment may be received a second time, indicating that it The first fragment may be received a second time, indicating that it
did not reach the destination and was retried. In that case, it did not reach the destination and was retried. In that case, it
SHOULD follow the same path as the first occurrence. It is up to SHOULD follow the same path as the first occurrence. It is up to
sending endpoint to determine whether to abort a transmission and sending endpoint to determine whether to abort a transmission and
skipping to change at page 25, line 21 skipping to change at page 25, line 21
caused the initial loss, and potentially leading to congestion caused the initial loss, and potentially leading to congestion
collapse. collapse.
This saturation may lead to excessive radio interference, or random This saturation may lead to excessive radio interference, or random
early discard (leaky bucket) in relaying nodes. Additional queuing early discard (leaky bucket) in relaying nodes. Additional queuing
and memory congestion may result while waiting for a low power next and memory congestion may result while waiting for a low power next
hop to emerge from its sleeping state. hop to emerge from its sleeping state.
Considering that RFC 4944 defines an MTU is 1280 bytes and that in Considering that RFC 4944 defines an MTU is 1280 bytes and that in
most incarnations (but 802.15.4g) a IEEE Std. 802.15.4 frame can most incarnations (but 802.15.4g) a IEEE Std. 802.15.4 frame can
limit the MAC address payload to as few as 74 bytes, a packet might limit the MAC payload to as few as 74 bytes, a packet might be
be fragmented into at least 18 fragments at the 6LoWPAN shim layer. fragmented into at least 18 fragments at the 6LoWPAN shim layer.
Taking into account the worst-case header overhead for 6LoWPAN Taking into account the worst-case header overhead for 6LoWPAN
Fragmentation and Mesh Addressing headers will increase the number of Fragmentation and Mesh Addressing headers will increase the number of
required fragments to around 32. This level of fragmentation is much required fragments to around 32. This level of fragmentation is much
higher than that traditionally experienced over the Internet with higher than that traditionally experienced over the Internet with
IPv4 fragments. At the same time, the use of radios increases the IPv4 fragments. At the same time, the use of radios increases the
probability of transmission loss and Mesh-Under techniques compound probability of transmission loss and Mesh-Under techniques compound
that risk over multiple hops. that risk over multiple hops.
Mechanisms such as TCP or application-layer segmentation could be Mechanisms such as TCP or application-layer segmentation could be
used to support end-to-end reliable transport. One option to support used to support end-to-end reliable transport. One option to support
skipping to change at page 25, line 47 skipping to change at page 25, line 47
that the end-to-end transport is aware of the delivery properties of that the end-to-end transport is aware of the delivery properties of
the underlying LLN, which is a layer violation, and difficult to the underlying LLN, which is a layer violation, and difficult to
achieve from the far end of the IPv6 network. achieve from the far end of the IPv6 network.
Appendix B. Requirements Appendix B. Requirements
For one-hop communications, a number of Low Power and Lossy Network For one-hop communications, a number of Low Power and Lossy Network
(LLN) link-layers propose a local acknowledgment mechanism that is (LLN) link-layers propose a local acknowledgment mechanism that is
enough to detect and recover the loss of fragments. In a multihop enough to detect and recover the loss of fragments. In a multihop
environment, an end-to-end fragment recovery mechanism might be a environment, an end-to-end fragment recovery mechanism might be a
good complement to a hop-by-hop MAC address level recovery. This good complement to a hop-by-hop MAC level recovery. This draft
draft introduces a simple protocol to recover individual fragments introduces a simple protocol to recover individual fragments between
between 6LoWPAN endpoints that may be multiple hops away. The method 6LoWPAN endpoints that may be multiple hops away. The method
addresses the following requirements of an LLN: addresses the following requirements of an LLN:
Number of fragments: The recovery mechanism must support highly Number of fragments: The recovery mechanism must support highly
fragmented packets, with a maximum of 32 fragments per packet. fragmented packets, with a maximum of 32 fragments per packet.
Minimum acknowledgment overhead: Because the radio is half duplex, Minimum acknowledgment overhead: Because the radio is half duplex,
and because of silent time spent in the various medium access and because of silent time spent in the various medium access
mechanisms, an acknowledgment consumes roughly as many resources mechanisms, an acknowledgment consumes roughly as many resources
as a data fragment. as a data fragment.
 End of changes. 16 change blocks. 
28 lines changed or deleted 28 lines changed or added

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