idnits 2.17.1 draft-corujo-icn-mgmt-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2014) is 3579 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'NDN-VOIP' is defined on line 738, but no explicit reference was found in the text == Unused Reference: 'NDNFlexManager' is defined on line 743, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 761, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 765, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG D. Corujo 3 Internet-Draft Instituto de Telecomunicacoes 4 Intended status: Informational K. Pentikousis 5 Expires: January 2, 2015 EICT 6 I. Vidal 7 J. Garcia-Reinoso 8 UC3M 9 S. Lederer 10 Alpen-Adria Universitat Klagenfurt 11 S. Spirou 12 Intracom Telecom 13 C. Westphal 14 Huawei 15 July 1, 2014 17 ICN Management Considerations 18 draft-corujo-icn-mgmt-05 20 Abstract 22 ICN has been proposing and evaluating novel ways for reaching on-line 23 content in upcoming Future Internet environments, leveraging 24 intrinsic capabilities such as naming, caching and built-in security. 25 In order to fully realize the capabilities and vision provided by 26 ICN, supportive management procedures need to be ensured, providing 27 the architectures, and the elements that figure in them, with the 28 means to facilitate the delivery of content and the operation of the 29 network. In the current Internet, these management aspects have been 30 being developed and enhanced in parallel to the existing data 31 protocol and mechanisms, resulting in a plethora of different and 32 hard-to-integrate approaches, but still fulfil indispensable roles 33 and actions for the operation and well-being of the network. We 34 consider that the availability of management mechanisms for ICN will 35 foster deployment and, as such, should be tackled still in the design 36 and experimentation phases. In this way, this document addresses and 37 identifies ICN management considerations, under two different 38 settings: a) achieving management operations using ICN-based 39 mechanisms and, b) how to manage ICN procedures themselves. The 40 ultimate goal is to provide the necessary breadth to establish 41 management mechanisms deployment guidelines in a common way 42 throughout the existing ICN ecosystem of architectures. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on January 2, 2015. 61 Copyright Notice 63 Copyright (c) 2014 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. ICN Management Approaches . . . . . . . . . . . . . . . . . . 4 80 2.1. ICN-assisted Management . . . . . . . . . . . . . . . . . 4 81 2.1.1. Video Adaptation . . . . . . . . . . . . . . . . . . 4 82 2.1.1.1. Adaptive Delivery of Multimedia Content in ICN . 4 83 2.1.2. Content Management . . . . . . . . . . . . . . . . . 5 84 2.1.3. Network Policies . . . . . . . . . . . . . . . . . . 7 85 2.1.3.1. NetInf Management Considerations . . . . . . . . 7 86 2.1.4. Resource Management . . . . . . . . . . . . . . . . . 8 87 2.2. Management for ICN Aspects . . . . . . . . . . . . . . . 10 88 2.2.1. Caching . . . . . . . . . . . . . . . . . . . . . . . 10 89 2.2.2. Information Freshness . . . . . . . . . . . . . . . . 11 90 2.3. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 11 91 2.3.1. Face Management . . . . . . . . . . . . . . . . . . . 11 92 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 93 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 95 6. Informative References . . . . . . . . . . . . . . . . . . . 14 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 98 1. Introduction 100 Information-centric networking (ICN) enables new ideas for naming and 101 addressing, privacy, security, and trust, and should also lead us to 102 think new ways for deploying, operating and managing networks in the 103 future. By default, users, programs, information objects and hosts 104 are in general untrustworthy and mobile in an information-centric 105 network. This means that many of the assumptions in traditional 106 network management, including all aspects of FCAPS (Fault, 107 Configuration, Accounting, Performance, and Security) need to be 108 rethought. However, despite the different instantiations of ICN 109 architectures, and the plethora of novel research work built on top 110 of them, little attention has been paid to management aspects so far. 111 This includes both enabling "traditional" network management 112 operations (which work well from small networks to large 113 infrastructure networks), and supporting and optimizing intrinsic 114 procedures of the ICN fabric. 116 This document aims to draw the attention of ICNRG to the importance 117 of network management for real-world deployments. Today, network 118 management is practically an add-on to host-centric deployments. We 119 can do better as we move forward in ICN research considering the full 120 range of deployments from home-office environments to challenged 121 networks to tier-1 networks. To this end, we draft some first 122 management considerations that, on the one hand, capitalize on ICN 123 concepts for defining management procedures and, on the other, 124 explore the possibilities for defining a common management framework 125 irrespective of the ICN approach taken. We reckon that the later is 126 a much more formidable task and we are looking forward to tackling it 127 together with other members of ICNRG. 129 We argue that addressing management at an early stage is not only 130 important for real-world adoption and the successful future 131 deployment of ICN, but also to deal with scenarios where management 132 can simplify, enhance or optimize ICN network utilization and 133 performance. The subject becomes particularly challenging, as 134 disparate characteristics from different ICN approaches (e.g., in 135 terms of namespace, granularity, routing, and so on) impact the 136 definition and design of these management mechanisms. This document 137 analyses ICN Management under three different perspectives. Firstly, 138 in Section 2 it will provide considerations regarding the usage of 139 ICN mechanisms for realizing management procedures. Secondly, in 140 Section 2.2 will look into how the intrinsic procedures used for 141 operating the ICN architecture can be managed. Finally, in 142 Section 2.3 we will look in a combined way to the former two issues 143 and identify the role of ICN when it's own procedures will be used to 144 manage ICN operations. 146 We plan to incrementally develop the draft, incorporating 147 considerations on other ICN aspects as well as different approaches 148 (e.g., [PURSUIT] and [NetInf]) as well as address other pertinent 149 aspects as we receive feedback from the research group members. 151 2. ICN Management Approaches 153 In this part of the document, ICN management approaches will be 154 addressed in respect to how ICN mechanisms can be used to realize 155 management procedures, how to manage the specific ICN mechanisms 156 themselves and hybrid approaches where the ICN mechanisms themselves 157 are used to realize the management of ICN aspects. 159 2.1. ICN-assisted Management 161 This section addresses how the ICN operational mechanisms can be used 162 to realize different kinds of network managament procedures. 164 2.1.1. Video Adaptation 166 This section investigates ICN management considerations for the 167 delivery of video data, and especially the adaptive delivery of 168 video. From a content perspective, multimedia is omnipresent in the 169 Internet, e.g., producing 62% of the total Internet traffic in North 170 America's fixed access networks [GIPR2013]. 172 Video, and multimedia content in general, is has specific 173 characteristics, which have to be considered and where network 174 management consideration are necessary. The consumption of 175 multimedia content comes along with timing requirements for the 176 delivery of the content, for both, live and on-demand consumption. 177 Long startup delays, buffering periods or poor quality, etc. should 178 be avoided to achieve a good Quality of Experience of the consumer of 179 the content. Of course, these requirements are heavily influenced by 180 routing decision and caching, which are central parts of ICN, and 181 which may be leveraged more efficiently by an intelligent network 182 management. 184 2.1.1.1. Adaptive Delivery of Multimedia Content in ICN 186 Today's dominant streaming systems are based on the common approach 187 of leveraging HTTP-based Internet infrastructures, which are 188 consequently based on the Transmission Control Protocol (TCP) and the 189 Internet Protocol (IP). Especially the adaptive multimedia streaming 190 (AMS) via HTTP is gaining more and more momentum and resulted in the 191 standardization of MPEG-DASH [MPEG-DASH], which stands for Dynamic 192 Adaptive Streaming over HTTP. The basic idea of AHS is to split up 193 the media file into segments of equal length, which can be encoded at 194 different resolutions, bitrates, etc. The segments are stored on 195 conventional HTTP Web server and can be accessed through HTTP GET 196 requests from the client. Due to this, the streaming system is pull 197 based and the entire streaming logic is on the client side. This 198 means that the client fully controls the bitrate of the streaming 199 media on a per-segment basis, which has several advantages, e.g., the 200 client knows its bandwidth requirements and capabilities best. As 201 one can see, ICN and adaptive multimedia streaming have several 202 elements in common, such as the client-initiated pull approach, the 203 content being dealt with in pieces as well as the support of 204 efficient replication and distribution of content pieces within the 205 network. As ICN is a promising candidate for the Future Internet 206 (FI) architecture, it is useful to investigate its suitability in 207 combination with AMS systems and standards like MPEG-DASH as shown in 208 [AdaptCCN][InterAdaptCCN], as well as the possibilities and benefits 209 of intelligent network management to improve the performance of AMS 210 in ICN as well as the resulting QoE at the client. 212 One of the most promising aspects in this context is the possibility 213 of ICN to consume content from different origin nodes as well as over 214 different network links in parallel, which can be seen as an 215 intrinsic error resilience feature w.r.t. the network. This is a 216 useful feature of ICN for adaptive multimedia streaming within mobile 217 environments since most mobile devices are equipped with multiple 218 network links. Here, a focus of ICN management could be in the load 219 balancing of such traffic between the available links. This would 220 increase the effective media throughput of the multimedia content, 221 however, it could potentially lead to high variations of the 222 resulting bandwidth which is available to the client. As DASH is 223 designed for environments with dynamic bandwidth conditions, they can 224 be compensated in general. However, more conservative adaptation 225 algorithms may prevent too frequent switching between the content's 226 bitrate representations as well as compensate short-term bandwidth 227 drops caused by network link switches more smoothly. 229 2.1.2. Content Management 231 An ICN network aims to facilitate access to, and delivery of, 232 information objects (content and services). Content (in particular, 233 video) access and delivery seems to be the dominant use case in 234 traditional, host-based networks, so ICN networking is forced to 235 adopt content delivery as a minimum requirement. Indeed, virtually 236 all ICN approaches so far target at least content delivery. 238 From the perspective of a content owner or provider, an ICN network 239 functions essentially as a content delivery network. This creates a 240 set of requirements for ICN. First of all, end-users and content 241 providers alike should be able to Read (consume) a content object 242 available on the ICN network. In addition, content providers need 243 the ability to Create (publish), Update, and Delete content. 244 Finally, Accounting (logging) is necessary to support business models 245 that typically require charging, analytics, and monitoring. 247 The Read operation has received the lion's share in ICN research. 248 This is expected as content access and delivery is at the heart of 249 ICN. Given a request for a named content object, the ICN network 250 resolves that name to an object replica and proceeds with delivery to 251 the end-user. Of course, different ICN approaches employ different 252 mechanisms to achieve the Read operation. For example, name 253 resolution can be done with a hierarchical system resembling DNS, 254 with DHTs, or with flooding. Similarly, content delivery can be done 255 over normal best-effort paths from the origin server, over 256 dynamically computed provisioned paths, or from caches close to the 257 end-user. Some approaches can even cater to mobile end-users and 258 content hosts. ICN should be able to handle frequent Reads as well 259 as Read spikes (flash crowds). In fact, it seems crucial for ICN's 260 deployment chances to at least match the capabilities of incumbent 261 content delivery systems. 263 ICN research has not addressed Create as much as Read, but some 264 effort has been expanded on mechanisms for publishing content. Much 265 of this effort has focused on content naming schemes that enable 266 global uniqueness of names and hence allow global addressing of the 267 content objects. It has been difficult to balance human readability 268 of names, efficiency in machine processing, and name aggregation 269 (that can realistically enable request routing by name). Although a 270 fully automated mechanism for (human-readable) name assignment would 271 be desirable, so far it seems that a manual process, similar to that 272 of domain name registration in DNS, is necessary to allocate at least 273 namespaces. No other restrictions on naming have been seriously 274 considered. The consensus seems to be that with ICN anyone should be 275 able to publish anything. Content semantics are a higher layer 276 issue. This might be a prudent approach when building a transport 277 layer technology, but it could undermine the potential of ICN 278 deployment. A content owner would not want copies of its content 279 published on an ICN network under different names. In any case, once 280 a name has been assigned, the Create operation is mainly about 281 creating an entry in the name resolution system. This is obviously a 282 security risk and furthermore, for highly distributed name resolution 283 systems, it can suffer from considerable lag in availability. 284 Fortunately, Create is a rare operation compared to Read. 286 Update is an operation that seeks to alter an already created object. 287 A content provider would want to modify the data or the metadata of a 288 published object either to rectify publication errors or to augment 289 the object. It is debatable whether the provider should address the 290 later simply by creating a new object. Another use case for Update 291 comes from the need to rebrand or alias an object when its rights 292 have been sold to another party. Nevertheless, the Update operation 293 has received minimal attention in ICN research. The main problem is 294 one of consistency: once an update has been committed, an ICN network 295 with highly distributed name resolution and content delivery 296 (caching) would host both the old and new versions of the updated 297 content object for some time. Security concerns for the Update and 298 Create operations are similar. Update is normally rarer than Create, 299 but this will not be the case for collaborative media. 301 Content providers may occasionally need to remove a published object. 302 This is the goal of the Delete operation. An object might be deleted 303 when it was published by mistake, because it's no longer useful or 304 relevant, or because it's illegal. Consistency is a major challenge 305 for the Delete operation as well. The high degree of distribution in 306 ICN can sustain a network state where some data or metadata replicas 307 of an object have been deleted, while others persist. On the other 308 hand, this lag can be beneficial if deletion was initiated 309 erroneously or maliciously. Like with the Update operation, Delete 310 has not been properly investigated in ICN research. Deletes are 311 typically less often than updates. 313 From the point of view of content providers and end users, an ICN 314 network resembles a content directory and repository, with Create, 315 Read, Update, and Delete as typical operations. As with any database 316 system, the reliability of those operations (or transactions) depends 317 on the properties of atomicity, consistency, isolation, and 318 durability. The challenge for ICN research is to build systems at a 319 massive scale that employ those properties. 321 2.1.3. Network Policies 323 Currently this section addresses Network Policies under the scope of 324 NetInf. In future instantiations of this document, a more generic 325 approach will be provided, besides highlighting specific ICN 326 instantiations contributions. 328 2.1.3.1. NetInf Management Considerations 330 Early-phase work in NetInf management [NetInfSelfX] discussed a two- 331 fold problem. The first question that arises is whether it is 332 possible by adopting a new set of network primitives and in-network 333 storage to usher a new type of network management. In other words, 334 can network management become information-centric while handling 335 often host-centric data? The second question is whether an 336 information-centric network is more suitable for self-management 337 mechanisms than IP-based networks are. In particular with respect to 338 the later, [NetInfSelfX] introduced some design considerations for 339 adding self-management mechanisms in NetInf. 341 Of interest from this early work are two examples where network 342 management can play a new role. First, network management can get 343 involved in decisions about caching and (re)distribution of content, 344 and not only whether an (inter)face is on or off, or what traffic 345 limits should be enforced. Moreover, network policies can be 346 distributed securely in the same way as other content in the network, 347 removing the need for centralized management, and enabling improved 348 recovery procedures. Second, network management can get involved in 349 more intricate processes such as controlling multiaccess support, 350 intermediating for content adaptation when deemed appropriate, and 351 enabling richer tools for traffic engineering. 353 2.1.4. Resource Management 355 While caching has been the focus of much of the attention in ICN, one 356 of the key advantages of the ICN architecture is that it allows a 357 fine grained allocation of content to resources. This has been 358 observed in [CB-TE] and [ICN-TE] for instance. Unlike IP, an ICN 359 packet carries specific, explicit information about the content it 360 carries. Further, this content is uniquely named, and different 361 versions of the content will have different names. 363 ICN enables a shift in how to manage resources: instead of allocating 364 open-ended flows to network resource, it allows to allocate well 365 defined objects. This requires new network management tools beyond 366 the current mechanisms which are specifically dedicated to ICN. 367 NetFlow or the current TE mechanism do not take advantage of the ICN 368 semantics, and of the benefits associated with these semantics. 370 In IP, a flow from a certain source address to a certain destination 371 address can correspond to myriad potential applications: web traffic, 372 video streaming, VoIP call all may use the same port 80 and be hosted 373 by same servers. Therefore, providing appropriate resource to such a 374 flow is a matter of guessing. The simple problem of identifying when 375 a flow terminates is made unnecessarily complex in ICN: a timer is 376 set-up, and when no packets match the flow filter, then the flow is 377 over. Of course, multiple packets from different applications may 378 match the same filter, and flows with different characteristics in 379 terms of inter-arrival times could be broken down into multiple flows 380 with an improper choice of time-out values. 382 In ICN, there is a unique mapping of the name to the content of the 383 data stream going through the network. If a content object is 384 requested, then it has well defined semantics, and the network 385 management layer can identify exactly when the data stream starts and 386 ends based upon these semantics. Further, a content management layer 387 can also learn the properties of the stream associated with a given 388 identifier. [CB-TE] presented such a mechanism to learn the 389 properties associated with a name, either by counting the bytes on 390 the wire corresponding to this name, or by reading the footprint of 391 the content with this name when stored in a cache. It is therefore 392 possible for the management layer to gather meta-data pertaining to 393 the content that goes through the network, and to use this meta-data 394 to make proper resource allocations. 396 Of course, the resource manager should only acquire meta-data about 397 content that is likely to be seen again (i.e., popular) or specific 398 in any way (for instance, the name of an elephant flow). This 399 considerably simplifies the task as the data of interest is 400 concentrated on a few items. One potential usage of this meta-data 401 is to keep track of what content is going through which link. In 402 this scenario, each link keeps an aggregate tally of the amount of 403 data that has been assigned to this link and subtracts the amount 404 that has gone through. The resulting backlog can be then used to 405 allocate new data streams to this or another link. 407 In [ICN-TE], it was shown that such a policy would significantly 408 reduce the time spent in the network by content streams when 409 considering a WAN topology and its corresponding end-to-end traffic 410 matrix. The network load would stay the same when comparing with a 411 min-MLU policy, but by splitting elephant flows across different 412 paths, the completion time would be reduced. In the simulations of 413 [ICN-TE], min-MLU is roughly 50% slower than a content-based policy. 415 This is an encouraging result and a step towards a management 416 framework that assigns resource to content in a deterministic and 417 fine-grained manner, unlike the probabilistic allocation of IP. The 418 ICNRG should consider such a management framework, and evaluate the 419 different proposals in light of this opportunity. For instance, an 420 ICN architecture such as [PURSUIT] contains a natural mechanism to 421 perform such allocation of content to paths as it assigns a source 422 route to the content. On the other hand, an ICN architecture such as 423 [NDN] needs to be expanded as the link allocation semantics are, in 424 the current proposal, tied to the content resolution process: the 425 interest homes into the content, and lays the reverse path for the 426 content delivery at the same time. This semantics make the 427 management for multiple link selection more difficult, as multiple 428 interests would have to be sent over multiple links to provide path 429 diversity. However, it could be an area of study for the ICNRG as 430 solving such resource management problem would provide significant 431 benefits to ICN architectures. 433 2.2. Management for ICN Aspects 435 This section will address management aspects for intrinsic ICN 436 procedures. 438 2.2.1. Caching 440 Caching is a hot topic research nowadays in ICN. The challenges of 441 caching in ICN are different than those of web caching, mainly 442 because the former has to deal with high line rates and with a huge 443 amount of content. Some ICN works propose to cache content in all 444 ICN routers traversed by the data packet, in an LCE (Leave Copy 445 Everywhere) fashion as in [NDN]. Some studies, like [L4M-ICN], have 446 shown that other cache decision policies, focused to reduce the cache 447 redundancy, may increase the overall caching performance. Some of 448 these decision policies only use the local information available at 449 the ICN routers, but others use the information available at other 450 nodes to cache or not the incoming content. This is known as 451 explicit cache coordination decision, and there are several proposals 452 around this concept [ICN-CACHING]. The idea behind the explicit 453 coordination is to exchange topological information, individual 454 cache's state and content popularity view among a set of ICN routers, 455 in order to coordinate caching decisions. 457 ICN may benefit of in-network caching, which consists of introducing 458 content stores in ICN routers. The benefits are twofold: (1) 459 improving the end-user experience by reducing the delay to retrieve 460 content, and (2) reducing the overall aggregated bandwidth per 461 request. On the other hand, caching in ICN presents several 462 challenges like (1) centralized vs distributed management of the 463 caches, (2) cache scalability, reducing the impact of the size of the 464 total content catalog, (3) routing based on cache contents, (4) 465 considering the different requirements imposed by different types of 466 traffic (web/multimedia/IoT/etc.), etc. Most of these challenges can 467 be solved, or at least minimized, by introducing management 468 considerations in ICN proposals. 470 This way, a given ICN router may forward a request towards another 471 router storing the requested content. In this context, the routing 472 protocol is affected by the cache's state of surrounding neighbours. 473 For example, in [CATT] the authors propose to distinguish between the 474 source(s) and routers' caches that hold a copy of that content: the 475 former paths are globally advertised, while the latter are only 476 advertised within the router's neighbourhood. In all these cases, 477 the use of a management framework may bring significant advantages, 478 providing standard interfaces that allow the routers to dynamically 479 manage their caches. 481 2.2.2. Information Freshness 483 One of the prime contributions of ICN-based designs, is the ability 484 for the networking entities in charge of exercising the routing of 485 the content, to actually store it, allowing it to serve content 486 requests in a more readily fashion. However, there are scenarios 487 where such facilities can raise issues, such as Internet of Things 488 and Machinte-to-Machine scenarios. Concretely, despite the caching 489 capabilities of ICN contributing for, as an example, reducing the 490 amount of networking stack fabric to be implemented in low-powered 491 nodes and sensors, it can cause that the information consumed from 492 caches is not up-to-date comparing to the information currently 493 existing at the source. As an example, consider an accelerometer 494 sensor which is providing the acceleration value of a car, and 495 disseminates it via a ICN network towards different uses. When a 496 consumer (e.g., a road traffic monitoring infrastructure) wishes to 497 know the current speed of the car by requesting its name, it can be 498 served by a stale content residing in a cache between the consumer 499 and the information source. 501 These kinds of situations demand facilities and mechanisms to avoid 502 the provision of stale content. For example, [ICN-FRESHNESS] 503 considers the realization of an agreement mechanism, using ICN 504 messaging exchanges, where both the source and the consumer agree on 505 the minimal content freshness values for the information. 506 Concretely, when the network entity determines that it has the 507 content referring to a received name request, it will also evaluate 508 the freshness value. If it is lower than the one previously agreed, 509 it will then discard the content and rather forward the content 510 request back to the source. 512 2.3. Hybrid Approaches 514 This section will analyse how ICN procedures can be used to manage 515 ICN operations. 517 2.3.1. Face Management 519 The Named Data Networking [NDN] ICN architecture provides a new 520 communication framework built on named data. Like other ICN 521 counterparts, such as [NetInf], [PURSUIT] and [DONA], NDN 522 intrinsically supports security, routing/forwarding, reliability, 523 caching and even mobility, aiming at scalable and more efficient 524 content-distribution than today's IP-based approaches. Fostered by 525 an open-source implementation [CCNx], NDN has been at the heart of an 526 active topic with several research contributions evaluating its 527 deployment feasibility and performance in a number of scenarios 528 [ICN-Scenarios]. 530 NDN introduces the concept of a Strategy Layer, which can control 531 Interest packet forwarding behavior. It basically determines which 532 is the best interface (or set of interfaces) to send an Interest 533 packet. The "strategy" component establishes a pre-configured 534 algorithm for tackling Interest packet decisions, ranging from 535 sending it sequentially on each interface until a Data packet is 536 received, to evaluating which interfaces provide better performance 537 (i.e., lower average RTT) in retrieving certain content (as discussed 538 in [NDN]). 540 It is important to keep in mind that NDN replaces the commonly used 541 term "interface" with the term "face", since packets can be forwarded 542 over hardware network interfaces as well as between application 543 interfaces, further acknowledging the information dissemination 544 capabilities of ICN. This aspect is considered in [NDN] and [NDN-R], 545 where programs can be associated to the NDN governing structures 546 (like the FIB), defining configurations such as "sendToAll" and 547 "sendToBest" with respect to managing the content reaching process. 548 Corujo et al. [NDN-MGMT] exploit these concepts enabling management 549 mechanisms to be deployed, and steer network operations and NDN 550 operation, as described in the following section. 552 An important aspect supporting network management procedures is the 553 interaction of network information residing at the network side with 554 information about the network from the perspective of clients 555 connected to it. The former includes, for instance, information 556 stored in the network operator core about user profiles, associated 557 policies, or data collected by the access network equipment, such as 558 current and past traffic load levels, active flows, and maintenance 559 information. Today, such information can be retrieved for management 560 and operation support through dedicated signaling protocols (e.g., 561 [RFC1157], [RFC6733]), or Operation Support Services (OSS) web 562 services. The client point of view of the network includes 563 information that, for example, a wireless terminal can provide, 564 indicating wireless link quality, average return-trip times (RTT) or 565 perceived Quality of Experience (QoE). 567 Both types of information can be capitalized upon allowing, for 568 example, the network to coordinate network management procedures, 569 considering as input information obtained from other network elements 570 as well as from user nodes. One way to generate management 571 information in network entities and at client nodes, as well as to 572 consume and act upon it (i.e., using the management information 573 exchange as a control channel) is to couple NDN nodes with Management 574 Agent (MA) entities. 576 Fig. 1 (redrawn here from [NDN-MGMT] for convenience) illustrates how 577 a MA can be deployed in both network and client entities, interfacing 578 with different operational aspects and protocol layers of an NDN 579 node. By using NDN content reaching and disseminating mechanisms, 580 management information can be consumed by the MA to steer not only 581 the behavior of application processes and network interfaces, but 582 also to interface with NDN supporting structures (i.e. Content Store 583 (CS), Forward Information Base (FIB) and Pending Interest 584 Table (PIT). Effectively, different kinds of information can be 585 conveyed to a network node responsible for managing the network 586 (under different perspectives and processes), and resubmitted back 587 towards client nodes, affecting the way applications interface with 588 network interfaces and the NDN fabric. 590 NDN Fabric 591 +------------------------------------------+ 592 | Face 0 | 593 | +--------------+ +---+ | +------+ 594 | |Content Store | ptr/type | <---->|WLAN | 595 | +------------^-+ +-+----+ +---+ | +------+ 596 | +---------+| | Face 1 | 597 | +--------------+ +------+ +---+ | +------+ 598 | |Pending <--------+| | | <---->|LTE | 599 | |Interest Table| +------+ +---+ | +------+ 600 | +--------------+ | | | Face i | 601 | +------+ +---+ | +------+ 602 | +--------------+ | | | | <---->| MA | 603 | |Forward | +------+ +---+ | +------+ 604 | |Information <---------+| | Face j | 605 | |Base | +-+----+ +---+ | +------+ 606 | +--------------+ | <---->|VoIP | 607 | +---+ | |Video | 608 +------------------------------------------+ +------+ 610 Figure 1. NDN Management Framework 612 MA can interface with the PIT and FIB structures, acting as a 613 dynamic, application- and/or network-controlled interface to the 614 strategy layer. This could also be used to direct how to forward NDN 615 Interest and Data packets, in a configurable manner. Regarding 616 network interfaces, the MA can interface with them not only to 617 control (i.e., initiate wireless access scanning procedures), but 618 also to collect information (i.e., an informational event regarding 619 detected access points). Finally, the MA can also interface with 620 application processes, drawing out information about the perceived 621 QoS/QoE (e.g., lost packets or delay from a real-time video feed) and 622 also to execute commands, such as selecting a better video codec when 623 the network commands the video flow to be accessed from a different 624 wireless access interface. 626 Conversely, MA entities residing in network equipment can provide 627 informational events as well, but related to network-side link layer 628 characteristics (such as number of attached nodes or load), as well 629 as accepting commands from the network (i.e., activate maintenance 630 procedures). Management processes residing in the network core can 631 leverage information collected from applications, client terminals 632 and network equipment, to drive optimization procedures. Such 633 optimization procedures can also tap into other entities, containing 634 complementary information such as policies and subscription 635 information, and use it to produce an overall network decision, which 636 can then be forwarded to multiple client nodes, in a policy enforcing 637 way. 639 An important consideration from the NDN architecture, is the 640 hierarchical namespace, allowing nodes to request and convey 641 management data, by simply using an appropriate prefix (e.g., 642 ccn://domain/management/ME). 644 By leveraging the NDN information-centric dissemination mechanisms to 645 convey management information and commands as content, these 646 management extensions inherit the intrinsic capabilities of the NDN 647 architecture, including security and reliability, which are 648 fundamental for management procedures. 650 3. Acknowledgements 652 This document has benefited from comments and/or text provided by the 653 following members of ICNRG: TBD 655 4. IANA Considerations 657 This memo includes no request to IANA. 659 5. Security Considerations 661 TBD 663 6. Informative References 665 [AdaptCCN] 666 Lederer, S., Mueler, C., Rainer, B., Timmerer, C., and H. 667 Hellwagner, "Adaptive Streaming over Content Centric 668 Networks in Mobile Networks using Multiple Links", 669 Proceedings of the IEEE International Conference on 670 Communication (ICC), Budapest, Hungary , June 2013. 672 [CATT] Eum, S., Nakauchi, K., Murata, M., Shoji, Y., and N. 673 Nishinaga, "CATT: potential based routing with content 674 caching for ICN", Workshop on Information-centric 675 networking, pp 49-54 , 2012. 677 [CB-TE] Chanda, A. et al., "Content Based Traffic Engineering in 678 Software Defined Information Centric Networks", IEEE 679 INFOCOM Workshop NOMEN , April 2013. 681 [CCNx] PARC, "CCNx Project", 2013, . 683 [DONA] Koponen, T. et al., "A Data-Oriented (and Beyond) Network 684 Architecture", SIGCOMM, ACM , 2007. 686 [GIPR2013] 687 Sandivine, , "Global Internet Phenomena Report 1H 2013", 688 Sandvine Intelligent Broadband Networks , 2013. 690 [ICN-CACHING] 691 Zhang, G., Li, Y., and T. Lin, "Caching in information 692 centric networking: A survey", Computer Networks, vol. 57, 693 no. 16, pp. 3128-3141, Nov , 2013. 695 [ICN-FRESHNESS] 696 Quevedo, J., Corujo, D., and R. Aguiar, "Consumer Driven 697 Information Freshness Approach for Content Centric 698 Networking", IEEE INFOCOM Workshop on Name-Oriented 699 Mobility, Toronto, Canada, May , 2014. 701 [ICN-Scenarios] 702 Pentikousis, K., Ohlman, B., Corujo, D., and G. Boggia, 703 "ICN Baseline Scenarios", draft-pentikousis-icn-scenarios 704 (work in progress), February 2013. 706 [ICN-TE] Su, K. et al., "On the Benefit of Information Centric 707 Networks for Traffic Engineering", IEEE ICC , June 2014. 709 [InterAdaptCCN] 710 Grandl, R., Su, K., and C. Westphal, "On the Interaction 711 of Adaptive Video Streaming with Content-Centric 712 Networking", Proceedings of the 20th Packet Video Workshop 713 2013, San Jose, USA , December 2013. 715 [L4M-ICN] Chai, W., He, D., Psaras, I., and G. Pavlou, "Cache "less 716 for more" in information-centric networks", Lecture Notes 717 in Computer Science Vol. 7289, Springer, pp. 27-40 , 2012. 719 [MPEG-DASH] 720 Sodagar, I., "The MPEG-DASH Standard for Multimedia 721 Streaming Over the Internet", IEEE MultiMedia, IEEE, 722 vol.18, no.4, pp.62-67 , 2011. 724 [NDN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 725 Briggss, N., and R. Braynard, "Networking Named Content", 726 CoNEXT 2009, Rome , Dec 2009. 728 [NDN-MGMT] 729 Corujo, D., Vidal, I., Garcia-Reinoso, J., and R. Aguiar, 730 "A named data networking flexible framework for management 731 communications", Communications Magazine, IEEE , vol.50, 732 no.12, pp.36-43 , Dec 2012. 734 [NDN-R] Zhang, L. et al., "Named Data Networking (NDN) Project", 735 NDN Report ndn-0001, Tech Report, PARC , 2010, 736 . 738 [NDN-VOIP] 739 Jacobson, V., Smetters, D., Briggss, N., Plass, M., 740 Steward, P., and J. Thornton, "VoCCN: Voice Over Content- 741 Centric Networks", ReARCH 2009, Rome , Dec 2009. 743 [NDNFlexManager] 744 UC3M and ITAV, "Framework for Flexible NDN Management", 745 2013, . 747 [NetInf] Ahlgren, B. et al., "Design considerations for a network 748 of information", CoNEXT, Re-Arch Workshop, ACM , 2008. 750 [NetInfSelfX] 751 Pentikousis, K. et al., "Self-Management for a Network of 752 Information", IEEE ICC Workshops 2009 , June 2009. 754 [PURSUIT] Fotiou, N. et al., "Developing Information Networking 755 Further: From PSIRP to PURSUIT", BROADNETS, ICST , 2010. 757 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 758 "Simple Network Management Protocol (SNMP)", STD 15, RFC 759 1157, May 1990. 761 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 762 Text on Security Considerations", BCP 72, RFC 3552, July 763 2003. 765 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 766 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 767 May 2008. 769 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 770 "Diameter Base Protocol", RFC 6733, October 2012. 772 Authors' Addresses 774 Daniel Corujo 775 Instituto de Telecomunicacoes 776 Campus Universitario de Santiago 777 Aveiro P-3810-193 Aveiro 778 Portugal 780 Phone: +351 234 377 900 781 Email: dcorujo@av.it.pt 783 Kostas Pentikousis 784 EICT GmbH 785 Torgauer Strabe 12-15 786 10829 Berlin 787 Germany 789 Email: k.pentikousis@eict.de 791 Ivan Vidal 792 UC3M 793 Av de la Universidad, 30 794 28911 Leganes, Madrid 795 Spain 797 Email: ividal@it.uc3m.es 799 Jaime Garcia-Reinoso 800 UC3M 801 Av de la Universidad, 30 802 28911 Leganes, Madrid 803 Spain 805 Email: jgr@it.uc3m.es 806 Stefan Lederer 807 Alpen-Adria Universitat Klagenfurt 808 Universitatsstrasse 65-67 809 Klagenfurt 810 Austria 812 Email: stefan.lederer@itec.aau.at 814 Spiros Spirou 815 Intracom Telecom 816 19.7 km Markopoulou Avenue 817 Peania 19002 818 Greece 820 Email: spis@intracom.com 822 Cedric Westphal 823 Huawei 824 2330 Central Expressway 825 Santa Clara, CA95050 826 USA 828 Email: cedric.westphal@huawei.com