idnits 2.17.1 draft-irtf-nwcrg-nwc-ccn-reqs-08.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 (November 15, 2021) is 892 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-irtf-nwcrg-coding-and-congestion-09 == Outdated reference: A later version (-05) exists of draft-irtf-icnrg-flic-03 Summary: 1 error (**), 0 flaws (~~), 3 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: May 19, 2022 C. Westphal 6 Huawei 7 November 15, 2021 9 Network Coding for Content-Centric Networking / Named Data Networking: 10 Considerations and Challenges 11 draft-irtf-nwcrg-nwc-ccn-reqs-08 13 Abstract 15 This document describes the current research outcomes in Network 16 Coding (NC) for Content-Centric Networking (CCNx) / Named Data 17 Networking (NDN), and clarifies the technical considerations and 18 potential challenges for applying NC in CCNx/NDN. This document is 19 the product of the Coding for Efficient Network Communications 20 Research Group (NWCRG) and the Information-Centric Networking 21 Research Group (ICNRG). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 19, 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Definitions related to NC . . . . . . . . . . . . . . . . 4 60 2.2. Definitions related to CCNx/NDN . . . . . . . . . . . . . 6 61 3. CCNx/NDN Basics . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. NC Basics . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Advantages of NC and CCNx/NDN . . . . . . . . . . . . . . . . 8 64 6. Technical Considerations . . . . . . . . . . . . . . . . . . 9 65 6.1. Content Naming . . . . . . . . . . . . . . . . . . . . . 9 66 6.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 67 6.2.1. Scope of NC . . . . . . . . . . . . . . . . . . . . . 11 68 6.2.2. Consumer Operation . . . . . . . . . . . . . . . . . 11 69 6.2.3. Forwarder Operation . . . . . . . . . . . . . . . . . 12 70 6.2.4. Producer Operation . . . . . . . . . . . . . . . . . 13 71 6.2.5. Backward Compatibility . . . . . . . . . . . . . . . 14 72 6.3. In-network Caching . . . . . . . . . . . . . . . . . . . 14 73 6.4. Seamless Consumer Mobility . . . . . . . . . . . . . . . 15 74 7. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 7.1. Adoption of Convolutional Coding . . . . . . . . . . . . 15 76 7.2. Rate and Congestion Control . . . . . . . . . . . . . . . 16 77 7.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 16 78 7.4. Routing Scalability . . . . . . . . . . . . . . . . . . . 17 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 81 10. Informative References . . . . . . . . . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 84 1. Introduction 86 Information-Centric Networking (ICN) in general, and Content-Centric 87 Networking (CCNx) [16] or Named Data Networking (NDN) [19] in 88 particular, have emerged as a novel communication paradigm advocating 89 the retrieval of data based on their names. This paradigm pushes 90 content awareness into the network layer. It is expected to enable 91 consumers to obtain the content they desire in a straightforward and 92 efficient manner from the heterogenous networks they may be connected 93 to. The CCNx/NDN architecture has introduced innovative ideas and 94 has stimulated research in a variety of areas, such as in-network 95 caching, name-based routing, multipath transport, and content 96 security. One key benefit of requesting content by name is that it 97 eliminates the requirement to establish a session between the client 98 and a specific server, and the content can thereby be retrieved from 99 multiple sources. 101 In parallel, there has been a growing interest in both academia and 102 industry for better understanding the fundamental aspects of Network 103 Coding (NC) toward enhancing key system performance metrics such as 104 data throughput, robustness and reduction in the required number of 105 transmissions through connected networks, and redundant transmission 106 on broadcast or point-to-multipoint connections. NC is a technique 107 that is typically used for encoding packets to recover from lost 108 source packets at the receiver, and for effectively obtaining the 109 desired information in a fully distributed manner. In addition, in 110 terms of security aspects, NC can be managed using a practical 111 security scheme that deals with pollution attacks [2], and can be 112 utilized for preventing eavesdroppers from obtaining meaningful 113 information [3] or protecting a wireless video stream while retaining 114 the NC benefits [4] [5]. 116 From the perspective of the NC transport mechanism, NC can be divided 117 into two major categories: coherent NC, and non-coherent NC [38] 118 [39]. In coherent NC, the source and destination nodes know the 119 exact network topology and the coding operations available at 120 intermediate nodes. When multiple consumers are attempting to 121 receive the same content such as live video streaming, coherent NC 122 could enable optimal throughput by sending the content flow over the 123 constructed optimal multicast trees [32]. However, it requires a 124 fully adjustable and specific routing mechanism, and a large 125 computational capacity for central coordination. In the case of non- 126 coherent NC, that often comprises the use of Random Linear Coding 127 (RLC), it is not necessary to know the network topology nor the 128 intermediate coding operations [33]. As non-coherent NC works in a 129 completely independent and decentralized manner, this approach is 130 more feasible in terms of eliminating such a central coordination. 132 NC combines multiple packets together with parts of the same content, 133 and may do this at the source or at other nodes in the network. 134 Network coded packets are not associated with a specific server, as 135 they may have been combined within the network. As NC is focused on 136 what information should be encoded in a network packet instead of the 137 specific host at which it has been generated, it is in line with the 138 architecture of the CCNx/NDN core networking layer. NC has already 139 been implemented for information/content dissemination [6] [7] [8]. 140 Montpetit, et al., first suggested that NC techniques be exploited to 141 enhance key aspects of system performance in ICN [9]. NC provides 142 CCNx/NDN with the highly beneficial potential of effectively 143 disseminating information in a completely topology independent and 144 decentralized manner. 146 In this document, we consider how NC can be applied to the CCNx/NDN 147 architecture and describe the technical considerations and potential 148 challenges for making CCNx/NDN-based communications better using the 149 NC technology. It should be noted that the presentation of specific 150 solutions (e.g., NC optimization methods) for enhancing CCNx/NDN 151 performance metrics by exploiting NC is outside the scope of this 152 document. 154 This document represents the collaborative work and consensus of the 155 Coding for Efficient Network Communications Research Group (NWCRG) 156 and the Information-Centric Networking Research Group (ICNRG). It is 157 not an IETF product and is not a standard. 159 2. Terminology 161 This section provides the terms related to NC and CCNx/NDN used in 162 this document. 164 2.1. Definitions related to NC 166 The terms regarding NC used in this document are defined as follows. 167 These are aligned with RFCs produced by the FEC Framework (FECFRAME) 168 IETF Working Groups as well as IRTF Coding for Efficient Network 169 Communications Research Group (NWCRG)[21]. 171 o Source Symbol: A unit of data originating from the source that is 172 used as input to encoding operations. 174 o Coded Symbol, or Repair Symbol: A unit of data that is the result 175 of a coding operation, applied either to source symbols or (in 176 case of re-coding) source and/or coded symbols. 178 o Source Packet: A packet originating from the source that 179 contributes to one or more source symbols. The source symbol is a 180 unit of data originating from the source that is used as input to 181 encoding operations. For instance, a real-time transport protocol 182 (RTP) packet as a whole can constitute a source symbol. In other 183 situations (e.g., to address variable size packets), a single RTP 184 packet may contribute to various source symbols. 186 o Repair Packet: A packet containing one or more coded symbols (also 187 called repair symbol). When there is a single repair symbol per 188 repair packet, a repair symbol corresponds to a repair packet. 190 o Innovative Packet: A source or repair packet that increases the 191 rank of the linear system (also called degrees of freedom) at a 192 receiver. 194 o Encoding versus Re-coding versus Decoding: Encoding is an 195 operation that takes source symbols as input and produces encoding 196 symbols (source or coded symbols) as output. Re-coding is an 197 operation that takes encoding symbols as input and produces 198 encoding symbols as output. Decoding is an operation takes 199 encoding symbols as input and produces source symbols as output. 201 The terms regarding coding types are defined as follows: 203 o Linear Coding: Linear combination of a set of input symbols (i.e., 204 source and/or coded symbols) using a given set of coefficients and 205 resulting in a repair symbol. 207 o Random Linear Coding (RLC): A particular form of linear coding 208 using a set of random coding coefficients. 210 o Block Coding: A coding technique wherein the input flow(s) must be 211 first segmented into a sequence of blocks; encoding and decoding 212 are performed independently on a per-block basis. 214 o Sliding Window Coding or Convolutional Coding: A general class of 215 coding techniques that rely on a sliding encoding window. 216 Encoding window is a set of source (and coded in the case of re- 217 coding) symbols used as input to the coding operations. The set 218 of symbols change over time, as the encoding window slides over 219 the input flow(s). This is an alternative solution to block 220 coding. 222 o Fixed or Elastic Sliding Window Coding: A coding technique that 223 generates coded symbol(s) on the fly, from the set of source 224 symbols present in the sliding encoding window at that time, 225 usually by using linear coding. The sliding window may be either 226 of fixed size or of variable size over the time (also known as 227 "Elastic Sliding Window"). For instance, the size may depend on 228 acknowledgments sent by the receiver(s) for a particular source 229 symbol or source packet (received, decoded, or decodable). 231 The terms regarding low-level coding aspects are defined as follows: 233 o Rank of the Linear System or Degrees of Freedom: At a receiver, 234 the number of linearly independent equations of the linear system. 235 It is also known as "Degrees of Freedom". The system may be of 236 "full rank," wherein decoding is possible, or "partial rank", 237 wherein only partial decoding is possible. 239 o Generation, or Block: With block codes, the set of source symbols 240 of the input flow(s) that are logically grouped into a block, 241 before doing encoding. 243 o Generation Size, or Block Size: With block codes, the number of 244 source symbols belonging to a block. It is equivalent to the 245 number of source packets when there is a single source symbol per 246 source packet. 248 o Generation ID, or Block ID: With block codes, the identifier of a 249 block to which source and coded symbols belong. It is also known 250 as "Source Block Number (SBN)". 252 o Coding Coefficient: With linear coding, this is a coefficient in a 253 certain finite field. This coefficient may be chosen in different 254 ways: for instance, randomly, in a predefined table, or using a 255 predefined algorithm plus a seed. 257 o Coding Vector: A set of coding coefficients used to generate a 258 certain coded symbol through linear coding. 260 o Finite Field: Finite fields, used in linear codes, have the 261 desired property of having all elements (except zero) invertible 262 for + and * and no operation over any elements can result in an 263 overflow or underflow. Examples of finite fields are prime fields 264 {0..p^m-1}, where p is prime. Most used fields use p=2 and are 265 called binary extension fields {0..2^m-1}, where m often equals 1, 266 4 or 8 for practical reasons. 268 o Finite Field size: The number of elements in a finite field. For 269 example the binary extension field {0..2^m-1} has size q=2^m. 271 2.2. Definitions related to CCNx/NDN 273 The terminologies regarding CCNx/NDN used in this document are 274 defined in RFC8793 [17] produced by ICNRG. They are consistent with 275 the relevant documents ([1] [18]). 277 3. CCNx/NDN Basics 279 We briefly explain the key concepts of CCNx/NDN. In a CCNx/NDN 280 network, there are two types of packets at the network level: 281 interest and data packet (defined in Section 3.4 of [17]). The term 282 of content object, which means a unit of content data, is an alias to 283 data packet [17]. The ICN consumer (defined in Section 3.2 of [17]) 284 requests a content object by sending an interest that carries the 285 name of the data. 287 Once an ICN forwarder (defined in Section 3.2 of [17]) receives an 288 interest, it performs a series of lookups: first it checks if it has 289 a copy of the requested content object available in the Content Store 290 (CS) (defined in Section 3.3 of [17]). If it does, it returns the 291 data, and the transaction is considered to have been successfully 292 completed. 294 If it does not have a copy of the requested content object in the CS, 295 it performs a lookup of the Pending Interest Table (PIT) (defined in 296 Section 3.3 of [17]) to check if there is already an outgoing 297 interest for the same content object. If there is no such interest, 298 then it creates an entry in the PIT that lists the name included in 299 the interest, and the interfaces from which it received the interest. 300 This is later used to send the content object back, as interest 301 packets do not carry a source field that identifies the consumer. If 302 there is already a PIT entry for this name, it is updated with the 303 incoming interface of this new interest, and the interest is 304 discarded. 306 After the PIT lookup, the interest undergoes a Forwarding Information 307 Base (FIB) (defined in Section 3.3 of [17]) lookup for selecting an 308 outgoing interface. The FIB lists name prefixes and their 309 corresponding forwarding interfaces in order to send the interest 310 towards a forwarder that possesses a copy of the requested data. 312 Once a copy of the data is retrieved, it is sent back to the 313 consumer(s) using the trail of PIT entries; forwarders remove the PIT 314 state every time that an interest is satisfied, and may store the 315 data in their CS. 317 Data packets carry some information for verifying data integrity and 318 origin authentication, and in particular, that the data is indeed 319 that which corresponds to the name [24]. This is necessary because 320 authentication of the object is crucial in CCNx/NDN. However, this 321 step is optional at forwarders in order to speed up the processing. 323 The key aspect of CCNx/NDN is that the consumer of the content does 324 not establish a session with a specific server. Indeed, the 325 forwarder or producer (defined in Section 3.2 of [17]) that returns 326 the content object is not aware of the network location of the 327 consumer and the consumer is not aware of the network location of the 328 node that provides the content. This, in theory, allows the 329 interests to follow different paths within a network or even to be 330 sent over completely different networks. 332 4. NC Basics 334 While the forwarding node simply relays received data packets in 335 conventional IP communication networks, NC allows the node to combine 336 some data packets that are already received into one or several 337 output packets to be sent. In this section, we simply describe the 338 basic operations of NC. Herein, we focus on RLC in a block coding 339 manner that is well known as a major coding technique. 341 For simplicity, let us consider an example case of end-to-end coding 342 wherein a producer and consumer respectively perform encoding and 343 decoding for a content object. This end-to-end coding is regarded as 344 a special case of NC. The producer splits the content into several 345 blocks called generations. Encoding and decoding are performed 346 independently on a per-block (per-generation) basis. Let us assume 347 that each generation consists of K original source packets of the 348 same size. When the packets do not have the same size, zero padding 349 is added. In order to generate one repair packet within a certain 350 generation, the producer linearly combines K of the original source 351 packets, where additions and multiplications are performed using a 352 coding vector consisting of K coding coefficients that are randomly 353 selected in a certain finite field. The producer may respond to 354 interests to send the corresponding source packets and repair packets 355 in the content flow (called systematic coding), where the repair 356 packets are typically used for recovering lost source packets. 358 Repair packets can also be used for performing encoding. If the 359 forwarding nodes know each coding vector and generation identifier of 360 the received repair packets, they may perform an encoding operation 361 (called re-coding), which is the most distinctie feature of NC 362 compared to other coding techniques. 364 At the consumer, decoding is performed by solving a set of linear 365 equations that are represented by the coding vectors of the received 366 source and repair packets (possibly only repair packets) within a 367 certain generation. In order to obtain all the source packets, the 368 consumer requires K linearly independent equations. In other words, 369 the consumer must receive at least K linearly independent data 370 packets (called innovative packets). As receiving a linearly 371 dependent data packet is not useful for decoding, re-coding should 372 generate and provide innovative packets. One of major benefits of 373 RLC is that even for a small-sized finite field (e.g., q=2^8), the 374 probability of generating linearly dependent packets is negligible 375 [32]. 377 5. Advantages of NC and CCNx/NDN 379 Combining NC and CCNx/NDN can contribute to effective large-scale 380 content/information dissemination. They individually provide similar 381 benefits such as throughput/capacity gain and robustness enhancement. 382 The difference between their approaches is that, the former considers 383 content flow as algebraic information that is to be combined [20], 384 while the latter focuses on the content/information itself at the 385 networking layer. Because these approaches are complementary and 386 their combination would be advantageous, it is natural to combine 387 them. 389 The name-based communication in CCNx/NDN enables consumers to obtain 390 requested content objects without establishing and maintaining end- 391 to-end communication channels between nodes. This feature 392 facilitates the exploitation of the in-network cache and multipath/ 393 multisource retrieval and also supports consumer mobility without the 394 need for updating the location information/identifier during handover 395 [16]. Furthermore, the name-based communication intrinsically 396 supports multicast communication because identical interests are 397 aggregated at the forwarders. 399 NC can enable the CCNx/NDN transport system to effectively distribute 400 and cache the data associated with multipath data retrieval [9]. 401 Exploiting multipath data retrieval and in-network caching with NC 402 contributes to not only improving the cache hit rate but also 403 expanding the anonymity set of each consumer (the set of potential 404 routers that can serve a given consumer) [30]. The expansion makes 405 it difficult for adversaries to infer the content consumed by others, 406 and thus contributes to improving cache privacy. Others also have 407 introduced some use cases of the application of NC in CCNx/NDN, such 408 as the cases of content dissemination with in-network caching [10] 409 [13] [14], seamless consumer mobility [11] [36], and low-latency low- 410 loss video streaming [15]. In this context, it is well worth 411 considering NC integration in CCNx/NDN. 413 6. Technical Considerations 415 This section presents the considerations for CCNx/NDN with NC in 416 terms of network architecture and protocol. This document focuses on 417 NC when employed in a block coding manner. 419 6.1. Content Naming 421 Naming content objects is as important for CCNx/NDN as naming hosts 422 is in the current-day Internet [24]. In this section, two possible 423 naming schemes are presented. 425 Each source and repair packet (hereinafter referred to as NC packet) 426 may have a unique name as each original content object has in CCNx/ 427 NDN, as PIT and CS (i.e., cache storage called content store) 428 operations typically require a unique name for identifying the NC 429 packet. As a method of naming an NC packet that takes into account 430 the feature of block coding, the coding vector and the identifier of 431 the generation (also called block) can be used as a part of the 432 content object name. As in [10], when the generation ID is "g-id", 433 generation size is 4, and coding vector is (1,0,0,0), the name could 434 be /CCNx.com/video-A/g-id/1000. Some other identifiers and/or 435 parameters related to the encoding scheme can also be used as name 436 components. For instance, the encoding ID specifying the coding 437 scheme may be used with "enc-id" such as /CCNx.com/video-A/enc-id/ 438 g-id/1000, as defined in the FEC Framework (FECFRAME) [26]. This 439 naming scheme is simple and can support the delivery of NC packets 440 with exactly the same operations in the PIT/CS as those for the 441 content objects. 443 If a content-naming schema such as the one presented above is used, 444 an interest requesting an NC packet may have the full name including 445 a generation id and coding vector (/CCNx.com/video-A/g-id/1000) or 446 only the name prefix including only a generation id (/CCNx.com/video- 447 A/g-id). In the former case, exact name matching to the PIT is 448 simply performed at data forwarders (as in CCNx/NDN). The consumer 449 is able to specify and retrieve an innovative packet necessary for 450 the consumer to decode successfully. This could shift the generation 451 of the coding vector from the data forwarder onto the consumer. 453 In the latter case, partial name matching is required at the data 454 forwarders. As the interest with only the prefix name matches any NC 455 packet with the same prefix, the consumer could immediately obtain an 456 NC packet from a nearby CS (in-network cache) without knowing the 457 coding vectors of the cached NC packets in advance. In the case 458 wherein NC packets in transit are modified by in-network re-coding 459 performed at forwarders, the consumer could also receive the modified 460 NC packets. However, in contrast to the former case, the consumer 461 may fail to obtain sufficient degrees of freedom (see Section 6.2.3). 462 To address this issue, a new TLV type in an interest message may be 463 required for specifying further coding information in order to limit 464 the NC packets to be received. For instance, this is enabled by 465 specifying the coding vectors of innovative packets for the consumer 466 (also called decoding matrix) as in [9]. This extension may incur an 467 interest packet of significantly increased size, and it may thus be 468 useful to use compression techniques for coding vectors [27] [28]. 469 Without such coding information provided by the interest, the 470 forwarder would be required to maintain some records regarding the 471 interest packets that were satisfied previously (See Section 6.2.3). 473 An NC packet may have a name that indicates that it is an NC packet, 474 and move the coding information into a metadata field in the payload 475 (i.e., the name includes the data type, source or repair packet). 476 This would not be beneficial for applications or services that may 477 not need to understand the packet payload. Owing to the possibility 478 that multiple NC packets may have the same name, some mechanism is 479 required for the consumer to obtain innovative packets. As described 480 in Section 6.3, a mechanism for managing the multiple innovative 481 packets in the CS would also be required. In addition, extra 482 computational overhead would be incurred when the payload is being 483 encrypted. 485 6.2. Transport 487 The pull-based request-response feature of CCNx/NDN is a fundamental 488 principle of its transport layer; one interest retrieves at most one 489 data packet. This means that forwarder or producer cannot 490 initiatively inject unrequested data. It is believed that it is 491 important that this rule not be violated, as 1) it would open denial- 492 of-service (DoS) attacks, 2) it invalidates existing congestion 493 control approaches following this rule, and 3) it would reduce the 494 efficiency of existing consumer mobility approaches. Thus, the 495 following basic operation should be considered for applying NC to 496 CCNx/NDN. Nevertheless, such security considerations must be 497 addressed if this rule were to be violated. 499 6.2.1. Scope of NC 501 An open question is whether data forwarder can perform in-network re- 502 coding with data packets that are being received in transit, or if 503 only the data that matches an interest can be subject to NC 504 operations. In the latter case, encoding or re-coding is performed 505 to generate the NC packet at any forwarder that is able to respond to 506 the interest. This could occur when each NC packet has a unique name 507 and interest has the full name. On the other hand, if interest has a 508 partial name without any coding vector information or NC packets have 509 a same name, the former case may occur; re-coding occurs anywhere in 510 the network where it is possible to modify the received NC packet and 511 forward it. As CCNx/NDN comprises mechanisms for ensuring the 512 integrity of the data during transfer, in-network re-coding 513 introduces complexities in the network that needs consideration for 514 the integrity mechanisms to still work. Similarly, in-network 515 caching of NC packets at forwarders may be valuable; however, the 516 forwarders would require some mechanisms to validate the NC packets 517 (see Section 8). 519 6.2.2. Consumer Operation 521 To obtain NC benefits (possibly associated with in-network caching), 522 the consumer is required to issue interests that direct the forwarder 523 (or producer) to respond with innovative packets if available. In 524 the case where each NC packet may have a unique name (as described in 525 Section 6.1), by issuing an interest specifying a unique name with 526 g-id and the coding vector for an NC packet, the consumer could 527 appropriately receive an innovative packet if it is available at some 528 forwarders. 530 In order to specify the exact name of the NC packet to be retrieved, 531 the consumer is required to know the valid naming scheme. From a 532 practical viewpoint, it is desirable for the consumer application to 533 automatically construct the right name components without depending 534 on any application specifications. To this end, the consumer 535 application may retrieve and refer to a manifest [1] that enumerates 536 the content objects including NC packets, or may use some coding 537 scheme specifier as a name component to construct the name components 538 of interests to request innovative packets. 540 Conversely, the consumer without decoding capability (e.g., specific 541 sensor node) may want to receive only the source packets. As 542 described in Section 6.1, because the NC packet can have a name that 543 is explicitly different from source packets, issuing interests for 544 retrieving source packets is possible. 546 6.2.3. Forwarder Operation 548 If the forwarder constantly responds to the incoming interests by 549 returning non-innovative packets, the consumer(s) cannot decode and 550 obtain the source packets. This issue could happen when 1) incoming 551 interests for NC packets do not specify some coding parameters such 552 as the coding vectors to be used, and 2) the forwarder does not have 553 a sufficient number of linearly independent NC packets (possibly in 554 the CS) to use for re-coding. In this case, the forwarder is 555 required to determine whether or not it can generate innovative 556 packets to be forwarded to the interface(s) at which the interests 557 arrived. An approach to deal with this issue is that the forwarder 558 maintains a tally of the interests for a specific name, generation ID 559 and the incoming interface(s), in order to record how many degrees of 560 freedom have already been provided [10]. As such a scheme requires 561 state management (and potentially timers) in forwarders, scalability 562 and practicality must be considered. In addition, some transport 563 mechanism for in-network loss detection and recovery [15] [36] at 564 forwarder as well as a consumer-driven mechanism could be 565 indispensable for enabling fast loss recovery and realising NC gains. 566 If a forwarder cannot either return a matching innovative packet from 567 its local content store, nor produce on-the-fly a recoded packet that 568 is innovative, it is important that the forwarder not simply return a 569 non-innovative packet but instead do a forwarding lookup in its FIB 570 and forward the interest toward the producer or upstream forwarder 571 that can provide an innovative packet. In this context, to retrieve 572 innovative packet effectively and quickly, an appropriate setting of 573 the FIB and efficient interest forwarding strategies should also be 574 considered. 576 In another possible case, when receiving interests only for source 577 packets, the forwarder may attempt to decode and obtain all the 578 source packets and store them (if the full cache capacity are 579 available), thus enabling a faster response to the interests. As re- 580 coding or decoding results in an extra computational overhead, the 581 forwarder is required to determine how to respond to received 582 interests according to the use case (e.g., a delay-sensitive or 583 delay-tolerant application) and the forwarder situation, such as 584 available cache space and computational capability. 586 6.2.4. Producer Operation 588 Before performing NC for specified content in CCNx/NDN, the producer 589 is responsible for splitting the overall content into small content 590 objects to avoid packet fragmentation that could cause unnecessary 591 packet processing and degraded throughput. The size of the content 592 objects should be within the allowable packet size in order to avoid 593 packet fragmentation in CCNx/NDN network. The producer performs the 594 encoding operation for a set of the small content objects, and the 595 naming process for the NC packets. 597 If the producer takes the lead in determining what coding vectors to 598 use in generating the NC packets, there are three general strategies 599 for naming and producing the NC packets: 601 1. consumers themselves understand in detail the naming conventions 602 used for NC packets and thereby can send the corresponding 603 interests toward the producer to obtain NC packets whose coding 604 parameters have already been determined by the producer. 606 2. the producer determines the coding vectors and generates the NC 607 packets after receiving interests specifying the packets the 608 consumer wished to receive. 610 3. The naming scheme for specifying the coding vectors and 611 corresponding NC packets is explicitly represented via a 612 "Manifest" (e.g., FLIC [23]) that can be obtained by the consumer 613 and used to select among the available coding vectors and their 614 corresponding packets, and thereby send the corresponding 615 interests. 617 In the first case, although the consumers cannot flexibly specify a 618 coding vector for generating the NC packet to obtain, the latency for 619 obtaining the NC packet is less than in the latter two cases. For 620 the second case, there is a latency penalty for the additional NC 621 operations performed after receiving the interests. For the third 622 case, the NC packets to be included in the manifest must be pre- 623 computed by the producer (since the manifest references NC packets by 624 their hashes, not their names), but the producer can select which to 625 include the manifest, and produce multiple manifests either in 626 advance or on demand with different coding tradeoffs if so desired. 628 A common benefit the first two approaches to end-to-end coding is 629 that if the producer adds a signature on the NC packets, data 630 validation becomes possible throughout (as is the case with CCNx/NDN 631 operation in the absence of NC). The third approach of using a 632 manifest trades off the additional latency incurred by the need to 633 fetch the manifest against the efficiency of needing a signature only 634 on the manifest and not on each individual NC packet. 636 6.2.5. Backward Compatibility 638 NC operations should be applied in addition to the regular ICN 639 behavior. Hence, nodes should be able to not support network coding 640 (not only in forwarding the packets, but also in the caching 641 mechanism). NC operations should function alongside regular ICN 642 operations. An NC framework should be compatible with a regular 643 framework in order to facilitate backward compatibility and smooth 644 migration from one framework to the other. 646 6.3. In-network Caching 648 Caching is a useful technique used for improving throughput and 649 latency in various applications. In-network caching in CCNx/NDN 650 essentially provides support at network level and is highly 651 beneficial owing to the involved exploitation of NC for enabling 652 effective multicast transmission [37], multipath data retrieval [10] 653 [11], fast loss recovery [15]. However, there remain several issues 654 to be considered. 656 There generally exist limitations in the CS capacity, and the caching 657 policy affects the consumer's performance [29] [34] [35]. It is thus 658 crucial for forwarders to determine which content objects should be 659 cached and which discarded. As delay-sensitive applications often do 660 not require an in-network cache for a long period owing to their 661 real-time constraints, forwarders have to know the necessity for 662 caching received content objects to save the caching volume. In 663 CCNx, this could be made possible by setting a Recommended Cache Time 664 (RCT) in the optional header of the data packet at the producer side. 665 The RCT serves as a guideline for the CS cache in determining how 666 long to retain the content object. When the RCT is set as zero, the 667 forwarder recognizes that caching the content object is not useful. 668 Conversely, the forwarder may cache it when the RCT has a greater 669 value. In NDN, the TLV type of FreshnessPeriod could be used. 671 One key aspect of in-network caching is whether or not forwarders can 672 cache NC packets in their CS. They may be caching the NC packets 673 without having the ability to perform a validation of the content 674 objects. Therefore, the caching of the NC packets would require some 675 mechanism to validate the NC packets (see Section 8). In the case 676 wherein the NC packets have the same name, it would also require some 677 mechanism to identify them. 679 6.4. Seamless Consumer Mobility 681 A key feature of CCNx/NDN is that it is sessionless, which enables 682 the consumer and forwarder to send multiple interests toward 683 different copies of the content in parallel, by using multiple 684 interfaces at the same time in an asynchronous manner. Through the 685 multipath data retrieval, the consumer could obtain the content from 686 multiple copies that are distributed while using the aggregate 687 capacity of multiple interfaces. For the link between the consumer 688 and the multiple copies, the consumer can perform a certain rate 689 adaptation mechanism for video streaming [11] or congestion control 690 for content acquisition [12]. 692 NC adds a reliability layer to CCNx in a distributed and asynchronous 693 manner, because NC provides a mechanism for ensuring that the 694 interests sent to multiple copies of the content in parallel retrieve 695 innovative packets, even in the case of packet losses on some of the 696 paths/networks to these copies. This applies to consumer mobility 697 events [11], wherein the consumer could receive additional degrees of 698 freedom with any innovative packet if at least one available 699 interface exists during the mobility event. An interest forwarding 700 strategy at the consumer (and possibly forwarder) for efficiently 701 obtaining innovative packets would be required for the consumer to 702 achieve seamless consumer mobility. 704 7. Challenges 706 This section presents several primary challenges and research items 707 to be considered when applying NC in CCNx/NDN. 709 7.1. Adoption of Convolutional Coding 711 Several block coding approaches have been proposed thus far; however, 712 there is still not sufficient discussion and application of the 713 convolutional coding approach (e.g., sliding or elastic window 714 coding) in CCNx/NDN. Convolutional coding is often appropriate for 715 situations wherein a fully or partially reliable delivery of 716 continuous data flows is required, and especially when these data 717 flows feature realtime constraints. As in [40], on an end-to-end 718 coding basis, it would be advantageous for continuous content flow to 719 adopt sliding window coding in CCNx/NDN. In this case, the producer 720 is required to appropriately set coding parameters and let the 721 consumer know the information, and the consumer is required to send 722 interests augmented with feedback information regarding the data 723 reception and/or decoding status. As CCNx/NDN utilises hop-by-hop 724 forwarding state, it would be worth discussing and investigating how 725 convolutional coding can be applied in a hop-by-hop manner and what 726 benefits might accrue. In particular, in the case wherein in-network 727 re-coding could occur at forwarders, both the encoding window and CS 728 management would be required, and the corresponding feasibility and 729 practicality should be considered. 731 7.2. Rate and Congestion Control 733 The addition of redundancy using repair packets may result in further 734 network congestion and could adversely affect the overall throughput. 735 In particular, in a situation wherein fair bandwidth sharing is more 736 desirable, each streaming flow must adapt to the network conditions 737 to fairly consume the available link bandwidth. It is thus necessary 738 that each content flow cooperatively implement congestion control to 739 adjust the consumed bandwidth [22]. From this perspective, although 740 a forwarder-supported approach would be effective, an effective 741 deployment approach that provides benefits under partial deployment 742 is required. 744 As described in Section 6.4, NC can contribute to seamless consumer 745 mobility by obtaining innovative packets without receiving duplicated 746 packets through multipath data retrieval. It can be challenging to 747 develop an effective rate and congestion control mechanism in order 748 to achieve seamless consumer mobility while improving the overall 749 throughput or latency by fully exploiting NC operations. 751 7.3. Security 753 While CCNx/NDN introduces new security issues at the networking layer 754 that are different from the IP network, such as a cache poisoning and 755 pollution attacks, a DoS attack using interest packets, some security 756 approaches are already provided [24] [25]. The application of NC in 757 CCNx/NDN brings two potential security aspects that need to be dealt 758 with. 760 The first is in-network re-coding at forwarders. Some mechanism for 761 ensuring the integrity of the NC packets newly produced by in-network 762 re-coding is required in order for consumers or other forwarders to 763 receive valid NC packets. To this end, there are some possible 764 approaches described in Section 8, but there may be more effective 765 method with lower complexity and computation overhead. 767 The second is that attackers maliciously request and inject NC 768 packets, which could amplify some attacks. As NC packets are 769 unpopular in general use, they could be targeted by a cache pollution 770 attack that requests less popular content objects more frequently to 771 undermine popularity-based caching by skewing the content popularity. 772 Such an attack needs to be dealt with in order to maintain the in- 773 network cache efficiency. By injecting invalid NC packets with the 774 goal of filling the CSs at the forwarders with them, the cache 775 poisoning attack could be effectual depending on the exact integrity 776 coverage on NC packets. On the assumption that each NC packet has 777 the valid signature, the straightforward approach would comprise the 778 forwarders verifying the signature within the NC packets in transit 779 and only transmitting and storing the validated NC packets. However, 780 as performing a signature verification by the forwarders may be 781 infeasible at line speed, some mechanisms should be considered for 782 distributing and reducing the load of signature verification, in 783 order to maintain in-network cache benefits such as latency and 784 network-load reduction. 786 7.4. Routing Scalability 788 In CCNx/NDN, a name-based routing protocol without a resolution 789 process streamlines the routing process and reduces the overall 790 latency. In IP routing, the growth in the routing table size has 791 become a concern. It is thus necessary to use a hierarchical naming 792 scheme in order to improve the routing scalability by enabling the 793 aggregation of the routing information. 795 To realize the benefits of NC, consumers need to efficiently obtain 796 innovative packets using multipath retrieval mechanisms of CCNx/NDN. 797 This would require some efficient routing mechanism to appropriately 798 set the FIB and also an efficient interest forwarding strategy. Such 799 routing coordination may create routing scalability issues. It would 800 be challenging to achieve effective and scalable routing for 801 interests requesting NC packets as well as to simplify the routing 802 process. 804 8. Security Considerations 806 In-network re-coding is a distinguishing feature of NC. Only valid 807 NC packets produced by in-network re-coding must be requested and 808 utilized (and possibly stored). To this end, there exist some 809 possible approaches. First, as a signature verification approach, 810 the exploitation of multi-signature capability could be applied. 811 This allows not only the original content producer but also some 812 forwarders responsible for in-network re-coding to have their own 813 unique signing key. Each forwarder of the group signs newly 814 generated NC packet in order for other nodes to be able to validate 815 the data with the signature. The CS may verify the signature within 816 the NC packet before storing it to avoid invalid data caching. 818 Second, as a consumer-dependent approach, the consumer puts a 819 restriction on the matching rule using only the name of the requested 820 data. The interest ambiguity can be clarified by specifying both the 821 name and the key identifier (the producer's public key digest) used 822 for matching to the requested data. This KeyId restriction is built 823 in the CCNx design [1]. Only the requested data packet satisfying 824 the interest with the KeyId restriction would be forwarded and stored 825 in the CS, thus resulting in a reduction in the chances of cache 826 poisoning. Moreover, in the CCNx design, there exists the rule that 827 the CS obeys in order to avoid amplifying invalid data; if an 828 interest has a KeyID restriction, the CS must not reply unless it 829 knows that the signature on the matching content object is correct. 830 If the CS cannot verify the signature, the interest may be treated as 831 a cache miss and forwarded to the upstream forwarder(s). Third, as a 832 certificate chain management approach (possibly without certificate 833 authority), some mechanism such as [31] could be used to establish a 834 trustworthy data delivery path. This approach adopts the hop-by-hop 835 authentication mechanism, wherein forwarding-integrated hop-by-hop 836 certificate collection is performed to provide suspension certificate 837 chains such that the data retrieval is trustworthy. 839 Depending on the adopted caching strategy such as cache replacement 840 policies, forwarders should also take caution when storing and 841 retaining the NC packets in the CS as they could be targeted by cache 842 pollution attacks. In order to mitigate the cache pollution attacks' 843 impact, forwarders should check the content request frequencies to 844 detect the attack and may limit requests by ignoring some of the 845 consecutive requests. The forwarders can then decide to apply or 846 change to the other cache replacement mechanism. 848 The forwarders or producers require careful attention to the DoS 849 attacks aiming at provoking the high load of NC operations by using 850 the interests for NC packets. In order to mitigate such attacks, the 851 forwarders could adopt a rate-limiting approach. For instance, they 852 could monitor the PIT size growth for NC packets per content to 853 detect the attacks, and limit the interest arrival rate when 854 necessary. If the NC application wishes to secure an interest 855 (considered as the NC actuator) in order to prevent such attacks, the 856 application should consider using an encrypted wrapper and an 857 explicit protocol. 859 9. Acknowledgements 861 The authors would like to thank ICNRG and NWCRG members, especially 862 Marie-Jose Montpetit, David Oran, Vincent Roca, and Thierry Turletti, 863 for their valuable comments and suggestions on this document. 865 10. Informative References 867 [1] Mosko, M. and et al., "Content-Centric Networking (CCNx) 868 Semantics", RFC 8569, July 2019, 869 . 871 [2] Gkantsidis, C. and P. Rodriguez, "Cooperative Security for 872 Network Coding File Distribution", Proc. Infocom, IEEE, 873 April 2006. 875 [3] Cai, N. and R. Yeung, "Secure network coding", Proc. 876 International Symposium on Information Theory 877 (ISIT), IEEE, June 2002. 879 [4] Lima, L., Gheorghiu, S., Barros, J., Medard, M., and A. 880 Toledo, "Secure Network Coding for Multi-Resolution 881 Wireless Video Streaming", IEEE Journal of Selected Area 882 (JSAC), vol. 28, no. 3, April 2010. 884 [5] Vilea, J., Lima, L., and J. Barros, "Lightweight security 885 for network coding", Proc. ICC, IEEE, May 2008. 887 [6] Dimarkis, A., Godfrey, P., Wu, Y., Wainwright, M., and K. 888 Ramchandran, "Network Coding for Distributed Storage 889 Systems", IEEE Trans. Information Theory, vol. 56, no.9, 890 September 2010. 892 [7] Gkantsidis, C. and P. Rodriguez, "Network coding for large 893 scale content distribution", Proc. Infocom, IEEE, March 894 2005. 896 [8] Seferoglu, H. and A. Markopoulou, "Opportunistic Network 897 Coding for Video Streaming over Wireless", Proc. Packet 898 Video Workshop (PV), IEEE, November 2007. 900 [9] Montpetit, M., Westphal, C., and D. Trossen, "Network 901 Coding Meets Information-Centric Networking: An 902 Architectural Case for Information Dispersion Through 903 Native Network Coding", Proc. Workshop on Emerging Name- 904 Oriented Mobile Networking Design (NoM), ACM, June 2012. 906 [10] Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun, 907 "NetCodCCN: a network coding approach for content-centric 908 networks", Proc. Infocom, IEEE, April 2016. 910 [11] Ramakrishnan, A., Westphal, C., and J. Saltarin, "Adaptive 911 Video Streaming over CCN with Network Coding for Seamless 912 Mobility", Proc. International Symposium on Multimedia 913 (ISM), IEEE, December 2016. 915 [12] Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, 916 "MIRCC: Multipath-aware ICN Rate-based Congestion 917 Control", Proc. Conference on Information-Centric 918 Networking (ICN), ACM, September 2016. 920 [13] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. 921 Westphal, "An Optimal Cache Management Framework for 922 Information-Centric Networks with Network Coding", Proc. 923 Networking Conference, IFIP/IEEE, June 2014. 925 [14] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. 926 Westphal, "A Minimum Cost Cache Management Framework for 927 Information-Centric Networks with Network Coding", 928 Computer Networks, Elsevier, August 2016. 930 [15] Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency 931 Low Loss Streaming using In-Network Coding and Caching", 932 Proc. Infocom, IEEE, May 2017. 934 [16] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 935 Briggs, N., and R. Braynard, "Networking Named Content", 936 Proc. CoNEXT, ACM, December 2009. 938 [17] Wissingh, B. and et al., "Information-Centric Networking 939 (ICN): Content-Centric Networking (CCNx) and Named Data 940 Networking (NDN) Terminology", RFC 8793, June 2020, 941 . 943 [18] Mosko, M. and et al., "Content-Centric Networking (CCNx) 944 Messages in TLV Format", RFC 8609, July 2019, 945 . 947 [19] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy, 948 K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, 949 "Named data networking", ACM Comput. Commun. Rev., vol. 950 44, no. 3, July 2014. 952 [20] Koetter, R. and M. Medard, "An Algebraic Approach to 953 Network Coding", IEEE/ACM Trans. on Networking, vol. 11, 954 no 5, Oct. 2003. 956 [21] Adamson, B. and et al., "Taxonomy of Coding Techniques for 957 Efficient Network Communications", RFC 8406, June 2018, 958 . 960 [22] Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Coding 961 and Congestion Control in Transport", Work in Progress, 962 draft-irtf-nwcrg-coding-and-congestion-09, June 2021. 964 [23] Tschudin, C., Wood, C., Mosko, M., and D. Oran, "File-Like 965 ICN Collections (FLIC)", Work in Progress, draft-irtf- 966 icnrg-flic-03, Nov. 2021. 968 [24] Kutscher, D. and et al., "Information-Centric Networking 969 (ICN) Research Challenges", RFC 7927, July 2016. 971 [25] Pentikousis, K. and et al., "Information-Centric 972 Networking: Evaluation and Security Considerations", 973 RFC 7945, July 2019. 975 [26] Watson, M. and et al., "Forward Error Correction (FEC) 976 Framework", RFC 6363, Oct. 2011. 978 [27] Thomos, N. and P. Frossard, "Toward one Symbol Network 979 Coding Vectors", IEEE Communications letters, vol. 16, no. 980 11, November 2012. 982 [28] Lucani, D., Pedersen, M., Heide, J., and F. Fitzek, 983 "Fulcrum Network Codes: A Code for Fluid Allocation of 984 Complexity", available at http://arxiv.org/abs/1404.6620, 985 April 2014. 987 [29] Perino, D. and M. Varvello, "A reality check for content 988 centric networking", Proc. SIGCOMM Workshop on 989 Information-centric networking (ICN'11), ACM, August 2011. 991 [30] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G. 992 Xie, "Privacy-Aware Multipath Video Caching for Content- 993 Centric Networks", IEEE Journal of Selected Area 994 (JSAC) vol. 38, no. 8, June 2016. 996 [31] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric 997 Authentication for Secure In-Network Big-Data Retrieval", 998 IEEE Trans. on Network Science and Engineering vol. 7, no. 999 1, September 2018. 1001 [32] Wu, Y., Chou, P., and K. Jain, "A comparison of network 1002 coding and tree packing", Proc. ISIT, IEEE, June 2004. 1004 [33] Ho, T., Medard, M., Koetter, R., Karger, R., Effros, D., 1005 Shi, M., and B. Leong, "A Random Linear Network Coding 1006 Approach to Multicast", IEEE Trans. Information 1007 Theory, vol. 52, no.10, October 2006. 1009 [34] Podlipnig, S. and L. Osz, "A Survey of Web Cache 1010 Replacement Strategies", Proc. ACM Computing Surveys vol. 1011 35, no. 4, December 2003. 1013 [35] Rossini, G. and D. Rossi, "Evaluating CCN multi-path 1014 interest forwarding strategies", Elsevier Computer 1015 Communication, vol.36, no. 7, April 2013. 1017 [36] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 1018 N., and X. Zeng, "Leveraging ICN In-network Control for 1019 Loss Detection and Recovery in Wireless Mobile networks", 1020 Proc. ICN ACM, September 2016. 1022 [37] Ali, M. and U. Niesen, "Coding for Caching: Fundamental 1023 Limits and Practical Challenges", IEEE Communications 1024 Magazine vol. 54, no. 8, August 2016. 1026 [38] Koetter, R. and F. Kschischang, "An algebraic approach to 1027 network coding", IEEE Trans. Netw. vol.11, no.5, October 1028 2003. 1030 [39] Vyetrenko, S., Ho, T., Effros, M., Kliewer, J., and E. 1031 Erez, "Rate regions for coherent and noncoherent 1032 multisource network error correction", Proc. International 1033 Symposium on Information Theory (ISIT), IEEE, July 2009. 1035 [40] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and 1036 V. Roca, "On-the-Fly Erasure Coding for Real-Time Video 1037 Applications", IEEE Trans. Multimeda vol.13, no.4, August 1038 2011. 1040 Authors' Addresses 1042 Kazuhisa Matsuzono 1043 National Institute of Information and Communications Technology 1044 4-2-1 Nukui-Kitamachi 1045 Koganei, Tokyo 184-8795 1046 Japan 1048 Email: matsuzono@nict.go.jp 1049 Hitoshi Asaeda 1050 National Institute of Information and Communications Technology 1051 4-2-1 Nukui-Kitamachi 1052 Koganei, Tokyo 184-8795 1053 Japan 1055 Email: asaeda@nict.go.jp 1057 Cedric Westphal 1058 Huawei 1059 2330 Central Expressway 1060 Santa Clara, California 95050 1061 USA 1063 Email: cedric.westphal@futurewei.com,