idnits 2.17.1 draft-irtf-icnrg-evaluation-methodology-05.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 12, 2016) is 2933 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Online' is mentioned on line 1546, but not defined == Unused Reference: 'ICARUS' is defined on line 1205, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-irtf-icnrg-challenges-04 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG K. Pentikousis, Ed. 3 Internet-Draft EICT 4 Intended Status: Informational B. Ohlman 5 Expires: October 14, 2016 Ericsson 6 E. Davies 7 Trinity College Dublin 8 S. Spirou 9 Intracom Telecom 10 G. Boggia 11 Politecnico di Bari 12 April 12, 2016 14 Information-centric Networking: Evaluation and Security Considerations 15 draft-irtf-icnrg-evaluation-methodology-05 17 Abstract 19 This document presents a number of considerations regarding 20 evaluating Information-centric Networking (ICN) and sheds some light 21 on the impact of ICN on network security. It also surveys the 22 evaluation tools currently available to researchers in the ICN area 23 and provides suggestions regarding methodology and metrics. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 Copyright and License Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Evaluation Considerations . . . . . . . . . . . . . . . . . . 4 62 2.1. Topology Selection . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Traffic Load . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.3. Choosing Relevant Metrics . . . . . . . . . . . . . . . . 10 65 2.3.1. Traffic Metrics . . . . . . . . . . . . . . . . . . . 13 66 2.3.2. System Metrics . . . . . . . . . . . . . . . . . . . . 14 67 2.4. Resource Equivalence and Tradeoffs . . . . . . . . . . . . 15 68 3. ICN Security Aspects . . . . . . . . . . . . . . . . . . . . . 15 69 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 16 70 3.2. Authorization, Access Control and Logging . . . . . . . . . 18 71 3.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 3.4. Changes to the Network Security Threat Model . . . . . . . 19 73 4. Evaluation Tools . . . . . . . . . . . . . . . . . . . . . . . 20 74 4.1. Open-source Implementations . . . . . . . . . . . . . . . 20 75 4.2. Simulators and Emulators . . . . . . . . . . . . . . . . . 21 76 4.2.1. ndnSIM . . . . . . . . . . . . . . . . . . . . . . . . 22 77 4.2.2. ccnSIM . . . . . . . . . . . . . . . . . . . . . . . . 22 78 4.2.3. Icarus simulator . . . . . . . . . . . . . . . . . . . 22 79 4.3. Experimental Facilities . . . . . . . . . . . . . . . . . 23 80 4.3.1. Open Network Lab [ONL] . . . . . . . . . . . . . . . . 23 81 4.3.2. POINT testbed . . . . . . . . . . . . . . . . . . . . 24 82 4.3.3. CUTEi: Container-based ICN testbed . . . . . . . . . . 24 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 86 8. Informative References . . . . . . . . . . . . . . . . . . . . 25 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 89 1. Introduction 90 Information-centric Networking (ICN) is a networking concept that 91 arose from the desire to align the operation model of a network with 92 the model of its typical use. For TCP/IP networks, this implies 93 changing the mechanisms of data access and transport from a host-to- 94 host model to a user-to-information model. The premise is that the 95 effort invested in changing models will be offset, or even surpassed, 96 by the potential of a "better" network. However, such a claim can be 97 validated only if it is quantified. 99 Different ICN approaches are evaluated in the peer-reviewed 100 literature using a mixture of theoretical analysis, simulation and 101 emulation techniques, and empirical (testbed) measurements. The 102 specific methodology employed may depend on the experimentation goal, 103 e.g., whether one wants to evaluate scalability, quantify resource 104 utilization, or analyze economic incentives. In addition, though, we 105 observe that ease and convenience of setting up and running 106 experiments can sometimes be a factor in published evaluations. As 107 discussed in [RFC7476], the development phase that ICN is going 108 through and the plethora of approaches to tackle the hardest problems 109 make this a very active and growing research area but, on the 110 downside, it also makes it more difficult to compare different 111 proposals on an equal footing. 113 Performance evaluation using actual network deployments has the 114 advantage of realistic workloads and reflects the environment where 115 the service or protocol are to be deployed. In the case of ICN, 116 however, it is not currently clear what qualifies as a "realistic 117 workload". Trace-based analysis of ICN is in its infancy, and more 118 work is needed towards defining characteristic workloads for ICN 119 evaluation studies. Accordingly, the experimental process and the 120 evaluation methodology per se are actively being researched for 121 different ICN architectures. Numerous factors affect the 122 experimental results, including the topology selected, the background 123 traffic that an application is being subjected to, network conditions 124 such as available link capacities, link delays, and loss-rate 125 characteristics throughout the selected topology; failure and 126 disruption patterns; node mobility and the diversity of devices used. 128 The goal of this document is to summarize evaluation guidelines and 129 tools alongside suggested data sets and high-level approaches. We 130 expect this to be of interest to the ICN community as a whole as it 131 can assist researchers and practitioners alike to compare and 132 contrast different ICN designs against each other, as well as against 133 the state of the art in host-centric solutions, and identify the 134 respective strengths and weaknesses. We note that apart from the 135 technical evaluation of the functionality of an ICN architecture, its 136 future success will be largely driven by its deployability and 137 economic viability. Therefore, ICN evaluations should assess 138 incremental deployability in the existing network environment 139 together with a view of how the technical functions will incentivize 140 deployers to invest in the capabilities that allow the architecture 141 to spread across the network. 143 This document has been produced by the IRTF Information-centric 144 Networking Research Group (ICNRG). The main objective of the ICNRG is 145 to couple ongoing ICN research in the above areas with solutions that 146 are relevant for evolving the Internet at large. The ICNRG produce 147 documents that provides guidelines for experimental activities in the 148 area of ICN so that different, alternative solutions can be compared 149 consistently, and information sharing accomplished for experimental 150 deployments. This document incorporates input from ICNRG participants 151 and their corresponding text contributions; it has been reviewed by 152 several ICNRG active participants (see section 7), and represents the 153 consensus of the research group. That said, note that this document 154 does not constitute an IETF standard; see also [RFC5743]. 156 The remainder of this document is organized as follows. Section 2 157 presents various techniques and considerations for evaluating 158 different ICN architectures. Section 3 discusses the impact of ICN 159 on network security. Section 4 surveys the tools currently available 160 to ICN researchers. 162 2. Evaluation Considerations 164 It is clear that the way we evaluate IP networks will not be directly 165 applicable for evaluating ICN. In IP the focus is on the performance 166 and characteristics of end-to-end connections between a source and a 167 destination. In ICN the "source" responding to a request can be any 168 ICN node in the network and may change from request to request. This 169 makes it difficult to use concepts like delay and throughput in a 170 traditional way. In addition evaluating resource usage in ICN is a 171 more complicated task as memory used for caching affects delays and 172 use of transmission resources, see the discussion on resource 173 equivalents at the end of this section. 175 There are two major types of evaluations of ICN that we see a need to 176 make. One type is to compare ICN to traditional networking and one 177 type is to compare different ICN implementations and approaches 178 against each other. 180 In this section we details some of the functional components needed 181 when evaluating different ICN implementations and approaches. 183 2.1. Topology Selection 184 There's a wealth of earlier work on topology selection for simulation 185 and performance evaluation of host-centric networks. While the 186 classic dumbbell topology is regarded as inappropriate for ICN, most 187 ICN studies so far have been based on that earlier work for host- 188 centric networks [RFC7476]. However, there is no single topology that 189 can be used to easily evaluate all aspects of ICN. Therefore, one 190 should choose from a range of topologies depending on the focus of 191 the evaluation. 193 For scalability and resilience studies, there is a wide range of 194 synthetic topologies, such as the Barabasi-Albert model [BA] and the 195 Watts-Strogatz small-world topology [WATTS]. These allow experiments 196 to be performed whilst controlling various key parameters (e.g., node 197 degree). These synthetic topologies are appropriate in the general 198 case, as there are no practical assurances that a future information- 199 centric network will share the same topology with today's networks. 201 When studies look at cost (e.g., transit cost) or migration to ICN, 202 realistic topologies should be used. These can be inferred from 203 Internet traces, such as the CAIDA Macroscopic Internet Topology Data 204 Kit (http://www.caida.org/data/active/internet-topology-data-kit) and 205 Rocketfuel 206 (http://www.cs.washington.edu/research/networking/rocketfuel). A 207 problem is the large size of the topology (approx. 45K ASes, close to 208 200K links), which may limit the scalability of the employed 209 evaluation tool. Katsaros et al. [ICNScale] address this problem by 210 using scaled down topologies created following the methodology 211 described in [COMPLEX]. 213 Studies that focus on node or content mobility can benefit from 214 topologies and their dynamic aspects as used in the DTN community. As 215 mentioned in [RFC7476], DTN traces are available to be used in such 216 ICN evaluations. 218 As with host-centric topologies, defining just a node graph will not 219 be enough for most ICN studies. The experimenter should also clearly 220 define and list the respective matrices that correspond to the 221 network, storage and computation capacities available at each node as 222 well as the delay characteristics of each link [Montage]. Real values 223 for such parameters can be taken from existing platforms such as 224 iPlane (http://iplane.cs.washington.edu). Synthetic values could be 225 produced with specific tools [DELAY]. 227 2.2. Traffic Load 229 In this subsection we provide a set of common guidelines, in the form 230 of what we will refer to as a content catalog for different 231 scenarios. This catalog, which is based on previously published 232 work, could be used to evaluate different ICN proposals, for 233 instance, on routing, congestion control, and performance, and can be 234 considered as other kinds of ICN contributions emerge. As we are 235 still lacking ICN-specific traffic workloads we can currently only 236 extrapolate from today's workloads. A significant challenge then 237 relates to the identification of the applications contributing to the 238 observed traffic (e.g., Web or peer-to-peer), as well as to the exact 239 amount of traffic they contribute to the overall traffic mixture. 240 Efforts in this direction can take heed from today's traffic mix 241 comprising web, peer-to-peer file sharing, and User Generated Content 242 (UGC) platforms (e.g., YouTube), as well as Video on Demand (VoD) 243 services. Publicly available traces for these include those 244 available from web sites such as 245 http://multiprobe.ewi.tudelft.nl/multiprobe.html, 246 http://an.kaist.ac.kr/traces/IMC2007.html, and 247 http://traces.cs.umass.edu/index.php/Network/Network. 249 Taking a more systematic approach, and with the purpose of modeling 250 the traffic load, we can resort to measurement studies that 251 investigate the composition of Internet traffic, such as [1][2]. In 252 [1] a large scale measurement study was performed, with the purpose 253 of studying the traffic crossing inter-domain links. The results 254 indicate the dominance of Web traffic, amounting to 52% over all 255 measured traffic. However, Deep Packet Inspection (DPI) techniques 256 reveal that 25-40% of all HTTP traffic actually carries video 257 traffic. Results from DPI techniques also reveal the difficulty in 258 correctly identifying the application type in the case of P2P 259 traffic: mapping observed port numbers to well-known applications 260 shows P2P traffic constituting only 0.85% of overall traffic, while 261 DPI raises this percentage to 18.32% [1]. Relevant studies on a 262 large ISP show the percentage of P2P traffic ranging from 17 to 19% 263 of overall traffic [2]. Table I provides an overview of these 264 figures. The "other" traffic type denotes traffic that cannot be 265 classified in any of the first three application categories, and 266 consists of unclassified traffic and traffic heavily fragmented into 267 several applications (e.g., 0.17% DNS traffic). 269 Table I. Traffic type ratios of total traffic [1, 2] 271 Traffic Type | Ratio 272 ===================== 273 Web | 31-39% 274 --------------------- 275 P2P | 17-19% 276 --------------------- 277 Video | 13-21% 278 --------------------- 279 Other | 29-31% 280 ===================== 282 The content catalog for each type of traffic can be characterized by 283 a specific set of parameters: 285 a) The cardinality of the estimated content catalog. 287 b) The size of the exchanged contents (either chunks or entire named 288 information objects). 290 c) The popularity of objects expressed in their request frequency. 292 In most application types, the popularity distribution follows some 293 power law, indicating that a small number of information items 294 trigger a large proportion of the entire set of requests. The exact 295 shape of the power law popularity distribution directly impacts the 296 performance of the underlying protocols. For instance, highly skewed 297 popularity distributions (e.g., a Zipf-like distribution with a high 298 slope value) favor the deployment of caching schemes, since caching a 299 very small set of information items can dramatically increase the 300 cache hit ratio. 302 Several studies in the past few years have stated that Zipf's law is 303 the discrete distribution that best represents the request frequency 304 in a number of application scenarios, ranging from the Web to video 305 on demand (VoD) services. The key aspect of this distribution is 306 that the frequency of a content request is inversely proportional to 307 the rank of the content itself, i.e., the smaller the rank, the 308 higher the request frequency. If we denote with M the content 309 catalog cardinality and with 1 <= i <= M the rank of the i-th most 310 popular content, we can express the probability of requesting the 311 content with rank "i" as: 313 P(X=i) = ( 1/i^(alpha) ) / C, with C = SUM(1 / j^(alpha)), alpha > 0 314 where the sum is obtained considering all values of j, 1 <= j <= M. 316 A recent analysis of HTTP traffic showed that content popularity is 317 better reflected by a trimodal distribution model in which the head 318 and tail of a Zipf distribution (with slope value 0.84) are replaced 319 by two discrete Weibull distributions with shape parameter values 0.5 320 and 0.24 respectively [IMB2014]. 322 A variation of the Zipf distribution, termed the Mandelbrot-Zipf 323 distribution was suggested [P2PMod] to better model environments 324 where nodes can locally store previously requested content. For 325 example, it was observed that peer-to-peer file sharing applications 326 typically exhibited a 'fetch-at-most-once' style of behavior. This 327 is because peers tend to persistently store the files they download, 328 a behavior that may also be prevalent in ICN. 330 Popularity can also be characterized in terms of: 332 a) The temporal dynamics of popularity, i.e., how requests are 333 distributed in time. The popularity distribution expresses the 334 number of requests submitted for each information item 335 participating into a certain workload. However, they do not 336 describe how these requests are distributed in time. This aspect 337 is of primary importance when considering the performance of 338 caching schemes since the ordering of the requests obviously 339 affects the contents of a cache. For example, with a Least 340 Frequently Used (LFU) cache replacement policy, if all requests 341 for a certain item are submitted close in time, the item is 342 unlikely to be evicted from the cache, even by a (globally) more 343 popular item whose requests are more evenly distributed in time. 344 The temporal ordering of requests gains even more importance when 345 considering workloads consisting of various applications, all 346 competing for the same cache space. 348 b) The spatial locality of popularity i.e., how requests are 349 distributed throughout a network. The importance of spatial 350 locality relates to the ability to avoid redundant traffic in the 351 network. If requests are highly localized in some area of the 352 entire network, then similar requests can be more efficiently 353 served with mechanisms such as caching and/or multicast i.e., the 354 concentration of similar requests in a limited area of the network 355 allows increasing the perceived cache hit ratios at caches in the 356 area and/or the traffic savings from the use of multicast. Table 357 II provides an overview of distributions that can be used to model 358 each of the identified traffic types i.e., Web, Video (based on 359 YouTube measurements) and P2P (based on BitTorrent measurements). 360 These distributions are the outcome of a series of modeling 361 efforts based on measurements of real traffic workloads 363 [3][4][5][6][7][8][9][10][11][12][13]. A tool for the creation of 364 synthetic workloads following these models, and also allowing the 365 generation of different traffic mixes is described in [14]. 367 Table II. Overview of traffic types models 369 | Object Size | Temporal Locality | Popularity Distribution 370 ===================================================================== 371 Web | Concatenation | Ordering via LRU | Zipf: p(i)=K/i^a 372 | of Lognormal | stack model [5] | i: popularity rank 373 | (body) and | | N: total items 374 | Pareto (tail) | Exact timing via | K: 1/Sum(1/i^a) 375 | [7,8] | exponential | a: distribution slope 376 | | distribution [6] | values 0.64-0.84 [3][4] 377 --------------------------------------------------------------------- 378 VoD | Duration/size: | No analytical models | Weibull: k=0.513, 379 | Concatenated | | lambda=6010 380 | normal, most | Random distribution | 381 | videos | across total | Gamma: k=0.372, 382 | ~330 kb/s [13] | duration | theta=23910 [12] 383 --------------------------------------------------------------------- 384 P2P | Wide variation | Mean arrival rate of | Mandelbrot-Zipf [9]: 385 | on torrent | 0.9454 torrents/hour | p(i)=K/((i+q)/a) 386 | sizes [9]. | Peers in a swarm | q: plateau factor, 387 | No analytical | arrive as | 5 to 100. 388 | models exist: | l(t)= l0*e^(-t/tau) | Flatter head than in 389 | Sample a real | l0: initial arrival | Zipf-like distribution 390 | BitTorrent [11]| rate (87.74 average) | (where q=0) 391 | distribution | tau: object | 392 | or use fixed | popularity | 393 | value | (1.16 average)* [10] | 394 ===================================================================== 396 * Random ordering of swarm births (first request). For each swarm 397 calculate a different tau. Based on average tau and object 398 popularity. Exponential decay rule for subsequent requests. 400 Table III summarizes the content catalog. With this shared point of 401 reference, the use of the same set of parameters (depending on the 402 scenario of interest) among researchers will be eased, and different 403 proposals could be compared on a common base. 405 Table III. Content catalog 407 Traffic | Catalog | Mean Object Size | Popularity Distribution 408 Load | Size | [L4][L5][L7][L8] | [L3][L5][L6][L11][L12] 409 | [L1][L2]| [L9][L10] | 410 | [L3][L5]| | 411 ================================================================== 412 Web | 10^12 | Chunk: 1-10 kB | Zipf with 413 | | | 0.64 <= alpha <= 0.83 414 ------------------------------------------------------------------ 415 File | 5x10^6 | Chunk: 250-4096 kB | Zipf with 416 sharing | | Object: ~800 MB | 0.75 <= alpha<= 0.82 417 ------------------------------------------------------------------ 418 UGC | 10^8 | Object: ~10 MB | Zipf, alpha >= 2 419 ------------------------------------------------------------------ 420 VoD | 10^4 | Object: ~100 MB | Zipf, 0.65 <= alpha <= 1 421 (+HLS) | | ~1 kB (*) | 422 (+DASH) | | ~5.6 kB (*) | 423 ================================================================== 425 UGC = User Generated Content VoD = Video on Demand 427 (*) Using adaptive video streaming (e.g., HLS and DASH), with an 428 optimal segment length (2 s for DASh and 10 s for HLS) and a bitrate 429 of 4500 kbps [W16][Led12] 431 2.3. Choosing Relevant Metrics 433 Quantification of network performance requires a set of standard 434 metrics. These metrics should be broad enough so they can be applied 435 equally to host-centric and information-centric (or other) networks. 436 This will allow reasoning about a certain ICN approach in relation to 437 an earlier version of the same approach, to another ICN approach or 438 to the incumbent host-centric approach. It will therefore be less 439 difficult to gauge optimization and research direction. On the other 440 hand, the metrics should be targeted to network performance only and 441 should avoid unnecessary expansion into the physical and application 442 layers. Similarly, at this point, it is more important to capture as 443 metrics only the main figures of merit and to leave more esoteric and 444 less frequent cases for the future. 446 To arrive at a set of relevant metrics, it would be beneficial to 447 look at the metrics used in existing ICN approaches, such as CCN 448 [CCN] [VoCCN] [NDNP], NetInf [4WARD6.1] [4WARD6.3] [SAIL-B2] [SAIL- 449 B3], PURSUIT [PRST4.5], COMET [CMT-D5.2] [CMT-D6.2], Connect [SHARE] 450 [RealCCN], and CONVERGENCE [ICN-Web] [ICN-Scal] [ICN-Tran]. The 451 metrics used in these approaches fall into two categories: metrics 452 for the approach as a whole, and metrics for individual components 453 (name resolution, routing, and so on). Metrics for the entire 454 approach are further subdivided into traffic and system metrics. It 455 is important to note that the various approaches do not name or 456 define metrics consistently. This is a major problem when trying to 457 find metrics that allow comparison between approaches. For the 458 purposes of exposition, we have tried to smooth over differences by 459 classifying similarly defined metrics under the same name. Also, due 460 to space constraints, we have chosen to report here only the most 461 common metrics between approaches. For more details the reader 462 should consult the references for each approach. 464 Traffic metrics in existing ICN approaches are summarized in Table 465 IV. These are metrics for evaluating an approach mainly from the 466 perspective of the end user, i.e., the consumer, provider, or owner 467 of the content or service. Depending on the level where these 468 metrics are measured, we have made the distinction into user, 469 application and network-level traffic metrics. So for example, 470 network-level metrics are mostly focused on packet characteristics, 471 whereas user-level metrics can cover elements of human perception. 472 The approaches do not make this distinction explicitly, but we can 473 see from the table that CCN and NetInf have used metrics from all 474 levels, PURSUIT and COMET have focused on lower-level metrics, and 475 Connect and CONVERGENCE opted for higher-level metrics. Throughput 476 and download time seem to be the most popular metrics altogether. 478 Table IV. Traffic metrics used in ICN evaluations 480 User | Application | Network 481 ====================================================== 482 Download | Goodput | Startup | Throughput | Packet 483 time | | latency | | delay 484 ================================================================== 485 CCN | x | x | | x | x 486 ------------------------------------------------------------------ 487 NetInf | x | | x | x | x 488 ------------------------------------------------------------------ 489 PURSUIT | | | x | x | x 490 ------------------------------------------------------------------ 491 COMET | | | x | x | 492 ------------------------------------------------------------------ 493 Connect | x | | | | 494 ------------------------------------------------------------------ 495 CONVERGENCE | x | x | | | 496 ================================================================== 497 While traffic metrics are more important for the end user, the owner 498 or operator of the networking infrastructure is normally more 499 interested in system metrics, which can reveal the efficiency of an 500 approach. The most common system metrics used are: protocol overhead, 501 total traffic, transit traffic, cost savings, router cost, and router 502 energy consumption. 504 Besides the traffic and systems metrics that aim to evaluate an 505 approach as a whole, all surveyed approaches also evaluate the 506 performance of individual components. Name resolution, request/data 507 routing, and data caching are the most typical components, as 508 summarized in Table V. FIB size and path length, i.e., the routing 509 component metrics, are almost ubiquitous among approaches, perhaps 510 due to the networking background of the involved researchers. That 511 might be also the reason for the sometimes decreased focus on traffic 512 and system metrics, in favor of component metrics. It can certainly 513 be argued that traffic and system metrics are affected by component 514 metrics, however no approach has made the relationship clear. With 515 this in mind and taking into account that traffic and system metrics 516 are readily useful to end users and network operators, we will 517 restrict ourselves to those in the following sections. 519 Table V. Component metrics in existing ICN approaches 521 Resolution | Routing | Cache 522 ====================================================== 523 Resolution | Request | FIB | Path | Size | Hit 524 time | rate | size | length | | ratio 525 ================================================================== 526 CCN | x | | x | x | x | x 527 ------------------------------------------------------------------ 528 NetInf | x | x | | x | | x 529 ------------------------------------------------------------------ 530 PURSUIT | | | x | x | | 531 ------------------------------------------------------------------ 532 COMET | x | x | x | x | | x 533 ------------------------------------------------------------------ 534 CONVERGENCE | | x | x | | x | 535 ================================================================== 537 Before proceeding, we should note that we would like our metrics to 538 be applicable to host-centric networks as well. Standard metrics 539 already exist for IP networks and it would certainly be beneficial to 540 take them into account. It is encouraging that many of the metrics 541 used by existing ICN approaches can also be used on IP networks and 542 that all of the approaches have tried on occasion to draw the 543 parallels. 545 2.3.1. Traffic Metrics 547 The IETF has been working for more than a decade on devising metrics 548 and methods for measuring the performance of IP networks. The work 549 has been carried out largely within the IP performance metrics (IPPM) 550 working group, guided by a relevant framework [RFC2330]. IPPM 551 metrics include delay, delay variation, loss, reordering, and 552 duplication. While the IPPM work is certainly based on packet- 553 switched IP networks, it is conceivable that it can be modified and 554 extended to cover ICN networks as well. However, more study is 555 necessary to turn this claim into a certainty. Many experts have 556 toiled for a long time on devising and refining the IPPM metrics and 557 methods, so it would be an advantage to use them for measuring ICN 558 performance. In addition, said metrics and methods work already for 559 host-centric networks, so comparison with information-centric 560 networks would entail only the ICN extension of the IPPM framework. 561 Finally, an important benefit of measuring the transport performance 562 of a network at its output, using QoS metrics such as IPPM, is that 563 it can be done mostly without any dependence to applications. 565 Another option for measuring transport performance would be to use 566 Quality of Service (QoS) metrics, not at the output of the network 567 like with IPPM, but at the input to the application. For live video 568 streaming application the relevant metrics would be startup latency, 569 playout lag and playout continuity. The benefit of this approach is 570 that it abstracts away all details of the underlying transport 571 network, so it can be readily applied to compare between networks of 572 different concepts (host-centric, information-centric, or other). As 573 implied earlier, the drawback of the approach is its dependence on 574 the application, so it is likely that different types of applications 575 will require different metrics. It might be possible to identify 576 standard metrics for each type of application, but the situation is 577 not as clear as with IPPM metrics and further investigation is 578 necessary. 580 At a higher level of abstraction, we could measure the network's 581 transport performance at the application output. This entails 582 measuring the quality of the transported and reconstructed 583 information as perceived by the user during consumption. In such an 584 instance we would use Quality of Experience (QoE) metrics, which are 585 by definition dependent on the application. For example, the 586 standardized methods for obtaining a Mean Opinion Score (MOS) for 587 VoIP (e.g., ITU-T P.800) is quite different from those for IPTV 588 (e.g., PEVQ). These methods are notoriously hard to implement, as 589 they involve real users in a controlled environment. Such 590 constraints can be relaxed or dropped by using methods that model 591 human perception under certain environments, but these methods are 592 typically intrusive. The most important drawback of measuring 593 network performance at the output of the application is that only one 594 part of each measurement is related to network performance. The rest 595 is related to application performance, e.g., video coding, or even 596 device capabilities, both of which are irrelevant to our purposes 597 here and are generally hard to separate. We therefore see the use of 598 QoE metrics in measuring ICN performance as a poor choice at this 599 stage. 601 2.3.2. System Metrics 603 Overall system metrics that need to be considered include 604 reliability, scalability, energy efficiency, and delay/disconnection 605 tolerance. In deployments where ICN is addressing specific 606 scenarios, relevant system metrics could be derived from current 607 experience. For example, in IoT scenarios, which were discussed 608 earlier in [RFC7476], it is reasonable to consider the current 609 generation of sensor nodes, sources of information, and even 610 measurement gateways (e.g., for smart metering at homes) or 611 smartphones. In this case, ICN operation ought to be evaluated with 612 respect not only to overall scalability and network efficiency, but 613 also the impact on the nodes themselves. Karnouskos et al. 614 [SensReqs] provide a comprehensive set of sensor and IoT-related 615 requirements, for example, which include aspects such as resource 616 utilization, service life-cycle management and device management. 618 Additionally, various specific metrics are also critical in 619 constrained environments, such as processing requirements, signaling 620 overhead, and memory allocation for caching procedures in addition to 621 power consumption and battery lifetime. For gateways, which 622 typically act as a point of service to a large number of nodes and 623 have to satisfy the information requests from remote entities we need 624 to consider scalability-related metrics, such as frequency and 625 processing of successfully satisfied information requests. 627 Finally, given the in-network caching functionality of ICNs, 628 efficiency and performance metrics of in-network caching have to be 629 defined. Such metrics will need to guide researchers and operators 630 regarding the performance of in-network caching algorithms. A first 631 step on this direction has been made in [L9]. The paper proposes a 632 formula that approximates the proportion of time that a content stays 633 in a network cache. The model takes as input the rate of requests 634 for a given content (the Content of Interest) and the rate of 635 requests for all other contents that go through the given network 636 element (router) and move the CoI down in the (LRU) cache. The 637 formula takes also into account the size of the cache of this router. 639 The output of the model essentially reflects the probability that the 640 CoI will be found in a given cache. An initial study [L9] is applied 641 to the CCN/NDN framework, where contents get cached at every node 642 they traverse. The formula according to which the probability or 643 proportion is calculated is given by: 645 pi = [mu/(mu+lambda)]^N, 647 where lambda is the request rate for CoI, mu is the request rate for 648 contents that move CoI down the cache and N is the size of the cache 649 (in slots). 651 The formula can be used to assess the caching performance of the 652 system and can also potentially be used to identify the gain of the 653 system due to caching. This can then be used to compare against gains 654 by other factors, e.g., addition of extra bandwidth in the network. 656 2.4. Resource Equivalence and Tradeoffs 658 As we have seen above, every ICN network is built from a set of 659 resources, which include link capacities, different types of memory 660 structures and repositories used for storing named data objects and 661 chunks temporarily (i.e., caching) or persistently, as well as name 662 resolution and other lookup services. Complexity and processing 663 needs in terms of forwarding decisions, management (e.g., need for 664 manual configuration, explicit garbage collection, and so on), and 665 routing (i.e., amount of state needed, need for manual configuration 666 of routing tables, support for mobility, etc.) set the stage for a 667 range of engineering tradeoffs. 669 In order to be able to compare different ICN approaches it would be 670 beneficial to be able to define equivalence in terms of different 671 resources which today are considered incomparable. For example, 672 would provisioning an additional 5 Mb/s link capacity lead to better 673 performance than adding 100 GB of in-network storage? Within this 674 context one would consider resource equivalence (and the associated 675 tradeoffs) for example for cache hit ratios per GB of cache, 676 forwarding decision times, CPU cycles per forwarding decision, and so 677 on. 679 3. ICN Security Aspects 681 The introduction of an information-centric networking architecture 682 and the corresponding communication paradigm results in changes to 683 many aspects of network security. These will affect all scenarios 684 described in [RFC7476]. Additional evaluation will be required to 685 ensure relevant security requirements are appropriately met by the 686 implementation of the chosen architecture in the various scenarios. 688 The ICN security aspects described in this document is complementing 689 the ICN security challenges outlined in the "ICN Research Challenges" 690 document [ICNCHA]. [***EDITORS NOTE: The referenced document is 691 expected to have become an RFC by the time this document is 692 published, this reference should thus be updated before publication 693 of this document.***] 695 The ICN architectures currently proposed have concentrated on 696 authentication of delivered content to ensure the integrity of the 697 content. However the approaches are primarily applicable to freely 698 accessible content that does not require access authorization, 699 although they will generally support delivery of encrypted content. 701 The introduction of widespread caching mechanisms may also provide 702 additional attack surfaces. The caching architecture to be used also 703 needs to be evaluated to ensure that it meets the requirements of the 704 usage scenarios. 706 In practice, the work on security in the various ICN research 707 projects has been heavily concentrated on authentication of content. 708 Work on authorization, access control, privacy and security threats 709 due to the expanded role of in-network caches has been quite limited. 710 For Example, a roadmap for improving the security model in NetInf can 711 be found in [NETINFSC]. As secure communications on the Internet are 712 becoming the norm, major gaps in ICN security aspects are bound to 713 undermine the adoption of ICN. 715 In the rest of this section we briefly consider the issues and 716 provide pointers to the work that has been done on the security 717 aspects of the architectures proposed. 719 3.1. Authentication 721 For fully secure content distribution, content access requires that 722 the receiver needs to be able to reliably assess: 724 validity: is it a complete, uncorrupted copy of what was 725 originally published; 727 provenance: can the receiver identify the publisher, and, if so, 728 whether it and the source of any cached version of the 729 document can be adequately trusted; and 731 relevance: is the content an answer to the question that the 732 receiver asked. 734 All ICN architectures considered in this document primarily target 735 the validity requirement using strong cryptographic means to tie the 736 content request name to the content. Provenance and relevance are 737 directly targeted to varying extents: There is a tussle or trade-off 738 between simplicity and efficiency of access and level of assurance of 739 all these traits. For example, maintaining provenance information 740 can become extremely costly, particularly when considering (historic) 741 relationships between multiple objects. Architectural decisions have 742 therefore been taken in each case as to whether the assessment is 743 carried out by the information-centric network or left to the 744 application. 746 An additional consideration for authentication is whether a name 747 should be irrevocably and immutably tied to a static piece of 748 preexisting content or whether the name can be used to refer to 749 dynamically or subsequently generated content. Schemes that only 750 target immutable content can be less resource hungry as they can use 751 digest functions rather than public key cryptography for generating 752 and checking signatures. However, this can increase the load on 753 applications because they are required to manage many names, rather 754 than using a single name for an item of evolving content that changes 755 over time (e.g., a piece of data containing an age reference). 757 DONA (Data Oriented Network Architecture) [DONA] and CCN [CCN] 758 [SECCONT] integrate most of the data needed to verify provenance into 759 all content retrievals but need to be able to retrieve additional 760 information (typically a security certificate) in order to complete 761 the provenance authentication. Whether the application has any 762 control of this extra retrieval will depend on the implementation. 763 CCN is explicitly designed to handle dynamic content allowing names 764 to be pre-allocated and attached to subsequently generated content. 765 DONA offers variants for dynamic and immutable content. 767 PURSUIT [PSTSEC] appears to allow implementers to choose the 768 authentication mechanism so that it can, in theory, emulate the 769 authentication strategy of any of the other architectures. It is not 770 clear whether different choices would lead to lack of 771 interoperability. 773 NetInf uses the Named Information (ni) URI scheme [RFC6920] to 774 identify content. This allows NetInf to assure validity without any 775 additional information but gives no assurance on provenance or 776 relevance. A "search" request allows an application to identify 777 relevant content and applications may choose to structure content to 778 allow provenance assurance but this will typically require additional 779 network access. NetInf validity authentication is consequently 780 efficient in a network environment with intermittent connectivity as 781 it does not force additional network accesses and allows the 782 application to decide on provenance validation if required. For 783 dynamic content NetInf can use e.g. signed manifests. For more 784 details on NetInf security see [SCNETINF]. 786 3.2. Authorization, Access Control and Logging 788 A potentially major concern for all ICN architectures considered here 789 is that they do not provide any inbuilt support for an authorization 790 framework or for logging. Once content has been published and cached 791 in servers, routers or end points not controlled by the publisher, 792 the publisher has no way to enforce access control, determine which 793 users have accessed the content or revoke its publication. In fact, 794 in some cases, it is even difficult for the publishers themselves to 795 perform access control, where requests do not necessarily contain 796 host/user identifier information. 798 Access could be limited by encrypting the content but the necessity 799 of distributing keys out-of-band appears to negate the advantages of 800 in-network caching. This also creates significant challenges when 801 attempting to manage and restrict key access. An authorization 802 delegation scheme has been proposed [ACDICN]. This scheme allows 803 semi-trusted entities (such as caches, CDN nodes) to delegate access 804 control decisions to 3rd party access control providers that are 805 trusted by the content publisher. The former entities have no access 806 to subscriber related information and should respect the decisions of 807 the access control providers. 809 A recent proposal for an extra layer in the protocol stack [LIRA] 810 gives control of the name resolution infrastructure to the publisher. 811 This enables access logging as well some degree of active cache 812 management, e.g., purging of stale content. 814 One possible technique that could allow for providing access control 815 to heterogeneous groups and still allow for a single encrypted object 816 representation that remains cacheable is Attribute Based Encryption 817 (ABE). A first proposal for this is presented in [ABE]. To support 818 heterogeneous group and avoid having a single authority that has a 819 master key multi authority ABE can be used [LEWKO]. 821 Evaluating the impact of the absence of these features will be 822 essential for any scenario where an ICN architecture might be 823 deployed. It may have a seriously negative impact on the 824 applicability of ICN in commercial environments unless a solution can 825 be found. 827 3.3. Privacy 828 Another area where the architectures have not been significantly 829 analyzed is privacy. Caching implies a trade-off between network 830 efficiency and privacy. The activity of users is significantly more 831 exposed to the scrutiny of cache owners with whom they may not have 832 any relationship. However it should be noted that it is only the 833 first hop router/cache that can see who request what, this as 834 requests are aggregated and only the previous hop router is visible 835 when a request is forwarded. 837 Although in many ICN architectures the source of a request is not 838 explicitly identified, an attacker may be able to obtain considerable 839 information if s/he can monitor transactions on the cache and obtain 840 details of the objects accessed, the topological direction of 841 requests and information about the timing of transactions. The 842 persistence of data in the cache can make life easier for an attacker 843 by giving a longer timescale for analysis. 845 The impact of CCN on privacy has been investigated in [CCNSEC] and 846 the analysis is applicable to all ICN architectures because it is 847 mostly focused on the common caching aspect. The privacy risks of 848 named data networking are also highlighted in [CCNPRIV]. Further 849 work on privacy in ICNs can be found in [CONPRV]. Finally, Fotiou et 850 al. define an ICN privacy evaluation framework in [PRIFRA]. 852 3.4. Changes to the Network Security Threat Model 854 The architectural differences of the various ICN models as compared 855 to TCP/IP have consequences for network security. There is limited 856 consideration of the threat models and potential mitigation in the 857 various documents describing the architectures. [CCNSEC] and [CONPRV] 858 also consider the changed threat model. Some of the key aspects are: 860 o Caching implies a tradeoff between network efficiency and user 861 privacy as discussed in Section 4.3. 863 o More powerful routers upgraded to handle persistent caching 864 increase the network's attack surface. This is particularly the 865 case in systems that may need to perform cryptographic checks on 866 content that is being cached. For example, not doing this could 867 lead routers to disseminate invalid content. 869 o ICNs makes it difficult to identify the origin of a request as 870 mentioned in Section 4.3 slowing down the process of blocking 871 requests and requiring alternative mechanisms to differentiate 872 legitimate requests from inappropriate ones as access control 873 lists (ACLs) will probably be of little value for ICN requests. 875 o Denial-of-service (DoS) attacks may require more effort on ICN 876 than on TCP/IP but they are still feasible. One reason for this 877 is that it is difficult for the attacker to force repeated 878 requests for the same content onto a single node; ICNs naturally 879 spread content so that after the initial few requests, subsequent 880 requests will generally be satisfied by alternative sources, 881 blunting the impact of a DoS attack. That said, there are many 882 ways around this, e.g., generating random suffix identifiers that 883 always result in cache misses. 885 o Per-request state in routers can be abused for DoS attacks. 887 o Caches can be misused in the following ways: 889 + Attackers can use caches as storage to make their own content 890 available. 892 + The efficiency of caches can be decreased by attackers with the 893 goal of DoS attacks. 895 + Content can be extracted by any attacker connected to the 896 cache, putting users' privacy at risk. 898 Appropriate mitigation of these threats will need to be considered in 899 each scenario. 901 4. Evaluation Tools 903 Since ICN is an emerging area, the community is in the process of 904 developing effective evaluation environments, including releasing 905 open-source implementations, simulators, emulators, and testbeds. To 906 date, none of the available evaluation tools can be seen as the one 907 and only community reference evaluation tool. Furthermore, no single 908 environment supports all well-known ICN approaches, as we describe 909 below, hindering the direct comparison of the results obtained for 910 different ICN approaches. The rest of this subsection reviews the 911 publicly available ICN implementations, simulators and experimental 912 facilities currently available to the community. 914 An updated version of the information in this section will be 915 maintained at the ICNRG Wiki page: 916 https://trac.tools.ietf.org/group/irtf/trac/wiki/IcnEvaluationAndTestbeds 918 4.1. Open-source Implementations 920 The Named Data Networking (NDN) project has open-sourced a software 921 reference implementation of the architecture and protocol called NDN 922 (http://http://named-data.net). NDN is available for deployment on 923 various operating systems and includes C and Java libraries that can 924 be used to build applications. 926 CCN-lite (http://www.ccn-lite.net) is a lightweight implementation of 927 the CCN protocol that supports most of the key features of CCNx and 928 is interoperable with CCNx. CCN-lite implements the core CCN logic 929 in about 1000 lines of code, so it is ideal for classroom work and 930 course projects as well as for quickly experimenting with CCN 931 extensions. For example, Baccelli et al. use CCN-lite on top of the 932 RIOT operating system to conduct experiments over an IoT (Internet of 933 Things) testbed [NDNIOT]. 935 PARC is offering CCN source code under various licensing schemes, 936 please see http://www.ccnx.org for details. 938 The PURSUIT project (http://www.fp7-pursuit.eu) has open-sourced its 939 Blackhawk publish-subscribe (Pub/Sub) implementation for Linux and 940 Android; more details are available at https://github.com/fp7- 941 pursuit/blackadder. Blackadder uses the Click modular router for 942 ease of development. The code distribution features a set of tools, 943 test applications and scripts. The POINT project (http://www.point- 944 h2020.eu/) is currently maintaining Blackadder. 946 The 4WARD and SAIL projects have open-sourced software that 947 implements different aspects of NetInf, e.g., NetInf URI format, HTTP 948 and UDP convergence layer, using different programming languages. 949 The Java implementation provides a local caching proxy and client. 950 Further, an OpenNetInf prototype is available as well as a hybrid 951 host-centric and information-centric network architecture called the 952 Global Information Network (GIN), a browser plug-in and video 953 streaming software. See http://www.netinf.org/open-source for more 954 details. 956 4.2. Simulators and Emulators 958 Simulators and emulators should be able to capture faithfully all 959 features and operations of the respective ICN architecture(s) and any 960 limitations should be openly documented. It is essential that these 961 tools and environments come with adequate logging facilities so that 962 one can use them for in-depth analysis as well as debugging. 963 Additional requirements include the ability to support medium- to 964 large-scale experiments, the ability to quickly and correctly set 965 various configurations and parameters, as well as to support the 966 playback of traffic traces captured on a real testbed or network. 967 Obviously, this does not even begin to touch upon the need for strong 968 validation of any evaluated implementations. 970 4.2.1. ndnSIM 972 The Named Data Networking (NDN) project (http://named-data.net/) has 973 developed ndnSIM [ndnSIM][ndnSIM2]; this is a module that can be 974 plugged into the ns-3 simulator (https://www.nsnam.org/) and supports 975 the core features of NDN. One can use ndnSIM to experiment with 976 various NDN applications and services as well as components developed 977 for NDN such as routing protocols, caching and forwarding strategies 978 among others. The code for ns-3 and ndnSIM is openly available to 979 the community and can be used as the basis for implementing ICN 980 protocols or applications. For more details see 981 http://ndnsim.net/2.0/. 983 4.2.2. ccnSIM 985 ccnSim [ccnSim] is CCN-specific simulator that was specially designed 986 to handle forwarding of a large number of CCN-chunks 987 (http://www.infres.enst.fr/~drossi/index.php?n=Software.ccnSim). 988 ccnSim is written in C++ for the OMNeT++ simulation framework 989 (https://omnetpp.org/). Other CCN-specific simulators include CCN 990 Packet Level Simulator [CCNPL] and CCN-Joker [CCNj]. CCN-Joker 991 emulates in user-space all basic aspects of a CCN node (e.g., 992 handling of Interest and Data packets, cache sizing, replacement 993 policies), including both flow and congestion control. The code is 994 open source and is suitable for both emulation-based analyses and 995 real experiments. Finally, Cabral et al. [MiniCCNx] use container- 996 based emulation and resource isolation techniques to develop a 997 prototyping and emulation tool. 999 4.2.3. Icarus simulator 1001 The Icarus simulator focuses on caching in ICN and is agnostic with 1002 respect to any particular ICN implementation. The simulator is 1003 implemented in Python, uses the Fast Network Simulator Setup tool 1004 [FNSS], and is available at http://icarus-sim.github.io/. Icarus has 1005 several caching strategies implemented, including among others 1006 ProbCache [PROBCACH], node-centrality-based caching [CL4M] and hash- 1007 route-based caching [HASHROUT]. 1009 ProbCache [PROBCACH] is taking a resource management view on caching 1010 decisions and approximates the available cache capacity along the 1011 path from source to destination. Based on this approximation and in 1012 order to reduce caching redundancy across the path, it caches content 1013 probabilistically. According to [CL4M] the node with the highest 1014 betweenness centrality along the path from source to destination is 1015 responsible for caching incoming content. Finally, [HASHROUT] 1016 calculates the hash-function of a content's name and assigns contents 1017 to caches of a domain according to that. The hash-space is split 1018 according to the number of caches of the network. Then upon 1019 subsequent requests, and based again on the hash of the name included 1020 in the request, edge routers redirect requests to the cache assigned 1021 with the corresponding hash-space. [HASHROUT] is an off-path caching 1022 strategy, in contrast to [PROBCACH] and [CL4M], which however, 1023 requires minimum co-ordination and redirection overhead. In its 1024 latest update, Icarus also includes implementation of the "Satisfied 1025 Interest Table" (SIT) [SIT]. The SIT table is pointing towards the 1026 direction where content has been sent recently. Among other benefits, 1027 this enables information resilience in case of network fragmentation 1028 (i.e., content can still be found in neighbour caches or in users' 1029 devices) and inherently supports user-assisted caching (i.e., P2P- 1030 like content distribution). 1032 The simulator is constantly being updated and more strategies are 1033 added in each update. Tortelli et al. [ICNSIMS] provide a comparison 1034 of ndnSIM, ccnSim, and Icarus. 1036 4.3. Experimental Facilities 1038 An important consideration in the evaluation of any kind of future 1039 Internet mechanism lies in the characteristics of that evaluation 1040 itself. Central to the assessment of the features provided by a novel 1041 mechanism, lies the consideration of how it improves over already 1042 existing technologies, and by "how much." With the disruptive nature 1043 of clean-slate approaches generating new and different technological 1044 requirements, it is complex to provide meaningful results for a 1045 network layer framework, in comparison with what is deployed in the 1046 current Internet. Thus, despite the availability of ICN 1047 implementations and simulators, the need for large-scale environments 1048 supporting experimental evaluation of novel research is of prime 1049 importance to the advancement of ICN deployment. 1051 Different experimental facilities have different characteristics and 1052 capabilities, e.g. low cost of use, reproducible configuration, easy- 1053 to-use tools, sharable, available background traffic. 1055 4.3.1. Open Network Lab [ONL] 1057 An example of an experimental facility that supports CCN is the Open 1058 Network Lab [ONL] that currently comprises 18 extensible gigabit 1059 routers and over a 100 computers representing clients and is freely 1060 available to the public for running CCN experiments. Nodes in ONL 1061 are preloaded with CCNx software. ONL provides a graphical user 1062 interface for easy configuration and testbed setup as per the 1063 experiment requirements, and also serves as a control mechanism, 1064 allowing access to various control variables and traffic counters. 1066 Further, it is also possible to run and evaluate CCN over popular 1067 testbeds [PLANET] [EMULAB] [DETERLAB] [OFELIA] by directly running, 1068 for example, the CCNx open-source code [CCNOFELI] [ICNGRID] [CCNPL] 1069 [CCNOSN]. Also, the Network Experimentation Programming Interface 1070 [NEPI] is a tool developed for controlling and managing large-scale 1071 network experiments. NEPI can be used to control and manage large- 1072 scale CCNx experiments e.g., on PlanetLab [NEPIICN]. 1074 4.3.2. POINT testbed 1076 The POINT project is maintaining a testbed with 40 machines across 1077 Europe, North America (MIT) and Japan (NICT) interconnected in a 1078 topology containing one Topology Manager and one Rendezvous node that 1079 handle all publish/subscribe and topology formation requests [IEICE]. 1080 All machines run Blackadder. New nodes can join and experiments can 1081 be run on request. 1083 4.3.3. CUTEi: Container-based ICN testbed 1085 NICT has also developed a testbed used for ICN experiments [AFI] 1086 comprising multiple servers located in Asia and other locations. 1087 Each testbed server (or VM) utilizes a Linux kernel-based container 1088 (LXC) for node virtualization. This testbed enables users to run 1089 applications and protocols for ICN in two experimentation modes using 1090 two different container designs: 1092 1. application-level experimentation using a "common container" and 1094 2. network-level experimentation using a "user container." 1096 A common container is shared by all testbed users, and a user 1097 container is assigned to one testbed user. A common container has a 1098 global IP address to connect with other containers or external 1099 networks, whereas each user container uses a private IP address and a 1100 user space providing a closed networking environment. A user can 1101 login to his/her user containers using SSH with his/her certificate, 1102 or access them from PCs connected to the Internet using SSH 1103 tunnelling. 1105 This testbed also implements an "on-filesystem cache" to allocate 1106 caching data on a UNIX filesystem. The on-filesystem cache system 1107 accommodates two kinds of caches: "individual cache" and "shared 1108 cache." Individual cache is accessible for one dedicated router for 1109 the individual user, while shared cache is accessible for a set of 1110 routers in the same group to avoid duplicated caching in the 1111 neighborhood for cooperative caching. 1113 5. Security Considerations 1115 This document does not impact the security of the Internet. 1117 6. IANA Considerations 1119 This document presents no IANA considerations. 1121 7. Acknowledgments 1123 Konstantinos Katsaros contributed the updated text of Section 2.2 1124 along with an extensive set of references. 1126 Priya Mahadevan, Daniel Corujo and Gareth Tyson contributed to an 1127 earlier version of this document. 1129 This document has benefited from reviews, pointers to the growing ICN 1130 literature, suggestions, comments and proposed text provided by the 1131 following members of the IRTF Information-Centric Networking Research 1132 Group (ICNRG), listed in alphabetical order: Marica Amadeo, Hitoshi 1133 Asaeda, E. Baccelli, Claudia Campolo, Christian Esteve Rothenberg, 1134 Suyong Eum, Nikos Fotiou, Dorothy Gellert, Luigi Alfredo Grieco, 1135 Myeong-Wuk Jang, Ren Jing, Will Liu, Antonella Molinaro, Luca 1136 Muscariello, Ioannis Psaras, Dario Rossi, Stefano Salsano, Damien 1137 Saucez, Dirk Trossen, Jianping Wang, Yuanzhe Xuan, and Xinwen Zhang. 1139 The IRSG review was provided by Aaron Falk. 1141 8. Informative References 1143 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1144 "Framework for IP Performance Metrics", RFC 2330, May 1145 1998. 1147 [RFC5743] Falk, A., "Definition of an Internet Research Task Force 1148 (IRTF) Document Stream", RFC 5743, December 2009. 1150 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1151 Keranen, A., and P. Hallam-Baker, "Naming Things with 1152 Hashes", RFC 6920, April 2013. 1154 [RFC7476] Pentikousis, K., Ohlman, B., Corujo, D., Boggia, G., 1155 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1156 "Information-Centric Networking: Baseline Scenarios ", RFC 1157 7476, March 2015. 1159 [ICNCHA] Internet draft, "ICN Research Challenges" draft-irtf- 1160 icnrg-challenges-04, [***EDITORS NOTE: This reference is 1161 expected to have become an RFC by the time this document 1162 is published, this reference should thus be updated before 1163 publication of this document.***] 1165 [ndnSIM] Afanasyev, A. et al., "ndnSIM: NDN simulator for NS-3", 1166 NDN Technical Report NDN-0005, Revision 2, October 2012. 1168 [ndnSIM2] Mastorakis, S. et al., "ndnSIM 2.0: A new version of the 1169 NDN simulator for NS-3", NDN Technical Report NDN-0028, 1170 Revision 1, January 2015. 1172 [ccnSim] Rossini, G. and D. Rossi, "Large scale simulation of CCN 1173 networks", Proc. Algotel 2012 , La Grande Motte, France, 1174 May 2012. 1176 [CCNPL] Muscariello, L., "Content centric networking packet level 1177 simulator", available online at 1178 http://perso.rd.francetelecom.fr/muscariello/sim.html 1180 [CCNj] Cianci, I. et al. "CCN - Java Opensource Kit EmulatoR for 1181 Wireless Ad Hoc Networks", Proc. 7th ACM Int. Conf. on 1182 Future Internet Technologies, Seoul, Korea, Sept., 2012. 1184 [IEICE] G. Parisis, D. Trossen, and H. Asaeda, "A Node Design and 1185 a Framework for Development and Experimentation for an 1186 Information-Centric Network", IEICE Trans. Commun., vol. 1187 E96-B, no. 7, pp.1650-1660, July 2013. 1189 [PROBCACH] I. Psaras, W. Chai, G. Pavlou, "Probabilistic In-Network 1190 Caching for Information-Centric Networks", Proc. SIGCOMM 1191 ICN Workshop. ACM, 2012. 1193 [CL4M] Chai, W. K. et al., "Cache 'Less for More' in Information- 1194 centric Networks", Proc. Networking. IFIP, 2012. 1196 [SIT] Vasilis Sourlas, Leandros Tassiulas, Ioannis Psaras and 1197 George Pavlou, "Information Resilience through User- 1198 Assisted Caching in Disruptive Content-Centric Networks" 1199 14th IFIP NETWORKING, Toulouse, France, May 2015. 1201 [HASHROUT] L. Saino, I. Psaras, G. Pavlou, "Hash-routing Schemes for 1202 Information-Centric Networking", Proc. SIGCOMM ICN 1203 Workshop. ACM, 2013. 1205 [ICARUS] L. Saino, I. Psaras, G. Pavlou, "Icarus: a Caching 1206 Simulator for Information Centric Networking (ICN)", Proc. 1207 SIMUTOOLS. ICST, 2014. 1209 [FNSS] L. Saino, C. Cocora and G. Pavlou, "A Toolchain for 1210 Simplifying Network Simulation Setup", Proc. SIMUTOOLS. 1211 ACM, 2013. 1213 [BA] Barabasi, A. and R. Albert, "Emergence of scaling in 1214 random networks", Science, vol. 286, no. 5439, pp. 509- 1215 512, 1999. 1217 [WATTS] Watts, D. J. and S. H. Strogatz, "Collective dynamics of 1218 small-world networks", Nature, vol. 393, no. 6684, pp. 40- 1219 "10, 1998. 1221 [Montage] Hussain, A. and J. Chen, "Montage Topology Manager: Tools 1222 for Constructing and Sharing Representative Internet 1223 Topologies", DETER Technical Report, ISI-TR-684, Aug. 1224 2012. 1226 [DELAY] Kaune, S. et al., "Modelling the Internet Delay Space 1227 Based on Geographical Locations", Proc. Euromicro, Weimar, 1228 Germany, 2009. 1230 [IMB2014] C. Imbrenda, L. Muscariello, and D. Rossi,"Analyzing 1231 Cacheable Traffic in ISP Access Networks for Micro CDN 1232 Applications via Content-Centric Networking," In Proc. of 1233 ACM ICN, 2014. 1235 [L1] http://googleblog.blogspot.it/2008/07/we-knew-web-was- 1236 big.html 1238 [L2] Zhang, C., Dhungel, P., and K. Di Wu., "Unraveling the 1239 BitTorrent ecosystem", IEEE Transactions on Parallel and 1240 Distributed Systems, pp. 1164-1177, 2010. 1242 [L3] Cha, M., Kwak, H., Rodriguez, P., Ahn, Y.-Y., and S. Moon, 1243 "I tube, you tube, everybody tubes: analyzing the world's 1244 largest user generated content video system", Proc. ACM 1245 SIGCOMM conference on Internet measurement (IMC), San 1246 Diego (CA), USA, Oct. 2007. 1248 [L4] Zhou, J., Li, Y., Adhikari, K., and Z.-L. Zhang, 1249 "Counting YouTube videos via random prefix sampling", In 1250 Proc. of IMC'11, Berlin, Germany, Nov. 2011. 1252 [L5] Fricker, C., Robert, P., Roberts, J. and N. Sbihim, 1253 "Impact of traffic mix on caching performance in a 1254 content-centric network", In Proc. of IEEE NOMEN 2012, 1255 Workshop on Emerging Design Choices in Name-Oriented 1256 Networking, Orlando, USA, Mar. 2012. 1258 [L6] Yu, H., Zheng, D., Zhao, B. Y. and W. Zheng, 1259 "Understanding user behavior in large-scale video-on- 1260 demand systems", In SIGOPS Oper. Syst. Rev., Vol. 40, pp. 1261 333-344, April 2006. 1263 [L7] Marciniak, P., Liogkas, N., Legout, A. and E. Kohler, 1264 "Small is not always beautiful", In Proc. of IPTPS, 1265 International Workshop of Peer-to-Peer Systems, Tampa Bay, 1266 Florida (FL), USA, Feb. 2008. 1268 [L8] Bellissimo, A., Levine, B. and P. Shenoy, "Exploring the 1269 use of BitTorrent as the basis for a large trace 1270 repository", University of Massachusetts, Tech. Rep., 1271 2004. 1273 [L9] Psaras, I. et al., "Modelling and Evaluation of CCN- 1274 Caching Trees", In Proc. of the 10th international IFIP 1275 conference on Networking, Valencia, Spain, May 2011. 1277 [L10] Carofiglio, G., Gallo, M., Muscariello, L., and D. Perino, 1278 "Modeling Data Transfer in Content-Centric Networking", In 1279 Proc. of ITC, San Francisco, USA, Sep. 2011. 1281 [L11] Breslau, L., Cao, P., Fan, L., Phillips, G. and S. 1282 Shenker, "Web caching and zipf-like distributions: 1283 evidence and implications", In Proc. of INFOCOM '99, New 1284 York (NY), USA, Mar. 1999. 1286 [L12] Mahanti, A., Williamson, C., and D. Eager., "Traffic 1287 analysis of a web proxy caching hierarchy", IEEE Network, 1288 Vol.14, No.3, pp.16-23, May/June 2000. 1290 [P2PMod] Saleh, O., and M. Hefeeda, "Modeling and caching of peer- 1291 to-peer traffic", Proc. ICNP. IEEE, 2006. 1293 [W16] C. Westphal, Ed., "Adaptive Video Streaming over ICN", 1294 ICNRG Internet Draft. 1296 [Led12] S. Lederer, C. Muller, and C. Timmerer, "Dynamic adaptive 1297 streaming over HTTP dataset", in Proceedings of the ACM 1298 Multimedia Systems Conference 2012, 2012, pp. 89-94. 1300 [CCN] Jacobson, V. et al., "Networking Named Content", Proc. 1302 CoNEXT. ACM, 2009. 1304 [VoCCN] Jacobson, V. et al., "VoCCN: Voice-over Content-Centric 1305 Networks", Proc. CoNEXT Re-Arch Workshop. ACM, 2009. 1307 [NDNP] Zhang, L. et al., "Named Data Networking (NDN) Project", 1308 NDN Technical Report NDN-0001, Oct. 2010. Available: 1309 http://named-data.net/publications/techreports/ 1311 [4WARD6.1] Ohlman, B. et al., "First NetInf Architecture 1312 Description", 4WARD Project Deliverable D-6.1, Apr. 2009. 1314 [4WARD6.3] Ahlgren, B. et al., "NetInf Evaluation", 4WARD Project 1315 Deliverable D-6.3, June 2010. 1317 [SAIL-B2] SAIL, "NetInf Content Delivery and Operations", SAIL 1318 Project Deliverable D-B.2, May. 2012. 1320 [SAIL-B3] Kutscher, D. (ed.) et al., "Final NetInf Architecture", 1321 SAIL Project Deliverable D-B.3 , Jan. 2013. Available: 1322 http://www.sail-project.eu/deliverables/ 1324 [PRST4.5] Riihijarvi, J. et al., "Final Architecture Validation and 1325 Performance Evaluation Report", PURSUIT Project 1326 Deliverable D4.5, Jan. 2013. 1328 [CMT-D5.2] B ben, A. et al, "Scalability of COMET System", COMET 1329 Project Deliverable D5.2, Feb. 2013. 1331 [CMT-D6.2] Georgiades, M. et al., "Prototype Experimentation and 1332 Demonstration", COMET Project Deliverable D6.2, Feb. 2013. 1334 [SHARE] Muscariello, L. et al., "Bandwidth and storage sharing 1335 performance in information centric networking", Proc. 1336 SIGCOMM ICN Workshop. ACM, 2011. 1338 [RealCCN] Perino, D. et al., "A Reality Check for Content Centric 1339 Networking", Proc. SIGCOMM ICN Workshop. ACM, 2011. 1341 [ICN-Web] Detti, A. et al., "Supporting the Web with an Information 1342 Centric Network that Routes by Name", Elsevier Computer 1343 Networks, vol. 56, no. 17, Nov. 2012. 1345 [ICN-Scal] Blefari Melazzi, N. et al., "Scalability Measurements in 1346 an Information-Centric Network", Springer Lecture Notes in 1347 Computer Science (LNCS), vol. 7586, 2012. 1349 [ICN-Tran] Salsano, S. et al., "Transport-Layer Issues in Information 1350 Centric Networks ", Proc. SIGCOMM ICN Workshop. ACM, 2012. 1352 [SensReqs] Karnouskos, S. et al., "Requirement considerations for 1353 ubiquitous integration of cooperating objects", Proc. 1354 NTMS. IFIP, 2011. 1356 [NETINFSC] Renault, E, Ahmad, A., and M. Abid, "Towards a Security 1357 Model for the Future Network of Information", Proc. Conf. 1358 Ubiquitous Information Technologies and Applications, 1359 IEEE, 2009. 1361 [DONA] Koponen, T. et al., "A Data-Oriented (and Beyond) Network 1362 Architecture", Proc. SIGCOMM. ACM, 2007. 1364 [SECCONT] Smetters, D., and V. Jacobson, "Securing network content", 1365 Technical Report TR-2009-01, PARC, 2009. 1367 [PSTSEC] Tagger, B., et al, "Update on the Architecture and Report 1368 on Security Analysis", Deliverable 2.4, PURSUIT EU FP7 1369 project, April 2012. 1371 [ABE] Mihaela Ion, Jianqing Zhang, and Eve M. Schooler. 2013. 1372 Toward content-centric privacy in ICN: attribute-based 1373 encryption and routing. In Proceedings of the ACM SIGCOMM 1374 2013 conference on SIGCOMM (SIGCOMM '13). ACM, New York, 1375 NY, USA, 513-514. DOI=10.1145/2486001.2491717 1376 http://doi.acm.org/10.1145/2486001.2491717 1378 [LEWKO] Lewko, A., Waters, B.: Decentralizing attribute-based 1379 encryption. In: Proc. of EUROCRYPT 11, LNCS, vol. 6632, 1380 pp. 568-588 (2011). 1382 [SCNETINF] C. Dannewitz, J. Golic, B. Ohlman, B. Ahlgren, "Secure 1383 Naming for A Network of Information," Proc. 13th IEEE 1384 Global Internet Symp. 2010, San Diego, CA, Mar. 2010. 1386 [ACDICN] Fotiou, N. et al., "Access control enforcement delegation 1387 for information-centric networking architectures", Proc. 1388 SIGCOMM ICN Workshop. ACM, 2012. 1390 [CCNSEC] Lauinger, T., "Security and Scalability of Content-Centric 1391 Networking", Masters Thesis, Technische Universitaet 1392 Darmstadt and Eurecom, Sep. 2010. 1394 [CCNPRIV] Lauinger, Y., et al, "Privacy Risks in Named Data 1395 Networking: What is the Cost of Performance?", ACM SIGCOMM 1396 Computer Communication Review Editorial Note, vol. 42, 1397 iss. 5, 2012 1399 [CONPRV] Chaabane, A et al, "Privacy in Content-Oriented 1400 Networking: Threats and Countermeasures", arXiv:1211.5183, 1401 2012. 1403 [1] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, 1404 and F. Jahanian. 2010. Internet inter-domain traffic. In 1405 Proceedings of the ACM SIGCOMM 2010 conference (SIGCOMM 1406 '10). ACM, New York, NY, USA, 75-86. 1407 DOI=10.1145/1851182.1851194, 1408 http://doi.acm.org/10.1145/1851182.1851194 1410 [2] G. Maier, A. Feldmann, V. Paxson, and M. Allman. 2009. On 1411 dominant characteristics of residential broadband internet 1412 traffic. In Proceedings of the 9th ACM SIGCOMM conference 1413 on Internet measurement conference (IMC '09). ACM, New 1414 York, NY, USA, 90-102. DOI=10.1145/1644893.1644904 1415 http://doi.acm.org/10.1145/1644893.1644904 1417 [3] L. Breslau, P. Cao, L. Fan, G. Phillips, and S. Shenker, 1418 "Web Caching and Zipf-like Distributions: Evidence and 1419 Implications," in IEEE INFOCOM, 1999, pp. 126-134. 1421 [4] A. Mahanti, C. Williamson, and D. Eager, "Traffic analysis 1422 of a web proxy caching hierarchy," IEEE Network, vol. 14, 1423 no. 3, pp. 16 -23, 2000. 1425 [5] M. Busari and C. Williamson, "ProWGen: a synthetic 1426 workload generation tool for simulation evaluation of web 1427 proxy caches," Computer Networks, vol. 38, no. 6, pp. 779- 1428 794, 2002. 1430 [6] M. F. Arlitt and C. L. Williamson, "Internet web servers: 1431 workload characterization and performance implications," 1432 IEEE/ACM Transactions on Networking, vol. 5, pp. 631-645, 1433 1997. 1435 [7] P. Barford and M. Crovella, "Generating representative web 1436 workloads for network and server performance evaluation," 1437 in ACM SIGMETRICS/PERFORMANCE, 1998, pp. 151-160. 1439 [8] P. Barford, A. Bestavros, A. Bradley, and M. Crovella, 1440 "Changes in web client access patterns: Characteristics 1441 and caching implications," World Wide Web, vol. 2, pp. 15- 1442 28, 1999. 1444 [9] M. Hefeeda and O. Saleh, "Traffic Modeling and 1445 Proportional Partial Caching for Peer-to-Peer Systems," 1446 IEEE/ACM Transactions on Net- working, vol. 16, no. 6, pp. 1448 1447-1460, 2008. 1450 [10] L. Guo, S. Chen, Z. Xiao, E. Tan, X. Ding, and X. Zhang, 1451 "A performance study of BitTorrent-like peer-to-peer 1452 systems," IEEE Journal on Selected Areas in Communication, 1453 vol. 25, no. 1, pp. 155-169, 2007. 1455 [11] A. Bellissimo, B. N. Levine, and P. Shenoy, "Exploring the 1456 use of BitTorrent as the basis for a large trace 1457 repository," University of Massachusetts Amherst, Tech. 1458 Rep., 2004. 1460 [12] X. Cheng, C. Dale, and J. Liu, "Statistics and social 1461 network of YouTube videos," in IEEE IWQoS. IEEE, 2008, pp. 1462 229-238. 1464 [13] X. Cheng, C. Dale, and J. Liu, "Understanding the 1465 Characteristics of Internet Short Video Sharing: YouTube 1466 as a Case Study," CoRR, vol. abs/0707.3670, 2007. 1468 [14] K. V. Katsaros, G. Xylomenos, and G. C. Polyzos, 1469 "GlobeTraff: a traffic workload generator for the 1470 performance evaluation of future Internet architectures," 1471 Proc. IEEE/IFIP NTMS, 2012. 1473 [MiniCCNx] C. Cabral, et al., "High fidelity content-centric 1474 experiments with Mini-CCNx", Proc. ISCC. IEEE, 2014. 1476 [ICNSIMS] M. Tortelli, et al., "CCN Simulators: Analysis and Cross- 1477 Comparison", Proc. SIGCOMM ICN. ACM, 2014. 1479 [AFI] H. Asaeda, R. Li, and N. Choi, "Container-Based Unified 1480 Testbed for Information-Centric Networking," IEEE Network, 1481 vol. 28, no. 6, pp. 60-66, 2014. 1483 [NDNIOT] E. Baccelli, et al., "Information Centric Networking in 1484 the IoT: Experiments with NDN in the Wild," Proc. SIGCOMM 1485 ICN. ACM, 2014. 1487 [ONL] J. DeHart, et al., "The open network laboratory: a 1488 resource for networking research and education", ACM 1489 SIGCOMM CCR, vol. 35, no. 5, pp. 75-78, 2005. 1491 [PLANET] B. Chun, et al., "Planetlab: an overlay testbed for broad- 1492 coverage services", ACM SIGCOMM CCR, vol. 33, no. 3, pp. 1493 3-12, 2003. 1495 [EMULAB] E. Eide, et. al., "An Experimentation Workbench for 1496 Replayable Networking Research", Proc. NSDI. USENIX, 2007. 1498 [DETERLAB] T. Benzel, "The Science of Cyber-Security Experimentation: 1499 The DETER Project", Proc. Annual Computer Security 1500 Applications Conference (ACSAC), Dec. 2011. 1502 [OFELIA] M. Sune, et al., "Design and implementation of the OFELIA 1503 FP7 facility: The European OpenFlow testbedDesign and 1504 implementation of the OFELIA FP7 facility: The European 1505 OpenFlow testbed", Computer Networks, vol. 61, pp. 132- 1506 150, March 2014. 1508 [NEPI] A. Quereilhac, et al., "NEPI: An integration framework for 1509 Network Experimentation", Proc. SoftCOM. IEEE, 2011. 1511 [NEPIICN] A. Quereilhac, et al., "Demonstrating a unified ICN 1512 development and evaluation framework", Proc. SIGCOMM ICN. 1513 ACM, 2014. 1515 [CCNOFELI] S. Salsano, et al., "Information Centric Networking over 1516 SDN and OpenFlow: Architectural Aspects and Experiments on 1517 the OFELIA Testbed", Computer Networks, vol. 57, no. 16, 1518 pp. 3207-3221, November 2013. 1520 [ICNGRID] G. Carofiglio, et al., "Optimal multipath congestion 1521 control and request forwarding in Information-Centric 1522 Networks", Proc. ICNP. IEEE, 2013. 1524 [CCNPL] S. Awiphan, et al., "Video streaming over content centric 1525 networking: Experimental studies on PlanetLab", Proc. 1526 ComComAp. IEEE, 2013 1528 [CCNOSN] C. Bernardini, et al., "Socially-aware caching strategy 1529 for content centric networking", Proc. Networking. IFIP, 1530 2014. 1532 [PRIFRA] N. Fotiou, et al. "A framework for privacy analysis of ICN 1533 architectures", Proc. APF. Springer, 2014. 1535 [ICNScale] K. V. Katsaros, et al., "On the Inter-domain Scalability 1536 of Route-by-Name Information-Centric Network 1537 Architectures", Proc. Networking. IFIP, 2015. 1539 [COMPLEX] X. Dimitropoulos, et al., "Graph annotations in modeling 1540 complex network topologies", ACM Trans. Model. Comput. 1541 Simul., vol. 19, no. 4, Nov. 2009. 1543 [LIRA] I. Psaras, K. Katsaros, L. Saino, and G. Pavlou, "Lira: A 1544 location independent routing layer based on source- 1545 provided ephemeral names," Electronic and Electrical Eng. 1546 Dept., UCL, London, UK, Tech. Rep. 2014. [Online]. 1547 Available: http://www.ee.ucl.ac.uk/comit- 1548 project/publications.html 1550 Authors' Addresses 1552 Kostas Pentikousis (editor) 1553 EICT GmbH 1554 Torgauer Strasse 12-15 1555 10829 Berlin 1556 Germany 1558 Email: k.pentikousis@eict.de 1560 Borje Ohlman 1561 Ericsson Research 1562 S-16480 Stockholm 1563 Sweden 1565 Email: Borje.Ohlman@ericsson.com 1567 Elwyn Davies 1568 Trinity College Dublin/Folly Consulting Ltd 1569 Dublin, 2 1570 Ireland 1572 Email: davieseb@scss.tcd.ie 1574 Spiros Spirou 1575 Intracom Telecom 1576 19.7 km Markopoulou Avenue 1577 19002 Peania, Athens 1578 Greece 1580 Email: spis@intracom-telecom.com 1582 Gennaro Boggia 1583 Dep. of Electrical and Information Engineering 1584 Politecnico di Bari 1585 Via Orabona 4 1586 70125 Bari 1587 Italy 1589 Email: g.boggia@poliba.it