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: [email protected]


  Hitoshi Asaeda
  National Institute of Information and Communications Technology
  4-2-1 Nukui-Kitamachi, Tokyo
  184-8795
  Japan
  Email: [email protected]


  Cedric Westphal
  Huawei
  2330 Central Expressway
  Santa Clara, California 95050
  United States of America
  Email: [email protected],

You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.