| rfc8931v3.txt | rfc8931.txt | |||
|---|---|---|---|---|
| skipping to change at line 425 ¶ | skipping to change at line 425 ¶ | |||
| to end as smaller fragment Sequences 13 and 14 in Section 6.2. | to end as smaller fragment Sequences 13 and 14 in Section 6.2. | |||
| The first fragment is recognized by a Sequence of 0; it carries its | The first fragment is recognized by a Sequence of 0; it carries its | |||
| Fragment_Size and the Datagram_Size of the compressed packet before | Fragment_Size and the Datagram_Size of the compressed packet before | |||
| it is fragmented, whereas the other fragments carry their | it is fragmented, whereas the other fragments carry their | |||
| Fragment_Size and Fragment_Offset. The last fragment for a datagram | Fragment_Size and Fragment_Offset. The last fragment for a datagram | |||
| is recognized when its Fragment_Offset and its Fragment_Size add up | is recognized when its Fragment_Offset and its Fragment_Size add up | |||
| to the stored Datagram_Size of the packet identified by the sender | to the stored Datagram_Size of the packet identified by the sender | |||
| link-layer address and the Datagram_Tag. | link-layer address and the Datagram_Tag. | |||
| 1 2 3 | 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |1 1 1 0 1 0 0|E| Datagram_Tag | | |1 1 1 0 1 0 0|E| Datagram_Tag | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |X| Sequence| Fragment_Size | Fragment_Offset | | |X| Sequence| Fragment_Size | Fragment_Offset | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| X set == Ack-Request | X set == Ack-Request | |||
| Figure 1: RFRAG Dispatch Type and Header | Figure 1: RFRAG Dispatch Type and Header | |||
| skipping to change at line 872 ¶ | skipping to change at line 872 ¶ | |||
| in the reassembling endpoint and on intermediate nodes. There is no | in the reassembling endpoint and on intermediate nodes. There is no | |||
| new parameter as echoing ECN is always on. These parameters | new parameter as echoing ECN is always on. These parameters | |||
| typically include the reassembly timeout at the reassembling | typically include the reassembly timeout at the reassembling | |||
| endpoint, an inactivity cleanup timer on the intermediate nodes, and | endpoint, an inactivity cleanup timer on the intermediate nodes, and | |||
| the number of messages that can be processed in parallel in all | the number of messages that can be processed in parallel in all | |||
| nodes. | nodes. | |||
| The configuration settings introduced by this specification only | The configuration settings introduced by this specification only | |||
| apply to the fragmenting endpoint, which is in full control of the | apply to the fragmenting endpoint, which is in full control of the | |||
| transmission. LLNs vary a lot in size (there can be thousands of | transmission. LLNs vary a lot in size (there can be thousands of | |||
| nodes in a mesh), in speed (from 10 Kbps to several Mbps at the | nodes in a mesh), in speed (from 10 Kbps to several Mbps at the PHY | |||
| Physical Layer (PHY) layer), in traffic density, and in optimizations | layer), in traffic density, and in optimizations that are desired | |||
| that are desired (e.g., the selection of a Routing Protocol for LLNs | (e.g., the selection of a Routing Protocol for LLNs (RPL) [RFC6550] | |||
| (RPL) [RFC6550] Objective Function [RFC6552] impacts the shape of the | Objective Function [RFC6552] impacts the shape of the routing graph). | |||
| routing graph). | ||||
| For that reason, only very generic guidance can be given on the | For that reason, only very generic guidance can be given on the | |||
| settings of the fragmenting endpoint and on whether complex | settings of the fragmenting endpoint and on whether complex | |||
| algorithms are needed to perform congestion control or to estimate | algorithms are needed to perform congestion control or to estimate | |||
| the round-trip time. To cover the most complex use cases, this | the round-trip time. To cover the most complex use cases, this | |||
| specification enables the fragmenting endpoint to vary the fragment | specification enables the fragmenting endpoint to vary the fragment | |||
| size, the window size, and the inter-frame gap based on the number of | size, the window size, and the inter-frame gap based on the number of | |||
| losses, the observed variations of the round-trip time, and the | losses, the observed variations of the round-trip time, and the | |||
| setting of the ECN bit. | setting of the ECN bit. | |||
| skipping to change at line 1498 ¶ | skipping to change at line 1497 ¶ | |||
| is to manage the number of fragments present in the network; this is | is to manage the number of fragments present in the network; this is | |||
| achieved by reducing the number of outstanding fragments over a | achieved by reducing the number of outstanding fragments over a | |||
| congested path by throttling the sources. | congested path by throttling the sources. | |||
| Acknowledgments | Acknowledgments | |||
| The author wishes to thank Michel Veillette, Dario Tedeschi, Laurent | The author wishes to thank Michel Veillette, Dario Tedeschi, Laurent | |||
| Toutain, Carles Gomez Montenegro, Thomas Watteyne, and Michael | Toutain, Carles Gomez Montenegro, Thomas Watteyne, and Michael | |||
| Richardson for their in-depth reviews and comments. Also, many | Richardson for their in-depth reviews and comments. Also, many | |||
| thanks to Roman Danyliw, Peter Yee, Colin Perkins, Tirumaleswar | thanks to Roman Danyliw, Peter Yee, Colin Perkins, Tirumaleswar | |||
| Reddy.K, Eric Vyncke, Warren Kumari, Magnus Westerlund, Erik | Reddy.K, Éric Vyncke, Warren Kumari, Magnus Westerlund, Erik | |||
| Nordmark, and especially Benjamin Kaduk and Mirja Kuehlewind for | Nordmark, and especially Benjamin Kaduk and Mirja Kühlewind for their | |||
| their careful reviews and help during the IETF Last Call and IESG | careful reviews and help during the IETF Last Call and IESG review | |||
| review process. Thanks to Jonathan Hui, Jay Werb, Christos Polyzois, | process. Thanks to Jonathan Hui, Jay Werb, Christos Polyzois, | |||
| Soumitri Kolavennu, Pat Kinney, Margaret Wasserman, Richard Kelsey, | Soumitri Kolavennu, Pat Kinney, Margaret Wasserman, Richard Kelsey, | |||
| Carsten Bormann, and Harry Courtice for their various contributions | Carsten Bormann, and Harry Courtice for their various contributions | |||
| in the long process that lead to this document. | in the long process that lead to this document. | |||
| 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 | |||
| End of changes. 3 change blocks. | ||||
| 10 lines changed or deleted | 9 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/ | ||||