idnits 2.17.1 draft-corujo-icn-mgmt-03.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 (February 14, 2014) is 3695 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3552' is defined on line 774, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 778, 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 (~~), 3 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: August 18, 2014 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 February 14, 2014 15 ICN Management Considerations 16 draft-corujo-icn-mgmt-03 18 Abstract 20 Motivated by the need to find and evaluate better ways for reaching 21 on-line content in upcoming Future Internet environments, ICN has 22 been increasingly deployed in an broad range of research and 23 experimental actions. Some deployments even go as far as subjecting 24 ICN to new scenarios beyond content-reaching, exposing the 25 flexibility of ICN core primitives in supporting such mechanisms. In 26 this sense, besides analyzing and discussing the role of network 27 management procedures in ICN environments, this document also 28 analyzes possibilities on how intrinsic core ICN mechanisms can be 29 reutilized for network management. We consider that the availability 30 of management mechanisms for ICN will foster their deployment and, as 31 such, should be tackled still in the design and experimentation 32 phases. Perhaps ICN can adapt successful mechanisms from the host- 33 centric paradigm, or new network management schemes can be designed. 34 Perhaps even both. This document centralizes that discussion, 35 drawing the attention of the ICNRG community to this underdeveloped 36 area of research in ICN. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on August 18, 2014. 55 Copyright Notice 57 Copyright (c) 2014 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. ICN Management Considerations . . . . . . . . . . . . . . . . 4 74 2.1. A Management Framework for NDN - The Face Management 75 Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2.1.1. NDN Management Operations . . . . . . . . . . . . . . 7 77 2.1.1.1. Discovery Procedure . . . . . . . . . . . . . . . 7 78 2.1.1.2. Management Data Exchange . . . . . . . . . . . . 9 79 2.1.2. Implementation Experience . . . . . . . . . . . . . . 10 80 2.2. Video Adaptation . . . . . . . . . . . . . . . . . . . . 11 81 2.2.1. Adaptive Delivery of Multimedia Content in ICN . . . 11 82 2.3. Content Management . . . . . . . . . . . . . . . . . . . 12 83 2.4. Network Policies . . . . . . . . . . . . . . . . . . . . 14 84 2.4.1. NetInf Management Considerations . . . . . . . . . . 14 85 2.5. Cache Management . . . . . . . . . . . . . . . . . . . . 15 86 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 87 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 6. Informative References . . . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 92 1. Introduction 94 Information-centric networking (ICN) enables new ideas for naming and 95 addressing, privacy, security, and trust, and should also lead us to 96 think new ways for deploying, operating and managing networks in the 97 future. By default, users, programs, information objects and hosts 98 are in general untrustworthy and mobile in an information-centric 99 network. This means that many of the assumptions in traditional 100 network management, including all aspects of FCAPS (Fault, 101 Configuration, Accounting, Performance, and Security) need to be 102 rethought. However, despite the different instantiations of ICN 103 architectures, and the plethora of novel research work built on top 104 of them, little attention has been paid to management aspects so far. 105 This includes both enabling "traditional" network management 106 operations (which work well from small networks to large 107 infrastructure networks), and supporting and optimizing intrinsic 108 procedures of the ICN fabric. 110 This document aims to draw the attention of ICNRG to the importance 111 of network management for real-world deployments. Today, network 112 management is practically an add-on to host-centric deployments. We 113 can do better as we move forward in ICN research considering the full 114 range of deployments from home-office environments to challenged 115 networks to tier-1 networks. To this end, we draft some first 116 management considerations that, on the one hand, capitalize on ICN 117 concepts for defining management procedures and, on the other, 118 explore the possibilities for defining a common management framework 119 irrespective of the ICN approach taken. We reckon that the later is 120 a much more formidable task and we are looking forward to tackling it 121 together with other members of ICNRG. In this document, different 122 ICN research aspects tackled by ICNRG members are analyzed in respect 123 to management possibilities and impact. 125 We argue that addressing management at an early stage is not only 126 important for real-world adoption and the successful future 127 deployment of ICN, but also to deal with scenarios where management 128 can simplify, enhance or optimize ICN network utilization and 129 performance. The subject becomes particularly challenging, as 130 disparate characteristics from different ICN approaches (e.g., in 131 terms of namespace, granularity, routing, and so on) impact the 132 definition and design of these management mechanisms. Section 2 133 below provides an initial assessment, showcasing considerations on 134 Face Management Section 2.1, Video Adaptation Section 2.2, Content 135 Management Section 2.3, Network Policies Section 2.4 and Cache 136 Management Section 2.5. 138 We plan to incrementally develop the draft, incorporating 139 considerations on other ICN aspects as well as different approaches 140 (e.g., [PURSUIT] and [NetInf]) as well as address other pertinent 141 aspects as we receive feedback from the research group members. 143 2. ICN Management Considerations 145 This section addresses management considerations regarding specific 146 ICN deployments and scenarios, by analyzing the opportunities, 147 requirements and possibilities for management deployment therein. 148 This analysis starts with the proposal of a NDN-based face management 149 framework, followed by considerations from video adaptation, content 150 management and network policies scenarios. 152 2.1. A Management Framework for NDN - The Face Management Example 154 The Named Data Networking [NDN] ICN architecture provides a new 155 communication framework built on named data. Like other ICN 156 counterparts, such as [NetInf], [PURSUIT] and [DONA], NDN 157 intrinsically supports security, routing/forwarding, reliability, 158 caching and even mobility, aiming at scalable and more efficient 159 content-distribution than today's IP-based approaches. Fostered by 160 an open-source implementation [CCNx], NDN has been at the heart of an 161 active topic with several research contributions evaluating its 162 deployment feasibility and performance in a number of scenarios 163 [ICN-Scenarios]. 165 NDN introduces the concept of a Strategy Layer, which can control 166 Interest packet forwarding behavior. It basically determines which 167 is the best interface (or set of interfaces) to send an Interest 168 packet. The "strategy" component establishes a pre-configured 169 algorithm for tackling Interest packet decisions, ranging from 170 sending it sequentially on each interface until a Data packet is 171 received, to evaluating which interfaces provide better performance 172 (i.e., lower average RTT) in retrieving certain content (as discussed 173 in [NDN]). 175 It is important to keep in mind that NDN replaces the commonly used 176 term "interface" with the term "face", since packets can be forwarded 177 over hardware network interfaces as well as between application 178 interfaces, further acknowledging the information dissemination 179 capabilities of ICN. This aspect is considered in [NDN] and [NDN-R], 180 where programs can be associated to the NDN governing structures 181 (like the FIB), defining configurations such as "sendToAll" and 182 "sendToBest" with respect to managing the content reaching process. 183 Corujo et al. [NDN-MGMT] exploit these concepts enabling management 184 mechanisms to be deployed, and steer network operations and NDN 185 operation, as described in the following section. 187 An important aspect supporting network management procedures is the 188 interaction of network information residing at the network side with 189 information about the network from the perspective of clients 190 connected to it. The former includes, for instance, information 191 stored in the network operator core about user profiles, associated 192 policies, or data collected by the access network equipment, such as 193 current and past traffic load levels, active flows, and maintenance 194 information. Today, such information can be retrieved for management 195 and operation support through dedicated signaling protocols (e.g., 196 [RFC1157], [RFC6733]), or Operation Support Services (OSS) web 197 services. The client point of view of the network includes 198 information that, for example, a wireless terminal can provide, 199 indicating wireless link quality, average return-trip times (RTT) or 200 perceived Quality of Experience (QoE). 202 Both types of information can be capitalized upon allowing, for 203 example, the network to coordinate network management procedures, 204 considering as input information obtained from other network elements 205 as well as from user nodes. One way to generate management 206 information in network entities and at client nodes, as well as to 207 consume and act upon it (i.e., using the management information 208 exchange as a control channel) is to couple NDN nodes with Management 209 Agent (MA) entities. 211 Fig. 1 (redrawn here from [NDN-MGMT] for convenience) illustrates how 212 a MA can be deployed in both network and client entities, interfacing 213 with different operational aspects and protocol layers of an NDN 214 node. By using NDN content reaching and disseminating mechanisms, 215 management information can be consumed by the MA to steer not only 216 the behavior of application processes and network interfaces, but 217 also to interface with NDN supporting structures (i.e. Content Store 218 (CS), Forward Information Base (FIB) and Pendint Interest 219 Table (PIT). Effectively, different kinds of information can be 220 conveyed to a network node responsible for managing the network 221 (under different perspectives and processes), and resubmitted back 222 towards client nodes, affecting the way applications interface with 223 network interfaces and the NDN fabric. 225 NDN Fabric 226 +------------------------------------------+ 227 | Face 0 | 228 | +--------------+ +---+ | +------+ 229 | |Content Store | ptr/type | <---->|WLAN | 230 | +------------^-+ +-+----+ +---+ | +------+ 231 | +---------+| | Face 1 | 232 | +--------------+ +------+ +---+ | +------+ 233 | |Pending <--------+| | | <---->|LTE | 234 | |Interest Table| +------+ +---+ | +------+ 235 | +--------------+ | | | Face i | 236 | +------+ +---+ | +------+ 237 | +--------------+ | | | | <---->| MA | 238 | |Forward | +------+ +---+ | +------+ 239 | |Information <---------+| | Face j | 240 | |Base | +-+----+ +---+ | +------+ 241 | +--------------+ | <---->|VoIP | 242 | +---+ | |Video | 243 +------------------------------------------+ +------+ 245 Figure 1. NDN Management Framework 247 MA can interface with the PIT and FIB structures, acting as a 248 dynamic, application- and/or network-controlled interface to the 249 strategy layer. This could also be used to direct how to forward NDN 250 Interest and Data packets, in a configurable manner. Regarding 251 network interfaces, the MA can interface with them not only to 252 control (i.e., initiate wireless access scanning procedures), but 253 also to collect information (i.e., an informational event regarding 254 detected access points). Finally, the MA can also interface with 255 application processes, drawing out information about the perceived 256 QoS/QoE (e.g., lost packets or delay from a real-time video feed) and 257 also to execute commands, such as selecting a better video codec when 258 the network commands the video flow to be accessed from a different 259 wireless access interface. 261 Conversely, MA entities residing in network equipment can provide 262 informational events as well, but related to network-side link layer 263 characteristics (such as number of attached nodes or load), as well 264 as accepting commands from the network (i.e., activate maintenance 265 procedures). Management processes residing in the network core can 266 leverage information collected from applications, client terminals 267 and network equipment, to drive optimization procedures. Such 268 optimization procedures can also tap into other entities, containing 269 complementary information such as policies and subscription 270 information, and use it to produce an overall network decision, which 271 can then be forwarded to multiple client nodes, in a policy enforcing 272 way. 274 An important consideration from the NDN architecture, is the 275 hierarchical namespace, allowing nodes to request and convey 276 management data, by simply using an appropriate prefix (e.g., ccn:// 277 domain/management/ME). 279 By leveraging the NDN information-centric dissemination mechanisms to 280 convey management information and commands as content, these 281 management extensions inherit the intrinsic capabilities of the NDN 282 architecture, including security and reliability, which are 283 fundamental for management procedures. 285 2.1.1. NDN Management Operations 287 In order to implement management operations, besides the interfacing 288 capabilities of the MA entity mentioned in the previous section, a 289 management framework needs other supporting mechanisms in order to 290 provide the envisioned management capabilities, while maintaining the 291 inherent NDN capabilities. Concretely, when nodes connect to the 292 network, the management entities need to become aware of the 293 management capabilities of the newly-connected node. In addition, an 294 asynchronous information exchange capability needs to be provided, 295 allowing not only the request of management information, but also the 296 ability to push information towards a remote node (i.e., sending a 297 command or an informational event). 299 2.1.1.1. Discovery Procedure 301 The discovery procedure is illustrated in Fig. 2 (redrawn from 302 [NDN-MGMT]), and borrows for the procedures described in [NDN-VOIP]. 303 The procedure starts with the newly connected User Equipment (UE) 304 broadcasting an Interest packet (Fig. 2:1) perhaps with a well-known 305 content name (e.g., ccn://domain/management/mgmt-case/ME) to its 306 local network. 308 +-------+ +------------+ 309 |+--+ | | +---+| 310 ||MA| UE| |Network|ME || 311 |+--+ | | +---+| 312 +-|-----+ +------------+ 313 |(1) INTEREST | 314 |-/domain/management/mgmt-case/ME ------------------>| 315 | | 316 |(2) DATA | 317 |<-/domain/management/mgmtm-case/ME------------------| 318 |(Signature, ME-publisher-id, key locator | 319 | DATA:supported security mechanisms) | 320 | | 321 |(3) INTEREST | 322 |-/domain/management/mgmt-case/ME/MA-published-id/ ->| 323 |(encrypted with ME's PK:security-mechanism, SKey) | 324 | | 325 |(4) DATA | 326 |<-/domain/management/mgmt-case/ME/MA-publisher-id/--| 327 |(encrypted with ME's PK:security-mechanism, SKey) | 328 | DATA: Session Key received | 329 | | 330 |(5) INTEREST | 331 |<-/domain/management/mgmt-case/MA-publisher-id/-----| 332 | /nonce (encrypted) | 333 | | 334 |(6) DATA | 335 |-/domain/management/mgmt-case/MA-publisher-id/----->| 336 | /nonce (encrypted) | 337 | DATA: Encrypted nonce received | 339 Figure 2. Secure Management Session Establishment 341 The "mgmt-case" part of the name can be used to select different 342 aspects of management capabilities allowed by a Management Entity 343 (ME) (i.e., a management decision point in the network). The ME then 344 replies to this Interest with a Data packet (Fig. 2:2), providing its 345 shorthand identifier (i.e., ME-publisher-key) and a key locator, 346 indicating how to retrieve its public key (assuming it is authorized 347 by another key trusted by the UE). In this way, the MA at the UE 348 recognizes the ME as a valid signer (and provider) of management 349 content. 351 A session key, Ks, is generated by the MA, considering an encryption 352 algorithm from the ones indicated by the ME in the Data packet. The 353 MA then expresses its desire to receive (and reply to) Interests 354 matching a specific NDN name associated with the management service 355 (e.g., ccn://domain/management/mgmt-case/ME/MA-publisher-id), where 356 MA-publisher-id uniquely and globally identifies the MA, through a 357 cryptographic digest of its public key. After this, the MA sends an 358 Interest packet (Fig. 2:3) to retrieve management Data from the ME 359 containing the short-hand identifier of the MA (MA-publisher-id), the 360 chosen encryption algorithm and session key (Ks), both encrypted with 361 the public key of the ME. In this way, the confidentiality of the 362 content exchanged between the ME and the MA is guaranteed. The ME 363 responds with a Data packet (Fig. 2:4) signaling the reception of the 364 session Key. 366 Before the actual exchange of management data begins, the ME 367 generates a challenge (i.e., a nonce) which is sent via an Interest 368 packet (Fig. 2:5) to the MA, indicating through a named data name 369 that it requests the reception of the response to this challenge, 370 sent by the MA using a Data packet (Fig. 2:6). This allows the ME, 371 after verifying the signature of the Data packet, to verify that the 372 encryption algorithm and the session key are valid for the MA, making 373 it ready to exchange information for coordinating management 374 procedures in the network. 376 2.1.1.2. Management Data Exchange 378 After the discovery and security establishment procedures have been 379 finalized, the framework provides the capability for both the MA and 380 the ME to securely obtain management content from one another. 382 In order to push unsolicited content, a dual Interest/Data procedure 383 can maintain compatibility with the Interest and Data exchange/ 384 consumption of the NDN architecture. Fig. 3 (redrawn from Fig.2 of 385 [NDN-MGMT]) illustrates the procedure which is initiated by the MA. 386 In this case, the MA intends to push management information to the 387 ME. It does so via an Interest packet manifesting its interest in 388 receiving management content with a local sequence number. This 389 sequencing allows the recovery of new content over cached content. 390 If the ME is interested in retrieving content from the MA, it answers 391 back with a Data packet, where it indicates that it is willing to 392 receive management content. Then, the ME sends an Interest packet to 393 retrieve the management data with the sequence number provided by the 394 MA, which responds with a Data packet containing the information it 395 wanted to push into the ME. 397 +-------+ +------------+ 398 |+--+ | | +---+| 399 ||MA| UE| |Network|ME || 400 |+--+ | | +---+| 401 +-|-----+ +------------+ 402 |(1) INTEREST | 403 |-/domain/management/faces/MA-publisher-id/seq_num-->| 404 | | 405 |(2) DATA | 406 |<-/domain/management/faces/MA-publisher-id/seq_num--| 407 |(Signature) | 408 | DATA:content seq_num accepted | 409 | | 410 |(3) INTEREST | 411 |<-/domain/management/faces/MA-publisher-id/seq_num--| 412 | | 413 |(4) DATA | 414 |-/domain/management/mgmt-case/ME/MA-publisher-id/-->| 415 |(Signature) | 416 | DATA: management data (encrypted with Ks) | 417 | | 419 Figure 3. Content Management Push 421 2.1.2. Implementation Experience 423 As a proof-of-concept, a software prototype of the management 424 framework, [NDNFlexManager] was developed for [NDN-MGMT], using the 425 CCNx Java API [CCNx]. At this stage, it includes the support of the 426 discovery procedure described in Section Section 2.1.1.1, as well as 427 the management data exchange operations outlined in 428 Section Section 2.1.1.2. The framework provides an API to easy the 429 development of management applications, i.e., MAs and MEs, which can 430 request and push unsolicited content to each other, related with 431 management operations. 433 To validate this basic prototype, [NDN-MGMT] considered a specific 434 use case supported by the framework, i.e., face management. This 435 entails configuring and selecting an appropriate face in a UE to 436 retrieve a given content. Based on the CCNx, an evaluation test-bed 437 was deployed including an NDN UE (featuring an MA and a set of 438 network interfaces), a content server and a network node (featuring 439 an ME). These entities are interconnected by a set of NDN routers. 440 The purpose of the evaluation scenario is to demonstrate feasibility 441 for the protocol exchanges mentioned earlier. Note that the code has 442 been tested in a small-scale environment where the ME is topology- 443 aware and keeps track of conditions of the access networks that are 444 available to the UE. Thus, the ME can provide the MA with management 445 information reporting the appropriate face for content retrieval, or 446 an alternative point of access that could be used to improve the 447 performance. The MA uses the management information to reconfigure 448 the FIB (and possibly the network interfaces) in the UE, setting the 449 appropriate face to forward subsequent Interests. 451 For validation purposes, a local application was also implemented at 452 the NDN UE that works similarly to a ping utility, generating 453 periodic Interests that match a given prefix (served by the content 454 server), and computing the Round Trip Time of each Interest/Data 455 exchange. The RTT values obtained by this application in [NDN-MGMT], 456 indicate that the performance that can be achieved by using the NDN 457 management framework in the considered evaluation scenario is 458 satisfactory, given the early stage of this work. Further 459 development and testing is ongoing. 461 2.2. Video Adaptation 463 This section investigates ICN management considerations for the 464 delivery of video data, and especially the adaptive delivery of 465 video. From a content perspective, multimedia is omnipresent in the 466 Internet, e.g., producing 62% of the total Internet traffic in North 467 America's fixed access networks [GIPR2013]. 469 Video, and multimedia content in general, is has specific 470 characteristics, which have to be considered and where network 471 management consideration are necessary. The consumption of 472 multimedia content comes along with timing requirements for the 473 delivery of the content, for both, live and on-demand consumption. 474 Long startup delays, buffering periods or poor quality, etc. should 475 be avoided to achieve a good Quality of Experience of the consumer of 476 the content. Of course, these requirements are heavily influenced by 477 routing decision and caching, which are central parts of ICN, and 478 which may be leveraged more efficiently by an intelligent network 479 management. 481 2.2.1. Adaptive Delivery of Multimedia Content in ICN 483 Today's dominant streaming systems are based on the common approach 484 of leveraging HTTP-based Internet infrastructures, which are 485 consequently based on the Transmission Control Protocol (TCP) and the 486 Internet Protocol (IP). Especially the adaptive multimedia streaming 487 (AMS) via HTTP is gaining more and more momentum and resulted in the 488 standardization of MPEG-DASH [MPEG-DASH], which stands for Dynamic 489 Adaptive Streaming over HTTP. The basic idea of AHS is to split up 490 the media file into segments of equal length, which can be encoded at 491 different resolutions, bitrates, etc. The segments are stored on 492 conventional HTTP Web server and can be accessed through HTTP GET 493 requests from the client. Due to this, the streaming system is pull 494 based and the entire streaming logic is on the client side. This 495 means that the client fully controls the bitrate of the streaming 496 media on a per-segment basis, which has several advantages, e.g., the 497 client knows its bandwidth requirements and capabilities best. As 498 one can see, ICN and adaptive multimedia streaming have several 499 elements in common, such as the client-initiated pull approach, the 500 content being dealt with in pieces as well as the support of 501 efficient replication and distribution of content pieces within the 502 network. As ICN is a promising candidate for the Future Internet 503 (FI) architecture, it is useful to investigate its suitability in 504 combination with AMS systems and standards like MPEG-DASH as shown in 505 [AdaptCCN][InterAdaptCCN], as well as the possibilities and benefits 506 of intelligent network management to improve the performance of AMS 507 in ICN as well as the resulting QoE at the client. 509 One of the most promising aspects in this context is the possibility 510 of ICN to consume content from different origin nodes as well as over 511 different network links in parallel, which can be seen as an 512 intrinsic error resilience feature w.r.t. the network. This is a 513 useful feature of ICN for adaptive multimedia streaming within mobile 514 environments since most mobile devices are equipped with multiple 515 network links. Here, a focus of ICN management could be in the load 516 balancing of such traffic between the available links. This would 517 increase the effective media throughput of the multimedia content, 518 however, it could potentially lead to high variations of the 519 resulting bandwidth which is available to the client. As DASH is 520 designed for environments with dynamic bandwidth conditions, they can 521 be compensated in general. However, more conservative adaptation 522 algorithms may prevent too frequent switching between the content's 523 bitrate representations as well as compensate short-term bandwidth 524 drops caused by network link switches more smoothly. 526 2.3. Content Management 528 An ICN network aims to facilitate access to, and delivery of, 529 information objects (content and services). Content (in particular, 530 video) access and delivery seems to be the dominant use case in 531 traditional, host-based networks, so ICN networking is forced to 532 adopt content delivery as a minimum requirement. Indeed, virtually 533 all ICN approaches so far target at least content delivery. 535 From the perspective of a content owner or provider, an ICN network 536 functions essentially as a content delivery network. This creates a 537 set of requirements for ICN. First of all, end-users and content 538 providers alike should be able to Read (consume) a content object 539 available on the ICN network. In addition, content providers need 540 the ability to Create (publish), Update, and Delete content. 542 Finally, Accounting (logging) is necessary to support business models 543 that typically require charging, analytics, and monitoring. 545 The Read operation has received the lion's share in ICN research. 546 This is expected as content access and delivery is at the heart of 547 ICN. Given a request for a named content object, the ICN network 548 resolves that name to an object replica and proceeds with delivery to 549 the end-user. Of course, different ICN approaches employ different 550 mechanisms to achieve the Read operation. For example, name 551 resolution can be done with a hierarchical system resembling DNS, 552 with DHTs, or with flooding. Similarly, content delivery can be done 553 over normal best-effort paths from the origin server, over 554 dynamically computed provisioned paths, or from caches close to the 555 end-user. Some approaches can even cater to mobile end-users and 556 content hosts. ICN should be able to handle frequent Reads as well 557 as Read spikes (flash crowds). In fact, it seems crucial for ICN's 558 deployment chances to at least match the capabilities of incumbent 559 content delivery systems. 561 ICN research has not addressed Create as much as Read, but some 562 effort has been expanded on mechanisms for publishing content. Much 563 of this effort has focused on content naming schemes that enable 564 global uniqueness of names and hence allow global addressing of the 565 content objects. It has been difficult to balance human readability 566 of names, efficiency in machine processing, and name aggregation 567 (that can realistically enable request routing by name). Although a 568 fully automated mechanism for (human-readable) name assignment would 569 be desirable, so far it seems that a manual process, similar to that 570 of domain name registration in DNS, is necessary to allocate at least 571 namespaces. No other restrictions on naming have been seriously 572 considered. The consensus seems to be that with ICN anyone should be 573 able to publish anything. Content semantics are a higher layer 574 issue. This might be a prudent approach when building a transport 575 layer technology, but it could undermine the potential of ICN 576 deployment. A content owner would not want copies of its content 577 published on an ICN network under different names. In any case, once 578 a name has been assigned, the Create operation is mainly about 579 creating an entry in the name resolution system. This is obviously a 580 security risk and furthermore, for highly distributed name resolution 581 systems, it can suffer from considerable lag in availability. 582 Fortunately, Create is a rare operation compared to Read. 584 Update is an operation that seeks to alter an already created object. 585 A content provider would want to modify the data or the metadata of a 586 published object either to rectify publication errors or to augment 587 the object. It is debatable whether the provider should address the 588 later simply by creating a new object. Another use case for Update 589 comes from the need to rebrand or alias an object when its rights 590 have been sold to another party. Nevertheless, the Update operation 591 has received minimal attention in ICN research. The main problem is 592 one of consistency: once an update has been committed, an ICN network 593 with highly distributed name resolution and content delivery 594 (caching) would host both the old and new versions of the updated 595 content object for some time. Security concerns for the Update and 596 Create operations are similar. Update is normally rarer than Create, 597 but this will not be the case for collaborative media. 599 Content providers may occasionally need to remove a published object. 600 This is the goal of the Delete operation. An object might be deleted 601 when it was published by mistake, because it's no longer useful or 602 relevant, or because it's illegal. Consistency is a major challenge 603 for the Delete operation as well. The high degree of distribution in 604 ICN can sustain a network state where some data or metadata replicas 605 of an object have been deleted, while others persist. On the other 606 hand, this lag can be beneficial if deletion was initiated 607 erroneously or maliciously. Like with the Update operation, Delete 608 has not been properly investigated in ICN research. Deletes are 609 typically less often than updates. 611 From the point of view of content providers and end users, an ICN 612 network resembles a content directory and repository, with Create, 613 Read, Update, and Delete as typical operations. As with any database 614 system, the reliability of those operations (or transactions) depends 615 on the properties of atomicity, consistency, isolation, and 616 durability. The challenge for ICN research is to build systems at a 617 massive scale that employ those properties. 619 2.4. Network Policies 621 2.4.1. NetInf Management Considerations 623 Early-phase work in NetInf management [NetInfSelfX] discussed a two- 624 fold problem. The first question that arises is whether it is 625 possible by adopting a new set of network primitives and in-network 626 storage to usher a new type of network management. In other words, 627 can network management become information-centric while handling 628 often host-centric data? The second question is whether an 629 information-centric network is more suitable for self-management 630 mechanisms than IP-based networks are. In particular with respect to 631 the later, [NetInfSelfX] introduced some design considerations for 632 adding self-management mechanisms in NetInf. 634 Of interest from this early work are two examples where network 635 management can play a new role. First, network management can get 636 involved in decisions about caching and (re)distribution of content, 637 and not only whether an (inter)face is on or off, or what traffic 638 limits should be enforced. Moreover, network policies can be 639 distributed securely in the same way as other content in the network, 640 removing the need for centralized management, and enabling improved 641 recovery procedures. Second, network management can get involved in 642 more intricate processes such as controlling multiaccess support, 643 intermediating for content adaptation when deemed appropriate, and 644 enabling richer tools for traffic engineering. 646 2.5. Cache Management 648 Caching is a hot topic research nowadays in ICN. The challenges of 649 caching in ICN are different than those of web caching, mainly 650 because the former has to deal with high line rates and with a huge 651 amount of content. Some ICN works propose to cache content in all 652 ICN routers traversed by the data packet, in an LCE (Leave Copy 653 Everywhere) fashion as in [NDN]. Some studies, like [L4M-ICN], have 654 shown that other cache decision policies, focused to reduce the cache 655 redundancy, may increase the overall caching performance. Some of 656 these decision policies only use the local information available at 657 the ICN routers, but others use the information available at other 658 nodes to cache or not the incoming content. This is known as 659 explicit cache coordination decision, and there are several proposals 660 around this concept [ICN-CACHING]. The idea behind the explicit 661 coordination is to exchange topological information, individual 662 cache's state and content popularity view among a set of ICN routers, 663 in order to coordinate caching decisions. 665 This way, a given ICN router may forward a request towards another 666 router storing the requested content. In this context, the routing 667 protocol is affected by the cache's state of surrounding neighbours. 668 For example, in [CATT] the authors propose to distinguish between the 669 source(s) and routers' caches that hold a copy of that content: the 670 former paths are globally advertised, while the latter are only 671 advertised within the router's neighbourhood. In all these cases, 672 the use of a management framework may bring significant advantages, 673 providing standard interfaces that allow the routers to dynamically 674 manage their caches. 676 3. Acknowledgements 678 This document has benefited from comments and/or text provided by the 679 following members of ICNRG: 681 4. IANA Considerations 683 This memo includes no request to IANA. 685 5. Security Considerations 687 TBD 689 6. Informative References 691 [AdaptCCN] 692 Lederer, S., Mueler, C., Rainer, B., Timmerer, C., and H. 693 Hellwagner, "Adaptive Streaming over Content Centric 694 Networks in Mobile Networks using Multiple Links", 695 Proceedings of the IEEE International Conference on 696 Communication (ICC), Budapest, Hungary , June 2013. 698 [CATT] Eum, S., Nakauchi, K., Murata, M., Shoji, Y., and N. 699 Nishinaga, "CATT: potential based routing with content 700 caching for ICN", Workshop on Information-centric 701 networking, pp 49-54 , 2012. 703 [CCNx] PARC, "CCNx Project", 2013, . 705 [DONA] Koponen, T. et al., "A Data-Oriented (and Beyond) Network 706 Architecture", SIGCOMM, ACM , 2007. 708 [GIPR2013] 709 Sandivine, , "Global Internet Phenomena Report 1H 2013", 710 Sandvine Intelligent Broadband Networks , 2013. 712 [ICN-CACHING] 713 Zhang, G., Li, Y., and T. Lin, "Caching in information 714 centric networking: A survey", Computer Networks, vol. 57, 715 no. 16, pp. 3128-3141, Nov , 2013. 717 [ICN-Scenarios] 718 Pentikousis, K., Ohlman, B., Corujo, D., and G. Boggia, 719 "ICN Baseline Scenarios", draft-pentikousis-icn-scenarios 720 (work in progress), February 2013. 722 [InterAdaptCCN] 723 Grandl, R., Su, K., and C. Westphal, "On the Interaction 724 of Adaptive Video Streaming with Content-Centric 725 Networking", Proceedings of the 20th Packet Video Workshop 726 2013, San Jose, USA , December 2013. 728 [L4M-ICN] Chai, W., He, D., Psaras, I., and G. Pavlou, "Cache "less 729 for more" in information-centric networks", Lecture Notes 730 in Computer Science Vol. 7289, Springer, pp. 27-40 , 2012. 732 [MPEG-DASH] 733 Sodagar, I., "The MPEG-DASH Standard for Multimedia 734 Streaming Over the Internet", IEEE MultiMedia, IEEE, 735 vol.18, no.4, pp.62-67 , 2011. 737 [NDN-MGMT] 738 Corujo, D., Vidal, I., Garcia-Reinoso, J., and R. Aguiar, 739 "A named data networking flexible framework for management 740 communications", Communications Magazine, IEEE , vol.50, 741 no.12, pp.36-43 , Dec 2012. 743 [NDN-R] Zhang, L. et al., "Named Data Networking (NDN) Project", 744 NDN Report ndn-0001, Tech Report, PARC , 2010, 745 . 747 [NDN-VOIP] 748 Jacobson, V., Smetters, D., Briggss, N., Plass, M., 749 Steward, P., and J. Thornton, "VoCCN: Voice Over Content- 750 Centric Networks", ReARCH 2009, Rome , Dec 2009. 752 [NDNFlexManager] 753 UC3M and ITAV, "Framework for Flexible NDN Management", 754 2013, . 756 [NDN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 757 Briggss, N., and R. Braynard, "Networking Named Content", 758 CoNEXT 2009, Rome , Dec 2009. 760 [NetInfSelfX] 761 Pentikousis, K. et al., "Self-Management for a Network of 762 Information", IEEE ICC Workshops 2009 , June 2009. 764 [NetInf] Ahlgren, B. et al., "Design considerations for a network 765 of information", CoNEXT, Re-Arch Workshop, ACM , 2008. 767 [PURSUIT] Fotiou, N. et al., "Developing Information Networking 768 Further: From PSIRP to PURSUIT", BROADNETS, ICST , 2010. 770 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 771 "Simple Network Management Protocol (SNMP)", STD 15, RFC 772 1157, May 1990. 774 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 775 Text on Security Considerations", BCP 72, RFC 3552, July 776 2003. 778 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 779 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 780 May 2008. 782 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 783 "Diameter Base Protocol", RFC 6733, October 2012. 785 Authors' Addresses 787 Daniel Corujo 788 Instituto de Telecomunicacoes 789 Campus Universitario de Santiago 790 Aveiro P-3810-193 Aveiro 791 Portugal 793 Phone: +351 234 377 900 794 Email: dcorujo@av.it.pt 796 Kostas Pentikousis 797 EICT GmbH 798 Torgauer Strabe 12-15 799 10829 Berlin 800 Germany 802 Email: k.pentikousis@eict.de 804 Ivan Vidal 805 UC3M 806 Av de la Universidad, 30 807 28911 Leganes, Madrid 808 Spain 810 Email: ividal@it.uc3m.es 812 Jaime Garcia-Reinoso 813 UC3M 814 Av de la Universidad, 30 815 28911 Leganes, Madrid 816 Spain 818 Email: jgr@it.uc3m.es 819 Stefan Lederer 820 Alpen-Adria Universitat Klagenfurt 821 Universitatsstrasse 65-67 822 Klagenfurt 823 Austria 825 Email: stefan.lederer@itec.aau.at 827 Spiros Spirou 828 Intracom Telecom 829 19.7 km Markopoulou Avenue 830 Peania 19002 831 Greece 833 Email: spis@intracom.com