idnits 2.17.1 draft-pentikousis-nmrg-andr-02.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 (May 4, 2015) is 3281 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-06 == Outdated reference: A later version (-06) exists of draft-irtf-nmrg-an-gap-analysis-05 == Outdated reference: A later version (-05) exists of draft-pentikousis-supa-mapping-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NMRG K. Pentikousis 3 Internet-Draft EICT 4 Intended status: Informational M. Sifalakis 5 Expires: November 5, 2015 University of Basel 6 J. Nobre 7 Federal University of Rio Grande do Sul 8 May 4, 2015 10 Autonomic Networking Definitions Revisited 11 draft-pentikousis-nmrg-andr-02 13 Abstract 15 This document revisits the autonomic networking terminology 16 established in peer-reviewed literature, aiming to contribute to the 17 ongoing discussion in the IRTF NMRG about how to move forward with 18 standardizing various autonomic networking aspects. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 5, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Operational Considerations and Outlook . . . . . . . . . . . 5 59 3.1. New Deployment Models . . . . . . . . . . . . . . . . . . 6 60 3.2. Programmable Network Elements and Functions . . . . . . . 6 61 3.3. Autonomic Planes . . . . . . . . . . . . . . . . . . . . 6 62 3.4. DevOps . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.5. Autonomic Monitoring . . . . . . . . . . . . . . . . . . 7 64 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 7. Informative References . . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 The IRTF Network Management Research Group (NMRG) has been working on 73 a set of definitions for autonomic networking. Defining and agreeing 74 on autonomic networking terminology is not an easy task as discussed 75 in [TAN]. In general, autonomic operation is associated with a range 76 of properties, such as self-configuration, self-healing, self- 77 optimization, and self-protection [ACDawn]. It is worth pointing out 78 that although there is some implicit consensus within the autonomic 79 computing community on the key properties/attributes of an autonomic 80 system, in the autonomic networking community this is not necessarily 81 the case. In the past, the common ground between different projects 82 and different contexts of operation was the presence of self-* 83 properties, without converging to a minimum set or different levels 84 of autonomic behavior, or where this behavior needs to be manifested. 86 1.1. Motivation 88 Behringer et al. [I-D.irtf-nmrg-autonomic-network-definitions] 89 describe a set of design goals and non-goals for autonomic networking 90 and introduce a model reference architecture in the context of future 91 IETF standardization [I-D.behringer-autonomic-control-plane]. 93 Prior to this effort at NMRG, autonomic networking has been the focus 94 of several research projects. For example, Bouabene et al. [ANA] 95 detail an autonomic network architecture (ANA). Nguengang et al. 96 [UMFSpec] propose a unified management framework (UMF) which has 97 autonomic properties and functions at its core. Chaparadza et al. 98 [SelfFI] introduce an elegant and "standardizable" [sic] generic 99 autonomic networking architecture (GANA) which they propose to be 100 adopted as a reference model. GANA was indeed further elaborated 101 under the auspices of ETSI as a group specification [GANA]. 103 Jennings et al. [TAM07] discuss the challenges one must deal with 104 when applying autonomic principles to network management. This 105 includes translation from business rules to resources/services to be 106 provided, contextual changes in the network, adaptation of the 107 management control loops, and verification of dynamic models for 108 machine learning purposes. Samaan and Karmouch [SK09] analyze the 109 requirements and the main contributions for the building blocks of 110 autonomic network management systems, describe a classification 111 methodology which compares previously proposed architectures, suggest 112 a reference framework, and point to a set of research challenges. 114 This list of earlier work in only indicative of the breadth of 115 research in this area over the last decade. However, standardization 116 remains an open question and deployment has been limited to specific 117 mechanisms only [I-D.irtf-nmrg-an-gap-analysis]. 119 1.2. Scope 121 We concur with Behringer et al. 122 [I-D.irtf-nmrg-autonomic-network-definitions] that for most of the 123 work in IETF it suffices to define autonomic behaviour at the node 124 level. However, recent standardization efforts in the IETF, such as, 125 for example, I2RS [I-D.ietf-i2rs-problem-statement], SFC [RFC7498], 126 ABNO [RFC7491], SUPA [I-D.pentikousis-supa-mapping], and LIME to name 127 a few, and new IRTF research groups such as SDNRG and NFVRG, indicate 128 that NMRG should perhaps dig a bit deeper into the definitions for 129 autonomic networking that will be of tangible benefit to the 130 researcher and practitioner communities alike. In particular, one 131 could reconsider the aspects of defining node-level autonomicity 132 only. 134 This document revisits the autonomic networking definitions proposed 135 earlier in the peer-reviewed literature Section 2, and relates them 136 with recent developments aiming to assist in the definition of a 137 coherent terminology in this emerging area of standardization at the 138 IETF. 140 2. Definitions 142 After some thorough analysis and discussion, Schmid et al. [TAN] put 143 forward the following definition, which captures in a concrete and 144 concise manner the essence of autonomicity: 146 An Autonomic System is a system that operates and serves its 147 purpose by managing its own self without external intervention 148 even in case of environmental changes. 150 Note that the authors explicitly define autonomicity at the system 151 level, not at the node level. They go on to list the minimum set of 152 properties that an autonomic system should possess. Namely, an 153 autonomic system is 155 o automatic, i.e. it can "self-control its internal functions and 156 operations" 158 o adaptive, i.e. it can change its "configuration, state and 159 functions", and 161 o aware, i.e. it can "monitor its operational context". 163 In principle, an autonomic system could wholly replaces a non- 164 autonomic one. In practice, however, real-world deployments will 165 include legacy network elements and services as well as new autonomic 166 ones. 168 A salient paper in the autonomic networking area is [FOCALE], in 169 which Strassner et al. lay the foundation for an autonomic network 170 architecture. We will not delve into the details of FOCALE, but we 171 do note that the authors define three types of managed components 172 according to their autonomic capabilities. In the remainder of this 173 document we consider that FOCALE "components" equate to network 174 resources as defined in [RFC7426], i.e. each network resource is a 175 "physical or virtual component available within a system", and expand 176 these definitions further. 178 In this sense, legacy equipment can be seen as autonomically unaware 179 resources, and can only be managed using traditional mechanisms. In 180 practice, field equipment could be upgraded to support certain 181 autonomic features, thus becoming autonomically-aware managed network 182 resources. This type of network element would typically require a 183 mediation layer as suggested in [FOCALE] or at the very least certain 184 system software updates. Finally, a deployment could include fully 185 autonomically-enabled network resources. FOCALE explicitly aims to 186 "accommodate legacy components" and foresees the deployment of an 187 autonomic manager "that orchestrates the behaviour of other autonomic 188 components in the system." 190 Figure 1 illustrates a simple sketch of an autonomic networking 191 control loop, based on Fig. 2 of [FOCALE]. In short, an autonomic 192 manager gathers data from the managed resource(s), evaluates the 193 current state, compares it with the desired one, and configures the 194 managed resource as necessary. As illustrated, this simple system 195 possess the minimum set of properties introduced above. 197 +---------------------+ 198 (Maintenance Loop) | Actual vs. desired | Autonomic manager 199 +-------------->| state evaluation | 200 | | and decision making | 201 | +---------o-----------+ 202 v | 203 +----------------+ | New configuration 204 | Data gathering | | (Adjustment Loop) 205 +----------------+ | 206 ^ v 207 | +------------------+ 208 +----------------o Managed resource | 209 +------------------+ 211 Figure 1: Simple sketch of an autonomic networking control loop 213 All three types of network resources (i.e. autonomically-unaware, 214 autonomically-aware, and autonomically-enabled) need to be managed. 215 One viable approach is proposed by Nguengang et al. [UMFSpec] who 216 describe an architecture based on the definition of two types of 217 management systems depending on the capacity of the underlying nodes, 218 namely an Enhanced Legacy Management System (ELMS) or a future 219 management system. In this context, it is worth considering the 220 approaches taken in other disciplines. For example, in aviation, 221 auto-navigation systems solve this challenge by means of distributed 222 consensus among an odd-number of controllers/managers that 223 independently carry out the tasks of data gathering and state 224 evaluation, and then make an election for each decision. On the 225 other hand, biologically-inspired systems have emergent coordination 226 (of managers) following principles such as entropy or mass action. 228 Finally, autonomic properties are highly desirable in the context of 229 new mobile architectures. For example, Barth and Kuehn [SON4G] 230 discuss the need for self-* properties in the context of small cell 231 deployments in 3GPP 4G/LTE, while Hamalainen et al. [LTESON] provide 232 a comprehensive guide and handy references to the efforts in 3GPP 233 along these lines. 235 3. Operational Considerations and Outlook 237 This section briefly describes emerging operational considerations 238 that in the authors' view should be taken into account as we move 239 forward with autonomic networking standardization in the IETF and 240 IRTF context. 242 3.1. New Deployment Models 244 Strassner et al. [FOCALE] highlight that an important goal of 245 autonomics is "making the life of the user easier by changing the 246 focus from a computer-centric to a task-centric model". Deployment 247 of new network technologies is typically a time-consuming, labour- 248 intensive and cumbersome task. In the past, we have seen that if the 249 newly designed infrastructure cannot be managed satisfactorily, 250 adverse results such as service launch delays may be inevitable. As 251 we move forward with new deployment models which are oriented towards 252 softwarized and cloudified network functions, autonomic networking 253 principles may prove invaluable. 255 As per [TAN], autonomic systems are by design programmable, which 256 bodes well with the emerging deployment models which emphasize 257 agility and shorter technology introduction cycles. We argue that 258 autonomic networking definitions, goals and gap analysis within the 259 context of IETF standardization should take this more into 260 consideration. Further, recent initiatives such as SUPA 261 [I-D.pentikousis-supa-mapping] point towards infrastructures which 262 are managed through intent (generic policies), for instance, as 263 opposed to network element specific configuration. 265 3.2. Programmable Network Elements and Functions 267 Although the development of models such as FoRCES [RFC5812] coincided 268 with the core of the above-mentioned autonomic networking research 269 literature, by and large, the two areas did not cross-pollinate. It 270 appears that as SDN and NFV principles reach a wider audience of 271 researchers and practitioners, fully programmable network elements 272 and functions could be further introduced in autonomic networking 273 architectures. Indeed, moving towards a "task-centric model" relates 274 well with other efforts in IETF such as SFC [RFC7498] 276 3.3. Autonomic Planes 278 Recent work at the SDNRG [RFC7426] highlighted the need for the wider 279 SDN community to think in terms of control, management, and 280 operational planes comprehensiveness and complementarity. As we have 281 seen above, earlier work in autonomic networking has been primarily 282 focusing on management aspects (cf. [UMFSpec]), while recent work in 283 NMRG is focusing on standardizing an autonomic networking control 284 plane [I-D.behringer-autonomic-control-plane]. 286 For an autonomic plane, there is the challenge on "which 287 functionality to place where". For example, one could consider an 288 architecture in which all three planes have autonomic features. 289 Alternatively, one could adopt a knowledge plane approach [KP2003] 290 establishing a separate, virtual/logical plane. A way forward could 291 be to consider autonomics in NMRG in the context of programmable 292 networks and through a more comprehensive manner. 294 3.4. DevOps 296 John et al. [NSC] elaborate on the concept of continuous network 297 service delivery. In this context, the authors argue for the need of 298 programmable observation points which could be inserted in a dynamic 299 service chain on demand. They expect that future service provider 300 DevOps would require new management technologies "based on the 301 experience from data centers" thus "addressing the challenges of 302 dynamic service chaining". This bodes well with the model 303 illustrated in Figure 1 and we could expect more results in this 304 direction in the future. 306 3.5. Autonomic Monitoring 308 Network monitoring is related to the mechanisms employed to perform 309 measurements and collect the respective results. These mechanisms 310 are some of the most important tools employed by network 311 administrators. Monitoring results encompass metrics such as delay 312 (one-way or round-trip), jitter, throughput, packet loss, protocol/ 313 application usage, among others. Results can be used in different 314 contexts, such as pre-deployment validation and measurement of in- 315 band live network performance characteristics, and by several 316 applications, such as intrusion detection and lawful interception. 318 Traditional (i.e., non-autonomic) monitoring mechanisms usually rely 319 on the predetermined production of measurements results. Thus, such 320 mechanisms are not able to dynamically adapt to different operational 321 conditions during runtime. On the other hand, autonomic monitoring 322 mechanisms are able to adjust themselves in order to optimize their 323 operation. This can be done using several techniques, such as 324 reinforcement learning and neural networks. 326 Several classifications have been proposed regarding autonomic 327 monitoring. Samaan and Karmouch [SK09] discuss a classification 328 methodology for autonomic monitoring methods in the context of an 329 analysis of current and future research directions of autonomic 330 network management. The authors provide a classification of 331 autonomic monitoring approaches considering the following classes: 332 active versus passive monitoring and distributed versus centralized 333 monitoring. The authors also comment on monitoring granularity 334 (measurements can be performed at the byte-, packet-, flow- or 335 aggregated-traffic levels); monitoring timing (fixed time, event- 336 based, and on-demand); and monitoring programmability (levels on what 337 the monitoring mechanism itself can dynamically modify with respect 338 to its operation). 340 In the following we provide a set of literature pointers to 341 monitoring systems which exhibit autonomic features. Note that such 342 mechanisms exhibit different levels of autonomic monitoring 343 functionality and employ different techniques to support this 344 functionality. 346 Massie et al. [MCC04] proposed Ganglia, a scalable, distributed 347 system monitor tool for high-performance computing systems such as 348 clusters and grids. This system is based on a hierarchical design 349 targeted at federations of clusters and it relies on a multicast- 350 based listen/announce protocol to monitor state within network nodes. 351 Using a set of programmable interfaces, Ganglia follows a passive 352 distributed monitoring approach where monitoring programmability is 353 left to the applications. 355 Song et al. [SQZ06] proposed NetQuest, a centralized monitoring 356 control of active measurement mechanisms with self-programmability 357 features. NetQuest models the selection of monitoring 358 functionalities and uses Bayesian experimental design concepts to 359 define the solution parameters. 361 Duarte et al. [DNGT11] proposed ManP2P-ng, a system focused in 362 materializing distributed self-healing features through the use of 363 P2P management overlays and high-level descriptions called workplans. 364 Workplans are used to set up the self-healing parameters regarding 365 managed devices and management peers. The self-healing service is 366 composed of independent monitoring and healing services. 368 Sekar et al. [SRWZKA08] proposed CSAMP, a centralized optimization 369 engine for system-wide flow monitoring. The main features of CSAMP 370 are the use of traffic information to steer flow sampling and hash- 371 based packet selection through a centralized engine for the 372 distribution of measurement responsibilities across routers. 374 Pietro et al. [PHCN10] proposed DECON, a decentralized coordination 375 system aimed at assigning passive monitoring probes. DECON uses 376 traffic information from probes seeing a particular ow to decide 377 which one shoud do the actual monitoring. After that, messages are 378 sent back to probes communicating the decision. 380 4. Acknowledgements 382 This document would not have been possible without the stimulating 383 discussion during the NMRG meeting at IETF 90 in Toronto. Many 384 thanks to all participants. 386 5. IANA Considerations 388 This memo includes no request to IANA. 390 6. Security Considerations 392 This document does not propose a new network architecture or protocol 393 and as such does not have any impact on the security of the Internet. 395 Autonomic networking introduces a range of opportunities for formal 396 verification techniques which could increase trustworthiness, 397 although this is clearly beyond the scope of this first version of 398 this document. Interested readers should consult [ACSec] for an 399 early exploration of the issues at hand in the context of autonomic 400 computing. 402 7. Informative References 404 [ACDawn] Ganek, A. G., and T. A. Corbi, "The dawning of the 405 autonomic computing era", IBM systems Journal, 42(1), 5-18 406 , 2003. 408 [ACSec] Chess, D. M., Palmer, C. C., and S. R. White, "Security in 409 an autonomic computing environment", IBM systems Journal, 410 42(1), 107-118 , 2003. 412 [ANA] Bouabene, G., Jelger, C., Tschudin, C., Schmid, S., 413 Keller, A., and M. May, "The autonomic network 414 architecture (ANA)", Journal on Selected Areas in 415 Communications, 28(1), 4-14 IEEE, 2003. 417 [DNGT11] Duarte, P. A. P. R., Nobre, J. C., Granville, L. Z., 418 Tarouco, L. M. R., "A P2P-Based Self-Healing Service for 419 Network Maintenance", Proceedings of the 12th IFIP/IEEE 420 International Symposium on Integrated Network Management 421 (IM) IEEE, 2011. 423 [FOCALE] Strassner, J., Agoulmine, N., and E. Lehtihet, "FOCALE: A 424 novel autonomic networking architecture", Proc. Latin 425 American Autonomic Computing Symposium (LAACS), Campo 426 Grande, Brazil, July 2006. 428 [GANA] ETSI GS AFI 002, , "Autonomic network engineering for the 429 self-managing Future Internet (AFI): GANA Architectural 430 Reference Model for Autonomic Networking, Cognitive 431 Networking and Self-Management.", April 2013. 433 [I-D.behringer-autonomic-control-plane] 434 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 435 Autonomic Control Plane", draft-behringer-autonomic- 436 control-plane-00 (work in progress), June 2014. 438 [I-D.ietf-i2rs-problem-statement] 439 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 440 Routing System Problem Statement", draft-ietf-i2rs- 441 problem-statement-06 (work in progress), January 2015. 443 [I-D.irtf-nmrg-an-gap-analysis] 444 Jiang, S., Carpenter, B., and M. Behringer, "General Gap 445 Analysis for Autonomic Networking", draft-irtf-nmrg-an- 446 gap-analysis-05 (work in progress), March 2015. 448 [I-D.irtf-nmrg-autonomic-network-definitions] 449 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 450 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 451 Networking - Definitions and Design Goals", draft-irtf- 452 nmrg-autonomic-network-definitions-07 (work in progress), 453 March 2015. 455 [I-D.pentikousis-supa-mapping] 456 Pentikousis, K. and D. Zhang, "Simplified Use of Policy 457 Abstractions (SUPA): Configuration and Policy Mapping", 458 draft-pentikousis-supa-mapping-04 (work in progress), 459 March 2015. 461 [KP2003] Clark, D. D., Partridge, C. , et al., "A Knowledge Plane 462 for the Internet", Proc. SIGCOMM, Karlsruhe, Germany ACM, 463 August 2003. 465 [LTESON] Hamalainen, S., Sanneck, H., and C. Sartori, "LTE Self- 466 Organising Networks (SON): Network Management Automation 467 for Operational Efficiency", John Wiley & Sons , 2012. 469 [MCC04] Massie, M.L. and Chun, B.N. and Culler, D.E., "The ganglia 470 distributed monitoring system: design, implementation, and 471 experience", Parallel Computing, vol. 30, no. 7, pp. 472 817-840 Elsevier, 2004. 474 [NSC] John, W., Pentikousis, K., et al., "Research directions in 475 network service chaining", Proc. SDN for Future Networks 476 and Services (SDN4FNS), Trento, Italy IEEE, November 2013. 478 [PHCN10] di Pietro, A. and Huici, F. and Costantini, D. and 479 Niccolini, S., "DECON: Decentralized Coordination for 480 Large-Scale Flow Monitoring", Proceedings of the IEEE 481 Conference on Computer Communications (INFOCOM) Workshops 482 IEEE, 2010. 484 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 485 Element Separation (ForCES) Forwarding Element Model", RFC 486 5812, March 2010. 488 [RFC7426] Haleplidis, E., Pentikousis, K., Denazis, S., Hadi Salim, 489 J., Meyer, D., and O. Koufopavlou, "Software-Defined 490 Networking (SDN): Layers and Architecture Terminology", 491 RFC 7426, January 2015. 493 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 494 Application-Based Network Operations", RFC 7491, March 495 2015. 497 [RFC7498] Quinn, P. and T. Nadeau, "Problem Statement for Service 498 Function Chaining", RFC 7498, April 2015. 500 [SK09] Samaan, N. and A. Karmouch, "Towards Autonomic Network 501 Management: an Analysis of Current and Future Research 502 Directions", Communications Surveys & Tutorials, vol. 11, 503 no. 3, pp. 22-36 IEEE, 2009. 505 [SON4G] Barth, U., and E. Kuehn, "Self-organization in 4G mobile 506 networks: Motivation and vision", Proc. 7th International 507 Symposium on Wireless Communication Systems (ISWCS), York, 508 UK, pp. 731-735, IEEE, September 2010. 510 [SQZ06] Song, H. H., Qiu, L., Zhang, Y., "NetQuest: a flexible 511 framework for large-scale network measurement", ACM 512 SIGMETRICS Performance Evaluation Review, Vol. 34. No. 1. 513 ACM, 2006. 515 [SRWZKA08] 516 Sekar, V. and Reiter, M.K. and Willinger, W. and Zhang, H. 517 and Kompella, R.R. and Andersen, D. G., "CSAMP: a system 518 for network-wide flow monitoring", Proceedings of the 5th 519 USENIX Symposium on Networked Systems Design and 520 Implementation (NSDI) USENIX, 2008. 522 [SelfFI] Chaparadza, R., Papavassiliou, S., et al., "Creating a 523 viable Evolution Path towards Self-Managing Future 524 Internet via a Standardizable Reference Model for 525 Autonomic Network Engineering", Future Internet Assembly 526 (pp. 136-147) IOS Press, 2009. 528 [TAM07] Jennings, B., van der Meer, s. et al., "Towards autonomic 529 management of communications networks", Communications 530 Magazine, vol. 45, no. 10, pp. 112-121 IEEE, 2007. 532 [TAN] Schmid, S., Sifalakis, M., and D. Hutchison, "Towards 533 autonomic networks", Proc. Autonomic Networking, LNCS 534 4195, pp. 1-11 Springer, 2006. 536 [UMFSpec] Nguengang, G. (ed.), et al., "UMF Specifications, Release 537 1", FP7-UNIVERSELF-Deliverable D2.1 , July 2011. 539 Authors' Addresses 541 Kostas Pentikousis 542 EICT GmbH 543 EUREF-Campus Haus 13 544 Torgauer Strasse 12-15 545 10829 Berlin 546 Germany 548 Email: k.pentikousis@eict.de 550 Manolis Sifalakis 551 University of Basel 552 Bernoullistrasse 16 553 4056 Basel 554 Switzerland 556 Email: sifalakis.manos@unibas.ch 558 Jeferson Campos Nobre 559 Federal University of Rio Grande do Sul 560 Institute of Informatics 561 Porto Alegre 562 Brazil 564 Email: jcnobre@inf.ufrgs.br