path: root/doc/rfc/rfc9273.txt

Internet Research Task Force (IRTF)                         K. Matsuzono
Request for Comments: 9273                                     H. Asaeda
Category: Informational                                             NICT
ISSN: 2070-1721                                              C. Westphal
                                                                  Huawei
                                                             August 2022


 Network Coding for Content-Centric Networking / Named Data Networking:
                     Considerations and Challenges

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 document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Research Task Force
   (IRTF).  The IRTF publishes the results of Internet-related research
   and development activities.  These results might not be suitable for
   deployment.  This RFC represents the consensus of the Coding for
   Efficient Network Communications Research Group of the Internet
   Research Task Force (IRTF).  Documents approved for publication by
   the IRSG are not candidates for any level of Internet Standard; see
   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/rfc9273.

Copyright Notice

   Copyright (c) 2022 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.

Table of Contents

   1.  Introduction
   2.  Terminology
     2.1.  Definitions Related to NC
     2.2.  Definitions Related to CCNx/NDN
   3.  CCNx/NDN Basics
   4.  NC Basics
   5.  Advantages of NC and CCNx/NDN
   6.  Technical Considerations
     6.1.  Content Naming
       6.1.1.  Unique Naming for NC Packets
       6.1.2.  Nonunique Naming for NC Packets
     6.2.  Transport
       6.2.1.  Scope of NC
       6.2.2.  Consumer Operation
       6.2.3.  Forwarder Operation
       6.2.4.  Producer Operation
       6.2.5.  Backward Compatibility
     6.3.  In-Network Caching
     6.4.  Seamless Consumer Mobility
   7.  Challenges
     7.1.  Adoption of Convolutional Coding
     7.2.  Rate and Congestion Control
     7.3.  Security
     7.4.  Routing Scalability
   8.  IANA Considerations
   9.  Security Considerations
   10. Informative References
   Acknowledgments
   Authors' Addresses

1.  Introduction

   Information-Centric Networking (ICN), in general, and Content-Centric
   Networking (CCNx) [1] or Named Data Networking (NDN) [2], in
   particular, have emerged as a novel communication paradigm that
   advocates for 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 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 [3] and can be
   utilized for preventing eavesdroppers from obtaining meaningful
   information [4] or protecting a wireless video stream while retaining
   the NC benefits [5] [6].

   From the perspective of the NC transport mechanism, NC can be divided
   into two major categories: coherent NC and noncoherent NC [7] [8].
   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 [9].  However, it requires a fully adjustable
   and specific routing mechanism and a large computational capacity for
   central coordination.  In the case of noncoherent NC, which often
   uses Random Linear Coding (RLC), it is not necessary to know the
   network topology nor the intermediate coding operations [10].  As
   noncoherent 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 and/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 allows for
   recovery of missing packets by encoding the information across
   several packets.  ICN is synergistic with NC, as it allows for
   caching of data packets throughout the network.  In a typical network
   that uses NC, the sender must transmit enough packets to retrieve the
   original data.  ICN offers an opportunity to retrieve network-coded
   packets directly from caches in the network, making the combination
   of ICN and NC particularly effective.  In fact, NC has already been
   implemented for information/content dissemination [11] [12] [13].
   Montpetit et al. first suggested that NC techniques be exploited to
   enhance key aspects of system performance in ICN [14].  Although
   CCNx/NDN excels to exploit the benefits of NC (as described in
   Section 5), some technical considerations are needed to combine NC
   and CCNx/NDN owing to the unique features of CCNx/NDN (as described
   in Section 6).

   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).  This
   document was read and reviewed by all the active research group
   members.  It is not an IETF product and is not a standard.

2.  Terminology

2.1.  Definitions Related to NC

   This section provides the terms related to NC used in this document,
   which are defined in RFC 8406 [15] and produced by the NWCRG.

   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.

   Repair Packet:
      A packet containing one or more coded symbols (also called repair
      symbol).  The coded symbol or repair symbol is a unit of data that
      is the result of a coding operation, applied either to source
      symbols or (in case of recoding) source and/or coded symbols.
      When there is a single repair symbol per repair packet, a repair
      symbol corresponds to a repair packet.

   Encoding versus Recoding versus Decoding:
      Encoding is an operation that takes source symbols as input and
      produces encoding symbols (source or coded symbols) as output.
      Recoding is an operation that takes encoding symbols as input and
      produces encoding symbols as output.  Decoding is an operation
      that takes encoding symbols as input and produces source symbols
      as output.

   The terms regarding coding types are defined as follows:

   Random Linear Coding (RLC):
      A particular form of linear coding using a set of random coding
      coefficients.  Linear coding performs a linear combination of a
      set of input symbols (i.e., source and/or coded symbols) using a
      given set of coefficients and results in a repair symbol.

   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.

   Sliding Window Coding or Convolutional Coding:
      A general class of coding techniques that rely on a sliding
      encoding window.  An encoding window is a set of source (and coded
      in the case of recoding) 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.

   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 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:

   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.

   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.

   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.

   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.

   Coding Vector:
      A set of coding coefficients used to generate a certain coded
      symbol through linear coding.

   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.

2.2.  Definitions Related to CCNx/NDN

   The terminology regarding CCNx/NDN used in this document is defined
   in RFC 8793 [16], which was produced by the ICNRG.  They are
   consistent with the relevant documents ([17] [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 [16]).  The term
   "content object", which means a unit of content data, is an alias to
   data packet [16].  The ICN consumer (defined in Section 3.2 of [16])
   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 [16]) 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 cache
   storage, called Content Store (CS) (defined in Section 3.3 of [16]).
   If it does, it returns the 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 [16]) 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 [16]) lookup for selecting an
   outgoing interface.  The FIB lists name prefixes and their
   corresponding forwarding interfaces in order to send the interest
   toward 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 [19].  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 [16]) 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
   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
   (hereinafter referred to as generation ID) of the received repair
   packets, they may perform an encoding operation (called recoding),
   which is the most distinctive 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, recoding should
   generate and provide innovative packets.  One of the 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 [9].

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 [7], while the latter focuses on the content/information
   itself at the networking layer.  Because these approaches are
   complementary and 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
   [1].  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 [14].
   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) [20].  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 [21]
   [22] [23], seamless consumer mobility [24] [25], and low-latency low-
   loss video streaming [26].  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 [19].  In this section, two possible
   naming schemes are presented.

6.1.1.  Unique Naming for NC Packets

   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 and as PIT and CS 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 generation ID can be used as a part of the content object name.
   As in [21], when the generation ID is "g-id", generation size is 4,
   and coding vector is (1,0,0,0), the name could 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) [27].  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 recoding
   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 [14].  This extension may incur
   an interest packet of significantly increased size, and it may thus
   be useful to use compression techniques for coding vectors [28] [29].
   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).

6.1.2.  Nonunique Naming for NC Packets

   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
   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 a forwarder or producer cannot
   inject unrequested data packets on its own initiative.  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 a data forwarder can perform in-network
   recoding 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 recoding 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 multiple NC
   packets have the same name, the former case may occur; recoding
   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
   recoding 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 9).

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.

   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 [17] 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 recoding.  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 [21].  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 [25][26] at a
   forwarder, as well as a consumer-driven mechanism, could be
   indispensable for enabling fast loss recovery and realizing 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
   an 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
   source packets and store them (if the full cache capacity are
   available), thus enabling a faster response to subsequent interests.
   As recoding 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 a 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 [30]) 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
   include in the manifest and produce multiple manifests either in
   advance or on demand with different coding tradeoffs, if so desired.

   A common benefit of 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 the 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 and should function alongside regular ICN operations.
   Hence, nodes that do not support NC should still be able to properly
   handle packets, not only in being able to forward the NC packets but
   also to cache these packets.  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 the network level and is highly
   beneficial, owing to the involved exploitation of NC for enabling
   effective multicast transmission [31], multipath data retrieval [21]
   [24], and fast loss recovery [26].  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 [32] [33] [34].  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
   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 9).  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 [24] or congestion control
   for content acquisition [35].

   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 [24], 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 real-time constraints.  As in [36], 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
   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 utilizes the 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 recoding 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 [37].  From this perspective, an
   effective deployment approach (e.g., a forwarder-supported approach
   that can provide 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, and avoiding duplicated
   packets has congestion control benefits as well.  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,
   pollution attacks, and a DoS attack using interest packets, some
   security approaches are already provided [19] [38].  The application
   of NC in CCNx/NDN brings two potential security aspects that need to
   be dealt with.

   The first is in-network recoding at forwarders.  Some mechanism for
   ensuring the integrity of the NC packets newly produced by in-network
   recoding 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 9, but there may be a 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
   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.  IANA Considerations

   This document has no IANA actions.

9.  Security Considerations

   In-network recoding is a distinguishing feature of NC.  Only valid NC
   packets produced by in-network recoding 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 recoding to have their own
   unique signing key.  Each forwarder of the group signs a 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.
   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 [17].  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 [39], could be used to establish
   a trustworthy data delivery path.  This approach adopts the hop-by-
   hop authentication mechanism, wherein the 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 aimed 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.

10.  Informative References

   [1]        Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
              Briggs, N., and R. Braynard, "Networking Named Content",
              Proc. CoNEXT, ACM, DOI 10.1145/1658939.1658941, December
              2009, <https://doi.org/10.1145/1658939.1658941>.

   [2]        Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy,
              K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang,
              "Named data networking", ACM SIGCOMM Computer
              Communication Review, vol. 44, no. 3,
              DOI 10.1145/2656877.2656887, July 2014,
              <https://doi.org/10.1145/2656877.2656887>.

   [3]        Gkantsidis, C. and P. Rodriguez, "Cooperative Security for
              Network Coding File Distribution", Proc. Infocom, IEEE,
              DOI 10.1109/INFOCOM.2006.233, April 2006,
              <https://doi.org/10.1109/INFOCOM.2006.233>.

   [4]        Cai, N. and R. Yeung, "Secure network coding", Proc.
              International Symposium on Information Theory (ISIT),
              IEEE, DOI 10.1109/ISIT.2002.1023595, June 2002,
              <https://doi.org/10.1109/ISIT.2002.1023595>.

   [5]        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, DOI 10.1109/JSAC.2010.100409,
              April 2010, <https://doi.org/10.1109/JSAC.2010.100409>.

   [6]        Vilea, J., Lima, L., and J. Barros, "Lightweight security
              for network coding", Proc. ICC, IEEE,
              DOI 10.48550/arXiv.0807.0610, May 2008,
              <https://doi.org/10.48550/arXiv.0807.0610>.

   [7]        Koetter, R. and M. Medard, "An Algebraic Approach to
              Network Coding", IEEE/ACM Transactions on Networking, vol.
              11, no. 5, DOI 10.1109/TNET.2003.818197, October 2003,
              <https://doi.org/10.1109/TNET.2003.818197>.

   [8]        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,
              DOI 10.1109/ISIT.2009.5206077, June 2009,
              <https://doi.org/10.1109/ISIT.2009.5206077>.

   [9]        Wu, Y., Chou, P., and K. Jain, "A comparison of network
              coding and tree packing", Proc. International Symposium on
              Information Theory (ISIT), IEEE,
              DOI 10.1109/ISIT.2004.1365182, June 2004,
              <https://doi.org/10.1109/ISIT.2004.1365182>.

   [10]       Ho, T., Medard, M., Koetter, R., Karger, D., Effros, M.,
              Shi, J., and B. Leong, "A Random Linear Network Coding
              Approach to Multicast", IEEE Trans. on Information Theory,
              vol. 52, no. 10, DOI 10.1109/TIT.2006.881746, October
              2006, <https://doi.org/10.1109/TIT.2006.881746>.

   [11]       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,
              DOI 10.1109/TIT.2010.2054295, September 2010,
              <https://doi.org/10.1109/TIT.2010.2054295>.

   [12]       Gkantsidis, C. and P. Rodriguez, "Network coding for large
              scale content distribution", Proc. Infocom, IEEE,
              DOI 10.1109/INFCOM.2005.1498511, March 2005,
              <https://doi.org/10.1109/INFCOM.2005.1498511>.

   [13]       Seferoglu, H. and A. Markopoulou, "Opportunistic Network
              Coding for Video Streaming over Wireless", Proc. Packet
              Video Workshop (PV), IEEE,
              DOI 10.1109/PACKET.2007.4397041, November 2007,
              <https://doi.org/10.1109/PACKET.2007.4397041>.

   [14]       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,
              DOI 10.1145/2248361.2248370, June 2012,
              <https://doi.org/10.1145/2248361.2248370>.

   [15]       Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek,
              F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J.,
              Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and
              S. Sivakumar, "Taxonomy of Coding Techniques for Efficient
              Network Communications", RFC 8406, DOI 10.17487/RFC8406,
              June 2018, <https://www.rfc-editor.org/info/rfc8406>.

   [16]       Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
              D., and C. Tschudin, "Information-Centric Networking
              (ICN): Content-Centric Networking (CCNx) and Named Data
              Networking (NDN) Terminology", RFC 8793,
              DOI 10.17487/RFC8793, June 2020,
              <https://www.rfc-editor.org/info/rfc8793>.

   [17]       Mosko, M., Solis, I., and C. Wood, "Content-Centric
              Networking (CCNx) Semantics", RFC 8569,
              DOI 10.17487/RFC8569, July 2019,
              <https://www.rfc-editor.org/info/rfc8569>.

   [18]       Mosko, M., Solis, I., and C. Wood, "Content-Centric
              Networking (CCNx) Messages in TLV Format", RFC 8609,
              DOI 10.17487/RFC8609, July 2019,
              <https://www.rfc-editor.org/info/rfc8609>.

   [19]       Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
              Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
              "Information-Centric Networking (ICN) Research
              Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
              <https://www.rfc-editor.org/info/rfc7927>.

   [20]       Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G.
              Xie, "Privacy-Aware Multipath Video Caching for Content-
              Centric Networks", IEEE Journal on Selected Areas in
              Communications (JSAC), vol. 38, no. 8,
              DOI 10.1109/JSAC.2016.2577321, June 2016,
              <https://doi.org/10.1109/JSAC.2016.2577321>.

   [21]       Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun,
              "NetCodCCN: a network coding approach for content-centric
              networks", Proc. Infocom, IEEE,
              DOI 10.1109/INFOCOM.2016.7524382, April 2016,
              <https://doi.org/10.1109/INFOCOM.2016.7524382>.

   [22]       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,
              DOI 10.1109/IFIPNetworking.2014.6857127, June 2014,
              <https://doi.org/10.1109/IFIPNetworking.2014.6857127>.

   [23]       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,
              DOI 10.1016/j.comnet.2016.08.004, August 2016,
              <https://doi.org/10.1016/j.comnet.2016.08.004>.

   [24]       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, DOI 10.1109/ISM.2016.0054, December 2016,
              <https://doi.org/10.1109/ISM.2016.0054>.

   [25]       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. of the 3rd ACM Conference on Information-Centric
              Networking, DOI 10.1145/2984356.2984361, September 2016,
              <https://doi.org/10.1145/2984356.2984361>.

   [26]       Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency
              Low Loss Streaming using In-Network Coding and Caching",
              Proc. Infocom, IEEE, DOI 10.1109/INFOCOM.2017.8057026, May
              2017, <https://doi.org/10.1109/INFOCOM.2017.8057026>.

   [27]       Watson, M., Begen, A., and V. Roca, "Forward Error
              Correction (FEC) Framework", RFC 6363,
              DOI 10.17487/RFC6363, October 2011,
              <https://www.rfc-editor.org/info/rfc6363>.

   [28]       Thomos, N. and P. Frossard, "Toward One Symbol Network
              Coding Vectors", IEEE Communications Letters, vol. 16, no.
              11, DOI 10.1109/LCOMM.2012.092812.121661, November 2012,
              <https://doi.org/10.1109/LCOMM.2012.092812.121661>.

   [29]       Lucani, D., Pedersen, M., Ruano, D., Sørensen, C., Heide,
              J., Fitzek, F., and O. Geil, "Fulcrum Network Codes: A
              Code for Fluid Allocation of Complexity",
              DOI 10.48550/arXiv.1404.6620, April 2014,
              <https://doi.org/10.48550/arXiv.1404.6620>.

   [30]       Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, "File-
              Like ICN Collections (FLIC)", Work in Progress, Internet-
              Draft, draft-irtf-icnrg-flic-03, 7 November 2021,
              <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
              flic-03>.

   [31]       Maddah-Ali, M. and U. Niesen, "Coding for Caching:
              Fundamental Limits and Practical Challenges", IEEE
              Communications Magazine, vol. 54, no. 8,
              DOI 10.1109/MCOM.2016.7537173, August 2016,
              <https://doi.org/10.1109/MCOM.2016.7537173>.

   [32]       Perino, D. and M. Varvello, "A reality check for content
              centric networking", Proc. SIGCOMM Workshop on
              Information-centric networking (ICN '11), ACM,
              DOI 10.1145/2018584.2018596, August 2011,
              <https://doi.org/10.1145/2018584.2018596>.

   [33]       Podlipnig, S. and L. Böszörmenyi, "A Survey of Web Cache
              Replacement Strategies", Proc. ACM Computing Surveys, vol.
              35, no. 4, DOI 10.1145/954339.954341, December 2003,
              <https://doi.org/10.1145/954339.954341>.

   [34]       Rossini, G. and D. Rossi, "Evaluating CCN multi-path
              interest forwarding strategies", Elsevier Computer
              Communications, vol. 36, no. 7,
              DOI 10.1016/j.comcom.2013.01.008, April 2013,
              <https://doi.org/10.1016/j.comcom.2013.01.008>.

   [35]       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, DOI 10.1145/2984356.2984365,
              September 2016, <https://doi.org/10.1145/2984356.2984365>.

   [36]       Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and
              V. Roca, "On-the-Fly Erasure Coding for Real-Time Video
              Applications", IEEE Transactions on Multimedia, vol. 13,
              no. 4, DOI 10.1109/TMM.2011.2126564, August 2011,
              <https://doi.org/10.1109/TMM.2011.2126564>.

   [37]       Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Forward
              Erasure Correction (FEC) Coding and Congestion Control in
              Transport", RFC 9265, DOI 10.17487/RFC9265, July 2022,
              <https://www.rfc-editor.org/info/rfc9265>.

   [38]       Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S.,
              and G. Boggia, "Information-Centric Networking: Evaluation
              and Security Considerations", RFC 7945,
              DOI 10.17487/RFC7945, September 2016,
              <https://www.rfc-editor.org/info/rfc7945>.

   [39]       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, DOI 10.1109/TNSE.2018.2872049, September 2018,
              <https://doi.org/10.1109/TNSE.2018.2872049>.

Acknowledgments

   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.

Authors' Addresses

   Kazuhisa Matsuzono
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi, Tokyo
   184-8795
   Japan
   Email: matsuzono@nict.go.jp


   Hitoshi Asaeda
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi, Tokyo
   184-8795
   Japan
   Email: asaeda@nict.go.jp


   Cedric Westphal
   Huawei
   2330 Central Expressway
   Santa Clara, California 95050
   United States of America
   Email: cedric.westphal@futurewei.com,