idnits 2.17.1 draft-irtf-nwcrg-nwc-ccn-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1872 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0' is mentioned on line 341, but not defined == Unused Reference: '28' is defined on line 841, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-irtf-nwcrg-network-coding-taxonomy-05 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Coding Research Group K. Matsuzono 3 Internet-Draft H. Asaeda 4 Intended status: Informational NICT 5 Expires: September 12, 2019 C. Westphal 6 Huawei 7 March 11, 2019 9 Network Coding for Content-Centric Networking / Named Data Networking: 10 Requirements and Challenges 11 draft-irtf-nwcrg-nwc-ccn-reqs-01 13 Abstract 15 This document describes the current research outcomes regarding 16 Network Coding (NC) for Content-Centric Networking (CCN) / Named Data 17 Networking (NDN), and clarifies the requirements and challenges for 18 applying NC into CCN/NDN. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 12, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. NDN/CCN Background . . . . . . . . . . . . . . . . . . . 5 58 3. Advantage given by NC and CCN/NDN . . . . . . . . . . . . . . 6 59 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Content Naming . . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.2.1. Scope of Network Coding . . . . . . . . . . . . . . . 9 63 4.2.2. Consumer Operation . . . . . . . . . . . . . . . . . 9 64 4.2.3. Router Operation . . . . . . . . . . . . . . . . . . 10 65 4.2.4. Publisher Operation . . . . . . . . . . . . . . . . . 11 66 4.2.5. Backward Compatibility . . . . . . . . . . . . . . . 11 67 4.3. In-network Caching . . . . . . . . . . . . . . . . . . . 11 68 4.4. Seamless Mobility . . . . . . . . . . . . . . . . . . . . 12 69 4.5. Security and Privacy . . . . . . . . . . . . . . . . . . 13 70 5. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 5.1. Adopting Convolutional Coding . . . . . . . . . . . . . . 13 72 5.2. Rate and Congestion Control . . . . . . . . . . . . . . . 14 73 5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 14 74 5.4. Routing Scalability . . . . . . . . . . . . . . . . . . . 15 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 78 7.2. Informative References . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 81 1. Introduction 83 Information-Centric Networks in general, and Content-Centric 84 Networking (CCN) [15] or Named Data Networking (NDN) [16] in 85 particular, have emerged as a novel communication paradigm advocating 86 to retrieve data through their names. This paradigm pushes content 87 awareness into the network layer. It is expected to enable consumers 88 to obtain the content they desire in a straightforward and efficient 89 manner from the heterogenous networks they may be connected to. The 90 CCN/NDN architecture has introduced innovative ideas and has 91 stimulated research in a variety of areas, such as in-network 92 caching, name-based routing, multi-path transport, content security, 93 and so on. One key benefit of requesting content by name is that it 94 removes the need to establish a session between the client and a 95 specific server, and that content can thereby be retrieved from 96 multiple sources. 98 In parallel, there has been a growing interest from both academia and 99 industry to better understand fundamental aspects of Network Coding 100 (NC) toward enhancing key system performance metrics such as data 101 throughput, robustness and reduction in the required number of 102 transmissions through connected networks, point-to-multipoint 103 connections, etc. Typically, NC is a technique mainly used to encode 104 packets to recover lost source packets at the receiver, and to 105 effectively get the desired information in a fully distributed 106 manner. In addition, NC can be used for security enhancements [2] 107 [3] [4] [5]. 109 NC aggregates multiple packets with parts of the same content 110 together, and may do this at the source or at other nodes in the 111 network. As such, network coded packets are not connected to a 112 specific server, as they may have evolved within the network. Since 113 NC focuses on what information should be encoded in a network packet, 114 rather than the specific host where it has been generated, it is in 115 line with the CCN/NDN core networking layer (described in more detail 116 later on). NC has already been implemented for information/content 117 dissemination (e.g. [6] [7] [8]). NC provides CCN/NDN with the 118 highly beneficial potential to effectively disseminate information in 119 a completely independent and decentralized manner. [9] first 120 suggested to exploit NC techniques to enhance key system performances 121 in ICN, and others have considered NC in ICN use cases such as 122 content dissemination [10], seamless mobility [11], joint caching and 123 network coding [12] [13], low-latency video streaming [14], etc. 125 In this document, we consider how NC can be applied to the CCN/NDN 126 architecture and describe the requirements and potential challenges 127 for making CCN/NDN-based communications better using the NC 128 technology. Please note that providing specific solutions (e.g., NC 129 optimization methods) to enhance CCN/NDN performance metrics by 130 exploiting NC is out of scope of this document. 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [1]. 138 2.1. Definitions 140 The terminology regarding NC used in this document is described 141 below. It is aligned with RFCs produced by the FEC Framework 142 (FECFRAME) IETF Working Groups as well as recent activities in the 143 Network Coding Research Group [18]. 145 o Random Linear Coding (RLC): Particular case of Linear Coding using 146 a set of random coding coefficients. 148 o Generation, or (IETF) Block: With Block Codes, the set of content 149 data that are logically grouped into a Block, before doing 150 encoding. 152 o Generation Size: With Block Codes, the number k of content data 153 belonging to a Block. 155 o Encoding Vector: A set of coding coefficients used to generate a 156 certain coded packet through linear coding. The number of nonzero 157 coefficients in the Coding Vector defines its density 159 o Finite Field: Finite fields, used in Linear Codes, have the 160 desired property of having all elements (except zero) invertible 161 for + and * and all operations over any elements do not result in 162 an overflow or underflow. Examples of Finite Fields are prime 163 fields {0..p^m-1}, where p is prime. Most used fields use p=2 and 164 are called binary extension fields {0..2^m-1}, where m often 165 equals 1, 4 or 8 for practical reasons. 167 o Finite Field size: The number of elements in a finite field. For 168 example the binary extension field {0..2^m-1} has size q=2^m. 170 o Block Coding: Coding technique where the input Flow(s) must be 171 first segmented into a sequence of blocks, FEC encoding and 172 decoding being performed independently on a per-block basis. 174 o Sliding Window Coding or Convolutional Coding: General class of 175 coding techniques that rely on a sliding encoding window. This is 176 an alternative solution to Block Coding. 178 o Fixed or Elastic Sliding Window Coding: Coding technique that 179 generates repair data on-the-fly, from the set of source data 180 present in the sliding encoding window at that time, usually by 181 using Linear Coding. The sliding window may be either of fixed 182 size or of variable size over the time (also known as "elastic 183 sliding window"). 185 o Feedback: Feedback information sent by a decoding node to a node 186 (or from a consumer to a publisher in case of End-to-End Coding). 187 The nature of information contained in a feedback packet varies, 188 depending on the use-case. It can provide reception and/or 189 decoding statistics, or the list of available source packets 190 received or decoded, or the list of lost source packets that 191 should be retransmitted, or a number of additional repair packet 192 needed to have a full rank linear system. 194 Concerning CCN/NDN, the following terminology and definitions are 195 used. 197 o Consumer: A node requesting content. It initiates communication 198 by sending an interest packets. 200 o Publisher: A node providing content. It originally creates or 201 owns the content. 203 o Forwarding Information Base (FIB): A lookup table in a content 204 router containing the name prefix and corresponding destination 205 interface to forward the interest packets. 207 o Pending Interest Table (PIT): A lookup table populated by the 208 interest packets containing the name prefix of the requested data, 209 and the outgoing interface used to forward the received data 210 packets. 212 o Content Store (CS): A storage space for a router to cache content 213 objects. It is also known as in-network cache. 215 o Content Object: A unit of content data delivered through the CCN/ 216 NDN network. 218 o Content Flow: A sequence of content objects associated with the 219 unique content name prefix. 221 2.2. NDN/CCN Background 223 Armed with the terminology above, we briefly explain the key concepts 224 of CCN/NDN. Both protocols are similar in principle, and different 225 on some implementation choices. 227 In a CCN network, there are two types of packets at the network 228 level: interest and data. The consumer request a content by sending 229 an "interest" message, that carries the name of the data. On 230 difference to note here in CCN and NDN is that in later versions of 231 CCN, the interest must carry a full name, while in NDN it may carry a 232 name prefix (and receive in return any data with a name matching this 233 prefix). 235 Once a router receives an "interest" message, it performs a series of 236 look-up: first it checks in the Content Store if it has a copy of the 237 requested content available. If it does, it returns the data and the 238 transaction has successfully completed. 240 If it does not, it performs a look-up of the PIT to see if there is 241 already an outgoing request for the same data. If there is not, then 242 it creates an entry in the PIT that lists the name included in the 243 interest, and the interfaces from which it received the interest. 244 This is used later to send the data back, since interest packets do 245 not carry a source field that identifies the requester. If there is 246 already a PIT entry for this name, then it is updated with the 247 incoming interface of this new request and the interest is discarded. 249 After the PIT look-up, the interest undergoes a FIB lookup to select 250 an outgoing interface. The FIB lists name prefixes and their 251 corresponding forwarding interfaces, to send the interface towards a 252 router that possesses a copy of the requested data. 254 Once a copy of the data is retrieved, it is send back to the 255 requester(s) using the trail of PIT entries; intermediate node remove 256 the PIT state every time that an interest is satisfied, and may store 257 the data in their content store. 259 Data packets carry some information to validate the data, in 260 particular that the data is indeed the one that corresponds to the 261 name. This is required since authentication of the object is crucial 262 in CCN/NDN. However, this step is optional at intermediate routers, 263 so as to speed up the processing. 265 The key aspect of CCN/NDN is that the consumer of the content does 266 not establish a session with a specific server. Indeed, the node 267 that returns the content is not aware of the network location of the 268 requester and the requester is not aware of the network location of 269 the node that provides the content. This in theory allows the 270 interests to follow different paths within a network, or even to be 271 sent over totally different networks. 273 3. Advantage given by NC and CCN/NDN 275 Both NC for large scale content dissemination [7] and CCN/NDN can 276 contribute to effective content/information delivery while working 277 jointly. They both bring similar benefits such as throughput/ 278 capacity gain and robustness enhancement. The difference between 279 their approaches is that, the former considers content flow as 280 algebraic information to combine [17], while the latter focuses on 281 content/information itself at the networking layer. Because these 282 approaches are complementary, it is natural to combine them. The 283 CCN/NDN core abstraction at networking layer through name makes 284 network stack simple as it enables applications to take maximum 285 advantage of multiple simultaneous connectivities due to its simpler 286 relationship with the layer 2 [15]. 288 CCN/NDN itself, however, cannot provide reliable and robust content 289 dissemination. This requires some specific CCN/NDN transport (i.e., 290 strategy layer) [15]. NC can enable the CCN/NDN transport system to 291 effectively distribute and cache data associated with multi-path data 292 retrieval. Furthermore, NC can contribute to improving both caching 293 performance and cache privacy that CCN/NDN newly poses at the 294 networking layer [23]. In this context, it should be natural that 295 there is much room for considering NC integration into CCN/NDN 296 transport exploiting in-network caching and multi-path transmission 297 [9] and seamless mobility [11] [29]. 299 From the perspective of NC transport mechanism, NC is divided into 300 two major categories: one is coherent NC, and the other is non- 301 coherent NC [31]. In coherent NC, source and destination nodes 302 exactly know network topology and coding operations at intermediate 303 nodes. When multiple consumers are trying to receive the same 304 content such as live video streaming, coherent NC could enable the 305 optimal throughput by making the content flow sent over the 306 constructed optimal multicast trees [24]. 308 However, it requires a fully adjustable and specific name-based 309 routing mechanism for CCN/NDN, and an intense computational task for 310 central coordination. In the case of non-coherent NC that often 311 utilizes RLC, it is not required to know either network topology nor 312 intermediate coding operations [25]. Since non-coherent NC works in 313 a completely independent and decentralized manner, this approach is 314 more feasible especially in the large scale use cases that are 315 intended with CCN/NDN. This document thus focuses on non-coherent NC 316 with RLC. 318 4. Requirements 320 This section presents the NC requirements for ICN/CCN in terms of 321 network architecture and protocol. The current document focuses on 322 NC in a block coding manner. 324 4.1. Content Naming 326 Naming content objects is as important for CCN/NDN as naming hosts is 327 for today's Internet [19]. Before performing network coding for 328 specified content in CCN/NDN, the overall content should be split 329 into small content objects to avoid packet fragmentation that could 330 cause unnecessary packet processing and degrade throughput. The size 331 of content objects should be within the allowable packet size so as 332 to avoid packet fragmentation in CCN/NDN network, and then network 333 coding should be applied into a set of the content objects. 335 Each coded packet MAY have a unique name as the original content 336 object has in CCN/NDN, since PIT/FIB/CS operations need a unique name 337 to identify the coded data. As a way of naming coded packet, the 338 encoding vector and the identifier of generation can be used as a 339 part of the content object name [10]. For instance, when the block 340 size (also called generation size) is k and the encoding vector is 341 [1,0,0,0], the name would be like /CCN.com/video-A/k/1000. This 342 naming scheme is simple and can support the delivery of coded packets 343 with exactly the same operations in the FIB/PIT/CS as for original 344 source packets. However, such a naming way requires the consumer to 345 know the naming structure (through a specific name resolution scheme 346 for instance) in order for nodes to specify the exact name of 347 generated coded data packet to retrieve it. From this point of view, 348 it could shift the generation of the encoding vector from the content 349 producer onto the content requester. 351 If a naming schema such as above is used, it would be valuable to 352 reconsider whether Interests should carry full names (as in CCN) or 353 prefixes (as in NDN) as multiple network coded packets could match a 354 response to a specific prefix for a given generation, such as 355 /CCN.com/video-A/k. In the latter case allowing partial name 356 matching, the content requestor may not be able to obtain degrees of 357 freedom. Thus, extensions in the TLV header of the Interest would be 358 used to specify further network coding information so as to limit 359 coded packets to be received (for instance, by specifying the encoded 360 vectors the content requestor receives (also called decoding matrix) 361 as in [9]). However, it may incur a largely increased size of TLV 362 header. Without such coding information, the forwarding node would 363 need to maintain some records regarding interest packets sent before, 364 in order to provide new degrees of freedom. 366 Coded packet MAY have a name that indicates that it is a coded 367 packet, and move the coding information into a metadata field in the 368 payload (i.e., the name includes only data type, original or coded 369 packet, etc). This however would preclude network coding on packets 370 without prior decoding them (for instance, in the CS of forwarding 371 nodes). It would not be beneficial for applications or services that 372 may not need to understand the packet payload. Due to the 373 possibility that multiple coded packets may have a same name, as 374 described above, some mechanism is needed for the content requestor 375 to obtain innovative coded packets.A mechanism to insert the multiple 376 innovative packets into the CS may be required as well. If the 377 coding information of coded packet are encrypted together with the 378 payload (for instance, at source coding), the content requestor or 379 forwarding nodes would incur extra computational overhead for 380 decryption of the packet to interpret the coding information. 382 4.2. Transport 384 The pull-based request-response feature of CCN/NDN is a fundamental 385 principle of its transport layer; one Interest retrieves at most one 386 Data packet. It is believed that it is important to not violate this 387 rule, as it would open denial of service attacks issues, and thus the 388 following basic operation should be considered to apply NC to CCN/ 389 NDN. In any case, such security considerations must be addressed if 390 this rule were to be violated. 392 4.2.1. Scope of Network Coding 394 It should be discussed whether the network can update data packets 395 that are being received in transit, or if only the data that matches 396 an interest can be subject to network coding operations. In the 397 latter case, the network coding is performed on an end-to-end basis 398 (where one end is the consumer, and the other end is any node that is 399 able to respond to the Interest). In the former case, NC happens 400 anywhere in the network that is able to update the data. As CCN/NDN 401 has mechanisms in place to ensure the integrity of the data during 402 transfer, NC in the network introduce complexities that would require 403 special consideration for the integrity mechanisms to still work. 405 Similarly, caching of network coded packets at intermediate node may 406 be valuable, but may prevent the node caching the coded content to 407 validate the content. 409 4.2.2. Consumer Operation 411 To obtain NC benefits associated with in-network caching, consumers 412 need to issue interests directing the router (or publisher) to 413 forward innovative coded packets if available. The reason why this 414 directive is needed is that delay-sensitive applications such as 415 live-video streaming may want to sequentially get original packets 416 rather than coded packets cached in routers due to real-time 417 constraint. Issuing such an interest is possible by using optional 418 TLV (Type Length Value) header contained in Interest TLV packet 419 format which allows network elements to add or modify information on 420 the fly. Consumer can put an instruction into it, and for instance, 421 if routers detect that it is better for consumer to get coded packets 422 rather than original packets, routers can modify it to do so. After 423 receiving interests having the instruction in optional header, the 424 router with useful coded packets forward them. 426 As another solution, consumer issues Interests specifying unique 427 names for each coded packets. In this case, a unified naming scheme 428 considering both original and coded packets is required. Moreover, 429 in the case of NC end-to-end approach, publishers need to get 430 feedback from the corresponding receivers to adjust some coding 431 parameters. To deal with this, a receiver may have to request a 432 specific interest name to reach the corresponding publisher and put 433 required information into the optional header. 435 4.2.3. Router Operation 437 Routers need to appropriately handle PIT entries to accommodate 438 interests for coded packets as well as original packets. Moreover, 439 in order to decode as necessary, nodes need to know the coding vector 440 used for each coded packet (note: since all the data for a specific 441 content may not come through the same path/network, intermediate 442 nodes may never be able to decode). In a typical case, the coding 443 vector used for each coded packet is attached to the header of coded 444 data. In regard to this point, the generation size (also called 445 block size) for NC should be set to a reasonable value so that the 446 total coded packet size including header needed for expressing the 447 coding vector information and data message fits into the allowable 448 packet size. It may be useful to use compression techniques for 449 coding vectors [20] [21]. 451 Router may try to forward useful independent coded packets toward 452 downstream nodes in order to respond to received interests for coded 453 packets. Routers thus need to determine whether or not they can 454 generate useful coded packets for consumers. Assuming that the size 455 of the Finite Field in use is not relatively small, re-encoding using 456 enough cached packets has a strong probability of making independent 457 coded packets [24]. If router does not have enough cached packets to 458 newly produce independent coded packets, it relays received interests 459 to upstream nodes to receive a new original or independent coded 460 packet and pass it to downstream nodes. In another possible case, 461 when receiving interests for only original packets, routers may try 462 to decode and get all the original packets and store them (if there 463 are fully available cache capacity), enabling faster response to the 464 interests. Since there is a tradeoff between NC encoding/decoding 465 calculation cost and cache capacity, and the usage efficacy of re- 466 encoding or decoding at router, router should need to determine how 467 to response to receiving interests according to the use case (e.g., 468 delay-sensitive or delay-tolerant application) and the router 469 situation such as available cache space and computational capability. 471 Some proposed schemes [10]require that the router maintain a tally of 472 the interests for a specific name and generation, so as to know how 473 many degrees of freedom have been provided already for the NC 474 packets. Scalability and practicality of maintaining such scheme at 475 intermediate routers should considered. 477 To enable fast loss recovery cooperating with in-network caching, a 478 transport mechanism of in-network loss detection and recovery [29] 479 [14] at router as well as consumer-driven mechanism should be 480 considered. 482 4.2.4. Publisher Operation 484 The procedure for splitting an overall content into small content 485 objects is responsible for the original publisher. When applying NC 486 for the content, the publisher performs NC over the content objects, 487 and naming processing for the coded packets. If the producer takes 488 the lead in determining the used encoding vectors and generating the 489 coded packets, there are the two possible end-to-end cases; 1) 490 content requestors obtain the names of coded packets through a 491 certain mechanism, and send the correspond interests toward the 492 publisher to get the coded packets already generated at the 493 publisher, and 2) the publisher determines the encoding vectors after 494 receiving interests specifying them. In the former case, although 495 content requestors cannot flexibly specify an encoding vector for 496 generating the coded packet to retain, but the latency for getting 497 the coded data can be reduced compared to the latter case where 498 additional NC operations need after receiving interests. According 499 to application requirement for latency, such NC operation strategy 500 should be considered. 502 4.2.5. Backward Compatibility 504 Network Coding operations should be applied in addition to the 505 regular network behavior. As such, nodes should be able to not 506 support network coding (either in forwarding the packets, but also in 507 the caching mechanism). Network Coding operations should function 508 alongside regular network operations. A network coding framework 509 should be compatible with a regular framework, so as to allow 510 backward compatibility and smooth migration from one framework to the 511 other. 513 4.3. In-network Caching 515 Caching is an essential technique to improve throughput and latency 516 in various applications. In-network caching CCN/NDN essentially 517 supports at network level is highly beneficial by exploiting NC to 518 enable effective multicast transmission [30], multipath data 519 retrieval [10] [11], fast loss recovery [14], and so on. However, 520 there are several issues to be considered. 522 As a general issue, there are limitations of cache capacity, and 523 caching policy affects on consumer's performances [22] [26] [27]. It 524 is thus highly significant for routers to determine which packets 525 should be cached and discarded. Since delay-sensitive applications 526 often do not require in-network cache for a long period due to their 527 real-time constraints, routers have to know the necessity for caching 528 received packets to save the caching volume. This could be possible 529 by putting a flag into optional header of data packets at publisher 530 side. When receiving data packets with the flag meaning no necessity 531 for cache, routers just have to forward them to downstream nodes. On 532 the other hand, when receiving original packets or coded packets 533 without the flag, router may cache them based on a specified 534 replacement policy. 536 One key aspect of in-network caching is whether or not intermediate 537 nodes can cache NC packets without first decoding them. If in- 538 network caches store coded packets, they need to be able to validate 539 that the packets are not compromised, so as to avoid cache pollution 540 attacks. Without having all the packets in a generation, the cache 541 cannot decode the packets to check if it is authenticated. Caching 542 of coded packets would require some mechanism to validate coded 543 packets. In addition, when coded packets have a same name, it would 544 also require some mechanism to identify them. 546 4.4. Seamless Mobility 548 This subsection presents how NC can achieve seamless mobility [11] 549 [29] and clarify the requirements. A key feature of CCN/NDN is that 550 it is sessionless and that multiple interests can be send to 551 different copies of the content in parallel. CCN/NDN enables a 552 consumer to retrieve the content from multiple sources that are 553 distributed and asynchronous. 555 In this context, network coding provide a mechanism to ensure that 556 the Interests sent to multiple copies of the content retrieve 557 innovative packets, even in the case of packet losses on some of the 558 paths/networks to these copies. NC adds a reliability layer to CCN 559 in a distributed and asynchronous manner. One key benefit is that 560 the link between the consumer and the multiple copies acts as a 561 virtual logical link, upon which rate adaptation mechanism (say, for 562 video streaming) can be performed. 564 This naturally applies to mobility event, where the consumer may 565 connect between multiple access points before a mobility event (make- 566 before-break handoff). In such mobility event, the consumer is 567 connected first to the previous access point, then to both the 568 previous and next access points, then finally only to the next access 569 points. With CCN, the consumer only sends interests on the available 570 interfaces. Requesting network coded packets ensures that during the 571 phase where it is connected to the previous and the next APs at the 572 same time, it does not receive duplicate data, but does not miss on 573 any content either. By combining NC with CCN, the consumer receives 574 additional degrees of freedom with any innovative packet it receives 575 on either interface. From this point of view, an effective interest 576 forwarding strategy with a rate adaptation mechanism should be 577 considered for consumer to achieve seamless mobility while improving 578 overall throughput or latency. 580 4.5. Security and Privacy 582 This subsection describes the requirement for security and privacy 583 provided by NC in CCN/NDN, such as data integrity especially when 584 intermediate nodes perform re-encoding, as in the case of hash 585 restrictions for original data packets, and so on. 587 Network coding impacts the security mechanisms of CCN/NDN. In 588 particular, CCN/NDN is designed to prevent modification of the Data 589 packets. Because Data packets for a specific name can be self- 590 authenticated, they can be validated on the delivery path, and can 591 also be cached at untrusted intermediate nodes. Network coding may 592 bring up issues if intermediate nodes are allowed to modify packets 593 by performing additional network coding operations. Intermediate 594 nodes may also be caching network coded packets without having the 595 ability to perform validation of the content and therefore open 596 themselves to cache pollution attacks. 598 In CCN/NDN, content objects can be encrypted to support access 599 control or privacy. If the coding information of coded packet is 600 included in the encrypted data payload, extra computational overhead 601 occurs. With consideration for low computation overhead, some 602 mechanism supporting both NC and access control/privacy should be 603 considered. 605 5. Challenges 607 This section presents several primary challenges and research items 608 to be considered when applying NC into CCN/NDN. 610 5.1. Adopting Convolutional Coding 612 Several block coding approaches have been proposed so far, but there 613 is still no sufficient discussion and application of convolutional 614 coding approach (e.g., sliding or elastic window coding) in CCN/NDN. 615 Convolutional coding is often appropriate to situations where a fully 616 or partially reliable delivery of continuous data flows is needed, 617 especially when these data flows feature realtime constraints. As in 618 [32] on an end-to-end basis, it would be advantageous for continuous 619 content flow to adopt sliding window coding in CCN/NDN. In this 620 case, the publisher needs to appropriately set coding parameters and 621 let content requestor know the information, and content requestor 622 needs to send interest (i.e., feedback information) about the data 623 reception status. Since CCN/NDN advocates hop-by-hop communication, 624 it would be worth discussing and investigating how convolutional 625 coding can be applied in a hop-by-hop fashion and the benefits. In 626 particular, assuming that NC could occur at intermediate nodes with 627 some useful data packets stored in the CS as described in the 628 previous section, both the encoding window and CS management would be 629 required, and the feasibility and practicality should be considered. 631 5.2. Rate and Congestion Control 633 Adding redundancy using coded packets may cause further network 634 congestion and adversely affect overall throughput performance. In 635 particular, in a situation where fair bandwidth sharing is more 636 desirable, each streaming flow must adapt to the network conditions 637 to fairly consume the available link bandwidth. It is thus 638 indispensable that each content flow cooperatively implements 639 congestion control to adjust the consumed bandwidth to stabilize the 640 network condition (i.e., to achieve low packet loss rate, delay, and 641 jitter). From this point of view, a router supported approach would 642 be effective, but an effective deployment scenario is needed. 644 5.3. Security and Privacy 646 CCN/NDN introduces new security and privacy issues at the networking 647 layer different from IP network, such as cache poisoning and 648 pollution attack, DoS attack using interest packets, and so on. 650 NC could be utilized to mitigate some security or privacy issues CCN/ 651 NDN introduces. For instance, assuming that consumers can utilize 652 multipath data retrieval and caching in CCN/NDN with NC, cache 653 privacy and anonymity set for consumers can be improved as well as 654 caching performance due to the diversity of caching content along 655 different paths. In the case that there is a trusted router or proxy 656 that can operate NC for both interest and data packets, consumer 657 privacy can be protected and censorship can be mitigated; consumer 658 splits the interest into small chunks and encrypts a linear 659 combination of the chunks with the public key of the trusted 660 intermediate node, and the content provider follows the same approach 661 as the client. This approach however prevents in-network cache 662 utilization and involves the high computation cost of many 663 cryptographic operations. 665 On the other hand, considering NC operations over CCN/NDN, the issues 666 related to in-network caching add additional complexity. In order to 667 avoid cache poisoning attack which tries to fill routers cache with 668 polluted content, router needs to check whether or not the content is 669 validated. However, in the case of performing NC and generating a 670 new coded data at routers, a validation mechanism to accurately 671 verify coded data as quickly as possible should be considered while 672 maintaining in-network cache benefits (lower latency and network 673 resource saving). If router can cache some valid coded data, it 674 needs to put a great deal of thought into the effectiveness with 675 respect to cache pollution attack, since coded data newly generated 676 may be unpopular. Moreover, Denial of Service (DoS) attacks may 677 target either the routers or the publishers performing NC to pose 678 unnecessary coded data, impose higher NC computation load, and 679 increase the number of PIT entries, which requires some careful 680 considerations to avoid them. 682 NC also offers a new surface of attack; for instance, if the encoding 683 vector is exposed at the network layer, it would have to be protected 684 (and validated) so as to avoid modifications by an attacker (and 685 allow for verification) on the path of the packet. 687 In this context, from the perspective of both feasibility and 688 practicability, a more effective approach with consideration for 689 security and privacy would be needed in order to accelerate the 690 deployment of CCN/NDN with NC. 692 5.4. Routing Scalability 694 In CCN/NDN, a name-based routing protocol without a resolution 695 process streamlines the routing process and reduces the overall 696 latency. As in IP routing, the growth in the routing table size has 697 become a concern. This may require a hierarchical naming scheme so 698 as to improve the routing scalability by enabling aggregation of 699 routing information. Moreover, in order to effectively leverage NC 700 over CCN/NDN to improve throughput or reduce latency, routers need to 701 know which node can exactly and quickly provide coded packets. Such 702 routing coordination creates routing scalability issues. 704 From another NC perspective, consumers need in advance to know how to 705 specify the names of the coded data to appropriately get it in a 706 scalable manner. In this context, it would be challenging to achieve 707 effective and scalable routing for Interests requesting coded data as 708 well as to simplify the routing process. 710 6. Security Considerations 712 This document does not impact the security of the Internet. Security 713 considerations related to NC for CCN/NDN are described in the 714 previous Section. 716 7. References 718 7.1. Normative References 720 [1] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, 722 DOI 10.17487/RFC2119, March 1997, 723 . 725 7.2. Informative References 727 [2] Cai, N. and R. Yeung, "Secure network coding", Proc. 728 International Symposium on Information Theory 729 (ISIT), IEEE, June 2002. 731 [3] Lima, L., Gheorghiu, S., Barros, J., Mdard, M., and A. 732 Toledo, "Secure Network Coding for Multi-Resolution 733 Wireless Video Streaming", IEEE Journal of Selected Area 734 (JSAC), vol. 28, no. 3, April 2002. 736 [4] Gkantsidis, C. and P. Rodriguez, "Cooperative Security for 737 Network Coding File Distribution", Proc. Infocom, IEEE, 738 April 2006. 740 [5] Vilea, J., Lima, L., and J. Barros, "Lightweight security 741 for network coding", Proc. ICC, IEEE, May 2008. 743 [6] Dimarkis, A., Godfrey, P., Wu, Y., Wainwright, M., and K. 744 Ramchandran, "Network Coding for Distributed Storage 745 Systems", IEEE Trans. Information Theory, vol. 56, no.9, 746 September 2010. 748 [7] Gkantsidis, C. and P. Rodriguez, "Network coding for large 749 scale content distribution", Proc. Infocom, IEEE, March 750 2005. 752 [8] Seferoglu, H. and A. Markopoulou, "Opportunistic Network 753 Coding for Video Streaming over Wireless", Proc. Packet 754 Video Workshop (PV), IEEE, November 2007. 756 [9] Montpetit, M., Westphal, C., and D. Trossen, "Network 757 Coding Meets Information-Centric Networking: An 758 Architectural Case for Information Dispersion Through 759 Native Network Coding", Proc. Workshop on Emerging Name- 760 Oriented Mobile Networking Design (NoM), ACM, June 2012. 762 [10] Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun, 763 "NetCodCCN: a network coding approach for content-centric 764 networks", Proc. Infocom, IEEE, April 2016. 766 [11] Ramakrishnan, A., Westphal, C., and J. Saltarin, "Adaptive 767 Video Streaming over CCN with Network Coding for Seamless 768 Mobility", Proc. International Symposium on Multimedia 769 (ISM), IEEE, December 2016. 771 [12] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. 772 Westphal, "An Optimal Cache Management Framework for 773 Information-Centric Networks with Network Coding", Proc. 774 Networking Conference, IFIP/IEEE, June 2014. 776 [13] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. 777 Westphal, "A Minimum Cost Cache Management Framework for 778 Information-Centric Networks with Network Coding", 779 Computer Networks, Elsevier, August 2016. 781 [14] Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency 782 Low Loss Streaming using In-Network Coding and Caching", 783 Proc. Infocom, IEEE, May 2017. 785 [15] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 786 Briggs, N., and R. Braynard, "Networking Named Content", 787 Proc. CoNEXT, ACM, December 2009. 789 [16] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy, 790 K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, 791 "Named data networking", ACM Comput. Commun. Rev., vol. 792 44, no. 3, July 2014. 794 [17] Koetter, R. and M. Medard, "An Algebraic Approach to 795 Network Coding", IEEE/ACM Trans. on Networking, vol. 11, 796 no 5, Oct. 2003. 798 [18] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 799 F., Lochin, E., Masucci, A., Montpetit, M., Pedersen, M., 800 Peralta, G., Roca, V., Saxena, P., and S. Sivakumar, 801 "Network Coding Taxonomy", draft-irtf-nwcrg-network- 802 coding-taxonomy-05 (work in progress), September 2017. 804 [19] Kutscher, et al., D., "Information-Centric Networking 805 (ICN) Research Challenges", RFC 7927, July 2016. 807 [20] Thomos, N. and P. Frossard, "Toward one Symbol Network 808 Coding Vectors", IEEE Communications letters, vol. 16, no. 809 11, November 2012. 811 [21] Lucani, D., Pedersen, M., Heide, J., and F. Fitzek, 812 "Fulcrum Network Codes: A Code for Fluid Allocation of 813 Complexity", available at http://arxiv.org/abs/1404.6620, 814 April 2014. 816 [22] Perino, D. and M. Varvello, "A reality check for content 817 centric networking", Proc. SIGCOMM Workshop on 818 Information-centric networking (ICN'11), ACM, August 2011. 820 [23] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G. 821 Xie, "Privacy-Aware Multipath Video Caching for Content- 822 Centric Networks", IEEE Journal of Selected Area 823 (JSAC) vol. 38, no. 8, June 2016. 825 [24] Wu, Y., Chou, P., and K. Jain, "A comparison of network 826 coding and tree packing", Proc. ISIT, IEEE, June 2004. 828 [25] Ho, T., Medard, M., Koetter, R., Karger, R., Effros, D., 829 Shi, M., and B. Leong, "A Random Linear Network Coding 830 Approach to Multicast", IEEE Trans. Information 831 Theory, vol. 52, no.10, October 2006. 833 [26] Podlipnig, S. and L. Osz, "A Survey of Web Cache 834 Replacement Strategies", Proc. ACM Computing Surveys vol. 835 35, no. 4, December 2003. 837 [27] Rossini, G. and D. Rossi, "Evaluating CCN multi-path 838 interest forwarding strategies", Elsevier Computer 839 Communication, vol.36, no. 7, April 2013. 841 [28] Chai, W., He, D., Psaras, I., and G. Pavlou, "Cache Less 842 for More in Information-centric Networks", Journal 843 Computer Communications, vol. 37. no. 7, April 2013. 845 [29] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 846 N., and X. Zeng, "Leveraging ICN In-network Control for 847 Loss Detection and Recovery in Wireless Mobile networks", 848 Proc. ICN ACM, September 2016. 850 [30] Ali, M. and U. Niesen, "Coding for Caching: Fundamental 851 Limits and Practical Challenges", IEEE Communications 852 Magazine vol. 54, no. 8, August 2016. 854 [31] Koetter, R. and F. Kschischang, "An algebraic approach to 855 network coding", IEEE Trans. Netw. vol.11, no.5, October 856 2008. 858 [32] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and 859 V. Roca, "On-the-Fly Erasure Coding for Real-Time Video 860 Applications", IEEE Trans. Multimeda vol.13, no.4, August 861 2011. 863 Authors' Addresses 865 Kazuhisa Matsuzono 866 National Institute of Information and Communications Technology 867 4-2-1 Nukui-Kitamachi 868 Koganei, Tokyo 184-8795 869 Japan 871 Email: matsuzono@nict.go.jp 873 Hitoshi Asaeda 874 National Institute of Information and Communications Technology 875 4-2-1 Nukui-Kitamachi 876 Koganei, Tokyo 184-8795 877 Japan 879 Email: asaeda@nict.go.jp 881 Cedric Westphal 882 Huawei 883 2330 Central Expressway 884 Santa Clara, California 95050 885 USA 887 Email: cedric.westphal@huawei.com