| CARVIEW |
Select Language
HTTP/2 200
date: Wed, 08 Oct 2025 15:20:42 GMT
content-type: text/plain; charset=utf-8
content-length: 13278
cf-ray: 98b69fa9bbd6343c-BLR
last-modified: Thu, 27 Jul 2023 01:13:53 GMT
etag: "b76d-6016dad70b189-gzip"
vary: Accept-Encoding
content-encoding: gzip
strict-transport-security: max-age=31536000; includeSubDomains
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
cf-cache-status: HIT
expires: Wed, 08 Oct 2025 15:40:42 GMT
cache-control: public, max-age=1200
accept-ranges: bytes
set-cookie: __cf_bm=KU1Y2bpAeXLSejPbRqEKhzT_eqRFo32OThxxotClfjk-1759936842-1.0.1.1-I1bi00SJ6yiP91XZ6JW1.ccYptuVrHNfCjvTDRIs4ot3gSvpEGZ4KcJ4pYBazTjEvCUVk8zJXHQNse5o7U21ARoS.HzH_O1pi5mpNHhAR5Q; path=/; expires=Wed, 08-Oct-25 15:50:42 GMT; domain=.rfc-editor.org; HttpOnly; Secure; SameSite=None
server: cloudflare
alt-svc: h3=":443"; ma=86400
Internet Engineering Task Force (IETF) JC. Zúñiga
Request for Comments: 9441 Cisco
Updates: 8724, 9363 C. Gomez
Category: Standards Track S. Aguilar
ISSN: 2070-1721 Universitat Politècnica de Catalunya
L. Toutain
IMT-Atlantique
S. Céspedes
Concordia University
D. Wistuba
NIC Labs, Universidad de Chile
July 2023
Static Context Header Compression (SCHC) Compound Acknowledgement (ACK)
Abstract
This document updates the Static Context Header Compression (SCHC)
and fragmentation protocol (RFC 8724) and the corresponding YANG
module (RFC 9363). It defines a SCHC Compound Acknowledgement (ACK)
message format and procedure, which are intended to reduce the number
of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error Mode,
by accumulating bitmaps of several windows in a single SCHC message
(i.e., the SCHC Compound ACK).
Both the message format and procedure are generic, so they can be
used, for instance, by any of the four Low-Power Wide Area Network
(LPWAN) technologies defined in RFC 8376, which are Sigfox, Long
Range Wide Area Network (LoRaWAN), Narrowband Internet of Things (NB-
IoT), and IEEE 802.15.4w.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9441.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
2. Terminology
3. SCHC Compound ACK
3.1. SCHC Compound ACK Message Format
3.2. SCHC Compound ACK Behavior
3.2.1. ACK-on-Error Mode (Replaces Section 8.4.3, RFC 8724)
4. SCHC Compound ACK Example
5. SCHC Compound ACK YANG Data Model
5.1. SCHC YANG Data Model Extension
5.2. SCHC YANG Tree Extension
6. SCHC Compound ACK Parameters
7. Security Considerations
8. IANA Considerations
8.1. URI Registration
8.2. YANG Module Name Registration
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
1. Introduction
The Generic Framework for Static Context Header Compression (SCHC)
and Fragmentation specification [RFC8724] describes two mechanisms:
i) a protocol header compression scheme and ii) a frame fragmentation
and loss recovery functionality. Either can be used on top of radio
technologies, such as the four Low-Power Wide Area Networks (LPWANs)
listed in [RFC8376], which are Sigfox, LoRaWAN, NB-IoT, and IEEE
802.15.4w. These LPWANs have similar characteristics, such as star-
oriented topologies, network architecture, and connected devices with
built-in applications.
SCHC offers a great level of flexibility to accommodate all these
LPWAN technologies. Even though there are a number of similarities
between them, some differences exist with respect to the transmission
characteristics, payload sizes, etc. Hence, there are optimal
parameters and modes of operation that can be used when SCHC is used
on top of a specific LPWAN technology.
In ACK-on-Error mode in [RFC8724], the SCHC Packet is fragmented into
pieces called tiles, where all tiles are the same size except for the
last one, which can be smaller. Successive tiles are grouped in
windows of fixed size. A SCHC Fragment carries one or several
contiguous tiles, which may span multiple windows. When sending all
tiles from all windows, the last tile is sent in an All-1 SCHC
Fragment. The SCHC receiver will send a SCHC ACK reporting on the
reception of exactly one window of tiles after receiving the All-1
SCHC Fragment. In case of SCHC Fragment losses, a bitmap is added to
the failure SCHC ACK, where each bit in the bitmap corresponds to a
tile in the window. If SCHC Fragment losses span multiple windows,
the SCHC receiver will send one failure SCHC ACK per window with
losses.
This document updates the SCHC protocol for frame fragmentation and
loss recovery. It defines a SCHC Compound ACK format and procedure,
which are intended to reduce the number of response transmissions
(i.e., SCHC ACKs) in the ACK-on-Error mode of SCHC. The SCHC
Compound ACK extends the failure SCHC ACK message format so that it
can contain several bitmaps, with each bitmap being identified by its
corresponding window number. The SCHC Compound ACK is backwards
compatible with the SCHC ACK as defined in [RFC8724], and introduces
flexibility, as the receiver has the capability to respond to the
All-0 SCHC Fragment, providing more Downlink opportunities and
therefore adjusting to the delay requirements of the application.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
It is assumed that the reader is familiar with the terms and
mechanisms defined in [RFC8376] and [RFC8724].
3. SCHC Compound ACK
The SCHC Compound ACK is a failure SCHC ACK message that can contain
several bitmaps, with each bitmap being identified by its
corresponding window number. In [RFC8724], the failure SCHC ACK
message only contains one bitmap corresponding to one window. The
SCHC Compound ACK extends this format, allowing more windows to be
acknowledged in a single ACK and reducing the total number of failure
SCHC ACK messages, especially when fragment losses are present in
intermediate windows.
The SCHC Compound ACK MAY be used in fragmentation modes that use
windows and that allow reporting the bitmaps of multiple windows at
the same time; otherwise, the SCHC Compound ACK MUST NOT be used.
The SCHC Compound ACK:
* provides feedback only for windows with fragment losses,
* has a variable size that depends on the number of windows with
fragment losses being reported in the single SCHC Compound ACK,
* includes the window number (i.e., W) of each bitmap,
* might not cover all windows with fragment losses of a SCHC Packet,
and
* is distinguishable from the SCHC Receiver-Abort.
3.1. SCHC Compound ACK Message Format
Figure 1 shows the success SCHC ACK format, i.e., when all fragments
have been correctly received (C=1), as defined in [RFC8724].
|--- SCHC ACK Header ---|
| |--T-|--M--| 1 |
+--------+----+-----+---+~~~~~~~~~~~~~~~~~~
| RuleID |DTag| W |C=1| padding as needed
+--------+----+-----+---+~~~~~~~~~~~~~~~~~~
Figure 1: SCHC Success ACK Message Format, as Defined in RFC 8724
In case SCHC Fragment losses are found in any of the windows of the
SCHC Packet, the SCHC Compound ACK MAY be used. The SCHC Compound
ACK message format is shown in Figures 2 and 3.
|--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
|--T-|---M--|-1-| |...|---M--| |---M--|
+------+----+------+---+--------+...+------+--------+------+~~~~~+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |00..00| pad |
+------+----+------+---+--------+...+------+--------+------+~~~~~+
next L2 Word boundary ->|<-- L2 Word ->|
Figure 2: SCHC Compound ACK Message Format. Losses are found in
windows W = w1,...,wi, where w1 < w2 <...< wi.
The SCHC Compound ACK groups the window number (W) with its
corresponding bitmap. Window numbers do not need to be contiguous.
However, the window numbers and their corresponding bitmaps included
in the SCHC Compound ACK message MUST be ordered from the lowest-
numbered to the highest-numbered window. Hence, if the bitmap of
window number zero is present in the SCHC Compound ACK message, it
MUST always be the first one in order and its window number MUST be
placed in the SCHC ACK Header.
If M or more padding bits would be needed after the last bitmap in
the message to fill the last layer two (L2) Word, M bits at 0 MUST be
appended after the last bitmap, and then padding is applied as needed
(see Figure 2). Since window number 0 (if present in the message) is
placed as w1, the M bits set to zero can't be confused with window
number 0; therefore, they signal the end of the SCHC Compound ACK
message.
Figure 3 shows the case when the required padding bits are strictly
less than M bits. In this case, the L2 Maximum Transmission Unit
(MTU) does not leave room for any extra window value, let alone any
bitmap, thereby signaling the end of the SCHC Compound ACK message.
|--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
|--T-|---M--|-1-| |...|---M--| |---M--|
+------+----+------+---+--------+...+------+--------+~~~+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |pad|
+------+----+------+---+--------+...+------+--------+~~~+
next L2 Word boundary ->|
Figure 3: SCHC Compound ACK Message Format with Less than M
Padding Bits. Losses are found in windows W = w1,...,wi, where
w1 < w2 <...< wi.
The SCHC Compound ACK MUST NOT use the Compressed Bitmap format for
intermediate windows/bitmaps (i.e., bitmaps that are not the last one
of the SCHC Compound ACK message); therefore, intermediate bitmap
fields MUST be of size WINDOW_SIZE. Hence, the SCHC Compound ACK MAY
use a Compressed Bitmap format only for the last bitmap in the
message. The optional usage of this Compressed Bitmap for the last
bitmap MUST be specified by the technology-specific SCHC Profile.
The case where the last bitmap is effectively compressed corresponds
to Figure 3, with the last bitmap ending (by construction) on an L2
Word boundary, therefore resulting in no padding at all.
Figure 4 illustrates a bitmap compression example of a SCHC Compound
ACK, where the bitmap of the last window (wi) indicates that the
first tile has not been correctly received. Because the compression
algorithm resulted in effective compression, no padding is needed.
|--- SCHC ACK Header --|- W=w1 -|...|-------- W=wi -------|
|--T-|---M--|-1-| |...|---M--|
+------+----+------+---+--------+...+------+--------------+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1 1 1 1 1 1 |
+------+----+------+---+--------+...+------+--------------+
next L2 Word boundary ->|
SCHC Compound ACK with Uncompressed Bitmap
|--- SCHC ACK Header --|- W=w1 -|...|-- W=wi --|
|--T-|---M--|-1-| |...|---M--|
+------+----+------+---+--------+...+------+---+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1|
+------+----+------+---+--------+...+------+---+
next L2 Word boundary ->|
Transmitted SCHC Compound ACK with Compressed Bitmap
Figure 4: SCHC Compound ACK Message Format with Compressed Bitmap
and No Padding Added. Losses are found in windows W = w1,...,wi,
where w1 < w2 <...< wi.
Figure 5 illustrates another bitmap compression example of a SCHC
Compound ACK, where the bitmap of the last window (wi) indicates that
the second and the fourth tiles have not been correctly received. In
this example, the compression algorithm does not result in effective
compression of the last bitmap. Besides, because more than M bits of
padding would be needed to fill the last L2 Word, M bits at 0 are
appended to the message before padding is applied.
|--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------|
|--T-|---M--|-1-| |...|---M--|
+------+----+------+---+------+...+------+--------------+
|RuleID|DTag| W=w1 |C=0|Bitmap|...| W=wi |1 0 1 0 1 1 1 |
+------+----+------+---+------+...+------+--------------+
next L2 Word boundary ->|
SCHC Compound ACK with Uncompressed Bitmap
|--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------|
|--T-|---M--|-1-| |...|---M--| |---M--|
+------+----+------+---+------+...+------+--------------+------+~~~+
|RuleID|DTag| W=w1 |C=0|Bitmap|...| W=wi |1 0 1 0 1 1 1 |00..00|pad|
+------+----+------+---+------+...+------+--------------+------+~~~+
next L2 Word boundary ->|<------ L2 Word ------>|
Transmitted SCHC Compound ACK
Figure 5: SCHC Compound ACK Message Format with Compressed Bitmap
and Padding Added to Reach the L2 Boundary. Losses are found in
windows W = w1,...,wi, where w1 < w2 <...|
|-----W=0, FCN=5 ----->|
|-----W=0, FCN=4 ----->|
|-----W=0, FCN=3 ----->|
|-----W=0, FCN=2 --X |
|-----W=0, FCN=1 ----->|
|-----W=0, FCN=0 ----->| Bitmap: 1111011
(no ACK)
|-----W=1, FCN=6 ----->|
|-----W=1, FCN=5 ----->|
|-----W=1, FCN=4 ----->|
|-----W=1, FCN=3 ----->|
|-----W=1, FCN=2 ----->|
|-----W=1, FCN=1 --X |
|-- W=1, FCN=7 + RCS ->| Integrity check: failure
|<--- Compound ACK ----| [C=0, W=0 - Bitmap:1111011,
|-----W=0, FCN=2 ----->| W=1 - Bitmap:1111101]
|-----W=1, FCN=1 ----->| Integrity check: success
|<--- ACK, W=1, C=1 ---| C=1
(End)
Figure 7: SCHC Compound ACK Message Sequence Example
|--- SCHC ACK Header --|- W=00 --|----- W=01 -----|
|--T-|---M--|-1-| |---M--| |---M--|
+------+----+------+---+---------+------+---------+------+-----+
|RuleID|DTag| W=00 |C=0| 1111011 | W=01 | 1111101 | 00 | pad |
+------+----+------+---+---------+------+---------+------+-----+
next L2 Word boundary ->|<-- L2 Word ->|
Figure 8: SCHC Compound ACK Message Format Example: Losses are
Found in Windows 00 and 01
5. SCHC Compound ACK YANG Data Model
This document also extends the SCHC YANG data model defined in
[RFC9363] by including a new leaf in the Ack-on-Error fragmentation
mode to describe both the option to use the SCHC Compound ACK, as
well as its bitmap format.
5.1. SCHC YANG Data Model Extension
file "ietf-schc-compound-ack@2023-07-26.yang"
module ietf-schc-compound-ack {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack";
prefix schc-compound-ack;
import ietf-schc {
prefix schc;
}
organization
"IETF IPv6 over Low Power Wide-Area Networks (lpwan)
Working Group";
contact
"WG Web:
Editor: Laurent Toutain
Editor: Juan Carlos Zuniga
Editor: Sergio Aguilar
";
description
"Copyright (c) 2023 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9363
(https://www.rfc-editor.org/info/rfc9363); see the RFC itself
for full legal notices.
***************************************************************
Generic data model for the Static Context Header Compression
Rule for SCHC, based on RFCs 8724 and 8824. Including
compression, no-compression, and fragmentation Rules.";
revision 2023-07-26 {
description
"Initial version for RFC 9441.";
reference
"RFC 9441 Static Context Header Compression (SCHC) Compound
Acknowledgement (ACK)";
}
identity bitmap-format-base-type {
description
"Define how the bitmap is formed in ACK messages.";
}
identity bitmap-RFC8724 {
base bitmap-format-base-type;
description
"Bitmap by default as defined in RFC 8724.";
reference
"RFC 8724 SCHC: Generic Framework for Static Context Header
Compression and Fragmentation";
}
identity bitmap-compound-ack {
base bitmap-format-base-type;
description
"Compound ACK allows several bitmaps in an ACK message.";
}
typedef bitmap-format-type {
type identityref {
base bitmap-format-base-type;
}
description
"Type of bitmap used in Rules.";
}
augment "/schc:schc/schc:rule/schc:nature/"
+ "schc:fragmentation/schc:mode/schc:ack-on-error" {
leaf bitmap-format {
when "derived-from-or-self(../schc:fragmentation-mode,
'schc:fragmentation-mode-ack-on-error')";
type schc-compound-ack:bitmap-format-type;
default "schc-compound-ack:bitmap-RFC8724";
description
"How the bitmaps are included in the SCHC ACK message.";
}
leaf last-bitmap-compression {
when "derived-from-or-self(../schc:fragmentation-mode,
'schc:fragmentation-mode-ack-on-error')";
type boolean;
default "true";
description
"When true, the ultimate bitmap in the SCHC ACK message
can be compressed. Default behavior from RFC 8724.";
reference
"RFC 8724 SCHC: Generic Framework for Static Context Header
Compression and Fragmentation";
}
description
"Augment the SCHC Rules to manage Compound ACK.";
}
}
Figure 9: SCHC YANG Data Model - Compound ACK Extension
5.2. SCHC YANG Tree Extension
module: ietf-schc-compound-ack
augment /schc:schc/schc:rule/schc:nature/schc:fragmentation/
schc:mode/schc:ack-on-error:
+--rw bitmap-format? schc-compound-ack:bitmap-format-type
+--rw last-bitmap-compression? boolean
Figure 10: Tree Diagram - Compound ACK Extension
6. SCHC Compound ACK Parameters
This section lists the parameters related to the SCHC Compound ACK
usage that need to be defined in the Profile. This list MUST be
appended to the list of SCHC parameters under "Decision to use SCHC
fragmentation mechanism or not. If yes, the document must describe:"
as defined in Appendix D of [RFC8724].
* whether the SCHC Compound ACK message is used or not, and
* whether the compressed bitmap format in the last window of the
SCHC Compound ACK message is used or not.
7. Security Considerations
This document specifies a message format extension for SCHC. Hence,
the same security considerations defined in [RFC8724] and [RFC9363]
apply.
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/
schc:ack-on-error:
All the data nodes may be modified. The Rule contains sensitive
information, such as the SCHC F/R mode configuration and usage and
SCHC Compound ACK configuration. An attacker may try to modify
other devices' Rules by changing the F/R mode or the usage of the
SCHC Compound ACK and may block communication or create extra
ACKs. Therefore, a device must be allowed to modify only its own
Rules on the remote SCHC instance. The identity of the requester
must be validated. This can be done through certificates or
access lists.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/
schc:ack-on-error:
By reading this module, an attacker may learn the F/R mode used by
the device, how the device manages the bitmap creation, the buffer
sizes, and when the device will request an ACK.
8. IANA Considerations
This document registers one URI and one YANG data model.
8.1. URI Registration
IANA registered the following URI in the "IETF XML Registry"
[RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
8.2. YANG Module Name Registration
IANA has registered the following YANG data model in the "YANG Module
Names" registry [RFC6020].
name: ietf-schc-compound-ack
namespace: urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack
prefix: schc-compound-ack
reference: RFC 9441
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
.
[RFC9363] Minaburo, A. and L. Toutain, "A YANG Data Model for Static
Context Header Compression (SCHC)", RFC 9363,
DOI 10.17487/RFC9363, March 2023,
.
9.2. Informative References
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
.
Acknowledgements
Carles Gomez has been funded in part by the Spanish Government
through the TEC2016-79988-P grant and the PID2019-106808RA-I00 grant
(funded by MCIN / AEI / 10.13039/501100011033) and by Secretaria
d'Universitats i Recerca del Departament d'Empresa i Coneixement de
la Generalitat de Catalunya through 2017 grant SGR 376 and 2021 grant
SGR 00330.
Sergio Aguilar has been funded by the ERDF and the Spanish Government
through project TEC2016-79988-P and project PID2019-106808RA-I00,
AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033).
Sandra Cespedes has been funded in part by the ANID Chile Project
FONDECYT Regular 1201893 and Basal Project FB0008.
Diego Wistuba has been funded by the ANID Chile Project FONDECYT
Regular 1201893.
The authors would like to thank Rafael Vidal, Julien Boite, Renaud
Marty, Antonis Platis, Dominique Barthel, and Pascal Thubert for
their very useful comments, reviews, and implementation design
considerations.
Authors' Addresses
Juan Carlos Zúñiga
Cisco
Montreal QC
Canada
Email: juzuniga@cisco.com
Carles Gomez
Universitat Politècnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Email: carles.gomez@upc.edu
Sergio Aguilar
Universitat Politècnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Email: sergio.aguilar.romero@upc.edu
Laurent Toutain
IMT-Atlantique
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
Email: Laurent.Toutain@imt-atlantique.fr
Sandra Céspedes
Concordia University
1455 De Maisonneuve Blvd. W.
Montreal QC, H3G 1M8
Canada
Email: sandra.cespedes@concordia.ca
Diego Wistuba
NIC Labs, Universidad de Chile
Av. Almte. Blanco Encalada 1975
Santiago
Chile
Email: research@witu.cl