idnits 2.17.1 draft-corujo-icn-mgmt-01.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 12, 2013) is 3939 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3552' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 562, 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: January 13, 2014 Huawei Technologies 6 I. Vidal 7 UC3M 8 July 12, 2013 10 ICN Management Considerations 11 draft-corujo-icn-mgmt-01 13 Abstract 15 This document aims to draw the attention of the ICNRG community to 16 network management, an important but hitherto underdeveloped area of 17 research in information-centric networking. We consider that the 18 availability of modern management mechanisms for information-centric 19 networks will foster their deployment in real-world environments. 20 For example, we argue that there is a need for creating basic network 21 management tools early on while ICN is still in the design and 22 experimentation phases that can evolve over time. Perhaps ICN can 23 borrow successful mechanisms from the host-centric paradigm and adapt 24 them to the new network primitives. Alternatively, novel network 25 management schemes can be designed based on ICN primitives. As a 26 discussion starter, this document summarizes recently published 27 approaches for ICN network management. In particular, this first 28 version presents a management framework for named data networking and 29 reviews previous work on NetInf management. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 13, 2014. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. NDN Management Considerations . . . . . . . . . . . . . . . . 4 66 2.1. Towards a Management Framework for NDN . . . . . . . . . . 5 67 2.2. NDN Management Operations . . . . . . . . . . . . . . . . 7 68 2.2.1. Discovery Procedure . . . . . . . . . . . . . . . . . 7 69 2.2.2. Management Data Exchange . . . . . . . . . . . . . . . 9 70 2.3. Implementation Experience . . . . . . . . . . . . . . . . 10 71 3. NetInf Management Considerations . . . . . . . . . . . . . . . 11 72 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 7. Informative References . . . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 Information-centric networking (ICN) enables new ideas for naming and 81 addressing, privacy, security, and trust, and should also lead us to 82 think new ways for deploying, operating and managing networks in the 83 future. By default, users, programs, information objects and hosts 84 are in general untrustworthy and mobile in an information-centric 85 network. This means that many of the assumptions in traditional 86 network management, including all aspects of FCAPS (Fault, 87 Configuration, Accounting, Performance, and Security) need to be 88 rethought. However, despite the different instantiations of ICN 89 architectures, and the plethora of novel research work built on top 90 of them, little attention has been paid to management aspects so far. 91 This includes both enabling "traditional" network management 92 operations (which work well from small networks to large 93 infrastructure networks), and supporting and optimizing intrinsic 94 procedures of the ICN fabric. 96 This document aims to draw the attention of ICNRG to the importance 97 of network management for real-world deployments. Today, network 98 management is practically an add-on to host-centric deployments. We 99 can do better as we move forward in ICN research considering the full 100 range of deployments from home-office environments to challenged 101 networks to tier-1 networks. To this end, we draft some first 102 management considerations that, on the one hand, capitalize on ICN 103 concepts for defining management procedures and, on the other, 104 explore the possibilities for defining a common management framework 105 irrespective of the ICN approach taken. We reckon that the later is 106 a much more formidable task and we are looking forward to tackling it 107 together with other members of ICNRG. We start this exercise in this 108 first version based on published literature and in particular with a 109 NDN approach. 111 We argue that addressing management at an early stage is not only 112 important for real-world adoption and the successful future 113 deployment of ICN, but also to deal with scenarios where management 114 can simplify, enhance or optimize ICN network utilization and 115 performance. The subject becomes particularly challenging, as 116 disparate characteristics from different ICN approaches (e.g., in 117 terms of namespace, granularity, routing, and so on) impact the 118 definition and design of these management mechanisms. Section 2 119 below provides an initial assessment, proposal and evaluation of 120 management mechanisms leveraging NDN intrinsic capabilities based on 121 [NDN-MGMT], while Section 3 briefly summarizes earlier work on self- 122 management for NetInf. 124 We plan to incrementally develop the draft and incorporate other ICN 125 approaches (e.g., [PURSUIT] and [NetInf]) as well as address other 126 pertinent aspects as we receive feedback from the research group 127 members. 129 2. NDN Management Considerations 131 The Named Data Networking [NDN] ICN architecture provides a new 132 communication framework built on named data. Like other ICN 133 counterparts, such as [NetInf], [PURSUIT] and [DONA], NDN 134 intrinsically supports security, routing/forwarding, reliability, 135 caching and even mobility, aiming at scalable and more efficient 136 content-distribution than today's IP-based approaches. Fostered by 137 an open-source implementation [CCNx], NDN has been at the heart of an 138 active topic with several research contributions evaluating its 139 deployment feasibility and performance in a number of scenarios 140 [ICN-Scenarios]. 142 NDN relies on a hierarchical, human-readable namespace to address 143 named data objects, where the naming scheme is simultaneously used to 144 both name information and to route it. It relies on content 145 requesters sending an Interest packet with a Content Name, where the 146 prefix can provide information for global and organizational routing, 147 while the suffix indicates versioning and segmentation details. When 148 a node receives an Interest packet asking for content which matches 149 what is already available at the node, it responds with a matching 150 Data packet carrying back the content. 152 Each NDN node comes with a set of supporting data structures which 153 enable the coordination between the transmission of Interest packets 154 with the reception of the corresponding Data packets. These 155 structures include: 157 1. Content Store: maintains an indication of locally available 158 content, according to name, and is used for Interest packet 159 matching. If the content is available at the node, the Interest 160 packet is consumed, and a Data packet with the respective content 161 is sent towards the request origin. 163 2. Pending Interest Table (PIT): keeps track of Interest packets 164 seen previously by the node, on their way to locate matching 165 content. Interest packets in the PIT were not matched to content 166 available in the node. Basically, PIT maintains a degree of 167 state regarding Interest packets, mapping them to a corresponding 168 egress network interface. 170 3. Forward Information Base (FIB): associates named data to 171 potential holders of the content. A routing protocol can 172 populate the FIB (although this is outside the scope of NDN) or 173 it can be populated through registration in a local NDN store. 175 NDN introduces the concept of a Strategy Layer, which can control 176 Interest packet forwarding behavior. It basically determines which 177 is the best interface (or set of interfaces) to send an Interest 178 packet. The "strategy" component establishes a pre-configured 179 algorithm for tackling Interest packet decisions, ranging from 180 sending it sequentially on each interface until a Data packet is 181 received, to evaluating which interfaces provide better performance 182 (i.e., lower average RTT) in retrieving certain content (as discussed 183 in [NDN]). 185 It is important to keep in mind that NDN replaces the commonly used 186 term "interface" with the term "face", since packets can be forwarded 187 over hardware network interfaces as well as between application 188 interfaces, further acknowledging the information dissemination 189 capabilities of ICN. This aspect is considered in [NDN] and [NDN-R], 190 where programs can be associated to the NDN governing structures 191 (like the FIB), defining configurations such as "sendToAll" and 192 "sendToBest" with respect to managing the content reaching process. 193 Corujo et al. [NDN-MGMT] exploit these concepts enabling management 194 mechanisms to be deployed, and steer network operations and NDN 195 operation, as described in the following section. 197 2.1. Towards a Management Framework for NDN 199 An important aspect supporting network management procedures is the 200 interaction of network information residing at the network side with 201 information about the network from the perspective of clients 202 connected to it. The former includes, for instance, information 203 stored in the network operator core about user profiles, associated 204 policies, or data collected by the access network equipment, such as 205 current and past traffic load levels, active flows, and maintenance 206 information. Today, such information can be retrieved for management 207 and operation support through dedicated signaling protocols (e.g., 208 [RFC1157], [RFC6733]), or Operation Support Services (OSS) web 209 services. The client point of view of the network includes 210 information that, for example, a wireless terminal can provide, 211 indicating wireless link quality, average return-trip times (RTT) or 212 perceived Quality of Experience (QoE). 214 Both types of information can be capitalized upon allowing, for 215 example, the network to coordinate network management procedures, 216 considering as input information obtained from other network elements 217 as well as from user nodes. One way to generate management 218 information in network entities and at client nodes, as well as to 219 consume and act upon it (i.e., using the management information 220 exchange as a control channel) is to couple NDN nodes with Management 221 Agent (MA) entities. 223 Fig. 1 (redrawn here from [NDN-MGMT] for convenience) illustrates how 224 a MA can be deployed in both network and client entities, interfacing 225 with different operational aspects and protocol layers of an NDN 226 node. By using NDN content reaching and disseminating mechanisms, 227 management information can be consumed by the MA to steer not only 228 the behavior of application processes and network interfaces, but 229 also to interface with NDN supporting structures (i.e. Content 230 Store, FIB, PIT). Effectively, different kinds of information can be 231 conveyed to a network node responsible for managing the network 232 (under different perspectives and processes), and resubmitted back 233 towards client nodes, affecting the way applications interface with 234 network interfaces and the NDN fabric. 236 NDN Fabric 237 +------------------------------------------+ 238 | Face 0 | 239 | +--------------+ +---+ | +------+ 240 | |Content Store | ptr/type | <---->|WLAN | 241 | +------------^-+ +-+----+ +---+ | +------+ 242 | +---------+| | Face 1 | 243 | +--------------+ +------+ +---+ | +------+ 244 | |Pending <--------+| | | <---->|LTE | 245 | |Interest Table| +------+ +---+ | +------+ 246 | +--------------+ | | | Face i | 247 | +------+ +---+ | +------+ 248 | +--------------+ | | | | <---->| MA | 249 | |Forward | +------+ +---+ | +------+ 250 | |Information <---------+| | Face j | 251 | |Base | +-+----+ +---+ | +------+ 252 | +--------------+ | <---->|VoIP | 253 | +---+ | |Video | 254 +------------------------------------------+ +------+ 256 Figure 1. NDN Management Framework 258 MA can interface with the PIT and FIB structures, acting as a 259 dynamic, application- and/or network-controlled interface to the 260 strategy layer. This could also be used to direct how to forward NDN 261 Interest and Data packets, in a configurable manner. Regarding 262 network interfaces, the MA can interface with them not only to 263 control (i.e., initiate wireless access scanning procedures), but 264 also to collect information (i.e., an informational event regarding 265 detected access points). Finally, the MA can also interface with 266 application processes, drawing out information about the perceived 267 QoS/QoE (e.g., lost packets or delay from a real-time video feed) and 268 also to execute commands, such as selecting a better video codec when 269 the network commands the video flow to be accessed from a different 270 wireless access interface. 272 Conversely, MA entities residing in network equipment can provide 273 informational events as well, but related to network-side link layer 274 characteristics (such as number of attached nodes or load), as well 275 as accepting commands from the network (i.e., activate maintenance 276 procedures). Management processes residing in the network core can 277 leverage information collected from applications, client terminals 278 and network equipment, to drive optimization procedures. Such 279 optimization procedures can also tap into other entities, containing 280 complementary information such as policies and subscription 281 information, and use it to produce an overall network decision, which 282 can then be forwarded to multiple client nodes, in a policy enforcing 283 way. 285 An important consideration from the NDN architecture, is the 286 hierarchical namespace, allowing nodes to request and convey 287 management data, by simply using an appropriate prefix (e.g., 288 ccn://domain/management/ME). 290 By leveraging the NDN information-centric dissemination mechanisms to 291 convey management information and commands as content, these 292 management extensions inherit the intrinsic capabilities of the NDN 293 architecture, including security and reliability, which are 294 fundamental for management procedures. 296 2.2. NDN Management Operations 298 In order to implement management operations, besides the interfacing 299 capabilities of the MA entity mentioned in the previous section, a 300 management framework needs other supporting mechanisms in order to 301 provide the envisioned management capabilities, while maintaining the 302 inherent NDN capabilities. Concretely, when nodes connect to the 303 network, the management entities need to become aware of the 304 management capabilities of the newly-connected node. In addition, an 305 asynchronous information exchange capability needs to be provided, 306 allowing not only the request of management information, but also the 307 ability to push information towards a remote node (i.e., sending a 308 command or an informational event). 310 2.2.1. Discovery Procedure 312 The discovery procedure is illustrated in Fig. 2 (redrawn from 313 [NDN-MGMT]), and borrows for the procedures described in [NDN-VOIP]. 314 The procedure starts with the newly connected User Equipment (UE) 315 broadcasting an Interest packet (Fig. 2:1) perhaps with a well-known 316 content name (e.g., ccn://domain/management/mgmt-case/ME) to its 317 local network. 319 +-------+ +------------+ 320 |+--+ | | +---+| 321 ||MA| UE| |Network|ME || 322 |+--+ | | +---+| 323 +-|-----+ +------------+ 324 |(1) INTEREST | 325 |-/domain/management/mgmt-case/ME ------------------>| 326 | | 327 |(2) DATA | 328 |<-/domain/management/mgmtm-case/ME------------------| 329 |(Signature, ME-publisher-id, key locator | 330 | DATA:supported security mechanisms) | 331 | | 332 |(3) INTEREST | 333 |-/domain/management/mgmt-case/ME/MA-published-id/ ->| 334 |(encrypted with ME's PK:security-mechanism, SKey) | 335 | | 336 |(4) DATA | 337 |<-/domain/management/mgmt-case/ME/MA-publisher-id/--| 338 |(encrypted with ME's PK:security-mechanism, SKey) | 339 | DATA: Session Key received | 340 | | 341 |(5) INTEREST | 342 |<-/domain/management/mgmt-case/MA-publisher-id/-----| 343 | /nonce (encrypted) | 344 | | 345 |(6) DATA | 346 |-/domain/management/mgmt-case/MA-publisher-id/----->| 347 | /nonce (encrypted) | 348 | DATA: Encrypted nonce received | 350 Figure 2. Secure Management Session Establishment 352 The "mgmt-case" part of the name can be used to select different 353 aspects of management capabilities allowed by a Management Entity 354 (ME) (i.e., a management decision point in the network). The ME then 355 replies to this Interest with a Data packet (Fig. 2:2), providing its 356 shorthand identifier (i.e., ME-publisher-key) and a key locator, 357 indicating how to retrieve its public key (assuming it is authorized 358 by another key trusted by the UE). In this way, the MA at the UE 359 recognizes the ME as a valid signer (and provider) of management 360 content. 362 A session key, Ks, is generated by the MA, considering an encryption 363 algorithm from the ones indicated by the ME in the Data packet. The 364 MA then expresses its desire to receive (and reply to) Interests 365 matching a specific NDN name associated with the management service 366 (e.g., ccn://domain/management/mgmt-case/ME/MA-publisher-id), where 367 MA-publisher-id uniquely and globally identifies the MA, through a 368 cryptographic digest of its public key. After this, the MA sends an 369 Interest packet (Fig. 2:3) to retrieve management Data from the ME 370 containing the short-hand identifier of the MA (MA-publisher-id), the 371 chosen encryption algorithm and session key (Ks), both encrypted with 372 the public key of the ME. In this way, the confidentiality of the 373 content exchanged between the ME and the MA is guaranteed. The ME 374 responds with a Data packet (Fig. 2:4) signaling the reception of the 375 session Key. 377 Before the actual exchange of management data begins, the ME 378 generates a challenge (i.e., a nonce) which is sent via an Interest 379 packet (Fig. 2:5) to the MA, indicating through a named data name 380 that it requests the reception of the response to this challenge, 381 sent by the MA using a Data packet (Fig. 2:6). This allows the ME, 382 after verifying the signature of the Data packet, to verify that the 383 encryption algorithm and the session key are valid for the MA, making 384 it ready to exchange information for coordinating management 385 procedures in the network. 387 2.2.2. Management Data Exchange 389 After the discovery and security establishment procedures have been 390 finalized, the framework provides the capability for both the MA and 391 the ME to securely obtain management content from one another. 393 In order to push unsolicited content, a dual Interest/Data procedure 394 can maintain compatibility with the Interest and Data exchange/ 395 consumption of the NDN architecture. Fig. 3 (redrawn from Fig.2 of 396 [NDN-MGMT]) illustrates the procedure which is initiated by the MA. 397 In this case, the MA intends to push management information to the 398 ME. It does so via an Interest packet manifesting its interest in 399 receiving management content with a local sequence number. This 400 sequencing allows the recovery of new content over cached content. 401 If the ME is interested in retrieving content from the MA, it answers 402 back with a Data packet, where it indicates that it is willing to 403 receive management content. Then, the ME sends an Interest packet to 404 retrieve the management data with the sequence number provided by the 405 MA, which responds with a Data packet containing the information it 406 wanted to push into the ME. 408 +-------+ +------------+ 409 |+--+ | | +---+| 410 ||MA| UE| |Network|ME || 411 |+--+ | | +---+| 412 +-|-----+ +------------+ 413 |(1) INTEREST | 414 |-/domain/management/faces/MA-publisher-id/seq_num-->| 415 | | 416 |(2) DATA | 417 |<-/domain/management/faces/MA-publisher-id/seq_num--| 418 |(Signature) | 419 | DATA:content seq_num accepted | 420 | | 421 |(3) INTEREST | 422 |<-/domain/management/faces/MA-publisher-id/seq_num--| 423 | | 424 |(4) DATA | 425 |-/domain/management/mgmt-case/ME/MA-publisher-id/-->| 426 |(Signature) | 427 | DATA: management data (encrypted with Ks) | 428 | | 430 Figure 3. Content Management Push 432 2.3. Implementation Experience 434 As a proof-of-concept, a software prototype of the management 435 framework, [NDNFlexManager] was developed for [NDN-MGMT], using the 436 CCNx Java API [CCNx]. At this early stage, it includes the 437 implementation of an ME and an MA as NDN applications, supporting the 438 NDN management operations outlined in Fig. 3. Thus, the ME and the 439 MA can push unsolicited content to each other, related with 440 management operations. 442 To validate this basic prototype, [NDN-MGMT] considered a specific 443 use case supported by the framework, i.e., face management. This 444 entails configuring and selecting an appropriate face in a UE to 445 retrieve a given content. Based on the CCNx, an evaluation test-bed 446 was deployed including an NDN UE (featuring an MA and a set of 447 network interfaces), a content server and a network node (featuring 448 an ME). These entities are interconnected by a set of NDN routers. 449 The purpose of the evaluation scenario is to demonstrate feasibility 450 for the protocol exchanges mentioned earlier. Note that the code has 451 been tested in a small-scale environment where the ME is topology- 452 aware and keeps track of conditions of the access networks that are 453 available to the UE. Thus, the ME can provide the MA with management 454 information reporting the appropriate face for content retrieval, or 455 an alternative point of access that could be used to improve the 456 performance. The MA uses the management information to reconfigure 457 the FIB (and possibly the network interfaces) in the UE, setting the 458 appropriate face to forward subsequent Interests. 460 For validation purposes, a local application was also implemented at 461 the NDN UE that works similarly to a ping utility, generating 462 periodic Interests that match a given prefix (served by the content 463 server), and computing the Round Trip Time of each Interest/Data 464 exchange. The RTT values obtained by this application in [NDN-MGMT], 465 indicate that the performance of the NDN management framework in the 466 considered evaluation scenario is satisfactory, given the early stage 467 of this work. Further development and testing is ongoing. 469 3. NetInf Management Considerations 471 Early-phase work in NetInf management [NetInfSelfX] discussed a two- 472 fold problem. The first question that arises is whether it is 473 possible by adopting a new set of network primitives and in-network 474 storage to usher a new type of network management. In other words, 475 can network management become information-centric while handling 476 often host-centric data? The second question is whether an 477 information-centric network is more suitable for self-management 478 mechanisms than IP-based networks are. In particular with respect to 479 the later, [NetInfSelfX] introduced some design considerations for 480 adding self-management mechanisms in NetInf. 482 Of interest from this early work are two examples where network 483 management can play a new role. First, network management can get 484 involved in decisions about caching and (re)distribution of content, 485 and not only whether an (inter)face is on or off, or what traffic 486 limits should be enforced. Moreover, network policies can be 487 distributed securely in the same way as other content in the network, 488 removing the need for centralized management, and enabling improved 489 recovery procedures. Second, network management can get involved in 490 more intricate processes such as controlling multiaccess support, 491 intermediating for content adaptation when deemed appropriate, and 492 enabling richer tools for traffic engineering. 494 4. Acknowledgements 496 This document has benefited from comments and/or text provided by the 497 following members of ICNRG: 499 Jaime Garcia-Reinoso (UC3M); Section 2.3 501 5. IANA Considerations 503 This memo includes no request to IANA. 505 6. Security Considerations 507 TBD 509 7. Informative References 511 [CCNx] PARC, "CCNx Project", 2013, . 513 [DONA] Koponen, T. et al., "A Data-Oriented (and Beyond) Network 514 Architecture", SIGCOMM, ACM , 2007. 516 [ICN-Scenarios] 517 Pentikousis, K., Ohlman, B., Corujo, D., and G. Boggia, 518 "ICN Baseline Scenarios", draft-pentikousis-icn-scenarios 519 (work in progress), February 2013. 521 [NDN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 522 Briggss, N., and R. Braynard, "Networking Named Content", 523 CoNEXT 2009, Rome , Dec 2009. 525 [NDN-MGMT] 526 Corujo, D., Vidal, I., Garcia-Reinoso, J., and R. Aguiar, 527 "A named data networking flexible framework for management 528 communications", Communications Magazine, IEEE , vol.50, 529 no.12, pp.36-43 , Dec 2012. 531 [NDN-R] Zhang, L. et al., "Named Data Networking (NDN) Project", 532 NDN Report ndn-0001, Tech Report, PARC , 2010, 533 . 535 [NDN-VOIP] 536 Jacobson, V., Smetters, D., Briggss, N., Plass, M., 537 Steward, P., and J. Thornton, "VoCCN: Voice Over Content- 538 Centric Networks", ReARCH 2009, Rome , Dec 2009. 540 [NDNFlexManager] 541 UC3M and ITAV, "Framework for Flexible NDN Management", 542 2013, . 544 [NetInf] Ahlgren, B. et al., "Design considerations for a network 545 of information", CoNEXT, Re-Arch Workshop, ACM , 2008. 547 [NetInfSelfX] 548 Pentikousis, K. et al., "Self-Management for a Network of 549 Information", IEEE ICC Workshops 2009 , June 2009. 551 [PURSUIT] Fotiou, N. et al., "Developing Information Networking 552 Further: From PSIRP to PURSUIT", BROADNETS, ICST , 2010. 554 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 555 "Simple Network Management Protocol (SNMP)", STD 15, 556 RFC 1157, May 1990. 558 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 559 Text on Security Considerations", BCP 72, RFC 3552, 560 July 2003. 562 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 563 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 564 May 2008. 566 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 567 "Diameter Base Protocol", RFC 6733, October 2012. 569 Authors' Addresses 571 Daniel Corujo 572 Instituto de Telecomunicacoes 573 Campus Universitario de Santiago 574 Aveiro, P-3810-193 Aveiro 575 Portugal 577 Phone: +351 234 377 900 578 Email: dcorujo@av.it.pt 580 Kostas Pentikousis 581 Huawei Technologies 582 Carnotstrasse 4 583 10587 Berlin 584 Germany 586 Email: k.pentikousis@huawei.com 587 Ivan Vidal 588 UC3M 589 Av de la Universidad, 30 590 28911 Leganes, Madrid 591 Spain 593 Email: ividal@it.uc3m.es