Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges
draft-irtf-nwcrg-nwc-ccn-reqs-08
The information below is for an old version of the document.
draft-irtf-nwcrg-nwc-ccn-reqs-08
Network Coding Research Group K. Matsuzono
Internet-Draft H. Asaeda
Intended status: Informational NICT
Expires: May 19, 2022 C. Westphal
Huawei
November 15, 2021
Network Coding for Content-Centric Networking / Named Data Networking:
Considerations and Challenges
draft-irtf-nwcrg-nwc-ccn-reqs-08
Abstract
This document describes the current research outcomes in Network
Coding (NC) for Content-Centric Networking (CCNx) / Named Data
Networking (NDN), and clarifies the technical considerations and
potential challenges for applying NC in CCNx/NDN. This document is
the product of the Coding for Efficient Network Communications
Research Group (NWCRG) and the Information-Centric Networking
Research Group (ICNRG).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 19, 2022.
Copyright Notice
Copyright (c) 2021 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
Matsuzono, et al. Expires May 19, 2022 [Page 1]
Internet-Draft NC for CCNx/NDN November 2021
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions related to NC . . . . . . . . . . . . . . . . 4
2.2. Definitions related to CCNx/NDN . . . . . . . . . . . . . 6
3. CCNx/NDN Basics . . . . . . . . . . . . . . . . . . . . . . . 6
4. NC Basics . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Advantages of NC and CCNx/NDN . . . . . . . . . . . . . . . . 8
6. Technical Considerations . . . . . . . . . . . . . . . . . . 9
6.1. Content Naming . . . . . . . . . . . . . . . . . . . . . 9
6.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.1. Scope of NC . . . . . . . . . . . . . . . . . . . . . 11
6.2.2. Consumer Operation . . . . . . . . . . . . . . . . . 11
6.2.3. Forwarder Operation . . . . . . . . . . . . . . . . . 12
6.2.4. Producer Operation . . . . . . . . . . . . . . . . . 13
6.2.5. Backward Compatibility . . . . . . . . . . . . . . . 14
6.3. In-network Caching . . . . . . . . . . . . . . . . . . . 14
6.4. Seamless Consumer Mobility . . . . . . . . . . . . . . . 15
7. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Adoption of Convolutional Coding . . . . . . . . . . . . 15
7.2. Rate and Congestion Control . . . . . . . . . . . . . . . 16
7.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. Routing Scalability . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
Information-Centric Networking (ICN) in general, and Content-Centric
Networking (CCNx) [16] or Named Data Networking (NDN) [19] in
particular, have emerged as a novel communication paradigm advocating
the retrieval of data based on their names. This paradigm pushes
content awareness into the network layer. It is expected to enable
consumers to obtain the content they desire in a straightforward and
efficient manner from the heterogenous networks they may be connected
to. The CCNx/NDN architecture has introduced innovative ideas and
has stimulated research in a variety of areas, such as in-network
caching, name-based routing, multipath transport, and content
security. One key benefit of requesting content by name is that it
Matsuzono, et al. Expires May 19, 2022 [Page 2]
Internet-Draft NC for CCNx/NDN November 2021
eliminates the requirement to establish a session between the client
and a specific server, and the content can thereby be retrieved from
multiple sources.
In parallel, there has been a growing interest in both academia and
industry for better understanding the fundamental aspects of Network
Coding (NC) toward enhancing key system performance metrics such as
data throughput, robustness and reduction in the required number of
transmissions through connected networks, and redundant transmission
on broadcast or point-to-multipoint connections. NC is a technique
that is typically used for encoding packets to recover from lost
source packets at the receiver, and for effectively obtaining the
desired information in a fully distributed manner. In addition, in
terms of security aspects, NC can be managed using a practical
security scheme that deals with pollution attacks [2], and can be
utilized for preventing eavesdroppers from obtaining meaningful
information [3] or protecting a wireless video stream while retaining
the NC benefits [4] [5].
From the perspective of the NC transport mechanism, NC can be divided
into two major categories: coherent NC, and non-coherent NC [38]
[39]. In coherent NC, the source and destination nodes know the
exact network topology and the coding operations available at
intermediate nodes. When multiple consumers are attempting to
receive the same content such as live video streaming, coherent NC
could enable optimal throughput by sending the content flow over the
constructed optimal multicast trees [32]. However, it requires a
fully adjustable and specific routing mechanism, and a large
computational capacity for central coordination. In the case of non-
coherent NC, that often comprises the use of Random Linear Coding
(RLC), it is not necessary to know the network topology nor the
intermediate coding operations [33]. As non-coherent NC works in a
completely independent and decentralized manner, this approach is
more feasible in terms of eliminating such a central coordination.
NC combines multiple packets together with parts of the same content,
and may do this at the source or at other nodes in the network.
Network coded packets are not associated with a specific server, as
they may have been combined within the network. As NC is focused on
what information should be encoded in a network packet instead of the
specific host at which it has been generated, it is in line with the
architecture of the CCNx/NDN core networking layer. NC has already
been implemented for information/content dissemination [6] [7] [8].
Montpetit, et al., first suggested that NC techniques be exploited to
enhance key aspects of system performance in ICN [9]. NC provides
CCNx/NDN with the highly beneficial potential of effectively
disseminating information in a completely topology independent and
decentralized manner.
Matsuzono, et al. Expires May 19, 2022 [Page 3]
Internet-Draft NC for CCNx/NDN November 2021
gt; are reserved for future use:
1. /o
Full details of the Device and NMS service URLs are defined in
Section 3.2.1 and Section 3.2.2.
3.3.2. Resource Encoding
3.3.2.1. Standard TLVs
The message payloads of CSMP requests and responses MUST be formatted
as a sequence of Type-Length-Value objects. Each TLV object has the
following format:
| Type | Length | Value |
The Type field is an unsigned integer identifying a specific CSMP TLV
ID and MUST be encoded as a Protocol Buffers varint.
The Length field is an unsigned integer containing the number of
octets occupied by the Value field. The Length field MUST be encoded
as a Protocol Buffers varint.
The Value field MUST contain the Protocol Buffers encoded TLV
corresponding to the indicated Type.
The set of objects defined by CSMP and their Type (TLV ID) are
specified in Section 3.3.2.2.
3.3.2.2. CSMP TLV Definitions
This section contains the CSMP TLV definitions (defined using [PB]).
The definitions are also available at [CSMPMSG] which is directly
importable into development tooling.
syntax = "proto3";
/*
The definitions for CSMP TLVs.
This file is directly consumable by the Protocol Buffer tool chain.
Requirements are specified using the terminology and conventions as
referenced in [RFC2119]. Requirements key words referenced in [RFC2119]
must be capitalized. Full details re: Protocol Buffers are accessible
at https://developers.google.com/protocol-buffers
*/
/*
Duffy (ed) Expires 13 June 2024 [Page 19]
Internet-Draft CoAP Simple Management Protocol December 2023
CSMP TLV ID Mapping to Protocol Buffer messages.
A unique TLV ID MUST be assigned to each CSMP Protocol Buffer
message (defined within). An unused TLV ID MAY be assigned to a new
message (the new TLV ID assignment MUST be recorded within, along with
the defintion of the new message). A Reserved TLV ID MUST NOT be
assigned to a message. An existing TLV ID assignment MUST NOT be
re-assigned to a new message.
NOTE the legend.
- Unused: available for assignment.
- Reserved: not available for assignment.
- All other named messages are currently used by CSMP.
All TLV assignments MUST be recorded in the table below.
Take care to maintain the numbering.
TLVID Message
1 TlvIndex
2 DeviceID
3 Reserved
4 Unused
5 Unused
6 NMSRedirectRequest
7 SessionID
8 DescriptionRequest
9 Unused
10 Reserved
11 HardwareDesc
12 InterfaceDesc
13 ReportSubscribe
14 Reserved
15 Reserved
16 IPAddress
17 IPRoute
18 CurrentTime
19 Reserved
20 Reserved
21 RPLSettings
22 Uptime
23 InterfaceMetrics
24 Reserved
25 IPRouteRPLMetrics
26 Unused
27-29 Reserved
30 PingRequest
31 PingResponse
Duffy (ed) Expires 13 June 2024 [Page 20]
Internet-Draft CoAP Simple Management Protocol December 2023
32 RebootRequest
33 Ieee8021xStatus
34 Ieee80211iStatus
35 WPANStatus
36 DHCP6ClientStatus
37-41 Reserved
42 NMSSettings
43 NMSStatus
44-46 Reserved
47 Ieee8021xSettings
48 Ieee802154BeaconStats
49-52 Reserved
53 RPLInstance
54 Reserved
55 GroupAssign
56 GroupEvict
57 GroupMatch
58 GroupInfo
59 Unused
60 Unused
61 Reserved
62 LowpanMacStats
63 LowpanPhySettings
64 Unused
65 TransferRequest
66 Reserved
67 ImageBlock
68 LoadRequest
69 CancelLoadRequest
70 SetBackupRequest
71 TransferResponse
72 LoadResponse
73 CancelLoadResponse
74 SetBackupResponse
75 FirmwareImageInfo
76 SignatureValidity
77 Signature
78 Reserved
79 SignatureSettings
80 Reserved
81 Reserved
82 Unused
83 Unused
84 Reserved
85 Unused
86 SysResetStats
87 Unused
88 Reserved
Duffy (ed) Expires 13 June 2024 [Page 21]
Internet-Draft CoAP Simple Management Protocol December 2023
89 Unused
90 Unused
91-97 Reserved
98 Unused
99 Unused
100 Reserved
101 Unused
102 Unused
103 Unused
104 Unused
105 Unused
106 Unused
107 Reserved
108 Reserved
109 Unused
110-112 Reserved
113 Unused
114 Unused
115-117 Reserved
118 Unused
119 Unused
120-122 Reserved
123 Unused
124 NetStat
125 Reserved
126 Reserved
127 Vendor Defined TLV
128-131 Reserved
132-139 Unused
140 Reserved
141 NetworkRole
142-151 Reserved
152-154 Unused
155-157 Reserved
158-159 Unused
160-165 Reserved
166-169 Unused
170-171 Reserved
172 CertBundle
173-179 Unused
180 Reserved
181-199 Unused
200-202 Reserved
203-209 Unused
210 Reserved
211 Reserved
212-216 Unused
217-220 Reserved
Duffy (ed) Expires 13 June 2024 [Page 22]
Internet-Draft CoAP Simple Management Protocol December 2023
221-239 Unused
240 Reserved
241 MplStats
242 MplReset
243-299 Unused
301-303 Reserved
304 Unused
305-307 Reserved
308-309 Unused
310-312 Reserved
313 RPLStats
314 DHCP6Stats
315 Reserved
316 Reserved
317-324 Unused
325-337 Reserved
338-339 Unused
340-399 Reserved
400-499 Unused
500 Reserved
501 Reserved
502 Reserved
503-509 Unused
510 Reserved
511 Reserved
512-519 Unused
520 Reserved
521 Reserved
522-529 Unused
530 Reserved
531 Reserved
532-539 Unused
540 Reserved
541-599 Unused
600-607 Reserved
608 ... Unused
*/
/*
Message definitions follow.
Tag notation used within ...
Class:: designates class of device for which the TLV is relevant.
Generic (any IP addressable device)
Mesh (Wi-SUN mesh devices)
Others TBD.
Duffy (ed) Expires 13 June 2024 [Page 23]
Internet-Draft CoAP Simple Management Protocol December 2023
*/
package csmp.tlvs;
option java_package = "com.cisco.cgms.protocols.csmp.tlvs";
// TLV 1
// A list of zero or more TLV IDs
// Class:: Generic
//
message TlvIndex {
// list of TLV IDs (string encoded) supported by the device.
repeated string tlvid = 1;
}
// TLV 2
// Primary identifier for a specific device.
// Class:: Generic
//
message DeviceID {
oneof type_present {
// Set to 1 to indicate EUI-64 format.
uint32 type = 1;
}
oneof id_present {
// The unique identifier of the device in EUI-64 format
string id = 2;
}
}
// TLV 6
// Used by NMS to force device registration to a specific NMS.
// Class:: Generic
//
message NMSRedirectRequest {
oneof url_present {
// NMS <base-url> to which the device registration will be directed.
// MUST be formatted per section 6 of RFC 7252
string url = 1;
}
oneof immediate_present {
// True == device should immediately send registration request
// to the specificed NMS url.
bool immediate = 2;
}
}
Duffy (ed) Expires 13 June 2024 [Page 24]
Internet-Draft CoAP Simple Management Protocol December 2023
// TLV 7
// Session ID used by NMS to track device CSMP messaging.
// Assigned by the NMS, used in all subsequent Device to NMS messaging.
// Class:: Generic
//
message SessionID {
oneof id_present {
string id = 1; // session ID
}
}
// TLV 8
// List of zero or more TLVs requested by the NMS from a Device.
// The requested TLV values will be sent to the NMS asynchronously.
// Class:: Generic
//
message DescriptionRequest {
// list of TLV IDs in string format.
repeated string tlvid = 1;
}
// A list of hardware modules with their firmware versions.
//
message HardwareModule {
oneof moduleType_present {
// hardware module type. Rf Dsp=1, PLC Dsp=2, CPU=3, FPGA=4
uint32 moduleType = 1;
}
oneof firmwareRev_present {
// firmware version of the hardware module
string firmwareRev = 2;
}
}
// TLV 11
// This TLV contains hardware description information for the device.
// The contents of the fields are defined by the equivalently-named
// fields in the entry of the SNMP MIB object entPhysicalTable.
// Class:: Generic
//
message HardwareDesc {
oneof entPhysicalIndex_present {
// index of this hardware being described.
int32 entPhysicalIndex = 1;
}
Duffy (ed) Expires 13 June 2024 [Page 25]
Internet-Draft CoAP Simple Management Protocol December 2023
oneof entPhysicalDescr_present {
// A textual description of physical entity.
string entPhysicalDescr = 2;
}
oneof entPhysicalVendorType_present {
// An indication of the vendor-specific hardware type of the
// physical entity.
bytes entPhysicalVendorType = 3;
}
oneof entPhysicalContainedIn_present {
// The value of entPhysicalIndex for the physical entity which
// 'contains' this physical entity.
int32 entPhysicalContainedIn = 4;
}
oneof entPhysicalClass_present {
// An indication of the general hardware type of the physical
// entity.
int32 entPhysicalClass = 5;
}
oneof entPhysicalParentRelPos_present {
// An indication of the relative position of this 'child' component
// among all its 'sibling&In this document, we consider how NC can be applied to the CCNx/NDN
architecture and describe the technical considerations and potential
challenges for making CCNx/NDN-based communications better using the
NC technology. It should be noted that the presentation of specific
solutions (e.g., NC optimization methods) for enhancing CCNx/NDN
performance metrics by exploiting NC is outside the scope of this
document.
This document represents the collaborative work and consensus of the
Coding for Efficient Network Communications Research Group (NWCRG)
and the Information-Centric Networking Research Group (ICNRG). It is
not an IETF product and is not a standard.
2. Terminology
This section provides the terms related to NC and CCNx/NDN used in
this document.
2.1. Definitions related to NC
The terms regarding NC used in this document are defined as follows.
These are aligned with RFCs produced by the FEC Framework (FECFRAME)
IETF Working Groups as well as IRTF Coding for Efficient Network
Communications Research Group (NWCRG)[21].
o Source Symbol: A unit of data originating from the source that is
used as input to encoding operations.
o Coded Symbol, or Repair Symbol: A unit of data that is the result
of a coding operation, applied either to source symbols or (in
case of re-coding) source and/or coded symbols.
o Source Packet: A packet originating from the source that
contributes to one or more source symbols. The source symbol is a
unit of data originating from the source that is used as input to
encoding operations. For instance, a real-time transport protocol
(RTP) packet as a whole can constitute a source symbol. In other
situations (e.g., to address variable size packets), a single RTP
packet may contribute to various source symbols.
o Repair Packet: A packet containing one or more coded symbols (also
called repair symbol). When there is a single repair symbol per
repair packet, a repair symbol corresponds to a repair packet.
o Innovative Packet: A source or repair packet that increases the
rank of the linear system (also called degrees of freedom) at a
receiver.
Matsuzono, et al. Expires May 19, 2022 [Page 4]
Internet-Draft NC for CCNx/NDN November 2021
o Encoding versus Re-coding versus Decoding: Encoding is an
operation that takes source symbols as input and produces encoding
symbols (source or coded symbols) as output. Re-coding is an
operation that takes encoding symbols as input and produces
encoding symbols as output. Decoding is an operation takes
encoding symbols as input and produces source symbols as output.
The terms regarding coding types are defined as follows:
o Linear Coding: Linear combination of a set of input symbols (i.e.,
source and/or coded symbols) using a given set of coefficients and
resulting in a repair symbol.
o Random Linear Coding (RLC): A particular form of linear coding
using a set of random coding coefficients.
o Block Coding: A coding technique wherein the input flow(s) must be
first segmented into a sequence of blocks; encoding and decoding
are performed independently on a per-block basis.
o Sliding Window Coding or Convolutional Coding: A general class of
coding techniques that rely on a sliding encoding window.
Encoding window is a set of source (and coded in the case of re-
coding) symbols used as input to the coding operations. The set
of symbols change over time, as the encoding window slides over
the input flow(s). This is an alternative solution to block
coding.
o Fixed or Elastic Sliding Window Coding: A coding technique that
generates coded symbol(s) on the fly, from the set of source
symbols present in the sliding encoding window at that time,
usually by using linear coding. The sliding window may be either
of fixed size or of variable size over the time (also known as
"Elastic Sliding Window"). For instance, the size may depend on
acknowledgments sent by the receiver(s) for a particular source
symbol or source packet (received, decoded, or decodable).
The terms regarding low-level coding aspects are defined as follows:
o Rank of the Linear System or Degrees of Freedom: At a receiver,
the number of linearly independent equations of the linear system.
It is also known as "Degrees of Freedom". The system may be of
"full rank," wherein decoding is possible, or "partial rank",
wherein only partial decoding is possible.
o Generation, or Block: With block codes, the set of source symbols
of the input flow(s) that are logically grouped into a block,
before doing encoding.
Matsuzono, et al. Expires May 19, 2022 [Page 5]
Internet-Draft NC for CCNx/NDN November 2021
o Generation Size, or Block Size: With block codes, the number of
source symbols belonging to a block. It is equivalent to the
number of source packets when there is a single source symbol per
source packet.
o Generation ID, or Block ID: With block codes, the identifier of a
block to which source and coded symbols belong. It is also known
as "Source Block Number (SBN)".
o Coding Coefficient: With linear coding, this is a coefficient in a
certain finite field. This coefficient may be chosen in different
ways: for instance, randomly, in a predefined table, or using a
predefined algorithm plus a seed.
o Coding Vector: A set of coding coefficients used to generate a
certain coded symbol through linear coding.
o Finite Field: Finite fields, used in linear codes, have the
desired property of having all elements (except zero) invertible
for + and * and no operation over any elements can result in an
overflow or underflow. Examples of finite fields are prime fields
{0..p^m-1}, where p is prime. Most used fields use p=2 and are
called binary extension fields {0..2^m-1}, where m often equals 1,
4 or 8 for practical reasons.
o Finite Field size: The number of elements in a finite field. For
example the binary extension field {0..2^m-1} has size q=2^m.
2.2. Definitions related to CCNx/NDN
The terminologies regarding CCNx/NDN used in this document are
defined in RFC8793 [17] produced by ICNRG. They are consistent with
the relevant documents ([1] [18]).
3. CCNx/NDN Basics
We briefly explain the key concepts of CCNx/NDN. In a CCNx/NDN
network, there are two types of packets at the network level:
interest and data packet (defined in Section 3.4 of [17]). The term
of content object, which means a unit of content data, is an alias to
data packet [17]. The ICN consumer (defined in Section 3.2 of [17])
requests a content object by sending an interest that carries the
name of the data.
Once an ICN forwarder (defined in Section 3.2 of [17]) receives an
interest, it performs a series of lookups: first it checks if it has
a copy of the requested content object available in the Content Store
(CS) (defined in Section 3.3 of [17]). If it does, it returns the
Matsuzono, et al. Expires May 19, 2022 [Page 6]
Internet-Draft NC for CCNx/NDN November 2021
data, and the transaction is considered to have been successfully
completed.
If it does not have a copy of the requested content object in the CS,
it performs a lookup of the Pending Interest Table (PIT) (defined in
Section 3.3 of [17]) to check if there is already an outgoing
interest for the same content object. If there is no such interest,
then it creates an entry in the PIT that lists the name included in
the interest, and the interfaces from which it received the interest.
This is later used to send the content object back, as interest
packets do not carry a source field that identifies the consumer. If
there is already a PIT entry for this name, it is updated with the
incoming interface of this new interest, and the interest is
discarded.
After the PIT lookup, the interest undergoes a Forwarding Information
Base (FIB) (defined in Section 3.3 of [17]) lookup for selecting an
outgoing interface. The FIB lists name prefixes and their
corresponding forwarding interfaces in order to send the interest
towards a forwarder that possesses a copy of the requested data.
Once a copy of the data is retrieved, it is sent back to the
consumer(s) using the trail of PIT entries; forwarders remove the PIT
state every time that an interest is satisfied, and may store the
data in their CS.
Data packets carry some information for verifying data integrity and
origin authentication, and in particular, that the data is indeed
that which corresponds to the name [24]. This is necessary because
authentication of the object is crucial in CCNx/NDN. However, this
step is optional at forwarders in order to speed up the processing.
The key aspect of CCNx/NDN is that the consumer of the content does
not establish a session with a specific server. Indeed, the
forwarder or producer (defined in Section 3.2 of [17]) that returns
the content object is not aware of the network location of the
consumer and the consumer is not aware of the network location of the
node that provides the content. This, in theory, allows the
interests to follow different paths within a network or even to be
sent over completely different networks.
4. NC Basics
While the forwarding node simply relays received data packets in
conventional IP communication networks, NC allows the node to combine
some data packets that are already received into one or several
output packets to be sent. In this section, we simply describe the
Matsuzono, et al. Expires May 19, 2022 [Page 7]
Internet-Draft NC for CCNx/NDN November 2021
basic operations of NC. Herein, we focus on RLC in a block coding
manner that is well known as a major coding technique.
For simplicity, let us consider an example case of end-to-end coding
wherein a producer and consumer respectively perform encoding and
decoding for a content object. This end-to-end coding is regarded as
a special case of NC. The producer splits the content into several
blocks called generations. Encoding and decoding are performed
independently on a per-block (per-generation) basis. Let us assume
that each generation consists of K original source packets of the
same size. When the packets do not have the same size, zero padding
is added. In order to generate one repair packet within a certain
generation, the producer linearly combines K of the original source
packets, where additions and multiplications are performed using a
coding vector consisting of K coding coefficients that are randomly
selected in a certain finite field. The producer may respond to
interests to send the corresponding source packets and repair packets
in the content flow (called systematic coding), where the repair
packets are typically used for recovering lost source packets.
Repair packets can also be used for performing encoding. If the
forwarding nodes know each coding vector and generation identifier of
the received repair packets, they may perform an encoding operation
(called re-coding), which is the most distinctie feature of NC
compared to other coding techniques.
At the consumer, decoding is performed by solving a set of linear
equations that are represented by the coding vectors of the received
source and repair packets (possibly only repair packets) within a
certain generation. In order to obtain all the source packets, the
consumer requires K linearly independent equations. In other words,
the consumer must receive at least K linearly independent data
packets (called innovative packets). As receiving a linearly
dependent data packet is not useful for decoding, re-coding should
generate and provide innovative packets. One of major benefits of
RLC is that even for a small-sized finite field (e.g., q=2^8), the
probability of generating linearly dependent packets is negligible
[32].
5. Advantages of NC and CCNx/NDN
Combining NC and CCNx/NDN can contribute to effective large-scale
content/information dissemination. They individually provide similar
benefits such as throughput/capacity gain and robustness enhancement.
The difference between their approaches is that, the former considers
content flow as algebraic information that is to be combined [20],
while the latter focuses on the content/information itself at the
networking layer. Because these approaches are complementary and
Matsuzono, et al. Expires May 19, 2022 [Page 8]
Internet-Draft NC for CCNx/NDN November 2021
their combination would be advantageous, it is natural to combine
them.
The name-based communication in CCNx/NDN enables consumers to obtain
requested content objects without establishing and maintaining end-
to-end communication channels between nodes. This feature
facilitates the exploitation of the in-network cache and multipath/
multisource retrieval and also supports consumer mobility without the
need for updating the location information/identifier during handover
[16]. Furthermore, the name-based communication intrinsically
supports multicast communication because identical interests are
aggregated at the forwarders.
NC can enable the CCNx/NDN transport system to effectively distribute
and cache the data associated with multipath data retrieval [9].
Exploiting multipath data retrieval and in-network caching with NC
contributes to not only improving the cache hit rate but also
expanding the anonymity set of each consumer (the set of potential
routers that can serve a given consumer) [30]. The expansion makes
it difficult for adversaries to infer the content consumed by others,
and thus contributes to improving cache privacy. Others also have
introduced some use cases of the application of NC in CCNx/NDN, such
as the cases of content dissemination with in-network caching [10]
[13] [14], seamless consumer mobility [11] [36], and low-latency low-
loss video streaming [15]. In this context, it is well worth
considering NC integration in CCNx/NDN.
6. Technical Considerations
This section presents the considerations for CCNx/NDN with NC in
terms of network architecture and protocol. This document focuses on
NC when employed in a block coding manner.
6.1. Content Naming
Naming content objects is as important for CCNx/NDN as naming hosts
is in the current-day Internet [24]. In this section, two possible
naming schemes are presented.
Each source and repair packet (hereinafter referred to as NC packet)
may have a unique name as each original content object has in CCNx/
NDN, as PIT and CS (i.e., cache storage called content store)
operations typically require a unique name for identifying the NC
packet. As a method of naming an NC packet that takes into account
the feature of block coding, the coding vector and the identifier of
the generation (also called block) can be used as a part of the
content object name. As in [10], when the generation ID is "g-id",
generation size is 4, and coding vector is (1,0,0,0), the name could
Matsuzono, et al. Expires May 19, 2022 [Page 9]
Internet-Draft NC for CCNx/NDN November 2021
be /CCNx.com/video-A/g-id/1000. Some other identifiers and/or
parameters related to the encoding scheme can also be used as name
components. For instance, the encoding ID specifying the coding
scheme may be used with "enc-id" such as /CCNx.com/video-A/enc-id/
g-id/1000, as defined in the FEC Framework (FECFRAME) [26]. This
naming scheme is simple and can support the delivery of NC packets
with exactly the same operations in the PIT/CS as those for the
content objects.
If a content-naming schema such as the one presented above is used,
an interest requesting an NC packet may have the full name including
a generation id and coding vector (/CCNx.com/video-A/g-id/1000) or
only the name prefix including only a generation id (/CCNx.com/video-
A/g-id). In the former case, exact name matching to the PIT is
simply performed at data forwarders (as in CCNx/NDN). The consumer
is able to specify and retrieve an innovative packet necessary for
the consumer to decode successfully. This could shift the generation
of the coding vector from the data forwarder onto the consumer.
In the latter case, partial name matching is required at the data
forwarders. As the interest with only the prefix name matches any NC
packet with the same prefix, the consumer could immediately obtain an
NC packet from a nearby CS (in-network cache) without knowing the
coding vectors of the cached NC packets in advance. In the case
wherein NC packets in transit are modified by in-network re-coding
performed at forwarders, the consumer could also receive the modified
NC packets. However, in contrast to the former case, the consumer
may fail to obtain sufficient degrees of freedom (see Section 6.2.3).
To address this issue, a new TLV type in an interest message may be
required for specifying further coding information in order to limit
the NC packets to be received. For instance, this is enabled by
specifying the coding vectors of innovative packets for the consumer
(also called decoding matrix) as in [9]. This extension may incur an
interest packet of significantly increased size, and it may thus be
useful to use compression techniques for coding vectors [27] [28].
Without such coding information provided by the interest, the
forwarder would be required to maintain some records regarding the
interest packets that were satisfied previously (See Section 6.2.3).
An NC packet may have a name that indicates that it is an NC packet,
and move the coding information into a metadata field in the payload
(i.e., the name includes the data type, source or repair packet).
This would not be beneficial for applications or services that may
not need to understand the packet payload. Owing to the possibility
that multiple NC packets may have the same name, some mechanism is
required for the consumer to obtain innovative packets. As described
in Section 6.3, a mechanism for managing the multiple innovative
packets in the CS would also be required. In addition, extra
Matsuzono, et al. Expires May 19, 2022 [Page 10]
Internet-Draft NC for CCNx/NDN November 2021
computational overhead would be incurred when the payload is being
encrypted.
6.2. Transport
The pull-based request-response feature of CCNx/NDN is a fundamental
principle of its transport layer; one interest retrieves at most one
data packet. This means that forwarder or producer cannot
initiatively inject unrequested data. It is believed that it is
important that this rule not be violated, as 1) it would open denial-
of-service (DoS) attacks, 2) it invalidates existing congestion
control approaches following this rule, and 3) it would reduce the
efficiency of existing consumer mobility approaches. Thus, the
following basic operation should be considered for applying NC to
CCNx/NDN. Nevertheless, such security considerations must be
addressed if this rule were to be violated.
6.2.1. Scope of NC
An open question is whether data forwarder can perform in-network re-
coding with data packets that are being received in transit, or if
only the data that matches an interest can be subject to NC
operations. In the latter case, encoding or re-coding is performed
to generate the NC packet at any forwarder that is able to respond to
the interest. This could occur when each NC packet has a unique name
and interest has the full name. On the other hand, if interest has a
partial name without any coding vector information or NC packets have
a same name, the former case may occur; re-coding occurs anywhere in
the network where it is possible to modify the received NC packet and
forward it. As CCNx/NDN comprises mechanisms for ensuring the
integrity of the data during transfer, in-network re-coding
introduces complexities in the network that needs consideration for
the integrity mechanisms to still work. Similarly, in-network
caching of NC packets at forwarders may be valuable; however, the
forwarders would require some mechanisms to validate the NC packets
(see Section 8).
6.2.2. Consumer Operation
To obtain NC benefits (possibly associated with in-network caching),
the consumer is required to issue interests that direct the forwarder
(or producer) to respond with innovative packets if available. In
the case where each NC packet may have a unique name (as described in
Section 6.1), by issuing an interest specifying a unique name with
g-id and the coding vector for an NC packet, the consumer could
appropriately receive an innovative packet if it is available at some
forwarders.
Matsuzono, et al. Expires May 19, 2022 [Page 11]
Internet-Draft NC for CCNx/NDN November 2021
In order to specify the exact name of the NC packet to be retrieved,
the consumer is required to know the valid naming scheme. From a
practical viewpoint, it is desirable for the consumer application to
automatically construct the right name components without depending
on any application specifications. To this end, the consumer
application may retrieve and refer to a manifest [1] that enumerates
the content objects including NC packets, or may use some coding
scheme specifier as a name component to construct the name components
of interests to request innovative packets.
Conversely, the consumer without decoding capability (e.g., specific
sensor node) may want to receive only the source packets. As
described in Section 6.1, because the NC packet can have a name that
is explicitly different from source packets, issuing interests for
retrieving source packets is possible.
6.2.3. Forwarder Operation
If the forwarder constantly responds to the incoming interests by
returning non-innovative packets, the consumer(s) cannot decode and
obtain the source packets. This issue could happen when 1) incoming
interests for NC packets do not specify some coding parameters such
as the coding vectors to be used, and 2) the forwarder does not have
a sufficient number of linearly independent NC packets (possibly in
the CS) to use for re-coding. In this case, the forwarder is
required to determine whether or not it can generate innovative
packets to be forwarded to the interface(s) at which the interests
arrived. An approach to deal with this issue is that the forwarder
maintains a tally of the interests for a specific name, generation ID
and the incoming interface(s), in order to record how many degrees of
freedom have already been provided [10]. As such a scheme requires
state management (and potentially timers) in forwarders, scalability
and practicality must be considered. In addition, some transport
mechanism for in-network loss detection and recovery [15] [36] at
forwarder as well as a consumer-driven mechanism could be
indispensable for enabling fast loss recovery and realising NC gains.
If a forwarder cannot either return a matching innovative packet from
its local content store, nor produce on-the-fly a recoded packet that
is innovative, it is important that the forwarder not simply return a
non-innovative packet but instead do a forwarding lookup in its FIB
and forward the interest toward the producer or upstream forwarder
that can provide an innovative packet. In this context, to retrieve
innovative packet effectively and quickly, an appropriate setting of
the FIB and efficient interest forwarding strategies should also be
considered.
In another possible case, when receiving interests only for source
packets, the forwarder may attempt to decode and obtain all the
Matsuzono, et al. Expires May 19, 2022 [Page 12]
Internet-Draft NC for CCNx/NDN November 2021
source packets and store them (if the full cache capacity are
available), thus enabling a faster response to the interests. As re-
coding or decoding results in an extra computational overhead, the
forwarder is required to determine how to respond to received
interests according to the use case (e.g., a delay-sensitive or
delay-tolerant application) and the forwarder situation, such as
available cache space and computational capability.
6.2.4. Producer Operation
Before performing NC for specified content in CCNx/NDN, the producer
is responsible for splitting the overall content into small content
objects to avoid packet fragmentation that could cause unnecessary
packet processing and degraded throughput. The size of the content
objects should be within the allowable packet size in order to avoid
packet fragmentation in CCNx/NDN network. The producer performs the
encoding operation for a set of the small content objects, and the
naming process for the NC packets.
If the producer takes the lead in determining what coding vectors to
use in generating the NC packets, there are three general strategies
for naming and producing the NC packets:
1. consumers themselves understand in detail the naming conventions
used for NC packets and thereby can send the corresponding
interests toward the producer to obtain NC packets whose coding
parameters have already been determined by the producer.
2. the producer determines the coding vectors and generates the NC
packets after receiving interests specifying the packets the
consumer wished to receive.
3. The naming scheme for specifying the coding vectors and
corresponding NC packets is explicitly represented via a
"Manifest" (e.g., FLIC [23]) that can be obtained by the consumer
and used to select among the available coding vectors and their
corresponding packets, and thereby send the corresponding
interests.
In the first case, although the consumers cannot flexibly specify a
coding vector for generating the NC packet to obtain, the latency for
obtaining the NC packet is less than in the latter two cases. For
the second case, there is a latency penalty for the additional NC
operations performed after receiving the interests. For the third
case, the NC packets to be included in the manifest must be pre-
computed by the producer (since the manifest references NC packets by
their hashes, not their names), but the producer can select which to
Matsuzono, et al. Expires May 19, 2022 [Page 13]
Internet-Draft NC for CCNx/NDN November 2021
include the manifest, and produce multiple manifests either in
advance or on demand with different coding tradeoffs if so desired.
A common benefit the first two approaches to end-to-end coding is
that if the producer adds a signature on the NC packets, data
validation becomes possible throughout (as is the case with CCNx/NDN
operation in the absence of NC). The third approach of using a
manifest trades off the additional latency incurred by the need to
fetch the manifest against the efficiency of needing a signature only
on the manifest and not on each individual NC packet.
6.2.5. Backward Compatibility
NC operations should be applied in addition to the regular ICN
behavior. Hence, nodes should be able to not support network coding
(not only in forwarding the packets, but also in the caching
mechanism). NC operations should function alongside regular ICN
operations. An NC framework should be compatible with a regular
framework in order to facilitate backward compatibility and smooth
migration from one framework to the other.
6.3. In-network Caching
Caching is a useful technique used for improving throughput and
latency in various applications. In-network caching in CCNx/NDN
essentially provides support at network level and is highly
beneficial owing to the involved exploitation of NC for enabling
effective multicast transmission [37], multipath data retrieval [10]
[11], fast loss recovery [15]. However, there remain several issues
to be considered.
There generally exist limitations in the CS capacity, and the caching
policy affects the consumer's performance [29] [34] [35]. It is thus
crucial for forwarders to determine which content objects should be
cached and which discarded. As delay-sensitive applications often do
not require an in-network cache for a long period owing to their
real-time constraints, forwarders have to know the necessity for
caching received content objects to save the caching volume. In
CCNx, this could be made possible by setting a Recommended Cache Time
(RCT) in the optional header of the data packet at the producer side.
The RCT serves as a guideline for the CS cache in determining how
long to retain the content object. When the RCT is set as zero, the
forwarder recognizes that caching the content object is not useful.
Conversely, the forwarder may cache it when the RCT has a greater
value. In NDN, the TLV type of FreshnessPeriod could be used.
One key aspect of in-network caching is whether or not forwarders can
cache NC packets in their CS. They may be caching the NC packets
Matsuzono, et al. Expires May 19, 2022 [Page 14]
Internet-Draft NC for CCNx/NDN November 2021
without having the ability to perform a validation of the content
objects. Therefore, the caching of the NC packets would require some
mechanism to validate the NC packets (see Section 8). In the case
wherein the NC packets have the same name, it would also require some
mechanism to identify them.
6.4. Seamless Consumer Mobility
A key feature of CCNx/NDN is that it is sessionless, which enables
the consumer and forwarder to send multiple interests toward
different copies of the content in parallel, by using multiple
interfaces at the same time in an asynchronous manner. Through the
multipath data retrieval, the consumer could obtain the content from
multiple copies that are distributed while using the aggregate
capacity of multiple interfaces. For the link between the consumer
and the multiple copies, the consumer can perform a certain rate
adaptation mechanism for video streaming [11] or congestion control
for content acquisition [12].
NC adds a reliability layer to CCNx in a distributed and asynchronous
manner, because NC provides a mechanism for ensuring that the
interests sent to multiple copies of the content in parallel retrieve
innovative packets, even in the case of packet losses on some of the
paths/networks to these copies. This applies to consumer mobility
events [11], wherein the consumer could receive additional degrees of
freedom with any innovative packet if at least one available
interface exists during the mobility event. An interest forwarding
strategy at the consumer (and possibly forwarder) for efficiently
obtaining innovative packets would be required for the consumer to
achieve seamless consumer mobility.
7. Challenges
This section presents several primary challenges and research items
to be considered when applying NC in CCNx/NDN.
7.1. Adoption of Convolutional Coding
Several block coding approaches have been proposed thus far; however,
there is still not sufficient discussion and application of the
convolutional coding approach (e.g., sliding or elastic window
coding) in CCNx/NDN. Convolutional coding is often appropriate for
situations wherein a fully or partially reliable delivery of
continuous data flows is required, and especially when these data
flows feature realtime constraints. As in [40], on an end-to-end
coding basis, it would be advantageous for continuous content flow to
adopt sliding window coding in CCNx/NDN. In this case, the producer
is required to appropriately set coding parameters and let the
Matsuzono, et al. Expires May 19, 2022 [Page 15]
Internet-Draft NC for CCNx/NDN November 2021
consumer know the information, and the consumer is required to send
interests augmented with feedback information regarding the data
reception and/or decoding status. As CCNx/NDN utilises hop-by-hop
forwarding state, it would be worth discussing and investigating how
convolutional coding can be applied in a hop-by-hop manner and what
benefits might accrue. In particular, in the case wherein in-network
re-coding could occur at forwarders, both the encoding window and CS
management would be required, and the corresponding feasibility and
practicality should be considered.
7.2. Rate and Congestion Control
The addition of redundancy using repair packets may result in further
network congestion and could adversely affect the overall throughput.
In particular, in a situation wherein fair bandwidth sharing is more
desirable, each streaming flow must adapt to the network conditions
to fairly consume the available link bandwidth. It is thus necessary
that each content flow cooperatively implement congestion control to
adjust the consumed bandwidth [22]. From this perspective, although
a forwarder-supported approach would be effective, an effective
deployment approach that provides benefits under partial deployment
is required.
As described in Section 6.4, NC can contribute to seamless consumer
mobility by obtaining innovative packets without receiving duplicated
packets through multipath data retrieval. It can be challenging to
develop an effective rate and congestion control mechanism in order
to achieve seamless consumer mobility while improving the overall
throughput or latency by fully exploiting NC operations.
7.3. Security
While CCNx/NDN introduces new security issues at the networking layer
that are different from the IP network, such as a cache poisoning and
pollution attacks, a DoS attack using interest packets, some security
approaches are already provided [24] [25]. The application of NC in
CCNx/NDN brings two potential security aspects that need to be dealt
with.
The first is in-network re-coding at forwarders. Some mechanism for
ensuring the integrity of the NC packets newly produced by in-network
re-coding is required in order for consumers or other forwarders to
receive valid NC packets. To this end, there are some possible
approaches described in Section 8, but there may be more effective
method with lower complexity and computation overhead.
The second is that attackers maliciously request and inject NC
packets, which could amplify some attacks. As NC packets are
#x27; components.
int32 entPhysicalParentRelPos = 6;
}
oneof entPhysicalName_present {
// The textual name of the physical entity.
string entPhysicalName = 7;
}
oneof entPhysicalHardwareRev_present {
// The vendor-specific hardware revision string for the physical
// entity.
string entPhysicalHardwareRev = 8;
}
oneof entPhysicalFirmwareRev_present {
// The vendor-specific firmware revision string for the physical
// entity.
string entPhysicalFirmwareRev = 9;
}
oneof entPhysicalSoftwareRev_present {
// The vendor-specific software revision string for the physical
// entity.
string entPhysicalSoftwareRev = 10;
}
oneof entPhysicalSerialNum_present {
// The vendor-specific serial number string for the physical
// entity.
string entPhysicalSerialNum = 11;
}
Duffy (ed) Expires 13 June 2024 [Page 26]
Internet-Draft CoAP Simple Management Protocol December 2023
oneof entPhysicalMfgName_present {
// The name of the manufacturer of this physical component.
string entPhysicalMfgName = 12;
}
oneof entPhysicalModelName_present {
// The vendor-specific model name identifier string associated
// with this physical component.
string entPhysicalModelName = 13;
}
oneof entPhysicalAssetID_present {
// This object is a user-assigned asset tracking identifier for
// the physical entity and provides non-volatile storage of this
// information.
string entPhysicalAssetID = 14;
}
oneof entPhysicalMfgDate_present {
// This object contains the date of manufacturing of the managed
// entity.
uint32 entPhysicalMfgDate = 15;
}
oneof entPhysicalURIs_present {
// This object contains additional identification information about
// the physical entity.
string entPhysicalURIs = 16;
}
oneof entPhysicalFunction_present {
// This field can take the following values: METER = 1,
// RANGE_EXTENDER = 2, DA_GATEWAY = 3, CGE = 4, ROOT = 5,
// CONTROLLER = 6, SENSOR = 7, NETWORKNODE = 8.
uint32 entPhysicalFunction = 17;
}
oneof entPhysicalOUI_present {
// uniquely identifies a vendor
bytes entPhysicalOUI = 18;
}
// This defines a list of hardware modules with their
// firmware versions
repeated HardwareModule hwModule = 19;
}
// TLV 12
// This TLV contains description information for an interface on
// the device. The contents of these fields are defined by the
// equivalently-named fields in the SNMP MIB object ifTable.
// Class:: Generic
//
message InterfaceDesc {
Duffy (ed) Expires 13 June 2024 [Page 27]
Internet-Draft CoAP Simple Management Protocol December 2023
oneof ifIndex_present {
// A unique value, greater than zero, for each interface.
int32 ifIndex = 1;
}
oneof ifName_present {
// The textual name of the interface.
string ifName = 2;
}
oneof ifDescr_present {
// A textual string containing information about the interface.
string ifDescr = 3;
}
oneof ifType_present {
// The type of interface.
int32 ifType = 4;
}
oneof ifMtu_present {
// The size of the largest packet which can be sent/received
// on the interface, specified in octets.
int32 ifMtu = 5;
}
oneof ifPhysAddress_present {
// The interface's address at its protocol sub-layer.
bytes ifPhysAddress = 6;
}
}
// TLV 13
// This TLV specifies the periodic reporting of a set of TLVs.
// Class:: Generic
//
message ReportSubscribe {
oneof interval_present {
// The periodic time interval (in seconds) at which the device
// sends the tlvid set of tlvs.
uint32 interval = 1;
}
// The tlvs to be sent on the interval.
repeated string tlvid = 2;
oneof intervalHeartBeat_present {
// The periodic time interval at which the device sends the
// tlvidHeartBeat set of tlvs.
uint32 intervalHeartBeat = 3;
}
// The tlvs to be sent on the heartbeat interval.
repeated string tlvidHeartBeat = 4;
Duffy (ed) Expires 13 June 2024 [Page 28]
Internet-Draft CoAP Simple Management Protocol December 2023
}
// TLV 16
// Describes a particular IP address (identified by the index) attached
// to an interface.
// Class:: Generic
//
message IPAddress {
oneof ipAddressIndex_present {
// A unique value, greater than zero, for each IP address
int32 ipAddressIndex = 1;
}
oneof ipAddressAddrType_present {
// Address type defined as integers :
// ipv4=1, ipvv6=2, ipv4z=3, ipv6z=4, ipv6am=5
uint32 ipAddressAddrType = 2;
}
oneof ipAddressAddr_present {
// The IP address
bytes ipAddressAddr = 3;
}
oneof ipAddressIfIndex_present {
// Index of the associated interface
int32 ipAddressIfIndex = 4;
}
oneof ipAddressType_present {
// IP type defined as integers :
// unicast=1, anycast=2, broadcast=3
uint32 ipAddressType = 5;
}
oneof ipAddressOrigin_present {
// Address origin defined as integers:
// other=1, manual=2, dhcp=4, linklayer=5, random=6
uint32 ipAddressOrigin = 6;
}
oneof ipAddressStatus_present {
// status defined as integers:
// preferred=1, deprecated=2, invalid=3, inaccessible=4, unknown=5,
// tentative=6, duplicate=7, optimistic=8
uint32 ipAddressStatus = 7;
}
reserved 8;
reserved 9;
oneof ipAddressPfxLen_present {
// The prefix length associated with the IP address.
uint32 ipAddressPfxLen = 10;
}
Duffy (ed) Expires 13 June 2024 [Page 29]
Internet-Draft CoAP Simple Management Protocol December 2023
}
// TLV 17
// Describes a particular IP route (identified by the index) attached
// to an interface.
// Class:: Generic
//
message IPRoute {
oneof inetCidrRouteIndex_present {
// A unique value, greater than zero, for each route.
int32 inetCidrRouteIndex = 1;
}
oneof inetCidrRouteDestType_present {
// Destination Addresss type defined as integers:
// ipv4=1, ipvv6=2, ipv4z=3, ipv6z=4, ipv6am=5.
uint32 inetCidrRouteDestType = 2;
}
oneof inetCidrRouteDest_present {
// IP address of the destination of the route.
bytes inetCidrRouteDest = 3;
}
oneof inetCidrRoutePfxLen_present {
// Associated prefix length of the route destination.
uint32 inetCidrRoutePfxLen = 4;
}
oneof inetCidrRouteNextHopType_present {
// Next hop Addresss type defined as integers:
// ipv4=1, ipvv6=2, ipv4z=3, ipv6z=4, ipv6am=5.
uint32 inetCidrRouteNextHopType = 5;
}
oneof inetCidrRouteNextHop_present {
// IP address of the next hop of the route (device parent).
bytes inetCidrRouteNextHop = 6;
}
oneof inetCidrRouteIfIndex_present {
// Index of the associated interface.
int32 inetCidrRouteIfIndex = 7;
}
reserved 8;
reserved 9;
reserved 10;
}
// TLV 18
// Contains the current time as maintainced on the device.
// For time stamping purposes, this tlvid MUST also be sent along with
// every periodic metric report. It MAY contain a POSIX timestamp
Duffy (ed) Expires 13 June 2024 [Page 30]
Internet-Draft CoAP Simple Management Protocol December 2023
// or an ISO 8601 timestamp.
// Class:: Generic
//
message CurrentTime {
oneof posix_present {
// posix timestamp.
uint32 posix = 1;
}
oneof iso8601_present {
// iso 8601 timestamp.
string iso8601 = 2;
}
oneof source_present {
// time service from:
// local=1, admin=2, network=3.
uint32 source = 3;
}
}
// TLV 21
// For retrieving the RPL Settings on the device.
// Class:: Mesh
//
message RPLSettings {
oneof ifIndex_present {
// interface id
int32 ifIndex = 1;
}
oneof enabled_present {
// whether RPL feature is enabled.
bool enabled = 2;
}
oneof dioIntervalMin_present {
// min interval of DIO trickle timer in milliseconds.
uint32 dioIntervalMin = 3;
}
oneof dioIntervalMax_present {
// max interval of DIO trickle timer in milliseconds.
uint32 dioIntervalMax = 4;
}
oneof daoIntervalMin_present {
// min interval of DAO trickle timer in milliseconds.
uint32 daoIntervalMin = 5;
}
oneof daoIntervalMax_present {
// max interval of DAO trickle timer in milliseconds.
Duffy (ed) Expires 13 June 2024 [Page 31]
Internet-Draft CoAP Simple Management Protocol December 2023
uint32 daoIntervalMax = 6;
}
oneof mopType_present {
// mode of operation for RPL. 1: non-storing mode; 2: storing mode.
uint32 mopType = 7;
}
}
// TLV 22
// Contains the total system uptime of the device (seconds).
// Class:: Generic
//
message Uptime {
oneof sysUpTime_present {
// uptime info in seconds.
uint32 sysUpTime = 1;
}
}
// TLV 23
// The statistics of an interface
// Class:: Generic
//
message InterfaceMetrics {
oneof ifIndex_present {
// A unique value, greater than zero, for each interface.
// Is same as in InterfaceDesc's ifIndex for the same interface.
int32 ifIndex = 1;
}
oneof ifInSpeed_present {
// The speed at which the incoming packets are received on the
// interface.
uint32 ifInSpeed = 2;
}
oneof ifOutSpeed_present {
// The speed at which the outgoing packets are transmitted on
// the interface.
uint32 ifOutSpeed = 3;
}
oneof ifAdminStatus_present {
// The desired state of the interface.
uint32 ifAdminStatus = 4;
}
oneof ifOperStatus_present {
// The current operational state of the interface.
uint32 ifOperStatus = 5;
Duffy (ed) Expires 13 June 2024 [Page 32]
Internet-Draft CoAP Simple Management Protocol December 2023
}
oneof ifLastChange_present {
// The value of sysUpTime at the time the interface entered its
// current operational state.
uint32 ifLastChange = 6;
}
oneof ifInOctets_present {
// The total number of octets received on the interface,
// including framing characters.
uint32 ifInOctets = 7;
}
oneof ifOutOctets_present {
// The total number of octets transmitted out of the interface,
// including framing characters.
uint32 ifOutOctets = 8;
}
oneof ifInDiscards_present {
// The number of inbound packets which were chosen to be discarded
// even though no errors had been detected to prevent their being
// deliverable to a higher-layer protocol (application dependant).
uint32 ifInDiscards = 9;
}
oneof ifInErrors_present {
// For packet-oriented interfaces, the number of inbound packets
// that contained errors preventing them from being deliverable to
// a higher-layer protocol (subset of ifInDiscards).
uint32 ifInErrors = 10;
}
oneof ifOutDiscards_present {
// The number of outbound packets which were chosen to be discarded
// even though no errors had been detected to prevent their being
// transmitted.
uint32 ifOutDiscards = 11;
}
oneof ifOutErrors_present {
// For packet-oriented interfaces, the number of outbound packets
// that could not be transmitted because of errors.
uint32 ifOutErrors = 12;
}
}
// TLV 25
// Describes status of each RPL router
// Class:: Mesh
//
message IPRouteRPLMetrics {
oneof inetCidrRouteIndex_present {
Duffy (ed) Expires 13 June 2024 [Page 33]
Internet-Draft CoAP Simple Management Protocol December 2023
// refers to a particular index in the IPRoute table.
int32 inetCidrRouteIndex = 1;
}
oneof instanceIndex_present {
// Corresponding RPL instance of this route.
int32 instanceIndex = 2;
}
oneof rank_present {
// advertised rank.
int32 rank = 3;
}
oneof hops_present {
// Not currently used, future use of hops metric.
int32 hops = 4;
}
oneof pathEtx_present {
// advertised path ethx.
int32 pathEtx = 5;
}
oneof linkEtx_present {
// next-hop link ETX.
int32 linkEtx = 6;
}
oneof rssiForward_present {
// forward RSSI value (relative to the device).
sint32 rssiForward = 7;
}
oneof rssiReverse_present {
// reverse RSSI value (relative to the device).
sint32 rssiReverse = 8;
}
oneof lqiForward_present {
// forward LQI value.
int32 lqiForward = 9;
}
oneof lqiReverse_present {
// reverse LQI value.
int32 lqiReverse = 10;
}
oneof dagSize_present {
// nodes count of this pan (number of joined devices).
uint32 dagSize = 11;
}
reserved 12 to 17;
// forward phy mode value.
PhyModeInfo phyModeForward = 18;
// reverse phy mode value.
PhyModeInfo phyModeReverse = 19;
Duffy (ed) Expires 13 June 2024 [Page 34]
Internet-Draft CoAP Simple Management Protocol December 2023
}
// TLV 30
// Request the device to perform a ping operation to a
// destination address.
// Class:: Generic
//
message PingRequest {
oneof dest_present {
// IP address to be pinged from the device.
string dest = 1;
}
oneof count_present {
// number of times to ping.
uint32 count = 2;
}
oneof delay_present {
// delay between ping in seconds.
uint32 delay = 3;
}
}
// TLV 31
// Acquire the current status of the last PingRequest.
// Class:: Generic
//
message PingResponse {
oneof sent_present {
// number of packets sent
uint32 sent = 1;
}
oneof received_present {
// number of packets received
uint32 received = 2;
}
oneof minRtt_present {
// min round trip time
uint32 minRtt = 3;
}
oneof meanRtt_present {
// mean round trip time
uint32 meanRtt = 4;
}
oneof maxRtt_present {
// max round trip time
uint32 maxRtt = 5;
Duffy (ed) Expires 13 June 2024 [Page 35]
Internet-Draft CoAP Simple Management Protocol December 2023
}
oneof stdevRtt_present {
// standard deviation of the round trip time
uint32 stdevRtt = 6;
}
oneof src_present {
// source IP address for the ping
string src = 7;
}
}
// TLV 32
// Request a device to reboot.
// Class:: Generic
//
message RebootRequest {
oneof flag_present {
// 0 : reboot and transfer to designated running image.
// 1 : reboot and stop at bootloader CLI.
uint32 flag = 1;
}
}
// TLV 33
// 802.1x status
// Class:: Mesh
//
message Ieee8021xStatus {
oneof ifIndex_present {
// It is RECOMMENDED this be set to 2 for the 6LowPAN interface.
int32 ifIndex = 1;
}
oneof enabled_present {
// 802.1x enabled or not?
bool enabled = 2;
}
oneof identity_present {
// subject name of certificate, max len 32
string identity = 3;
}
oneof state_present {
// state of tls handshake
uint32 state = 4;
}
oneof pmKId_present {
// hash value of pmk, len 16
Duffy (ed) Expires 13 June 2024 [Page 36]
Internet-Draft CoAP Simple Management Protocol December 2023
bytes pmkId = 5;
}
oneof clientCertValid_present {
// whether client cert is valid
bool clientCertValid = 6;
}
oneof caCertValid_present {
// whether ca cert is valid
bool caCertValid = 7;
}
oneof privateKeyValid_present {
// whether private key of client cert is valid
bool privateKeyValid = 8;
}
oneof rlyPanid_present {
// panid of relay node
uint32 rlyPanid = 9;
}
oneof rlyAddress_present {
// eui64 address of relay node, len 8
bytes rlyAddress = 10;
}
oneof rlyLastHeard_present {
// last heard from relay node in seconds
uint32 rlyLastHeard = 11;
}
}
// TLV 34
// 802.11i status
// Class:: Mesh
//
message Ieee80211iStatus {
oneof ifIndex_present {
// It is RECOMMENDED this be set to 2 for the 6LowPAN interface.
int32 ifIndex = 1;
}
oneof enabled_present {
// 802.11i is eabled or not
bool enabled = 2;
}
oneof pmkId_present {
// hash value of pmk, len 16
bytes pmkId = 3;
}
oneof ptkId_present {
// hash value of ptk, len 16
Duffy (ed) Expires 13 June 2024 [Page 37]
Internet-Draft CoAP Simple Management Protocol December 2023
bytes ptkId = 4;
}
oneof gtkIndex_present {
// index of gtk
int32 gtkIndex = 5;
}
oneof gtkAllFresh_present {
// whether all gtk are fresh
bool gtkAllFresh = 6;
}
// list of hash value for each gtk, hash len 8, max repeat 4
repeated bytes gtkList = 7;
// list of lifetime for each gtk, hash len 8, max repeat 4
repeated uint32 gtkLifetimes = 8;
oneof authAddress_present {
// eui64 address of authenticate node
bytes authAddress = 9;
}
}
message PhyModeInfo {
oneof phyMode_present {
// phy operating mode value (as defined in section 5.2 of
// PHYWG Wi-SUN PHY Technical Specification - Amendment 1VA8)
uint32 phyMode = 1;
}
oneof txPower_present {
// transmit power value in dbm.
int32 txPower = 2;
}
}
// TLV 35
// Configuration of WPAN-specific interface settings
// Class:: Mesh
//
message WPANStatus {
oneof ifIndex_present {
// It is RECOMMENDED this be set to 2 for the 6LowPAN interface.
int32 ifIndex = 1;
}
oneof SSID_present {
// Max len 32 (Wi-SUN NetName).
bytes SSID = 2;
}
oneof panid_present {
uint32 panid = 3;
Duffy (ed) Expires 13 June 2024 [Page 38]
Internet-Draft CoAP Simple Management Protocol December 2023
}
reserved 4;
oneof dot1xEnabled_present {
// Is dot1x enabled?
bool dot1xEnabled = 5;
}
oneof securityLevel_present {
// Security level
uint32 securityLevel = 6;
}
oneof rank_present {
uint32 rank = 7;
}
oneof beaconValid_present {
// Is beacon valid (where invalid means receipt has
// timed-out/contact with PAN was lost)? (PC frame for Wi-SUN)
bool beaconValid = 8;
}
oneof beaconVersion_present {
// Beacon version (Wi-SUN PAN version).
uint32 beaconVersion = 9;
}
oneof beaconAge_present {
// Last heard beacon message in seconds (PC frame for Wi-SUN).
uint32 beaconAge = 10;
}
oneof txPower_present {
// Transmit power value in dbm
int32 txPower = 11;
}
oneof dagSize_present {
// Count of nodes joined to this PAN
uint32 dagSize = 12;
}
oneof metric_present {
// Metric to border router (Wi-SUN Routing Cost)
uint32 metric = 13;
}
oneof lastChanged_present {
// seconds since last PAN change (PAN ID change).
uint32 lastChanged = 14;
}
oneof lastChangedReason_present {
// Reason for last PAN change:
// -1 == unknown,
// 0 == mesh initializing,
// 1 == mesh connectivity lost,
Duffy (ed) Expires 13 June 2024 [Page 39]
Internet-Draft CoAP Simple Management Protocol December 2023
// 2 == GTK timeout,
// 3 == default route lost,
// 4 == migrated to better PAN,
// 5 == reserved.
uint32 lastChangedReason = 15;
}
oneof demoModeEnabled_present {
// Is demo mode enabled?
bool demoModeEnabled = 16;
}
oneof txFec_present {
// Is FEC enabled?
bool txFec = 17;
}
oneof phyMode_present {
// Phy operating mode value (as defined in section 5.2 of
// PHYWG Wi-SUN PHY Technical Specification - Amendment 1VA8)
uint32 phyMode = 18;
}
reserved 19;
// Multi phy mode and transmit power value for adaptive modulation.
repeated PhyModeInfo phyModeList = 20;
}
// TLV 36
// Status of DHCP6 client
// Class:: Generic
//
message DHCP6ClientStatus {
oneof ifIndex_present {
// It is RECOMMENDED this be set to 2 for the 6LowPAN interface
int32 ifIndex = 1;
}
oneof ianaIAID_present {
// TA ID value.
uint32 ianaIAID = 2;
}
oneof ianaT1_present {
// T1 value.
uint32 ianaT1 = 3;
}
oneof ianaT2_present {
// T2 value.
uint32 ianaT2 = 4;
}
}
Duffy (ed) Expires 13 June 2024 [Page 40]
Internet-Draft CoAP Simple Management Protocol December 2023
// TLV 42
// Configure device reporting settings.
// Class:: Generic
//
message NMSSettings {
oneof regIntervalMin_present {
// Min interval of register trickle timer in seconds.
uint32 regIntervalMin = 1;
}
oneof regIntervalMax_present {
// Max interval of register trickle timer in seconds.
uint32 regIntervalMax = 2;
}
reserved 3 to 6;
}
// TLV 43
// Registration status to NMS.
// NMS uses this TLV to record the reason for the registration
// operation as recorded in the lastRegReason field of the TLV.
// Class:: Generic
//
message NMSStatus {
oneof registered_present {
// True if device is registerd with NMS.
bool registered = 1;
}
oneof NMSAddr_present {
// IPv6 address of NMS.
bytes NMSAddr = 2;
}
oneof NMSAddrOrigin_present {
// Mechanism used to get NMS's IPv6 address.
// (fixed/DHCPv6/redirect by TLV6 ... values).
uint32 NMSAddrOrigin = 3;
}
oneof lastReg_present {
// Time since last succesful registration in seconds.
uint32 lastReg = 4;
}
oneof lastRegReason_present {
// Reason for last registration:
// 1: coldstart,
// 2: administrative,
// 3: IP address changed,
// 4: NMS changed,
Duffy (ed) Expires 13 June 2024 [Page 41]
Internet-Draft CoAP Simple Management Protocol December 2023
// 5: NMS redirect,
// 6: NMS error,
// 7: IDevID, LDevID, or NMS certificate changed,
// 8: outage recovery.
uint32 lastRegReason = 5;
}
oneof nextReg_present {
// Time to next registration attempt in seconds.
uint32 nextReg = 6;
}
oneof NMSCertValid_present {
// True if NMS certificate is valid.
bool NMSCertValid = 7;
}
}
// TLV 47
// Device settings for 802.1x
// Class:: Mesh
//
message Ieee8021xSettings {
oneof ifIndex_present {
// It is RECOMMENDED this be set to 2 for the 6LowPAN interface.
int32 ifIndex = 1;
}
oneof secMode_present {
// Security mode, non-security or security (Security Level from
// Aux Security Header of IEEE 802.15.4-2020).
uint32 secMode = 2;
}
oneof authIntervalMin_present {
// Min interval of 802.1x trickle timer in seconds.
uint32 authIntervalMin = 3;
}
oneof authIntervalMax_present {
// Max interval of 802.1x trickle timer in seconds.
uint32 authIntervalMax = 4;
}
oneof immediate_present {
// True == do 802.1x authentication immediately,
// False == do 802.1x authentication at next authentication
// interval.
bool immediate = 5;
}
}
// TLV 48
Duffy (ed) Expires 13 June 2024 [Page 42]
Internet-Draft CoAP Simple Management Protocol December 2023
// Statistic of 802.15.4 beacon packets
// Class:: Mesh
//
message Ieee802154BeaconStats {
oneof ifIndex_present {
// It is RECOMMENDED this be set to 2 for the 6LowPAN interface.
int32 ifIndex = 1;
}
oneof inFrames_present {
// Count of received beacon.
uint32 inFrames = 10;
}
oneof inFramesBeaconPAS_present {
// Count of received PAS beacon.
uint32 inFramesBeaconPAS = 11;
}
oneof inFramesBeaconPA_present {
// Count of received PA beacon.
uint32 inFramesBeaconPA = 12;
}
oneof inFramesBeaconPCS_present {
// Count of received PCS beacon.
uint32 inFramesBeaconPCS = 13;
}
oneof inFramesBeaconPC_present {
// Count of received PC beacon.
uint32 inFramesBeaconPC = 14;
}
oneof outFrames_present {
// Count of all sent out beacon.
uint32 outFrames = 20;
}
oneof outFramesBeaconPAS_present {
// Count of sent out PAS beacon.
uint32 outFramesBeaconPAS = 21;
}
oneof outFramesBeaconPA_present {
// Count of sent out PA beacon.
uint32 outFramesBeaconPA = 22;
}
oneof outFramesBeaconPCS_present {
// Count of sent out PCS beacon.
uint32 outFramesBeaconPCS = 23;
}
oneof outFramesBeaconPC_present {
// Count of sent out PC beacon.
uint32 outFramesBeaconPC = 24;
Duffy (ed) Expires 13 June 2024 [Page 43]
Internet-Draft CoAP Simple Management Protocol December 2023
}
}
// TLV 53
// Indicates RPL instance information
// Class:: Mesh
//
message RPLInstance {
oneof instanceIndex_present {
// Index for instance.
int32 instanceIndex = 1;
}
oneof instanceId_present {
// Instance id.
int32 instanceId = 2;
}
oneof doDagId_present {
// DODAG id, len 16.
bytes doDagId = 3;
}
oneof doDagVersionNumber_present {
// DODAG version number of instance.
int32 doDagVersionNumber = 4;
}
oneof rank_present {
// Rank value.
int32 rank = 5;
}
oneof parentCount_present {
// Count of available parents (Wi-SUN candidate parent set).
int32 parentCount = 6;
}
oneof dagSize_present {
// Node count of this DODAG.
uint32 dagSize = 7;
}
// Max repeat 3.
repeated RPLParent parents = 8;
// Max repeat 3.
repeated RPLParent candidates = 9;
}
message RPLParent {
oneof parentIndex_present {
// This parent's index in the RPLParent table.
int32 parentIndex = 1;
}
Duffy (ed) Expires 13 June 2024 [Page 44]
Internet-Draft CoAP Simple Management Protocol December 2023
oneof instanceIndex_present {
// A particular index in the RPLInstance table that this
// parent underlies.
int32 instanceIndex = 2;
}
oneof routeIndex_present {
// A particular index in the IPRoute table that this
// parent underlies.
int32 routeIndex = 3;
}
oneof ipv6AddressLocal_present {
// IPv6 linklocal address.
bytes ipv6AddressLocal = 4;
}
oneof ipv6AddressGlobal_present {
// IPv6 global address.
bytes ipv6AddressGlobal = 5;
}
oneof doDagVersionNumber_present {
// DODAG version number if RPL parent.
uint32 doDagVersionNumber = 6;
}
oneof pathEtx_present {
// The parent's ETX back to the root.
int32 pathEtx = 7;
}
oneof linkEtx_present {
// The node's ETX to its next-hop.
int32 linkEtx = 8;
}
oneof rssiForward_present {
// Forward RSSI value.
sint32 rssiForward = 9;
}
oneof rssiReverse_present {
// Reverse RSSI value.
sint32 rssiReverse = 10;
}
oneof lqiForward_present {
// Forward LQI value.
int32 lqiForward = 11;
}
oneof lqiReverse_present {
// Reverse LQI value.
int32 lqiReverse = 12;
}
oneof hops_present {
// parent's hop value.
Duffy (ed) Expires 13 June 2024 [Page 45]
Internet-Draft CoAP Simple Management Protocol December 2023
int32 hops = 13;
}
}
// Groups in CSMP provide a mechanism to realize application
// layer multicast in the network. A group is uniquely defined by
// a type, id pair. Membership within a group type is exclusive,
// i.e., a device can be a member of only one group-id within a
// group-type. However, a device can be a member of more than one
// group of different group-types.
// A device is informed about its membership to a group using the
// GroupAssign TLV. On their very first boot, devices do not
// belong to any group. A device is added to a group by sending a
// GroupAssign TLV to the device. Receipt of a GroupAssign TLV
// replaces any existing group assignments. GroupAssign may occur
// either by direct unicast to a device or in the registration
// response from the NMS to the device. Note that a GroupAssign
// should not be sent over multicast, because it would possibly
// cause some group members to change and some group members not
// to change.
// Group membership information MUST be stored in persistent
// storage so that once a device has been assigned any group it is
// remembered across reboots. A device will only process multicast
// messages containing a GroupMatch TLV if the device belongs to a
// group specified by the GroupMatch TLV.
// TLV 55
// Class:: Generic
//
message GroupAssign {
oneof type_present {
uint32 type = 1;
}
oneof id_present {
uint32 id = 2;
}
}
// TLV 57
// Class:: Generic
//
message GroupMatch {
oneof type_present {
uint32 type = 1;
Duffy (ed) Expires 13 June 2024 [Page 46]
Internet-Draft CoAP Simple Management Protocol December 2023Matsuzono, et al. Expires May 19, 2022 [Page 16]
Internet-Draft NC for CCNx/NDN November 2021
unpopular in general use, they could be targeted by a cache pollution
attack that requests less popular content objects more frequently to
undermine popularity-based caching by skewing the content popularity.
Such an attack needs to be dealt with in order to maintain the in-
network cache efficiency. By injecting invalid NC packets with the
goal of filling the CSs at the forwarders with them, the cache
poisoning attack could be effectual depending on the exact integrity
coverage on NC packets. On the assumption that each NC packet has
the valid signature, the straightforward approach would comprise the
forwarders verifying the signature within the NC packets in transit
and only transmitting and storing the validated NC packets. However,
as performing a signature verification by the forwarders may be
infeasible at line speed, some mechanisms should be considered for
distributing and reducing the load of signature verification, in
order to maintain in-network cache benefits such as latency and
network-load reduction.
7.4. Routing Scalability
In CCNx/NDN, a name-based routing protocol without a resolution
process streamlines the routing process and reduces the overall
latency. In IP routing, the growth in the routing table size has
become a concern. It is thus necessary to use a hierarchical naming
scheme in order to improve the routing scalability by enabling the
aggregation of the routing information.
To realize the benefits of NC, consumers need to efficiently obtain
innovative packets using multipath retrieval mechanisms of CCNx/NDN.
This would require some efficient routing mechanism to appropriately
set the FIB and also an efficient interest forwarding strategy. Such
routing coordination may create routing scalability issues. It would
be challenging to achieve effective and scalable routing for
interests requesting NC packets as well as to simplify the routing
process.
8. Security Considerations
In-network re-coding is a distinguishing feature of NC. Only valid
NC packets produced by in-network re-coding must be requested and
utilized (and possibly stored). To this end, there exist some
possible approaches. First, as a signature verification approach,
the exploitation of multi-signature capability could be applied.
This allows not only the original content producer but also some
forwarders responsible for in-network re-coding to have their own
unique signing key. Each forwarder of the group signs newly
generated NC packet in order for other nodes to be able to validate
the data with the signature. The CS may verify the signature within
the NC packet before storing it to avoid invalid data caching.
Matsuzono, et al. Expires May 19, 2022 [Page 17]
Internet-Draft NC for CCNx/NDN November 2021
Second, as a consumer-dependent approach, the consumer puts a
restriction on the matching rule using only the name of the requested
data. The interest ambiguity can be clarified by specifying both the
name and the key identifier (the producer's public key digest) used
for matching to the requested data. This KeyId restriction is built
in the CCNx design [1]. Only the requested data packet satisfying
the interest with the KeyId restriction would be forwarded and stored
in the CS, thus resulting in a reduction in the chances of cache
poisoning. Moreover, in the CCNx design, there exists the rule that
the CS obeys in order to avoid amplifying invalid data; if an
interest has a KeyID restriction, the CS must not reply unless it
knows that the signature on the matching content object is correct.
If the CS cannot verify the signature, the interest may be treated as
a cache miss and forwarded to the upstream forwarder(s). Third, as a
certificate chain management approach (possibly without certificate
authority), some mechanism such as [31] could be used to establish a
trustworthy data delivery path. This approach adopts the hop-by-hop
authentication mechanism, wherein forwarding-integrated hop-by-hop
certificate collection is performed to provide suspension certificate
chains such that the data retrieval is trustworthy.
Depending on the adopted caching strategy such as cache replacement
policies, forwarders should also take caution when storing and
retaining the NC packets in the CS as they could be targeted by cache
pollution attacks. In order to mitigate the cache pollution attacks'
impact, forwarders should check the content request frequencies to
detect the attack and may limit requests by ignoring some of the
consecutive requests. The forwarders can then decide to apply or
change to the other cache replacement mechanism.
The forwarders or producers require careful attention to the DoS
attacks aiming at provoking the high load of NC operations by using
the interests for NC packets. In order to mitigate such attacks, the
forwarders could adopt a rate-limiting approach. For instance, they
could monitor the PIT size growth for NC packets per content to
detect the attacks, and limit the interest arrival rate when
necessary. If the NC application wishes to secure an interest
(considered as the NC actuator) in order to prevent such attacks, the
application should consider using an encrypted wrapper and an
explicit protocol.
9. Acknowledgements
The authors would like to thank ICNRG and NWCRG members, especially
Marie-Jose Montpetit, David Oran, Vincent Roca, and Thierry Turletti,
for their valuable comments and suggestions on this document.
Matsuzono, et al. Expires May 19, 2022 [Page 18]
Internet-Draft NC for CCNx/NDN November 2021
10. Informative References
[1] Mosko, M. and et al., "Content-Centric Networking (CCNx)
Semantics", RFC 8569, July 2019,
<https://tools.ietf.org/html/rfc8569>.
[2] Gkantsidis, C. and P. Rodriguez, "Cooperative Security for
Network Coding File Distribution", Proc. Infocom, IEEE,
April 2006.
[3] Cai, N. and R. Yeung, "Secure network coding", Proc.
International Symposium on Information Theory
(ISIT), IEEE, June 2002.
[4] Lima, L., Gheorghiu, S., Barros, J., Medard, M., and A.
Toledo, "Secure Network Coding for Multi-Resolution
Wireless Video Streaming", IEEE Journal of Selected Area
(JSAC), vol. 28, no. 3, April 2010.
[5] Vilea, J., Lima, L., and J. Barros, "Lightweight security
for network coding", Proc. ICC, IEEE, May 2008.
[6] Dimarkis, A., Godfrey, P., Wu, Y., Wainwright, M., and K.
Ramchandran, "Network Coding for Distributed Storage
Systems", IEEE Trans. Information Theory, vol. 56, no.9,
September 2010.
[7] Gkantsidis, C. and P. Rodriguez, "Network coding for large
scale content distribution", Proc. Infocom, IEEE, March
2005.
[8] Seferoglu, H. and A. Markopoulou, "Opportunistic Network
Coding for Video Streaming over Wireless", Proc. Packet
Video Workshop (PV), IEEE, November 2007.
[9] Montpetit, M., Westphal, C., and D. Trossen, "Network
Coding Meets Information-Centric Networking: An
Architectural Case for Information Dispersion Through
Native Network Coding", Proc. Workshop on Emerging Name-
Oriented Mobile Networking Design (NoM), ACM, June 2012.
[10] Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun,
"NetCodCCN: a network coding approach for content-centric
networks", Proc. Infocom, IEEE, April 2016.
Matsuzono, et al. Expires May 19, 2022 [Page 19]
Internet-Draft NC for CCNx/NDN November 2021
[11] Ramakrishnan, A., Westphal, C., and J. Saltarin, "Adaptive
Video Streaming over CCN with Network Coding for Seamless
Mobility", Proc. International Symposium on Multimedia
(ISM), IEEE, December 2016.
[12] Mahdian, M., Arianfar, S., Gibson, J., and D. Oran,
"MIRCC: Multipath-aware ICN Rate-based Congestion
Control", Proc. Conference on Information-Centric
Networking (ICN), ACM, September 2016.
[13] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C.
Westphal, "An Optimal Cache Management Framework for
Information-Centric Networks with Network Coding", Proc.
Networking Conference, IFIP/IEEE, June 2014.
[14] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C.
Westphal, "A Minimum Cost Cache Management Framework for
Information-Centric Networks with Network Coding",
Computer Networks, Elsevier, August 2016.
[15] Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency
Low Loss Streaming using In-Network Coding and Caching",
Proc. Infocom, IEEE, May 2017.
[16] Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
Briggs, N., and R. Braynard, "Networking Named Content",
Proc. CoNEXT, ACM, December 2009.
[17] Wissingh, B. and et al., "Information-Centric Networking
(ICN): Content-Centric Networking (CCNx) and Named Data
Networking (NDN) Terminology", RFC 8793, June 2020,
<https://tools.ietf.org/html/rfc8793>.
[18] Mosko, M. and et al., "Content-Centric Networking (CCNx)
Messages in TLV Format", RFC 8609, July 2019,
<https://tools.ietf.org/html/rfc8609>.
[19] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy,
K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang,
"Named data networking", ACM Comput. Commun. Rev., vol.
44, no. 3, July 2014.
[20] Koetter, R. and M. Medard, "An Algebraic Approach to
Network Coding", IEEE/ACM Trans. on Networking, vol. 11,
no 5, Oct. 2003.
Matsuzono, et al. Expires May 19, 2022 [Page 20]
Internet-Draft NC for CCNx/NDN November 2021
[21] Adamson, B. and et al., "Taxonomy of Coding Techniques for
Efficient Network Communications", RFC 8406, June 2018,
<https://tools.ietf.org/html/rfc8406>.
[22] Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Coding
and Congestion Control in Transport", Work in Progress,
draft-irtf-nwcrg-coding-and-congestion-09, June 2021.
[23] Tschudin, C., Wood, C., Mosko, M., and D. Oran, "File-Like
ICN Collections (FLIC)", Work in Progress, draft-irtf-
icnrg-flic-03, Nov. 2021.
[24] Kutscher, D. and et al., "Information-Centric Networking
(ICN) Research Challenges", RFC 7927, July 2016.
[25] Pentikousis, K. and et al., "Information-Centric
Networking: Evaluation and Security Considerations",
RFC 7945, July 2019.
[26] Watson, M. and et al., "Forward Error Correction (FEC)
Framework", RFC 6363, Oct. 2011.
[27] Thomos, N. and P. Frossard, "Toward one Symbol Network
Coding Vectors", IEEE Communications letters, vol. 16, no.
11, November 2012.
[28] Lucani, D., Pedersen, M., Heide, J., and F. Fitzek,
"Fulcrum Network Codes: A Code for Fluid Allocation of
Complexity", available at http://arxiv.org/abs/1404.6620,
April 2014.
[29] Perino, D. and M. Varvello, "A reality check for content
centric networking", Proc. SIGCOMM Workshop on
Information-centric networking (ICN'11), ACM, August 2011.
[30] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G.
Xie, "Privacy-Aware Multipath Video Caching for Content-
Centric Networks", IEEE Journal of Selected Area
(JSAC) vol. 38, no. 8, June 2016.
[31] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric
Authentication for Secure In-Network Big-Data Retrieval",
IEEE Trans. on Network Science and Engineering vol. 7, no.
1, September 2018.
[32] Wu, Y., Chou, P., and K. Jain, "A comparison of network
coding and tree packing", Proc. ISIT, IEEE, June 2004.
Matsuzono, et al. Expires May 19, 2022 [Page 21]
Internet-Draft NC for CCNx/NDN November 2021
[33] Ho, T., Medard, M., Koetter, R., Karger, R., Effros, D.,
Shi, M., and B. Leong, "A Random Linear Network Coding
Approach to Multicast", IEEE Trans. Information
Theory, vol. 52, no.10, October 2006.
[34] Podlipnig, S. and L. Osz, "A Survey of Web Cache
Replacement Strategies", Proc. ACM Computing Surveys vol.
35, no. 4, December 2003.
[35] Rossini, G. and D. Rossi, "Evaluating CCN multi-path
interest forwarding strategies", Elsevier Computer
Communication, vol.36, no. 7, April 2013.
[36] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova,
N., and X. Zeng, "Leveraging ICN In-network Control for
Loss Detection and Recovery in Wireless Mobile networks",
Proc. ICN ACM, September 2016.
[37] Ali, M. and U. Niesen, "Coding for Caching: Fundamental
Limits and Practical Challenges", IEEE Communications
Magazine vol. 54, no. 8, August 2016.
[38] Koetter, R. and F. Kschischang, "An algebraic approach to
network coding", IEEE Trans. Netw. vol.11, no.5, October
2003.
[39] Vyetrenko, S., Ho, T., Effros, M., Kliewer, J., and E.
Erez, "Rate regions for coherent and noncoherent
multisource network error correction", Proc. International
Symposium on Information Theory (ISIT), IEEE, July 2009.
[40] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and
V. Roca, "On-the-Fly Erasure Coding for Real-Time Video
Applications", IEEE Trans. Multimeda vol.13, no.4, August
2011.
Authors' Addresses
Kazuhisa Matsuzono
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795
Japan
Email: matsuzono@nict.go.jp
Matsuzono, et al. Expires May 19, 2022 [Page 22]
Internet-Draft NC for CCNx/NDN November 2021
Hitoshi Asaeda
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795
Japan
Email: asaeda@nict.go.jp
Cedric Westphal
Huawei
2330 Central Expressway
Santa Clara, California 95050
USA
Email: cedric.westphal@futurewei.com,
Matsuzono, et al. Expires May 19, 2022 [Page 23]