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