idnits 2.17.1 draft-matsuzono-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 5, 2018) is 2206 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0' is mentioned on line 338, but not defined -- Looks like a reference, but probably isn't: 'TBD' on line 628 == Unused Reference: '27' is defined on line 761, 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 (==), 2 comments (--). 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 6, 2018 C. Westphal 6 Huawei 7 March 5, 2018 9 Network Coding for Content-Centric Networking / Named Data Networking: 10 Requirements and Challenges 11 draft-matsuzono-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 6, 2018. 37 Copyright Notice 39 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 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.3. In-network Caching . . . . . . . . . . . . . . . . . . . 11 67 4.4. Seamless Mobility . . . . . . . . . . . . . . . . . . . . 12 68 4.5. Security and Privacy . . . . . . . . . . . . . . . . . . 12 69 5. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 5.1. Adopting Convolutional Coding . . . . . . . . . . . . . . 13 71 5.2. Rate and Congestion Control . . . . . . . . . . . . . . . 13 72 5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 14 73 5.4. Routing Scalability . . . . . . . . . . . . . . . . . . . 14 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 7.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 Information-Centric Networks in general, and Content-Centric 83 Networking (CCN) [15] or Named Data Networking (NDN) [16] in 84 particular, have emerged as a novel communication paradigm advocating 85 to retrieve data through their names. This paradigm pushes content 86 awareness into the network layer. It is expected to enable consumers 87 to obtain the content they desire in a straightforward and efficient 88 manner from the heterogenous networks they may be connected to. The 89 CCN/NDN architecture has introduced innovative ideas and has 90 stimulated research in a variety of areas, such as in-network 91 caching, name-based routing, multi-path transport, content security, 92 and so on. One key benefit of requesting content by name is that it 93 removes the need to establish a session between the client and a 94 specific server, and that content can thereby be retrieved from 95 multiple sources. 97 In parallel, there has been a growing interest from both academia and 98 industry to better understand fundamental aspects of Network Coding 99 (NC) toward enhancing key system performance metrics such as data 100 throughput, robustness and reduction in the required number of 101 transmissions through connected networks, point-to-multipoint 102 connections, etc. Typically, NC is a technique mainly used to encode 103 packets to recover lost source packets at the receiver, and to 104 effectively get the desired information in a fully distributed 105 manner. In addition, NC can be used for security enhancements 106 [2][3][4][5]. 108 NC aggregates multiple packets with parts of the same content 109 together, and may do this at the source or at other nodes in the 110 network. As such, network coded packets are not connected to a 111 specific server, as they may have evolved within the network. Since 112 NC focuses on what information should be encoded in a network packet, 113 rather than the specific host where it has been generated, it is in 114 line with the CCN/NDN core networking layer (described in more detail 115 later on). NC has already been implemented for information/content 116 dissemination (e.g. [6][7][8]). NC provides CCN/NDN with the highly 117 beneficial potential to effectively disseminate information in a 118 completely independent and decentralized manner. [9] first suggested 119 to exploit NC techniques to enhance key system performances in ICN, 120 and others have considered NC in ICN use cases such as content 121 dissemination [10], seamless mobility [11], joint caching and network 122 coding [12][13], low-latency video streaming [14], etc. 124 In this document, we consider how NC can be applied to the CCN/NDN 125 architecture and describe the requirements and potential challenges 126 for making CCN/NDN-based communications better using the NC 127 technology. Please note that providing specific solutions (e.g., NC 128 optimization methods) to enhance CCN/NDN performance metrics by 129 exploiting NC is out of scope of this document. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [1]. 137 2.1. Definitions 139 The terminology regarding NC used in this document is described 140 below. It is aligned with RFCs produced by the FEC Framework 141 (FECFRAME) IETF Working Groups as well as recent activities in the 142 Network Coding Research Group [18]. 144 o Random Linear Coding (RLC): Particular case of Linear Coding using 145 a set of random coding coefficients. 147 o Generation, or (IETF) Block: With Block Codes, the set of content 148 data that are logically grouped into a Block, before doing 149 encoding. 151 o Generation Size: With Block Codes, the number k of content data 152 belonging to a Block. 154 o Encoding Vector: A set of coding coefficients used to generate a 155 certain coded packet through linear coding. The number of nonzero 156 coefficients in the Coding Vector defines its density 158 o Finite Field: Finite fields, used in Linear Codes, have the 159 desired property of having all elements (except zero) invertible 160 for + and * and all operations over any elements do not result in 161 an overflow or underflow. Examples of Finite Fields are prime 162 fields {0..p^m-1}, where p is prime. Most used fields use p=2 and 163 are called binary extension fields {0..2^m-1}, where m often 164 equals 1, 4 or 8 for practical reasons. 166 o Finite Field size: The number of elements in a finite field. For 167 example the binary extension field {0..2^m-1} has size q=2^m. 169 o Block Coding: Coding technique where the input Flow(s) must be 170 first segmented into a sequence of blocks, FEC encoding and 171 decoding being performed independently on a per-block basis. 173 o Sliding Window Coding or Convolutional Coding: General class of 174 coding techniques that rely on a sliding encoding window. This is 175 an alternative solution to Block Coding. 177 o Fixed or Elastic Sliding Window Coding: Coding technique that 178 generates repair data on-the-fly, from the set of source data 179 present in the sliding encoding window at that time, usually by 180 using Linear Coding. The sliding window may be either of fixed 181 size or of variable size over the time (also known as "elastic 182 sliding window"). 184 o Feedback: Feedback information sent by a decoding node to a node 185 (or from a consumer to a publisher in case of End-to-End Coding). 186 The nature of information contained in a feedback packet varies, 187 depending on the use-case. It can provide reception and/or 188 decoding statistics, or the list of available source packets 189 received or decoded, or the list of lost source packets that 190 should be retransmitted, or a number of additional repair packet 191 needed to have a full rank linear system. 193 Concerning CCN/NDN, the following terminology and definitions are 194 used. 196 o Consumer: A node requesting content. It initiates communication 197 by sending an interest packets. 199 o Publisher: A node providing content. It originally creates or 200 owns the content. 202 o Forwarding Information Base (FIB): A lookup table in a content 203 router containing the name prefix and corresponding destination 204 interface to forward the interest packets. 206 o Pending Interest Table (PIT): A lookup table populated by the 207 interest packets containing the name prefix of the requested data, 208 and the outgoing interface used to forward the received data 209 packets. 211 o Content Store (CS): A storage space for a router to cache content 212 objects. It is also known as in-network cache. 214 o Content Object: A unit of content data delivered through the CCN/ 215 NDN network. 217 o Content Flow: A sequence of content objects associated with the 218 unique content name prefix. 220 2.2. NDN/CCN Background 222 Armed with the terminology above, we briefly explain the key concepts 223 of CCN/NDN. Both protocols are similar in principle, and different 224 on some implementation choices. 226 In a CCN network, there are two types of packets at the network 227 level: interest and data. The consumer request a content by sending 228 an "interest" message, that carries the name of the data. On 229 difference to note here in CCN and NDN is that in later versions of 230 CCN, the interest must carry a full name, while in NDN it may carry a 231 name prefix (and receive in return any data with a name matching this 232 prefix). 234 Once a router receives an "interest" message, it performs a series of 235 look-up: first it checks in the Content Store if it has a copy of the 236 requested content available. If it does, it returns the data and the 237 transaction has successfully completed. 239 If it does not, it performs a look-up of the PIT to see if there is 240 already an outgoing request for the same data. If there is not, then 241 it creates an entry in the PIT that lists the name included in the 242 interest, and the interfaces from which it received the interest. 243 This is used later to send the data back, since interest packets do 244 not carry a source field that identifies the requester. If there is 245 already a PIT entry for this name, then it is updated with the 246 incoming interface of this new request and the interest is discarded. 248 After the PIT look-up, the interest undergoes a FIB lookup to select 249 an outgoing interface. The FIB lists name prefixes and their 250 corresponding forwarding interfaces, to send the interface towards a 251 router that possesses a copy of the requested data. 253 Once a copy of the data is retrieved, it is send back to the 254 requester(s) using the trail of PIT entries; intermediate node remove 255 the PIT state every time that an interest is satisfied, and may store 256 the data in their content store. 258 Data packets carry some information to validate the data, in 259 particular that the data is indeed the one that corresponds to the 260 name. This is required since authentication of the object is crucial 261 in CCN/NDN. However, this step is optional at intermediate routers, 262 so as to speed up the processing. 264 The key aspect of CCN/NDN is that the consumer of the content does 265 not establish a session with a specific server. Indeed, the node 266 that returns the content is not aware of the network location of the 267 requester and the requester is not aware of the network location of 268 the node that provides the content. This in theory allows the 269 interests to follow different paths within a network, or even to be 270 sent over totally different networks. 272 3. Advantage given by NC and CCN/NDN 274 Both NC for large scale content dissemination [7] and CCN/NDN can 275 contribute to effective content/information delivery while working 276 jointly. They both bring similar benefits such as throughput/ 277 capacity gain and robustness enhancement. The difference between 278 their approaches is that, the former considers content flow as 279 algebraic information to combine [17], while the latter focuses on 280 content/information itself at the networking layer. Because these 281 approaches are complementary, it is natural to combine them. The 282 CCN/NDN core abstraction at networking layer through name makes 283 network stack simple as it enables applications to take maximum 284 advantage of multiple simultaneous connectivities due to its simpler 285 relationship with the layer 2 [15]. 287 CCN/NDN itself, however, cannot provide reliable and robust content 288 dissemination. This requires some specific CCN/NDN transport (i.e., 289 strategy layer) [15]. NC can enable the CCN/NDN transport system to 290 effectively distribute and cache data associated with multi-path data 291 retrieval. Furthermore, NC may further enhance CCN/NDN security 292 [23]. In this context, it should be natural that there is much room 293 for considering NC integration into CCN/NDN transport exploiting in- 294 network caching and multi-path transmission [9] and seamless mobility 295 [11] [28]. 297 From the perspective of NC transport mechanism, NC is divided into 298 two major categories: one is coherent NC, and the other is non- 299 coherent NC [30]. In coherent NC, source and destination nodes 300 exactly know network topology and coding operations at intermediate 301 nodes. When multiple consumers are trying to receive the same 302 content such as live video streaming, coherent NC could enable the 303 optimal throughput by making the content flow sent over the 304 constructed optimal multicast trees [24]. 306 However, it requires fully adjustable and specific name-based routing 307 mechanism for CCN/NDN, and an intense computational task for central 308 coordination. In the case of non-coherent NC that often utilizes 309 RLC, they do not need to know network topology and intermediate 310 coding operations. Since non-coherent NC works in a completely 311 independent and decentralized manner, this approach is more feasible 312 especially in the large scale use cases that are intended with CCN/ 313 NDN. This document thus focuses on non-coherent NC with RLC. 315 4. Requirements 317 This section presents the NC requirements for ICN/CCN in terms of 318 network architecture and protocol. The current document focuses on 319 NC in a block coding manner. 321 4.1. Content Naming 323 Naming content objects is as important for CCN/NDN as naming hosts is 324 for today's Internet [19]. Before performing network coding for 325 specified content in CCN/NDN, the overall content should be split 326 into small content objects to avoid packet fragmentation that could 327 cause unnecessary packet processing and degrades throughput. The 328 size of content objects should be within the allowable packet size so 329 as to avoid packet fragmentation in CCN/NDN network, and then network 330 coding should be applied into a set of the content objects. 332 Each coded packet MAY have a unique name as the original content 333 object has in CCN/NDN, since PIT/FIB/CS operations need a unique name 334 to identify the coded data. As a way of naming coded packet, the 335 encoding vector and the identifier of generation can be used as a 336 part of the content object name [10]. For instance, when the block 337 size (also called generation size) is k and the encoding vector is 338 [1,0,0,0], the name would be like /CCN.com/video-A/k/1000. This 339 naming scheme is simple and can support the delivery of coded packets 340 with exactly the same operations in the FIB/PIT/CS as for original 341 source packets. However, such a naming way requires the consumer to 342 know the naming structure (through a specific name resolution scheme 343 for instance) in order for nodes to specify the exact name of 344 generated coded data packet to retrieve it. From this point of view, 345 it could shift the generation of the encoding vector from the content 346 producer onto the content requester. 348 If a naming schema such as above is used, it would be valuable to 349 reconsider whether Interest should carry full names (as in CCN) or 350 prefixes (as in NDN) as multiple network coded packets could match a 351 response to a specific prefix for a given generation, such as 352 /CCN.com/video-A/k. In the latter case allowing partial name 353 matching, the content requestor may not be able to obtain degrees of 354 freedom. Thus, extensions in the TLV header of the Interest would be 355 used to specify further network coding information so as to limit 356 coded packets to be received (for instance, by specifying the encoded 357 vectors the content requestor receives (also called decoding matrix) 358 as in [9]). However, it may incur a largely increased size of TLV 359 header. Without such coding information, the forwarding node would 360 need to maintain some records regarding interest packets sent before, 361 in order to provide new degrees of freedom. 363 Coded packet MAY have a name that indicates that it is a coded 364 packet, and move the coding information into a metadata field in the 365 payload (i.e., the name includes only data type, original or coded 366 packet, etc). This however would preclude network coding on packets 367 without prior decoding them (for instance, in the CS of forwarding 368 nodes). It would not be beneficial for applications or services that 369 may not need to understand the packet payload. Due to the 370 possibility that multiple coded packets may have a same name, as 371 described above, some mechanism needs for the content requestor to 372 obtain innovative coded packets. It would also require some 373 mechanism to insert the multiple innovative packets into the CS. If 374 the coding information of coded packet are encrypted together with 375 the payload (for instance, at source coding), the content requestor 376 or forwarding nodes would incur extra computational overhead for 377 decryption of the packet to interpret the coding information. 379 4.2. Transport 381 The pull-based request-response feature of CCN/NDN is the fundamental 382 principle of its transport layer; one Interest retrieves at most one 383 Data packet. It is important to not violate this rule, as it would 384 open denial of service attacks issues, and thus the following basic 385 operation should be considered to apply NC to CCN/NDN. 387 4.2.1. Scope of Network Coding 389 It should be discussed whether the network can update data packets 390 that are being received in transit, or if only the data that matches 391 an interest can be subject to network coding operations. In the 392 latter case, the network coding is performed on an end-to-end basis 393 (where one end is the consumer, and the other end is any node that is 394 able to respond to the Interest). In the former case, NC happens 395 anywhere in the network that is able to update the data. As CCN/NDN 396 has mechanisms in place to ensure the integrity of the data during 397 transfer, NC in the network introduce complexities that would require 398 special consideration for the integrity mechanisms to still work. 400 Similarly, caching of network coded packets at intermediate node may 401 be valuable, but may prevent the node caching the coded content to 402 validate the content. 404 4.2.2. Consumer Operation 406 To attain NC benefits associated with in-network caching, consumers 407 need to issue interests directing the router (or publisher) to 408 forward innovative coded packets if available. The reason why this 409 directive is needed is that delay-sensitive applications such as 410 live-video streaming may want to sequentially get original packets 411 rather than coded packets cached in routers due to real-time 412 constraint. Issuing such an interest is possible by using optional 413 TLV (Type Length Value) header contained in Interest TLV packet 414 format which allows network elements to add or modify information on 415 the fly. Consumer can put an instruction into it, and for instance, 416 if routers detect that it is better for consumer to get coded packets 417 rather than original packets, routers can modify it to do so. After 418 receiving interests having the instruction in optional header, the 419 router with useful coded packets forward them. 421 As another solution, consumer issues interests specifying unique 422 names for each coded packets. In this case, a unified naming scheme 423 considering both original and coded packets is required. Moreover, 424 in the case of NC end-to-end approach, publishers need to get 425 feedback from the corresponding receivers to adjust some coding 426 parameters. To deal with this, a receiver may have to request a 427 specific interest name to reach the corresponding publisher and put 428 required information into the optional header. 430 4.2.3. Router Operation 432 Routers need to appropriately handle PIT entries to accommodate 433 interests for coded packets as well as original packets. Moreover, 434 in order to decode as necessary, nodes need to know the coding vector 435 used for each coded packet (note: since all the data for a specific 436 content may not come through the same path/network, intermediate 437 nodes may never be able to decode). In a typical case, the coding 438 vector used for each coded packet is attached to the header of coded 439 data. In regard to this point, the generation size (also called 440 block size) for NC should be set to a reasonable value so that the 441 total coded packet size including header needed for expressing the 442 coding vector information and data message fits into the allowable 443 packet size. It may be useful to use compression techniques for 444 coding vectors [20][21]. 446 Router may try to forward useful independent coded packets toward 447 downstream nodes in order to respond to received interests for coded 448 packets. Routers thus need to determine whether or not they can 449 generate useful coded packets for consumers. Assuming that the size 450 of the Finite Field in use is not relatively small, re-encoding using 451 enough cached packets has a strong probability of making independent 452 coded packets [24]. If router does not have enough cached packets to 453 newly produce independent coded packets, it relays received interests 454 to upstream nodes to receive a new original or independent coded 455 packet and pass it to downstream nodes. In another possible case, 456 when receiving interests for only original packets, routers may try 457 to decode and get all the original packets and store them (if there 458 are fully available cache capacity), enabling faster response to the 459 interests. Since there is a tradeoff between NC encoding/decoding 460 calculation cost and cache capacity, and the usage efficacy of re- 461 encoding or decoding at router, router should need to determine how 462 to response to receiving interests according to the use case (e.g., 463 delay-sensitive or delay-tolerant application) and the router 464 situation such as available cache space and computational capability. 466 Some proposed schemes [10]require that the router maintain a tally of 467 the interests for a specific name and generation, so as to know how 468 many degrees of freedom have been provided already for the NC 469 packets. Scalability and practicality of maintaining such scheme at 470 intermediate routers should considered. 472 To enable fast loss recovery cooperating with in-network caching, a 473 transport mechanism of in-network loss detection and recovery 474 [28][14] at router as well as consumer-driven mechanism should be 475 considered. 477 4.2.4. Publisher Operation 479 The procedure for splitting an overall content into small content 480 objects is responsible for the original publisher. When applying NC 481 for the content, the publisher performs NC over the content objects, 482 and naming processing for the coded packets. If the producer takes 483 the lead in determining the used encoding vectors and generating the 484 coded packets, there are the two possible end-to-end cases; 1) 485 content requestors obtain the names of coded packets through a 486 certain mechanism, and send the correspond interests toward the 487 publisher to get the coded packets already generated at the 488 publisher, and 2) the publisher determines the encoding vectors after 489 receiving interests specifying them. In the former case, although 490 content requestors cannot flexibly specify an encoding vector for 491 generating the coded packet to retain, but the latency for getting 492 the coded data can be reduced compared to the latter case where 493 additional NC operations need after receiving interests. According 494 to application requirement for latency, such NC operation strategy 495 should be considered. 497 4.3. In-network Caching 499 Caching is an essential technique to improve throughput and latency 500 in various applications. In-network caching CCN/NDN essentially 501 supports at network level is highly beneficial by exploiting NC to 502 enable effective multicast transmission [29], multipath data 503 retrieval[10] [11], fast loss recovery [14], and so on. However, 504 there are several issues to be considered. 506 As a general issue, there are limitations of cache capacity, and 507 caching policy affects on consumer's performances [22] [25] [26]. It 508 is thus highly significant for routers to determine which packets 509 should be cached and discarded. Since delay-sensitive applications 510 often do not require in-network cache for a long period due to their 511 real-time constraints, routers have to know the necessity for caching 512 received packets to save the caching volume. This could be possible 513 by putting a flag into optional header of data packets at publisher 514 side. When receiving data packets with the flag meaning no necessity 515 for cache, routers just have to forward them to downstream nodes. On 516 the other hand, when receiving original packets or coded packets 517 without the flag, router may cache them based on a specified 518 replacement policy. 520 One key aspect of in-network caching is whether or not intermediate 521 nodes can cache NC packets without first decoding them. If in- 522 network caches store coded packets, they need to be able to validate 523 that the packets are not compromised, so as to avoid cache pollution 524 attacks. Without having all the packets in a generation, the cache 525 cannot decode the packets to check if it is authenticated. Caching 526 of coded packets would require some mechanism to validate coded 527 packets. In addition, when coded packets have a same name, it would 528 also require some mechanism to identify them. 530 4.4. Seamless Mobility 532 This subsection presents how NC can achieve seamless mobility [11] 533 [28] and clarify the requirements. A key feature of CCN/NDN is that 534 it is sessionless and that multiple interests can be send to 535 different copies of the content in parallel. CCN/NDN enables a 536 consumer to retrieve the content from multiple sources that are 537 distributed and asynchronous. 539 In this context, network coding provide a mechanism to ensure that 540 the Interests sent to multiple copies of the content retrieve 541 innovative packets, even in the case of packet losses on some of the 542 paths/networks to these copies. NC adds a reliability layer to CCN 543 in a distributed and asynchronous manner. One key benefit is that 544 the link between the consumer and the multiple copies acts as a 545 virtual logical link, upon which rate adaptation mechanism can be 546 performed. 548 This naturally applies to mobility event, where the consumer may 549 connect between multiple access points before a mobility event (make- 550 before-break handoff). In such mobility event, the consumer is 551 connected first to the previous access point, then to both the 552 previous and next access points, then finally only to the next access 553 points. With CCN, the consumer only sends interests on the available 554 interfaces. Requesting network coded packets ensures that during the 555 phase where it is connected to the previous and the next APs at the 556 same time, it does not receive duplicate data, but does not miss on 557 any content either. By combining NC with CCN, the consumer receives 558 additional degrees of freedom with any innovative packet it receives 559 on either interface. 561 Further discussion is [TBD]. 563 4.5. Security and Privacy 565 This subsection describes the requirement for security and privacy 566 provided by NC in CCN/NDN, such as data integrity especially when 567 intermediate nodes perform re-encoding, as in the case of hash 568 restrictions for original data packets, and so on. 570 Network coding impacts the security mechanisms of CCN/NDN. In 571 particular, CCN/NDN is designed to prevent modification of the Data 572 packets. Because Data packets for a specific name can be self- 573 authenticated, they can be validated on the delivery path, and can 574 also be cached at untrusted intermediate nodes. Network coding may 575 bring up issues if intermediate nodes are allowed to modify packets 576 by performing additional network coding operations. Intermediate 577 nodes may also be caching network coded packets without having the 578 ability to perform validation of the content and therefore open 579 themselves to cache pollution attacks. 581 In CCN/NDN, content objects can be encrypted to support access 582 control or privacy. If the coding information of coded packet is 583 included in the encrypted data payload, extra computational overhead 584 occurs. 586 5. Challenges 588 This section presents several primary challenges and research items 589 to be considered when applying NC into CCN/NDN. 591 5.1. Adopting Convolutional Coding 593 Several block coding approaches have been proposed so far, but there 594 is still no sufficient discussion and application of convolutional 595 coding approach (e.g., sliding or elastic window coding) in CCN/NDN. 596 Convolutional coding is often appropriate to situations where a fully 597 or partially reliable delivery of continuous data flows is needed, 598 especially when these data flows feature realtime constraints. As in 599 [31] on an end-to-end basis, it would be advantageous for continuous 600 content flow to adopt sliding window coding in CCN/NDN. In this 601 case, the publisher needs to appropriately set coding parameters and 602 let content requestor know the information, and content requestor 603 needs to send interest (i.e., feedback information) about the data 604 reception status. Since CCN/NDN advocates hop-by-hop communication, 605 it would be worth discussing and investigating how convolutional 606 coding can be applied in a hop-by-hop fashion and the benefits. In 607 particular, assuming that NC could occur at intermediate nodes with 608 some useful data packets stored in the CS as described in the 609 previous section, both the encoding window and CS management would be 610 required, and the feasibility and practicality should be considered. 612 5.2. Rate and Congestion Control 614 Adding redundancy using coded packets may cause further network 615 congestion and adversely affect overall throughput performance. In 616 particular, in a situation where fair bandwidth sharing is more 617 desirable, each streaming flow must adapt to the network conditions 618 to fairly consume the available link bandwidth. It is thus 619 indispensable that each content flow cooperatively implements 620 congestion control to adjust the consumed bandwidth to stabilize the 621 network condition (i.e., to achieve low packet loss rate, delay, and 622 jitter). 624 5.3. Security and Privacy 626 A variety of security and privacy concerns would exist in NC and CCN/ 627 NDN. This subsection focuses on the description of security and 628 privacy challenges related to NC for CCN/NDN. [TBD] 630 5.4. Routing Scalability 632 This subsection focuses on the challenges of routing mechanisms such 633 as scalability and protocol overhead, and so on. 635 6. Security Considerations 637 This document does not impact the security of the Internet. Security 638 considerations related to NC for CCN/NDN are described in the 639 previous Section. 641 7. References 643 7.1. Normative References 645 [1] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, 647 DOI 10.17487/RFC2119, March 1997, 648 . 650 7.2. Informative References 652 [2] Cai, N. and R. Yeung, "Secure network coding", Proc. 653 International Symposium on Information Theory 654 (ISIT), IEEE, June 2002. 656 [3] Lima, L., Gheorghiu, S., Barros, J., Mdard, M., and A. 657 Toledo, "Secure Network Coding for Multi-Resolution 658 Wireless Video Streaming", IEEE Journal of Selected Area 659 (JSAC), vol. 28, no. 3, April 2002. 661 [4] Gkantsidis, C. and P. Rodriguez, "Cooperative Security for 662 Network Coding File Distribution", Proc. Infocom, IEEE, 663 April 2006. 665 [5] Vilea, J., Lima, L., and J. Barros, "Lightweight security 666 for network coding", Proc. ICC, IEEE, May 2008. 668 [6] Dimarkis, A., Godfrey, P., Wu, Y., Wainwright, M., and K. 669 Ramchandran, "Network Coding for Distributed Storage 670 Systems", IEEE Trans. Information Theory, vol. 56, no.9, 671 September 2010. 673 [7] Gkantsidis, C. and P. Rodriguez, "Network coding for large 674 scale content distribution", Proc. Infocom, IEEE, March 675 2005. 677 [8] Seferoglu, H. and A. Markopoulou, "Opportunistic Network 678 Coding for Video Streaming over Wireless", Proc. Packet 679 Video Workshop (PV), IEEE, November 2007. 681 [9] Montpetit, M., Westphal, C., and D. Trossen, "Network 682 Coding Meets Information-Centric Networking: An 683 Architectural Case for Information Dispersion Through 684 Native Network Coding", Proc. Workshop on Emerging Name- 685 Oriented Mobile Networking Design (NoM), ACM, June 2012. 687 [10] Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun, 688 "NetCodCCN: a network coding approach for content-centric 689 networks", Proc. Infocom, IEEE, April 2016. 691 [11] Ramakrishnan, A., Westphal, C., and J. Saltarin, "Adaptive 692 Video Streaming over CCN with Network Coding for Seamless 693 Mobility", Proc. International Symposium on Multimedia 694 (ISM), IEEE, December 2016. 696 [12] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. 697 Westphal, "An Optimal Cache Management Framework for 698 Information-Centric Networks with Network Coding", Proc. 699 Networking Conference, IFIP/IEEE, June 2014. 701 [13] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. 702 Westphal, "A Minimum Cost Cache Management Framework for 703 Information-Centric Networks with Network Coding", 704 Computer Networks, Elsevier, August 2016. 706 [14] Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency 707 Low Loss Streaming using In-Network Coding and Caching", 708 Proc. Infocom, IEEE, May 2017. 710 [15] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 711 Briggs, N., and R. Braynard, "Networking Named Content", 712 Proc. CoNEXT, ACM, December 2009. 714 [16] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy, 715 K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, 716 "Named data networking", ACM Comput. Commun. Rev., vol. 717 44, no. 3, July 2014. 719 [17] Koetter, R. and M. Medard, "An Algebraic Approach to 720 Network Coding", IEEE/ACM Trans. on Networking, vol. 11, 721 no 5, Oct. 2003. 723 [18] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 724 F., Lochin, E., Masucci, A., Montpetit, M., Pedersen, M., 725 Peralta, G., Roca, V., Saxena, P., and S. Sivakumar, 726 "Network Coding Taxonomy", draft-irtf-nwcrg-network- 727 coding-taxonomy-05 (work in progress), September 2017. 729 [19] Kutscher, et al., D., "Information-Centric Networking 730 (ICN) Research Challenges", RFC 7927, July 2016. 732 [20] Thomos, N. and P. Frossard, "Toward one Symbol Network 733 Coding Vectors", IEEE Communications letters, vol. 16, no. 734 11, November 2012. 736 [21] Lucani, D., Pedersen, M., Heide, J., and F. Fitzek, 737 "Fulcrum Network Codes: A Code for Fluid Allocation of 738 Complexity", available at http://arxiv.org/abs/1404.6620, 739 April 2014. 741 [22] Perino, D. and M. Varvello, "A reality check for content 742 centric networking", Proc. SIGCOMM Workshop on 743 Information-centric networking (ICN'11), ACM, August 2011. 745 [23] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G. 746 Xie, "Privacy-Aware Multipath Video Caching for Content- 747 Centric Networks", IEEE Journal of Selected Area 748 (JSAC) vol. 38, no. 8, June 2016. 750 [24] Wu, Y., Chou, P., and K. Jain, "A comparison of network 751 coding and tree packing", Proc. ISIT, IEEE, June 2004. 753 [25] Podlipnig, S. and L. Osz, "A Survey of Web Cache 754 Replacement Strategies", Proc. ACM Computing Surveys vol. 755 35, no. 4, December 2003. 757 [26] Rossini, G. and D. Rossi, "Evaluating CCN multi-path 758 interest forwarding strategies", Elsevier Computer 759 Communication, vol.36, no. 7, April 2013. 761 [27] Chai, W., He, D., Psaras, I., and G. Pavlou, "Cache Less 762 for More in Information-centric Networks", Journal 763 Computer Communications, vol. 37. no. 7, April 2013. 765 [28] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 766 N., and X. Zeng, "Leveraging ICN In-network Control for 767 Loss Detection and Recovery in Wireless Mobile networks", 768 Proc. ICN ACM, September 2016. 770 [29] Ali, M. and U. Niesen, "Coding for Caching: Fundamental 771 Limits and Practical Challenges", IEEE Communications 772 Magazine vol. 54, no. 8, August 2016. 774 [30] Koetter, R. and F. Kschischang, "An algebraic approach to 775 network coding", IEEE Trans. Netw. vol.11, no.5, October 776 2008. 778 [31] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and 779 V. Roca, "On-the-Fly Erasure Coding for Real-Time Video 780 Applications", IEEE Trans. Multimeda vol.13, no.4, August 781 2011. 783 Authors' Addresses 785 Kazuhisa Matsuzono 786 National Institute of Information and Communications Technology 787 4-2-1 Nukui-Kitamachi 788 Koganei, Tokyo 184-8795 789 Japan 791 Email: matsuzono@nict.go.jp 793 Hitoshi Asaeda 794 National Institute of Information and Communications Technology 795 4-2-1 Nukui-Kitamachi 796 Koganei, Tokyo 184-8795 797 Japan 799 Email: asaeda@nict.go.jp 800 Cedric Westphal 801 Huawei 802 2330 Central Expressway 803 Santa Clara, California 95050 804 USA 806 Email: cedric.westphal@huawei.com