idnits 2.17.1 draft-ietf-anima-reference-model-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 452: '...ains. The adjacency table MAY contain...' RFC 2119 keyword, line 852: '... control loops SHOULD be able to be ...' RFC 2119 keyword, line 864: '... SHOULD be able to use dynamic APIs ...' RFC 2119 keyword, line 874: '... APIs MUST be able to express and pr...' RFC 2119 keyword, line 882: '...-conditions that MUST be satisfied bef...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2016) is 2847 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Meyer97' is mentioned on line 875, but not defined == Outdated reference: A later version (-05) exists of draft-du-anima-an-intent-03 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-02 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-03 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-06 == Outdated reference: A later version (-07) exists of draft-ietf-anima-prefix-management-00 == Outdated reference: A later version (-06) exists of draft-liu-anima-grasp-api-01 == Outdated reference: A later version (-13) exists of draft-liu-anima-grasp-distribution-01 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA M. Behringer, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational B. Carpenter 5 Expires: January 9, 2017 Univ. of Auckland 6 T. Eckert 7 Cisco 8 L. Ciavaglia 9 P. Peloso 10 Nokia 11 B. Liu 12 Huawei Technologies 13 J. Nobre 14 Federal University of Rio Grande do Sul 15 J. Strassner 16 Huawei Technologies 17 July 8, 2016 19 A Reference Model for Autonomic Networking 20 draft-ietf-anima-reference-model-02 22 Abstract 24 This document describes a reference model for Autonomic Networking. 25 The goal is to define how the various elements in an autonomic 26 context work together, to describe their interfaces and relations. 27 While the document is written as generally as possible, the initial 28 solutions are limited to the chartered scope of the WG. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 9, 2017. 47 Copyright Notice 49 Copyright (c) 2016 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. The Network View . . . . . . . . . . . . . . . . . . . . . . 3 66 3. The Autonomic Network Element . . . . . . . . . . . . . . . . 4 67 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 4 68 4. The Autonomic Networking Infrastructure . . . . . . . . . . . 6 69 4.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.4. Signaling Between Autonomic Nodes . . . . . . . . . . . . 8 73 4.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.6. Intent Distribution (*) . . . . . . . . . . . . . . . . . 9 75 4.7. The Autonomic Control Plane . . . . . . . . . . . . . . . 9 76 5. Behaviour of an Autonomic Node . . . . . . . . . . . . . . . 10 77 6. Security and Trust Infrastructure . . . . . . . . . . . . . . 12 78 6.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 12 79 6.2. Domain Certificate . . . . . . . . . . . . . . . . . . . 12 80 6.3. The MASA . . . . . . . . . . . . . . . . . . . . . . . . 12 81 6.4. Sub-Domains (*) . . . . . . . . . . . . . . . . . . . . . 13 82 6.5. Cross-Domain Functionality (*) . . . . . . . . . . . . . 13 83 7. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 13 84 7.1. General Description of an ASA . . . . . . . . . . . . . . 13 85 7.2. ASA Life-Cycle Management . . . . . . . . . . . . . . . . 15 86 7.3. Specific ASAs for the Enrolment Process . . . . . . . . . 15 87 7.3.1. The Enrolment ASA . . . . . . . . . . . . . . . . . . 15 88 7.3.2. The Enrolment Proxy ASA . . . . . . . . . . . . . . . 16 89 7.3.3. The Registrar ASA . . . . . . . . . . . . . . . . . . 16 90 8. Management and Programmability . . . . . . . . . . . . . . . 16 91 8.1. How an AN Network Is Managed . . . . . . . . . . . . . . 16 92 8.2. Intent (*) . . . . . . . . . . . . . . . . . . . . . . . 17 93 8.3. Aggregated Reporting (*) . . . . . . . . . . . . . . . . 17 94 8.4. Feedback Loops to NOC(*) . . . . . . . . . . . . . . . . 18 95 8.5. Control Loops (*) . . . . . . . . . . . . . . . . . . . . 18 96 8.6. APIs (*) . . . . . . . . . . . . . . . . . . . . . . . . 19 97 8.7. Data Model (*) . . . . . . . . . . . . . . . . . . . . . 19 98 9. Coordination Between Autonomic Functions (*) . . . . . . . . 20 99 9.1. The Coordination Problem (*) . . . . . . . . . . . . . . 20 100 9.2. A Coordination Functional Block (*) . . . . . . . . . . . 21 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 102 10.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . 22 103 10.2. Security Mechanisms . . . . . . . . . . . . . . . . . . 23 104 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 105 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 106 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 109 1. Introduction 111 The document "Autonomic Networking - Definitions and Design Goals" 112 [RFC7575] explains the fundamental concepts behind Autonomic 113 Networking, and defines the relevant terms in this space, as well as 114 a high level reference model. This document defines this reference 115 model with more detail, to allow for functional and protocol 116 specifications to be developed in an architecturally consistent, non- 117 overlapping manner. While the document is written as generally as 118 possible, the initial solutions are limited to the chartered scope of 119 the WG. 121 As discussed in [RFC7575], the goal of this work is not to focus 122 exclusively on fully autonomic nodes or networks. In reality, most 123 networks will run with some autonomic functions, while the rest of 124 the network is traditionally managed. This reference model allows 125 for this hybrid approach. 127 This is a living document and will evolve with the technical 128 solutions developed in the ANIMA WG. Sections marked with (*) do not 129 represent current charter items. While this document must give a 130 long term architectural view, not all functions will be standardized 131 at the same time. 133 2. The Network View 135 This section describes the various elements in a network with 136 autonomic functions, and how these entities work together, on a high 137 level. Subsequent sections explain the detailed inside view for each 138 of the autonomic network elements, as well as the network functions 139 (or interfaces) between those elements. 141 Figure 1 shows the high level view of an Autonomic Network. It 142 consists of a number of autonomic nodes, which interact directly with 143 each other. Those autonomic nodes provide a common set of 144 capabilities across the network, called the "Autonomic Networking 145 Infrastructure" (ANI). The ANI provides functions like naming, 146 addressing, negotiation, synchronization, discovery and messaging. 148 Autonomic functions typically span several, possibly all nodes in the 149 network. The atomic entities of an autonomic function are called the 150 "Autonomic Service Agents" (ASA), which are instantiated on nodes. 152 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 153 : : Autonomic Function 1 : : 154 : ASA 1 : ASA 1 : ASA 1 : ASA 1 : 155 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 156 : : : 157 : +- - - - - - - - - - - - - - + : 158 : : Autonomic Function 2 : : 159 : : ASA 2 : ASA 2 : : 160 : +- - - - - - - - - - - - - - + : 161 : : : 162 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 163 : Autonomic Networking Infrastructure : 164 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 165 +--------+ : +--------+ : +--------+ : +--------+ 166 | Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n | 167 +--------+ : +--------+ : +--------+ : +--------+ 169 Figure 1: High level view of an Autonomic Network 171 In a horizontal view, autonomic functions span across the network, as 172 well as the Autonomic Networking Infrastructure. In a vertical view, 173 a node always implements the ANI, plus it may have one or several 174 Autonomic Service Agents. 176 The Autonomic Networking Infrastructure (ANI) therefore is the 177 foundation for autonomic functions. The current charter of the ANIMA 178 WG is to specify the ANI, using a few autonomic functions as use 179 cases. 181 3. The Autonomic Network Element 183 3.1. Architecture 185 This section describes an autonomic network element and its internal 186 architecture. The reference model explained in the document 187 "Autonomic Networking - Definitions and Design Goals" [RFC7575] shows 188 the sources of information that an autonomic service agent can 189 leverage: Self-knowledge, network knowledge (through discovery), 190 Intent, and feedback loops. Fundamentally, there are two levels 191 inside an autonomic node: the level of Autonomic Service Agents, and 192 the level of the Autonomic Networking Infrastructure, with the former 193 using the services of the latter. Figure 2 illustrates this concept. 195 +------------------------------------------------------------+ 196 | | 197 | +-----------+ +------------+ +------------+ | 198 | | Autonomic | | Autonomic | | Autonomic | | 199 | | Service | | Service | | Service | | 200 | | Agent 1 | | Agent 2 | | Agent 3 | | 201 | +-----------+ +------------+ +------------+ | 202 | ^ ^ ^ | 203 | - - | - - API level - -| - - - - - - - |- - - | 204 | V V V | 205 |------------------------------------------------------------| 206 | Autonomic Networking Infrastructure | 207 | - Data structures (ex: certificates, peer information) | 208 | - Autonomic Control Plane | 209 | - Autonomic Node Addressing | 210 | Discovery, negotiation and synchronisation functions | 211 | - Intent distribution | 212 | - Aggregated reporting and feedback loops | 213 | - Routing | 214 |------------------------------------------------------------| 215 | Basic Operating System Functions | 216 +------------------------------------------------------------+ 218 Figure 2: Model of an autonomic node 220 The Autonomic Networking Infrastructure (lower part of Figure 2) 221 contains node specific data structures, for example trust information 222 about itself and its peers, as well as a generic set of functions, 223 independent of a particular usage. This infrastructure should be 224 generic, and support a variety of Autonomic Service Agents (upper 225 part of Figure 2). The Autonomic Control Plane is the summary of all 226 interactions of the Autonomic Networking Infrastructure with other 227 nodes and services. 229 The use cases of "Autonomics" such as self-management, self- 230 optimisation, etc, are implemented as Autonomic Service Agents. They 231 use the services and data structures of the underlying autonomic 232 networking infrastructure. The underlying Autonomic Networking 233 Infrastructure should itself be self-managing. 235 The "Basic Operating System Functions" include the "normal OS", 236 including the network stack, security functions, etc. 238 Full AN nodes have the full Autonomic Networking Infrastructure, with 239 the full functionality described in this document. At a later stage 240 ANIMA may define a scope for constrained nodes with a reduced ANI and 241 well-defined minimal functionality. They are currently out of scope. 243 4. The Autonomic Networking Infrastructure 245 The Autonomic Networking Infrastructure provides a layer of common 246 functionality across an Autonomic Network. It comprises "must 247 implement" functions and services, as well as extensions. 249 An Autonomic Function, comprising of Autonomic Service Agents on 250 nodes, can rely on the fact that all nodes in the network implement 251 at least the "must implement" functions. 253 4.1. Naming 255 Inside a domain, each autonomic device should be assigned a unique 256 name. The naming scheme should be consistent within a domain. Names 257 are typically assigned by a Registrar at bootstrap time and 258 persistent over the lifetime of the device. All Registrars in a 259 domain must follow the same naming scheme. 261 In the absence of a domain specific naming scheme, a default naming 262 scheme should use the same logic as the addressing scheme discussed 263 in [I-D.ietf-anima-autonomic-control-plane]. The device name is then 264 composed of a Registrar ID (for example taking a MAC address of the 265 Registrar) and a device number. An example name would then look like 266 this: 268 0123-4567-89ab-0001 270 The first three fields are the MAC address, the fourth field is the 271 sequential number for the device. 273 4.2. Addressing 275 Autonomic Service Agents (ASAs) need to communicate with each other, 276 using the autonomic addressing of the Autonomic Networking 277 Infrastructure of the node they reside on. This section describes 278 the addressing approach of the Autonomic Networking Infrastructure, 279 used by ASAs. 281 Out of scope are addressing approaches for the data plane of the 282 network, which may be configured and managed in the traditional way, 283 or negotiated as a service of an ASA. One use case for such an 284 autonomic function is described in 285 [I-D.ietf-anima-prefix-management]. 287 Autonomic addressing is a function of the Autonomic Networking 288 Infrastructure (lower part of Figure 2), specifically the Autonomic 289 Control Plane. ASAs do not have their own addresses. They may use 290 either API calls, or the autonomic addressing scheme of the Autonomic 291 Networking Infrastructure. 293 An autonomic addressing scheme has the following requirements: 295 o Zero-touch for simple networks: Simple networks should have 296 complete self-management of addressing, and not require any 297 central address management, tools, or address planning. 299 o Low-touch for complex networks: If complex networks require 300 operator input for autonomic address management, it should be 301 limited to high level guidance only, expressed in Intent. 303 o Flexibility: The addressing scheme must be flexible enough for 304 nodes to be able to move around, for the network to grow, split 305 and merge. 307 o Robustness: It should be as hard as possible for an administrator 308 to negatively affect addressing (and thus connectivity) in the 309 autonomic context. 311 o Stability: The addressing scheme should be as stable as possible. 312 However, implementations need to be able to recover from 313 unexpected address changes. 315 o Support for virtualization: Autonomic Nodes may support Autonomic 316 Service Agents in different virtual machines or containers. The 317 addressing scheme should support this architecture. 319 o Simplicity: To make engineering simpler, and to give the human 320 administrator an easy way to trouble-shoot autonomic functions. 322 o Scale: The proposed scheme should work in any network of any size. 324 o Upgradability: The scheme must be able to support different 325 addressing concepts in the future. 327 The proposed addressing scheme is described in the document "An 328 Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane]). 330 4.3. Discovery 332 Traditionally, most of the information a node requires is provided 333 through configuration or northbound interfaces. An autonomic 334 function should rely on such northbound interfaces minimally or not 335 at all, and therefore it needs to discover peers and other resources 336 in the network. This section describes various discovery functions 337 in an autonomic network. 339 Discovering nodes and their properties and capabilities: A core 340 function to establish an autonomic domain is the mutual discovery of 341 autonomic nodes, primarily adjacent nodes and secondarily off-link 342 peers. This may in principle either leverage existing discovery 343 mechanisms, or use new mechanisms tailored to the autonomic context. 344 An important point is that discovery must work in a network with no 345 predefined topology, ideally no manual configuration of any kind, and 346 with nodes starting up from factory condition or after any form of 347 failure or sudden topology change. 349 Discovering services: Network services such as AAA should also be 350 discovered and not configured. Service discovery is required for 351 such tasks. An autonomic network can either leverage existing 352 service discovery functions, or use a new approach, or a mixture. 354 Thus the discovery mechanism could either be fully integrated with 355 autonomic signaling (next section) or could use an independent 356 discovery mechanism such as DNS Service Discovery or Service Location 357 Protocol. This choice could be made independently for each Autonomic 358 Service Agent, although the infrastructure might require some minimal 359 lowest common denominator (e.g., for discovering the security 360 bootstrap mechanism, or the source of Intent distribution, 361 Section 4.6). 363 The currently proposed protocol for node discovery is GRASP, 364 described in [I-D.ietf-anima-grasp]. 366 4.4. Signaling Between Autonomic Nodes 368 Autonomic nodes must communicate with each other, for example to 369 negotiate and/or synchronize technical objectives (i.e., network 370 parameters) of any kind and complexity. This requires some form of 371 signaling between autonomic nodes. Autonomic nodes implementing a 372 specific use case might choose their own signaling protocol, as long 373 as it fits the overall security model. However, in the general case, 374 any pair of autonomic nodes might need to communicate, so there needs 375 to be a generic protocol for this. A prerequisite for this is that 376 autonomic nodes can discover each other without any preconfiguration, 377 as mentioned above. To be generic, discovery and signaling must be 378 able to handle any sort of technical objective, including ones that 379 require complex data structures. The document "A Generic Autonomic 380 Signaling Protocol (GRASP)" [I-D.ietf-anima-grasp] describes more 381 detailed requirements for discovery, negotiation and synchronization 382 in an autonomic network. It also defines a protocol, GRASP, for this 383 purpose, including an integrated but optional discovery protocol. 385 GRASP is normally expected to run inside the Autonomic Control Plane 386 (see Section 4.7) and to depend on the ACP for security. It is also 387 capable of using TLS security in the absence of an ACP, and it may 388 run insecurely for a short time during bootstrapping. 390 An autonomic node will normally run a single instance of GRASP, used 391 by multiple ASAs. However, scenarios where multiple instances of 392 GRASP run in a single node, perhaps with different security 393 properties, are not excluded. 395 4.5. Routing 397 All autonomic nodes in a domain must be able to communicate with each 398 other, and with autonomic nodes outside their own domain. Therefore, 399 an Autonomic Control Plane relies on a routing function. For 400 Autonomic Networks to be interoperable, they must all support one 401 common routing protocol. 403 The routing protocol is defined in the ACP document 404 [I-D.ietf-anima-autonomic-control-plane]. 406 4.6. Intent Distribution (*) 408 Intent is the policy language of an Autonomic Network; see 409 Section 8.2 for general information on Intent. The distribution of 410 Intent is also a function of the Autonomic Control Plane. Since 411 Intent is a high level policy, it should change only infrequently 412 (order of days). Therefore, Intent should be simply flooded to all 413 nodes in an autonomic domain, and there is currently no perceived 414 need to have more targeted distribution methods. Intent is also 415 expected to be monolithic, and flooded as a whole. One possible 416 method for distributing Intent is discussed in 417 [I-D.liu-anima-grasp-distribution]. 419 4.7. The Autonomic Control Plane 421 The totality of autonomic interactions forms the "Autonomic Control 422 Plane". This control plane can be either implemented in the global 423 routing table of a node, such as IGPs in today's networks; or it can 424 be provided as an overlay network. The document "An Autonomic 425 Control Plane" ([I-D.ietf-anima-autonomic-control-plane]) describes 426 the details. 428 5. Behaviour of an Autonomic Node 430 This section provides an overview on how the functions in the 431 Autonomic Networking Infrastructure work together, and how the 432 various documents about AN relate to each other. 434 The foundations of Autonomic Networking, definitions and gap analysis 435 in the context of the IETF are described in [RFC7575] and [RFC7576]. 437 Autonomic Networking is based on direct interactions between devices 438 of a domain. The Autonomic Networking Infrastructure (ANI) is 439 normally built on a hop-by-hop basis. Therefore, many interactions 440 in the ANI are based on the ANI adjacency table. There are 441 interactions that provide input into the adjacency table, and other 442 interactions that leverage the information contained in it. 444 The ANI adjacency table contains information about adjacent autonomic 445 nodes, at a minimum: node-ID, IP address in data plane, IP address in 446 ACP, domain, certificate. An autonomic node maintains this adjacency 447 table up to date. The adjacency table only contains information 448 about other nodes that are capable of Autonomic Networking; non- 449 autonomic nodes are normally not tracked here. However, the 450 information is tracked independently of the status of the peer nodes; 451 specifically, it contains information about non-enrolled nodes, nodes 452 of the same and other domains. The adjacency table MAY contain 453 information about the validity and trust of the adjacent autonomic 454 node's certificate, although all autonomic interactions must verify 455 validity and trust independently. 457 The adjacency table is fed by the following inputs: 459 o Link local discovery: This interaction happens in the data plane, 460 using IPv6 link local addressing only, because this addressing 461 type is itself autonomic. This way the nodes learns about all 462 autonomic nodes around itself. This is described in 463 [I-D.ietf-anima-grasp]. 465 o Vendor re-direct: A new device may receive information on where 466 its home network is through a vendor based MASA re-direct; this is 467 typically a routable address. See 468 [I-D.ietf-anima-bootstrapping-keyinfra]. 470 o Non-autonomic input: A node may be configured manually with an 471 autonomic peer; it could learn about autonomic nodes through DHCP 472 options, DNS, and other non-autonomic mechanisms. Generally such 473 non-autonomic mechansims require some administrator intervention. 474 The key purpose is to by-pass a non-autonomic device or network. 476 As this pertains to new devices, it is covered in Section 5.3 of 477 [I-D.ietf-anima-bootstrapping-keyinfra]. 479 The adjacency table is defining the behaviour of an autonomic node: 481 o If the node has not bootstrapped into a domain (i.e., doesn't have 482 a domain certificate), it rotates through all nodes in the 483 adjacency table that claim to have a domain, and will attempt 484 bootstrapping through them, one by one. One possible response is 485 a vendor MASA re-direct, which will be entered into the adjacency 486 table (see second bullet above). See 487 [I-D.ietf-anima-bootstrapping-keyinfra]. 489 o If the node has bootstrapped into a domain (i.e., has a domain 490 certificate), it will act as a proxy for neighboring nodes that 491 need to be bootstrapped. See 492 [I-D.ietf-anima-bootstrapping-keyinfra]. 494 o If the adjacent node has the same domain, it will authenticate 495 that adjacent node and establish the Autonomic Control Plane 496 (ACP). See [I-D.ietf-anima-autonomic-control-plane]. 498 o Other behaviours are possible, for example establishing the ACP 499 also with devices of a sub-domain, to other domains, etc. Those 500 will likely be controlled by Intent. They are outside scope for 501 the moment. Note that Intent is distributed through the ACP; 502 therefore, a node can only adapt Intent driven behaviour once it 503 has joined the ACP. At the moment, ANIMA does not consider 504 providing Intent outside the ACP; this can be considered later. 506 Once a node has joined the ACP, it will also learn the ACP addresses 507 of its adjacent nodes, and add them to the adjacency table, to allow 508 for communication inside the ACP. Further interactions will now 509 happen inside the ACP. At this moment, only negotiation / 510 synchronization via GRASP [I-D.ietf-anima-grasp] is being defined. 511 (Note that GRASP runs in the data plane, as an input in building the 512 adjacency table, as well as inside the ACP.) 514 Autonomic Functions consist of Autonomic Service Agents (ASAs). They 515 run logically above the AN Infrastructure, and may use the adjacency 516 table, the ACP, negotiation and synchronization through GRASP in the 517 ACP, Intent and other functions of the ANI. Since the ANI only 518 provides autonomic interactions within a domain, autonomic functions 519 can also use any other context on a node, specifically the global 520 data plane. 522 6. Security and Trust Infrastructure 524 An Autonomic Network is self-protecting. All protocols are secure by 525 default, without the requirement for the administrator to explicitly 526 configure security. 528 Autonomic nodes have direct interactions between themselves, which 529 must be secured. Since an autonomic network does not rely on 530 configuration, it is not an option to configure for example pre- 531 shared keys. A trust infrastructure such as a PKI infrastructure 532 must be in place. This section describes the principles of this 533 trust infrastructure. 535 The default method to automatically bring up a trust infrastructure 536 is defined in the document "Bootstrapping Key Infrastructures" 537 [I-D.ietf-anima-bootstrapping-keyinfra]. The ASAs required for this 538 enrolment process are described in Section 7.3. An autonomic node 539 must implement the enrolment and enrolment proxy ASAs. The registrar 540 ASA may be implemented only on a sub-set of nodes. 542 6.1. Public Key Infrastructure 544 An autonomic domain uses a PKI model. The root of trust is a 545 certification authority (CA). A registrar acts as a registration 546 authority (RA). 548 A minimum implementation of an autonomic domain contains one CA, one 549 Registrar, and network elements. 551 6.2. Domain Certificate 553 Each device in an autonomic domain uses a domain certificate to prove 554 its identity. [I-D.ietf-anima-bootstrapping-keyinfra] describes how 555 a new device receives a domain certificate, and the certificate 556 format. 558 6.3. The MASA 560 The Manufacturer Authorized Signing Authority (MASA) is a trusted 561 service for bootstrapping devices. The purpose of the MASA is to 562 provide ownership tracking of devices in a domain. The MASA provides 563 audit, authorization, and ownership tokens to the registrar during 564 the bootstrap process to assist in the authentication of devices 565 attempting to join an Autonomic Domain, and to allow a joining device 566 to validate whether it is joining the correct domain. The details 567 for MASA service, security, and usage are defined in 568 [I-D.ietf-anima-bootstrapping-keyinfra]. 570 6.4. Sub-Domains (*) 572 By default, sub-domains are treated as different domains. This 573 implies no trust between a domain and its sub-domains, and no trust 574 between sub-domains of the same domain. Specifically, no ACP is 575 built, and Intent is valid only for the domain it is defined for 576 explicitly. 578 In the future, alternative trust models can be defined, for example 579 to allow full or limited trust between domain and sub-domain. 581 6.5. Cross-Domain Functionality (*) 583 By default, different domains do not interoperate, no ACP is built 584 and no trust is implied between them. 586 In the future, models can be established where other domains can be 587 trusted in full or for limited operations between the domains. 589 7. Autonomic Service Agents (ASA) 591 This section describes how autonomic services run on top of the 592 Autonomic Networking Infrastructure. 594 7.1. General Description of an ASA 596 An Autonomic Service Agent (ASA) is defined in [RFC7575] as "An agent 597 implemented on an autonomic node that implements an autonomic 598 function, either in part (in the case of a distributed function) or 599 whole." Thus it is a process that makes use of the features provided 600 by the ANI to achieve its own goals, usually including interaction 601 with other ASAs via the GRASP protocol [I-D.ietf-anima-grasp] or 602 otherwise. Of course it also interacts with the specific targets of 603 its function, using any suitable mechanism. Unless its function is 604 very simple, the ASA will need to be multi-threaded so that it can 605 handle overlapping asynchronous operations. It may therefore be a 606 quite complex piece of software in its own right, forming part of the 607 application layer above the ANI. 609 Thus we can distinguish at least three classes of ASAs: 611 o Simple ASAs with a small footprint that could run anywhere. 613 o Complex, multi-threaded ASAs that have a significant resource 614 requirement and will only run on selected nodes. 616 o A few 'infrastructure ASAs' that use basic ANI features in support 617 of the ANI itself, which must run in all autonomic nodes. These 618 are outlined in the following sections. 620 Autonomic nodes, and therefore their ASAs, will be self-aware. Every 621 autonomic node will be loaded with various functions and ASAs and 622 will be aware of its own capabilities, typically decided by the 623 hardware, firmware or pre-installed software. Its exact role may 624 depend on Intent and on the surrounding network behaviors, which may 625 include forwarding behaviors, aggregation properties, topology 626 location, bandwidth, tunnel or translation properties, etc. The 627 surrounding topology will depend on the network planning. Following 628 an initial discovery phase, the device properties and those of its 629 neighbors are the foundation of the behavior of a specific device. A 630 device and its ASAs have no pre-configuration for the particular 631 network in which they are installed. 633 Since all ASAs will interact with the ANI, they will depend on 634 appropriate application programming interfaces (APIs). It is 635 desirable that ASAs are portable between operating systems, so these 636 APIs need to be universal. An API for GRASP is described in 637 [I-D.liu-anima-grasp-api]. 639 ASAs will in general be designed and coded by experts in a particular 640 technology and use case, not by experts in the ANI and its 641 components. Also, they may be coded in a variety of programming 642 languages, in particular including languages that support object 643 constructs as well as traditional variables and structures. The APIs 644 should be designed with these factors in mind. 646 It must be possible to run ASAs as non-privileged (user space) 647 processes except for those (such as the infrastructure ASAs) that 648 necessarily require kernel privilege. Also, it is highly desirable 649 that ASAs can be dynamically loaded on a running node. 651 Since autonomic systems must be self-repairing, it is of great 652 importance that ASAs are coded using robust programming techniques. 653 All run-time error conditions must be caught, leading to suitable 654 recovery actions, with a complete restart of the ASA as a last 655 resort. Conditions such as discovery failures or negotiation 656 failures must be treated as routine, with the ASA retrying the failed 657 operation, preferably with an exponential back-off in the case of 658 persistent errors. When multiple threads are started within an ASA, 659 these threads must be monitored for failures and hangups, and 660 appropriate action taken. Attention must be given to garbage 661 collection, so that ASAs never run out of resources. There is 662 assumed to be no human operator - again, in the worst case, every ASA 663 must be capable of restarting itself. 665 ASAs will automatically benefit from the security provided by the 666 ANI, and specifically by the ACP and by GRASP. However, beyond that, 667 they are responsible for their own security, especially when 668 communicating with the specific targets of their function. 669 Therefore, the design of an ASA must include a security analysis 670 beyond 'use ANI security.' 672 7.2. ASA Life-Cycle Management 674 ASAs operating on a given ANI may come from different providers and 675 pursue different objectives. Whichever the ASA, its management and 676 its interactions with the ANI must follow the same operating 677 principles, hence comply to a generic life-cycle management model. 679 The ASA life-cycle provides standard processes to: 681 o install ASA: copy the ASA code onto the host and start it, 683 o deploy ASA: associate the ASA instance with a (some) managed 684 network device(s) (or network function), 686 o control ASA execution: when and how an ASA executes its control 687 loop. 689 The life-cyle will cover the sequential states below: Installation, 690 Deployment, Operation and the transitional states in-between. This 691 Life-Cycle will also define which interactions ASAs have with the ANI 692 in between the different states. The noticeable interactions are: 694 o Self-description of ASA instances at the end of deployment: its 695 format needs to define the information required for the management 696 of ASAs by ANI entities 698 o Control of ASA control-loop during the operation: a signaling has 699 to carry formatted messages to control ASA execution (at least 700 starting and stopping control loop) 702 7.3. Specific ASAs for the Enrolment Process 704 The following ASAs provide essential, required functionality in an 705 autonomic network, and are therefore mandatory to implement on 706 unconstrained autonomic nodes. 708 7.3.1. The Enrolment ASA 710 This section describes the function of an autonomic node to bootstrap 711 into the domain with the help of an enrolment proxy (see previous 712 section). This ASA must be installed by default on all nodes that 713 require an autonomic zero-touch bootstrap. [tbc] 715 7.3.2. The Enrolment Proxy ASA 717 This section describes the function of an autonomic node that helps a 718 non-enrolled, adjacent devices to enrol into the domain. This ASA 719 must be installed on all nodes. [tbc] 721 7.3.3. The Registrar ASA 723 This section describes the registrar function in an autonomic 724 network. It explains the tasks of a registrar element, and how 725 registrars are placed in a network, redundancy between several, etc. 726 This ASA does not need to be installed on all nodes, but only on 727 nodes that implement the Registrar function. [tbc] 729 8. Management and Programmability 731 This section describes how an Autonomic Network is managed, and 732 programmed. 734 8.1. How an AN Network Is Managed 736 Autonomic management usually co-exists with traditional management 737 methods in most networks. Thus, autonomic behavior will be defined 738 for individual functions in most environments. In fact, the co- 739 existence is twofold: autonomic functions can use traditional methods 740 and protocols (e.g., SNMP and NETCONF) to perform management tasks; 741 and autonomic functions can conflict with behavior enforced by the 742 same traditional methods and protocols. 744 The autonomic Intent is defined at a high level of abstraction. 745 However, since it is necessary to address individual managed 746 elements, autonomic management needs to communicate in lower-level 747 interactions (e.g., commands and requests). For example, it is 748 expected that the configuration of such elements be performed using 749 NETCONF and YANG modules as well as the monitoring be executed 750 through SNMP and MIBs. 752 Conflict can occur between autonomic default behavior, autonomic 753 Intent, traditional management methods. Conflict resolution is 754 achieved in autonomic management through prioritization [RFC7575]. 755 The rationale is that manual and node-based management have a higher 756 priority over autonomic management. Thus, the autonomic default 757 behavior has the lowest priority, then comes the autonomic Intent 758 (medium priority), and, finally, the highest priority is taken by 759 node-specific network management methods, such as the use of command 760 line interfaces. 762 8.2. Intent (*) 764 Intent is not covered by the ANIMA charter as of July 2016. This 765 section is for informational purposes only. 767 This section gives an overview of Intent, and how it is managed. 768 Intent and Policy-Based Network Management (PBNM) is already 769 described inside the IETF (e.g., PCIM and SUPA) and in other SDOs 770 (e.g., DMTF and TMF ZOOM). 772 Intent can be described as an abstract, declarative, high-level 773 policy used to operate an autonomic domain, such as an enterprise 774 network [RFC7575]. Intent should be limited to high level guidance 775 only, thus it does not directly define a policy for every network 776 element separately. It is expected Intent definitions from autonomic 777 function(s) and even from traditional network management elements. 779 Intent can be refined to lower level policies using different 780 approaches. This is expected in order to adapt the Intent to the 781 capabilities of managed devices. Intent may contain role or function 782 information, which can be translated to specific nodes [RFC7575]. 783 One of the possible refinements of the Intent is using Event- 784 Condition-Action (ECA) rules. 786 Different parameters may be configured for Intent. These parameters 787 are usually provided by the human operator. Some of these parameters 788 can influence the behavior of specific autonomic functions as well as 789 the way the Intent is used to manage the autonomic domain. 791 Intent is discussed in more detail in [I-D.du-anima-an-intent], 792 Intent distribution in [I-D.liu-anima-grasp-distribution]. 794 8.3. Aggregated Reporting (*) 796 As of July 2016, aggregated reporting is not in the ANIMA charter. 797 This section is provided for information only. 799 Autonomic Network should minimize the need for human intervention. 800 In terms of how the network should behave, this is done through an 801 autonomic Intent provided by the human administrator. In an 802 analogous manner, the reports which describe the operational status 803 of the network should aggregate the information produced in different 804 network elements in order to present the effectiveness of autonomic 805 Intent enforcement. Therefore, reporting in an autonomic network 806 should happen on a network-wide basis [RFC7575]. 808 Several events can occur in an autonomic network in the same way they 809 can happen in a traditional network. However, when reporting to a 810 human administrator, such events should be aggregated to avoid 811 advertisement about individual managed elements. In this context, 812 algorithms may be used to determine what should be reported (e.g., 813 filtering) and in which way and how different events are related to 814 each other. Besides that, an event in an individual element can be 815 compensated by changes in other elements to maintain a network-wide 816 level which is described in the autonomic Intent. 818 Reporting in an autonomic network may be in the same abstraction 819 level of the Intent. In this context, the visibility on current 820 operational status of an autonomic network can be used to switch to 821 different management modes. Despite the fact that autonomic 822 management should minimize the need for user intervention, possibly 823 there are some events that need to be addressed by human 824 administrator actions. 826 8.4. Feedback Loops to NOC(*) 828 Feedback loops are required in an autonomic network to allow the 829 intervention of a human administrator or central control systems, 830 while maintaining a default behaviour. Through a feedback loop an 831 administrator can be prompted with a default action, and has the 832 possibility to acknowledge or override the proposed default action. 834 8.5. Control Loops (*) 836 Control loops are used in autonomic networking to provide a generic 837 mechanism to enable the Autonomic System to adapt (on its own) to 838 various factors that can change the goals that the Autonomic System 839 is trying to achieve, or how those goals are achieved. For example, 840 as user needs, business goals, and the ANI itself changes, self- 841 adaptation enables the ANI to change the services and resources it 842 makes available to adapt to these changes. 844 Control loops operate to continuously observe and collect data that 845 enables the autonomic management system to understand changes to the 846 behavior of the system being managed, and then provide actions to 847 move the state of the system being managed toward a common goal. 848 Self-adaptive systems move decision-making from static, pre-defined 849 commands to dynamic processes computed at runtime. 851 Most autonomic systems use a closed control loop with feedback. Such 852 control loops SHOULD be able to be dynamically changed at runtime to 853 adapt to changing user needs, business goals, and changes in the ANI. 855 The document [I-D.strassner-anima-control-loops] defines the 856 requirements for an autonomic control loop, describes different types 857 of control loops, and explains how control loops are used in an 858 autonomic system. 860 8.6. APIs (*) 862 Most APIs are static, meaning that they are pre-defined and represent 863 an invariant mechanism for operating with data. An Autonomic Network 864 SHOULD be able to use dynamic APIs in addition to static APIs. 866 A dynamic API is one that retrieves data using a generic mechanism, 867 and then enables the client to navigate the retrieved data and 868 operate on it. Such APIs typically use introspection and/or 869 reflection. Introspection enables software to examine the type and 870 properties of an object at runtime, while reflection enables a 871 program to manipulate the attributes, methods, and/or metadata of an 872 object. 874 APIs MUST be able to express and preserve semantics across different 875 domains. For example, software contracts [Meyer97] are based on the 876 principle that a software-intensive system, such as an Autonomic 877 Network, is a set of communicating components whose interaction is 878 based on precisely-defined specifications of the mutual obligations 879 that interacting components must respect. This typically includes 880 specifying: 882 o pre-conditions that MUST be satisfied before the method can start 883 execution 885 o post-conditions that MUST be satisfied when the method has 886 finished execution 888 o invariant attributes that MUST NOT change during the execution of 889 the method 891 8.7. Data Model (*) 893 The following definitions are taken from [supa-model]: 895 An information model is a representation of concepts of interest to 896 an environment in a form that is independent of data repository, data 897 definition language, query language, implementation language, and 898 protocol. In contrast, a data model is a representation of concepts 899 of interest to an environment in a form that is dependent on data 900 repository, data definition language, query language, implementation 901 language, and protocol (typically, but not necessarily, all three). 903 The utility of an information model is to define objects and their 904 relationships in a technology-neutral manner. This forms a 905 consensual vocabulary that the ANI and ASAs can use. A data model is 906 then a technology-specific mapping of all or part of the information 907 model to be used by all or part of the system. 909 A system may have multiple data models. Operational Support Systems, 910 for example, typically have multiple types of repositories, such as 911 SQL and NoSQL, to take advantage of the different properties of each. 912 If multiple data models are required by an Autonomic System, then an 913 information model SHOULD be used to ensure that the concepts of each 914 data model can be related to each other without technological bias. 916 A data model is essential for certain types of functions, such as a 917 MRACL. More generally, a data model can be used to define the 918 objects, attributes, methods, and relationships of a software system 919 (e.g., the ANI, an autonomic node, or an ASA). A data model can be 920 used to help design an API, as well as any language used to interface 921 to the Autonomic Network. 923 9. Coordination Between Autonomic Functions (*) 925 9.1. The Coordination Problem (*) 927 Different autonomic functions may conflict in setting certain 928 parameters. For example, an energy efficiency function may want to 929 shut down a redundant link, while a load balancing function would not 930 want that to happen. The administrator must be able to understand 931 and resolve such interactions, to steer autonomic network performance 932 to a given (intended) operational point. 934 Several interaction types may exist among autonomic functions, for 935 example: 937 o Cooperation: An autonomic function can improve the behavior or 938 performance of another autonomic function, such as a traffic 939 forecasting function used by a traffic allocation function. 941 o Dependency: An autonomic function cannot work without another one 942 being present or accessible in the autonomic network. 944 o Conflict: A metric value conflict is a conflict where one metric 945 is influenced by parameters of different autonomic functions. A 946 parameter value conflict is a conflict where one parameter is 947 modified by different autonomic functions. 949 Solving the coordination problem beyond one-by-one cases can rapidly 950 become intractable for large networks. Specifying a common 951 functional block on coordination is a first step to address the 952 problem in a systemic way. The coordination life-cycle consists in 953 three states: 955 o At build-time, a "static interaction map" can be constructed on 956 the relationship of functions and attributes. This map can be 957 used to (pre-)define policies and priorities on identified 958 conflicts. 960 o At deploy-time, autonomic functions are not yet active/acting on 961 the network. A "dynamic interaction map" is created for each 962 instance of each autonomic functions and on a per resource basis, 963 including the actions performed and their relationships. This map 964 provides the basis to identify conflicts that will happen at run- 965 time, categorize them and plan for the appropriate coordination 966 strategies/mechanisms. 968 o At run-time, when conflicts happen, arbitration is driven by the 969 coordination strategies. Also new dependencies can be observed 970 and inferred, resulting in an update of the dynamic interaction 971 map and adaptation of the coordination strategies and mechanisms. 973 Multiple coordination strategies and mechanisms exists and can be 974 devised. The set ranges from basic approaches such as random process 975 or token-based process, to approaches based on time separation and 976 hierarchical optimization, to more complex approaches such as multi- 977 objective optimization, and other control theory approaches and 978 algorithms family. 980 9.2. A Coordination Functional Block (*) 982 A common coordination functional block is a desirable component of 983 the ANIMA reference model. It provides a means to ensure network 984 properties and predictable performance or behavior such as stability, 985 and convergence, in the presence of several interacting autonomic 986 functions. 988 A common coordination function requires: 990 o A common description of autonomic functions, their attributes and 991 life-cycle. 993 o A common representation of information and knowledge (e.g., 994 interaction maps). 996 o A common "control/command" interface between the coordination 997 "agent" and the autonomic functions. 999 Guidelines, recommendations or BCPs can also be provided for aspects 1000 pertaining to the coordination strategies and mechanisms. 1002 10. Security Considerations 1004 10.1. Threat Analysis 1006 This is a preliminary outline of a threat analysis, to be expanded 1007 and made more specific as the various Autonomic Networking 1008 specifications evolve. 1010 Since AN will hand over responsibility for network configuration from 1011 humans or centrally established management systems to fully 1012 distributed devices, the threat environment is also fully 1013 distributed. On the one hand, that means there is no single point of 1014 failure to act as an attractive target for bad actors. On the other 1015 hand, it means that potentially a single misbehaving autonomic device 1016 could launch a widespread attack, by misusing the distributed AN 1017 mechanisms. For example, a resource exhaustion attack could be 1018 launched by a single device requesting large amounts of that resource 1019 from all its peers, on behalf of a non-existent traffic load. 1020 Alternatively it could simply send false information to its peers, 1021 for example by announcing resource exhaustion when this was not the 1022 case. If security properties are managed autonomically, a 1023 misbehaving device could attempt a distributed attack by requesting 1024 all its peers to reduce security protections in some way. In 1025 general, since autonomic devices run without supervision, almost any 1026 kind of undesirable management action could in theory be attempted by 1027 a misbehaving device. 1029 If it is possible for an unauthorised device to act as an autonomic 1030 device, or for a malicious third party to inject messages appearing 1031 to come from an autonomic device, all these same risks would apply. 1033 If AN messages can be observed by a third party, they might reveal 1034 valuable information about network configuration, security 1035 precautions in use, individual users, and their traffic patterns. If 1036 encrypted, AN messages might still reveal some information via 1037 traffic analysis, but this would be quite limited (for example, this 1038 would be highly unlikely to reveal any specific information about 1039 user traffic). AN messages are liable to be exposed to third parties 1040 on any unprotected Layer 2 link, and to insider attacks even on 1041 protected Layer 2 links. 1043 10.2. Security Mechanisms 1045 The components of the ANI must each include appropriate security 1046 mechanisms. In particular, the ACP must provide security against 1047 interception, forgery, and replay of any messages sent over the ACP. 1048 The signaling protocol may rely on this protection, but must also 1049 provide for security when running without an ACP. All components of 1050 the security bootstrap process must of course themselves be secured. 1051 All ASAs must make use of the ANI's security, and must be carefully 1052 designed so that they do not create security "holes" in the boundary 1053 of the whole AN system. 1055 11. IANA Considerations 1057 This document requests no action by IANA. 1059 12. Acknowledgements 1061 Many people have provided feedback and input to this document: Sheng 1062 Jiang, Roberta Maglione, Jonathan Hansford. 1064 13. References 1066 [I-D.du-anima-an-intent] 1067 Du, Z., Jiang, S., Nobre, J., and L. Ciavaglia, "ANIMA 1068 Intent Policy and Format", draft-du-anima-an-intent-03 1069 (work in progress), March 2016. 1071 [I-D.ietf-anima-autonomic-control-plane] 1072 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 1073 Autonomic Control Plane", draft-ietf-anima-autonomic- 1074 control-plane-02 (work in progress), March 2016. 1076 [I-D.ietf-anima-bootstrapping-keyinfra] 1077 Pritikin, M., Richardson, M., Behringer, M., and S. 1078 Bjarnason, "Bootstrapping Remote Secure Key 1079 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1080 keyinfra-03 (work in progress), June 2016. 1082 [I-D.ietf-anima-grasp] 1083 Bormann, D., Carpenter, B., and B. Liu, "A Generic 1084 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 1085 grasp-06 (work in progress), June 2016. 1087 [I-D.ietf-anima-prefix-management] 1088 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 1089 IPv6 Edge Prefix Management in Large-scale Networks", 1090 draft-ietf-anima-prefix-management-00 (work in progress), 1091 January 2016. 1093 [I-D.liu-anima-grasp-api] 1094 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 1095 Autonomic Signaling Protocol Application Program Interface 1096 (GRASP API)", draft-liu-anima-grasp-api-01 (work in 1097 progress), June 2016. 1099 [I-D.liu-anima-grasp-distribution] 1100 Liu, B. and S. Jiang, "Information Distribution over 1101 GRASP", draft-liu-anima-grasp-distribution-01 (work in 1102 progress), March 2016. 1104 [I-D.strassner-anima-control-loops] 1105 Strassner, J., Halpern, J., and M. Behringer, "The Use of 1106 Control Loops in Autonomic Networking", draft-strassner- 1107 anima-control-loops-01 (work in progress), April 2016. 1109 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1110 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1111 Networking: Definitions and Design Goals", RFC 7575, DOI 1112 10.17487/RFC7575, June 2015, 1113 . 1115 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 1116 Analysis for Autonomic Networking", RFC 7576, DOI 1117 10.17487/RFC7576, June 2015, 1118 . 1120 Authors' Addresses 1122 Michael H. Behringer (editor) 1123 Cisco Systems 1124 Building D, 45 Allee des Ormes 1125 Mougins 06250 1126 France 1128 Email: mbehring@cisco.com 1129 Brian Carpenter 1130 Department of Computer Science 1131 University of Auckland 1132 PB 92019 1133 Auckland 1142 1134 New Zealand 1136 Email: brian.e.carpenter@gmail.com 1138 Toerless Eckert 1139 Cisco 1141 Email: eckert@cisco.com 1143 Laurent Ciavaglia 1144 Nokia 1145 Villarceaux 1146 Nozay 91460 1147 FR 1149 Email: laurent.ciavaglia@nokia.com 1151 Peloso Pierre 1152 Nokia 1153 Villarceaux 1154 Nozay 91460 1155 FR 1157 Email: pierre.peloso@nokia.com 1159 Bing Liu 1160 Huawei Technologies 1161 Q14, Huawei Campus 1162 No.156 Beiqing Road 1163 Hai-Dian District, Beijing 100095 1164 P.R. China 1166 Email: leo.liubing@huawei.com 1167 Jeferson Campos Nobre 1168 Federal University of Rio Grande do Sul 1169 Av. Bento Goncalves, 9500 1170 Porto Alegre 91501-970 1171 Brazil 1173 Email: jcnobre@inf.ufrgs.br 1175 John Strassner 1176 Huawei Technologies 1177 2330 Central Expressway 1178 Santa Clara, CA 95050 1179 USA 1181 Email: john.sc.strassner@huawei.com