idnits 2.17.00 (12 Aug 2021) /tmp/idnits36668/draft-papadimitriou-design-principles-evolution-00.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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 356 has weird spacing: '...ern the archi...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 21, 2012) is 3652 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 201, but not defined == Missing Reference: 'FIArch' is mentioned on line 703, but not defined == Missing Reference: 'RFC6077' is mentioned on line 703, but not defined == Unused Reference: 'Clark05' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'Clark88' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'Conti04' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'Dening05' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'Feldman07' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'Fogel66' is defined on line 789, but no explicit reference was found in the text == Unused Reference: 'Goldsmith02' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'Haapola05' is defined on line 798, but no explicit reference was found in the text == Unused Reference: 'Hakala06' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'Hilborn04' is defined on line 809, but no explicit reference was found in the text == Unused Reference: 'Johnsson03' is defined on line 825, but no explicit reference was found in the text == Unused Reference: 'Kempf04' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'Liu05' is defined on line 836, but no explicit reference was found in the text == Unused Reference: 'Prasad08' is defined on line 846, but no explicit reference was found in the text == Unused Reference: 'RFC793' is defined on line 849, but no explicit reference was found in the text == Unused Reference: 'RFC1631' is defined on line 855, but no explicit reference was found in the text == Unused Reference: 'RFC1925' is defined on line 858, but no explicit reference was found in the text == Unused Reference: 'RFC2775' is defined on line 864, but no explicit reference was found in the text == Unused Reference: 'Saltzer84' is defined on line 873, but no explicit reference was found in the text == Unused Reference: 'Stevens74' is defined on line 877, but no explicit reference was found in the text == Unused Reference: 'Willinger02' is defined on line 885, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1631 (Obsoleted by RFC 3022) -- Duplicate reference: RFC1958, mentioned in 'RFC3439', was also mentioned in 'RFC1958'. Summary: 5 errors (**), 0 flaws (~~), 27 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Papadimitriou 3 Internet Draft Alcatel-Lucent 4 Intended Status: Informational B. Sales 5 Expires: November 22, 2012 Alcatel-Lucent 6 Th. Zahariadis 7 Synelixis 8 May 21, 2012 10 Internet Architecture Design Principles Evolution 12 draft-papadimitriou-design-principles-evolution-00 14 Abstract 16 The purpose of this draft is to extend RFC 1958 and RFC 3439 17 analysing the design principles that govern the Internet 18 Architecture, evaluate how then have evolved since they were 19 initially introduced and how we expect to evolve in the near future. 20 We describe a number of design principle, discuss their implications 21 on the Internet architecture, design and engineering. 23 The work has been based on the outcome of the ad-hoc European 24 Commission Future Internet Architecture (FIArch) group. 26 Status of this Memo 28 This memo provides information for the Internet community. It does 29 not specify an Internet standard of any kind. Distribution of this 30 memo is unlimited. 32 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) 58 in effect on the date of publication of this document. Please 59 review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. 62 Code Components extracted from this document must include 63 Simplified BSD License text as described in Section 4.e of the 64 Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 This document may contain material from IETF Documents or IETF 68 Contributions published or made publicly available before November 69 10, 2008. The person(s) controlling the copyright in some of this 70 material may not have granted the IETF Trust the right to allow 71 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.1 Terminology . . . . . . . . . . . . . . . . . .. . . . . . 5 84 1.2 Abbreviations/Definitions . . . . . . . . . . .. . . . . . 6 85 2 Preserving certain design principles . . . . . . . . . . . . . 7 86 2.1 Heterogeneity support principle . . . . . . . . . . . . . 7 87 2.2 Scalability and the Amplification Principle . . . . . . . 8 88 2.3 Robustness principle . . . . . . . . . . . . . . . . . . . 9 89 2.4 Loose Coupling principle . . . . . . . . . . . . . . . . . 9 90 2.5 Locality Principle . . . . . . . . . . . . . . . . . . . . 10 91 3. Evidences for augmenting/adapting certain design principles . . 10 92 3.1 Keep it simple, but not "stupid" principle . . . . . .. . . 10 93 3.2 "Minimum Intervention" Principle . . . . . . . . . . .. . . 11 94 3.3 Robustness principle . . . . . . . . . . . . . . . . .. . . 12 95 3.4 Modularity & Adaptability Principle . . . . . . . . .. . . 12 96 3.5 Polymorphism principle (as extension to the modularity 97 principle) . . . . . . . . . . . . . . . . . . . . . . . . 13 98 3.6 Unambiguous naming and addressing principle . . . . .. . . 14 99 3.7 Extending the end-to-end principle . . . . . . . . . .. . . 15 100 4. Conclusions - Evidences of emergence of new seeds . . . . . . . 16 101 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 104 1 Introduction 106 The Internet is the most important information exchange means 107 nowadays. It has become the core communication environment, not only 108 for computers but also for sensors, as well as social and human 109 interactions. Yet, the immense success of Internet has increased the 110 demand for both performance and functionality to fulfill the needs 111 of, e.g. real-time applications, sensor/ad-hoc networks, and mobile 112 networks, but without guarantees that the Internet as we know it 113 today will be able to support them. These new demands and needs 114 combined with the continuous expansion of the Internet 115 (pervasive/ambient networks, vehicular networks, etc.) can up to a 116 certain degree be addressed by means of: 118 i) Capacity investment: incremental infrastructure investment, e.g., 119 more and more bandwidth in wireline, wireless and mobile networks. 120 However, analyses have shown that increasing the bandwidth on the 121 Internet core network will not suffice due to new qualitative 122 requirements in, for example, highly critical services such as e- 123 health applications, clouds of services and clouds of sensors, new 124 social network applications like collaborative 3D immersive 125 environments, new commercial and transactional applications, new 126 location-based services and so on [Jacobson09] [Zahariadis11]; and 128 ii) Capability investment: incremental and reactive improvement of 129 Internet protocols (and when protocol extensions are not possible 130 complement them by means of overlays). For instance, the recent Real 131 Time Collaboration on the World Wide Web (RTC-Web effort) to achieve 132 a standardized infrastructure in Web browsers on which real-time 133 interactive communication between Web users shows that protocols hit 134 performance walls. Hence, these limits range well beyond the 135 classical routing and congestion control challenges of the Internet. 137 Hence, even if it is difficult to provide accurate timeline when 138 applicability of classical engineering practices and associated 139 solutions will reach their objective limits, the functional, 140 performance as well as the structural and quality properties that the 141 Internet architecture is expected to meet (but that cannot be 142 resolved with current or foreseeable paradigms), lead to rethink its 143 foundational principles. 145 This effort is conducted and documented in this I_D without pre- 146 assuming a specific architectural transformation path (evolutionary 147 or not). Design principles have played, are playing and will play a 148 central role in the architecture of the Internet by driving most 149 engineering decisions at conception time but also by operational 150 decisions of ICT systems at running time. With the term design 151 principles, we refer to: 153 i) a set of commonly accepted rules delineating how a designer/an 154 architect can best structure and organize the various architectural 155 components at conception time, and rules guiding, controlling and/or 156 regulating a proper and acceptable behaviour at running time, and 158 ii) a set of fundamental and time invariant laws describing the 159 underlying the working of an engineered artefact. Often cited as the 160 corner stone of the Internet design compared to architectures that 161 rely exclusively on modelling, design principles are not formally 162 defined using a closed mathematical formulation. Classical 163 telecommunication systems (i.e., legacy voice communication) do not 164 consider design principles and derive their model directly from 165 requirements. 167 When it comes to the design of the Internet, the formulation of its 168 principles is a fundamental characteristic that guides the 169 specification of its model. In analyzing the Internet design 170 principles and their evolution, we must remember that technical 171 change is permanent (not necessarily continuous) in the information 172 and communication domain: "in this environment, some architectural 173 principles inevitably change. Principles that seemed inviolable a few 174 years ago are deprecated today. Principles that seem sacred today 175 will be deprecated tomorrow. The principle of constant change is 176 perhaps the only principle of the Internet that should survive 177 indefinitely [RFC1958]. 179 In this context, this I_D aims to review and analyse the application 180 of known design principles in today's and tomorrow's Internet 181 Architecture and evaluate their potential evolution. The proposed 182 analysis has been performed to minimize as much as possible the 183 subjective component that arises when dealing with architectural 184 evolution not derivable from closed mathematical formulation or 185 proof. Analogously to [RFC3439] the ultimate goal of this I_D is not 186 to lay down dogma about how Internet architecture and its underlying 187 protocols should be designed. Rather, it is to convey various 188 guidelines that have been found useful in conducting Internet-related 189 research, and that may be useful to those designing new protocols or 190 evaluating such designs. Finally, inline with the various 191 architectural efforts conducted in the last two decades, it also 192 invites the Internet community at large to initiate 193 investigation/analysis on new design principles that will potentially 194 drive the evolution of the Internet architecture. 196 1.1 Terminology 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in RFC2119 [RFC2119]. 202 1.2 Abbreviations/Definitions 204 It is important to define the terms we have used in our work: 206 o "Architecture" is a set of functions, states, and objects/ 207 information together with their behavior, structure, composition, 208 relationships and spatio-temporal distribution. The specification of 209 the associated functional, object/informational and state models 210 leads to an architectural model comprising a set of components (i.e. 211 procedures, data structures, state machines) and the characterization 212 of their interactions (i.e., messages, calls, events, etc.). Please 213 note that the canonical definition of architecture includes the 214 principles and guidelines governing their design and evolution over 215 time. 217 o "Data" to refer to any organized group of bits a.k.a. data packets, 218 data traffic, information, content (audio, video, multimedia), etc. 220 o "Service" to refer to any action or set of actions performed by a 221 provider (person or system) in fulfillment of a request, which occurs 222 through the Internet (i.e., by exploiting data communication, as 223 defined below) with the ultimate aim of creating and/or providing 224 added value or benefits to the requester(s). Services are the means 225 for users (organizations, public bodies, companies and people) to get 226 controlled access to the available data through the Internet. 228 o "Resource" is any logical or physical component that may be 229 uniquely identified. It may be service resource (e.g. a service 230 component, a service API), or infrastructure resources (e.g. CPU, 231 memory, network interface etc.) 233 o "Design principles" refer to agreed structural and behavioural 234 rules on how a designer/an architect can best structure the various 235 architectural components and describe the fundamental and time 236 invariant laws underlying the working of an engineered artefact. 238 o "Structural and behavioural rules" is a set of commonly accepted 239 and agreed rules serving to guide, control, or regulate a proper and 240 acceptable structure of a system at design time and a proper and 241 acceptable behaviour of a system at running time. 243 o "Time invariance" refers to a system whose output does not depend 244 explicitly on time (this time invariance is to be seen as within a 245 given set of initial conditions due to the technological change and 246 paradigms shifts, the economical constraints, etc.). Robustness and 247 longevity over time is a consequence of this time invariance. 249 o "Engineered artefact" is an object formed/produced by engineering. 251 One of the critical points that we have faced many times during our 252 analysis has been the term "complexity". There are multiple 253 definitions of the complexity. Within our analysis we have mainly 254 focus on the architectural and communication complexity. Moreover, we 255 define the following terms being used throughout this document: 257 o "Communication" the exchange of "data" (including both control 258 messages and "data") between a source and a sink. 260 o "Communication end-point" the physical or logical source and sink 261 of information. The communication end-point can be considered to be 262 an application, a service, a process, a protocol, a node, a network. 264 o "End-to-end communication" a communication that takes place between 265 communication end-points of the same physical or logical functional 266 level. 268 o "Module" is a unity that represents functions. It could be 269 considered as a physical or logical unity. 271 o "Security" is a process of taking into account all major 272 constraints. Security includes: Robustness, Confidentiality and 273 Integrity. 275 o "Robustness" is the degree to which a system operates correctly in 276 the presence of exceptional inputs or stressful environmental 277 conditions [IEEE-610]. 279 o "Confidentiality" is the property of "ensuring that information is 280 accessible only to those authorized to have access" and is one of the 281 cornerstones of information security [ISO-27002]. 283 o "Integrity" In literature there are multiple definitions of the 284 integrity. Here we consider mainly the "data integrity" and "system 285 integrity". 287 2 Preserving certain design principles 289 We start our analysis by highlighting design principles that apply to 290 current Internet and provide arguments why they should be preserved 291 also in the future. 293 2.1 Heterogeneity support principle 295 Since the early days of the Internet, heterogeneity is one of its 296 major characteristics. The Internet is characterized by heterogeneity 297 at many levels including: terminal/devices running TCP/IP stack and 298 intermediate nodes running routing function, scheduling algorithms 299 and queuing disciplines applied at intermediate nodes, multiplexing 300 of traffic (bufferless vs. elastic), traffic mix generated by a wide- 301 variety of applications, congestion control operated at multiple 302 spatial and temporal scales, and protocol versions and 303 implementations. 305 It is important to remember that IP (as network function) has been 306 designed as the common denominator among all data link layers 307 themselves relying on various physical medium enabling, e.g., point- 308 to-point (optical), multi-access (Ethernet) links. Heterogeneity is 309 also characteristic of the organic operation of the Internet that 310 comprises many autonomous organizations and service providers 311 reflected by a large heterogeneity of administrative domains, each 312 with their own separate policy (routing, traffic control, charging, 313 etc.). As a result, the heterogeneity principle is proposed to be 314 supported by design [RFC1958]. 316 In the future, the heterogeneity is expected to be much higher than 317 today. Multiple types of terminals/hosts, multiple network nodes, 318 multiple protocols, and multiple applications will exist. Hence, the 319 capability to support heterogeneity should remain as one of the main 320 design principles. 322 2.2 Scalability and the Amplification Principle 324 The need to ensure scalability is of increasing importance. 325 Scalability refers to the ability of a computational system (hardware 326 or software) to continue to function (without making changes to the 327 system) under satisfactory and well specified bounds, i.e., without 328 affecting its performance, when its input is changed in size or 329 volume or in their respective rate of variation. Accounting for the 330 continuous expansion of the Internet (e.g., 10% annual growth rate of 331 the number of AS, 20-25% annual increase of the number of routes), 332 scalability is considered among the major general principles of the 333 Internet: "All designs must scale readily to very many nodes per site 334 and to many millions of sites" [RFC1958]. This principle refers thus 335 to the scale invariant that the global Internet design should meet. 337 Scalability is also closely related with the amplification principle, 338 which states that "there do exist non-linearities which do not occur 339 at small to medium scale, but occur at large scale" [RFC3439]. In 340 other words, "in many large interconnected networks, even small 341 things can and do cause huge events; even small perturbations on the 342 input to a process can destabilize the system's output", and "the 343 design engineer must ensure such perturbations are extremely rare" 344 [RFC3439]. 346 The number of devices with Internet access (e.g., PCs, laptops, smart 347 phones), communication nodes (e.g., home, access, edge and core 348 routers), autonomous systems, applications in the Internet is 349 expected to significantly increase. Moreover, the direct 350 interconnection of sensor networks with the legacy Internet will 351 exponentially increase the number of Internet nodes. If one sees the 352 Internet currently comprising three level of tiers, extension of the 353 Internet at its periphery could expectedly lead to a fourth tier 354 which would have a fundamental impact on the properties of the 355 routing system. As a result, we believe that scalability is among the 356 major design principles that should govern the architecture of the 357 Internet, while the amplification principle would become more 358 prominent as the scale of the Internet increases. 360 2.3 Robustness principle 362 The robustness principle was based on the condition that each 363 protocol implementation must interoperate with other created by 364 different individuals. As there may be different interpretations of 365 the same protocol, each one should "be liberal in what you accept, 366 and conservative in what you send." The fundamental objective of this 367 principle was to maximize interoperability between network protocol 368 implementations, particularly in the face of ambiguous or incomplete 369 specifications. Focusing on the programmable part of the Internet 370 (being software or some programmable components), "Software should be 371 written to deal with every conceivable error, no matter how unlikely. 372 In general, it is best to assume that the network is filled with 373 malevolent entities that will send in packets designed to have the 374 worst possible effect" [RFC1122]. This assumption leads to suitable 375 protective design, although the most serious problems in the Internet 376 have been caused by un-envisaged mechanisms triggered by low- 377 probability events! In the future, the Internet is expected to 378 handle broader spectrum of applications including mission and time 379 critical applications, related with, e.g., health, energy, robotic, 380 transport/logistic (thus well beyond multimedia for entertainment). 382 As a result, part of the robustness principle that covers issues 383 related to minimizing the malfunction, uninterrupted operation and 384 interoperability, remains unchanged. As it is later analysed and 385 argued, the robustness principle should be extended/ adapted to 386 additional cover security issues. 388 2.4 Loose Coupling principle 390 Loose coupling appears to be a necessary condition for a well- 391 structured system and a good design as i) it simplifies testing and 392 troubleshooting procedures because problems are easy to isolate and 393 unlikely to spread or propagate, ii) combined with high cohesion, it 394 supports the general goals of high readability and maintainability, 395 and iii) it minimizes unwanted interaction among system elements. In 396 addition, tightly coupled systems are likely to have unforeseen 397 failure states and implies that the system has less flexibility in 398 recovering from failure states. For these reasons, this design 399 principle shall be preserved and even reinforced as a result of the 400 increasing importance of the availability objective [FIArch11]. 402 Nevertheless, recent evolution shows that loose coupling can also 403 increase difficulty in maintaining synchronization among diverse 404 components within a system when a higher degree of element 405 interdependence is necessary. Hence, loose coupling is important but 406 it would be appropriate to consider that under stress conditions, 407 higher cohesion should be possible for proper functionality. 409 2.5 Locality Principle 411 The locality principle has played a very important role in computer 412 design, programming and the Internet the last decades. Following the 413 principles of spatial and temporal locality, recent computer systems 414 have pushed cache memory to higher levels in the computer systems but 415 the essence remains the same: reflect the chosen methods for using 416 the principles of spatial and temporal locality. In this context, the 417 principles of spatial and temporal locality will have to be extended 418 to distributed computing systems and to the higher layers space of 419 distributed application architectures. On the other hand, locality 420 will play a fundamental role in self- stabilizing distributed systems 421 by ensure sub-linear stabilization with respect to the number of 422 local system components and interactions among components. 424 Based on the above considerations, the locality principle plays an 425 important role and should be preserved, while its scope should be 426 extended to cover additional roles in distributed systems and 427 distributed application architectures. 429 3. Evidences for augmenting/adapting certain design principles 431 In this section we highlight design principles that have been 432 described and still apply to the Internet architecture. Yet, we 433 challenge that they should be adapted in order to address the 434 evolving design objectives of the Internet. 436 3.1 Keep it simple, but not "stupid" principle 438 As already explained, one of the main design principles of the 439 Internet was the approach to keep things simple (the term things 440 refers here in particular to protocols and intermediate systems). If 441 there were many ways to do the same thing, one should choose the 442 simplest one [KISS]. This common sense engineering principle 443 continued requirement to make the usage of network functionality 444 simple and robust, but more processing logic is needed in order to 445 achieve the expected functionality. 447 In Internet design, the complexity belongs at the edges, and the IP 448 layer of the Internet remains as simple as possible. Complex systems 449 are generally less scalable, reliable and flexible. Architectural 450 complexity implies that in order to increase the reliability it is 451 mandatory to minimize the number of components and their interactions 452 in a service delivery path, where the service delivery path can be a 453 protocol path, a software path, or a physical path. However, this 454 principle has already been challenged. Complex problems sometimes 455 require more elaborated solutions and multidimensional problems such 456 as the Internet architecture will be providing non-trivial 457 functionality in many respects. The general problem can be seen as 458 follows: complexity is a global measure of the architecture structure 459 and behaviour. In that respect, arbitrary lowering complexity (over 460 space) might result in local minimum that may be globally 461 detrimental. Hence, the challenge becomes to determine the best 462 placement and distribution of functionality that would globally 463 minimize the architectural complexity. In turn, scalability and 464 simplicity should be handled as strongly interconnected first 465 priority principles of the Internet architecture. 467 3.2 "Minimum Intervention" Principle 469 The principle of minimum intervention states that: "To minimize the 470 scope of information, and to improve the efficiency of data flow 471 through the Encapsulation Layer, the payload should, where possible, 472 be transported as received without modification" [RFC3439]. The 473 minimum intervention principle is critical to maintain and preserve 474 data integrity and to avoid useless intermediate information message 475 or packet processing. 477 Deep Packet Inspection (DPI), Network Address Translation (NAT) and 478 network coding provide three good examples of detrimental 479 intermediate in-band processing of packet flows (note: the two first 480 are also good examples of locally deployed artefact to selfishly 481 compensate delays in adoption of global solutions, e.g., IPv6). 482 Moreover, in some cases, it directly conflicts with the simplicity 483 principle and the complexity minimization principle; e.g., in 484 sensor/machine-to-machine and ambient/pervasive networks where 485 communication gateways (store-and-forward) and actuators meant to 486 enable communication between networks by offloading capabilities that 487 would be costly -or sometimes even impossible- to support on 488 sensors. 490 As a result, the minimum intervention principle should be relaxed to 491 enable wider-variety of intermediate processing at the necessary 492 condition it decreases global complexity. 494 3.3 Robustness principle 496 Over recent years, in order to increase robustness and system 497 reliability, some have advocated to transform this fundamental 498 principle from "be liberal in what you accept, and conservative in 499 what you send" into "be conservative in what you send and be even 500 more conservative in what you accept from others". However, adoption 501 of this approach would result into dropping a significant level of 502 interoperability between protocol implementation. 504 Nevertheless with respect to security, this design principle leads to 505 weak security architecture thus requiring adaptation. Indeed, "it is 506 best to assume that the network is filled with malevolent entities 507 that will send in packets designed to have the worst possible effect. 508 This assumption will lead to suitable protective design" [RFC1122]. 510 Henceforth, we argue that the robustness principle should be adapted 511 to incorporate a self-protection structural and behavioural principle 512 (coordination of the local responses to external intrusions and 513 attacks including traffic, data and services trace back that would 514 enforce in turn accountability) as well as confidentiality, integrity 515 and authentication should be inherently offered to information 516 applications and service. 518 3.4 Modularity & Adaptability Principle 520 Current communication systems are designed as a stack of modules 521 structured by static and invariant binding between layers (modules) 522 that are specified at design time. Indeed, when they were developed 523 CPU and memory were scarce resources and the expected uniformity of 524 their utilisation (computing machine interconnection) lead to a 525 design optimizing the cost/performance ratio at design time. 527 Moreover, [RFC1122] also defines adaptability as a major design 528 principle: "Adaptability to change must be designed into all levels 529 of Internet host software. As a simple example, consider a protocol 530 specification that contains an enumeration of values for a particular 531 header field -- e.g., a type field, a port number, or an error code; 532 this enumeration must be assumed to be incomplete. Thus, if a 533 protocol specification defines four possible error codes, the 534 software must not break when a fifth code shows up." The second part 535 of the principle is almost as important: software on other hosts may 536 contain deficiencies that make it unwise to exploit legal but obscure 537 protocol features. A corollary of this is "watch out for misbehaving 538 hosts"; host software should be prepared, not just to survive other 539 misbehaving hosts, but also to cooperate to limit the amount of 540 disruption such hosts can cause to the shared communication facility. 542 Nowadays, looking at current evolution with i) repetition of 543 functionality across multiple layers, e.g., overlays that allow 544 carrying TDM over IP over Ethernet over IP/MPLS, emphasize the need 545 to define common patterns, monitoring modules repeated over multiple 546 layers (which then requires to recombine information in order to be 547 semantically interpretable) as well as security components each 548 associated to a specific protocol sitting at a given layer (which 549 result into inconsistent response to attacks), ii) as part of the 550 same layer, the proliferation of protocol variants all derived from a 551 kernel of common functions/ primitives, iii) the variability of 552 external and internal events that communication systems have to cope 553 with emphasize that the cost/performance objective to be met by 554 communication systems can vary over time (thus messages would be 555 processed by variable sequence of functions determined at running 556 time), iv) the increasing heterogeneity of environments where 557 communication systems are involved emphasize that some of these 558 functions may be more or less elaborated, and v) Increasing 559 heterogeneity of running conditions as well as increasing occurrence 560 of unexpected events leads to i) consider modules connected by means 561 of realization relationships that supply their behavioural 562 specification, ii) distinguish between general and specialized 563 modules (inheritance), and iii) enable dynamic and variable binding 564 between the different modules such that the sequence of functions 565 performed is specified at running time. 567 This being said, in the current architecture, the transport module is 568 not complete and thus not modular. Indeed the transport address 569 depends on the IP address and more generally its usage relationship 570 does exclusively depend on the existence of other modules in the 571 stack: one can't replace or use a TCP stack without knowledge of how 572 it will impact operations of other modules. 574 3.5 Polymorphism principle (as extension to the modularity principle) 576 Polymorphism (ability to take on different forms) in computer 577 science/programming space applies to data (generalized data type from 578 which a specialization is made) or functions (function that can 579 evaluate to or be applied to values of different types). It enables 580 to manipulate objects of various classes, and invoke methods on an 581 object without knowing that object's type. 583 The introduction of polymorphism principle is driven by the 584 motivation to make use of this fact to make our architecture simpler. 585 In many cases, the modularity and layering principles have been the 586 driving principles for both communication protocols and software 587 implementations. This principle has led to faster deployments, but 588 suboptimal solutions; as such these principles have been challenged 589 in many cases, especially in environments where functions of each 590 layer needs to be carried out completely before the protocol data 591 unit is passed to the next layer. 593 In this context, polymorphism enables to manage and operate first 594 class objects belonging to different kinds of classes (which within a 595 hierarchy often share common methods and attributes) while providing 596 the ability for a super-class to contain different objects of a 597 subclass type at different points in time. In turn, this allows i) 598 for objects of different classes to respond differently to the same 599 function call thus results in different functionality being executed 600 for the same method call, and ii) for run-time (dynamic) instead of 601 compile-time (static) binding. 603 Henceforth, the introduction of polymorphism would enable the same 604 abstract and autonomous loosely coupled components/objects to have 605 different functional and non-functional behaviour under different 606 environments or circumstances. The question remains open though as 607 how to parameterize these environmental variables and whether this 608 parametrization could be performed through distant exchanges 609 (remotely) which would turn this principle close to the concept 610 envisaged by active networks in the late 90's. 612 3.6 Unambiguous naming and addressing principle 614 As stated in [RFC1958], the Internet level protocol are and must 615 independent of the hardware medium and hardware addressing. This 616 approach allows the Internet to exploit any new digital transmission 617 technology of any kind, and to decouple its addressing mechanisms 618 from the hardware. It allows the Internet to be the easy way to 619 interconnect fundamentally different transmission media, and to offer 620 a single platform for a wide variety of Information Infrastructure 621 applications and services. 623 Concerning name and addressing, the following augmentations are 624 considered using [RFC1958] as starting point: 626 o Avoid any design that requires addresses to be hard coded or stored 627 on non-volatile storage. When this address this is an essential 628 requirement as in a name server or configuration server a discovery 629 process is recommended. In general, user applications should use 630 names rather than addresses. In that respect, the transport layer 631 address should be decoupled from any locator and use space invariant 632 identifiers associated to the communication end-point. In turn, this 633 would facilitate dynamic multi-homing, TCP connection continuity 634 (required for mobility) and more generally misuse of IP addresses. 636 o A single and common naming structure should be used. 638 o LOC/ID separation (initially proposed by the NIMROD effort): 639 resulting from the overload of IP address usage, upper layer 640 protocols must be able to determine end-point identifiers (ID) 641 unambiguously, and make use of locators (IP addresses) strictly for 642 end-to-end routing (processing at intermediate nodes) must be the 643 same at start and finish of transmission. This separation involves 644 the need to provide the capability for mapping (or resolving) 645 identifiers to locators at the end-points. Both Identifiers and 646 Locators must be unambiguous and be unique within any scope where 647 they may appear. 649 In the future, it is foreseen that not only the end-points (ID) and 650 their attachment points (LOC) need to be unambiguous and unique 651 within the scope in which they appear and are used, but also the 652 objects, e.g., data files/streams, software components, etc. At the 653 end, in most cases, the user is not willing to access a specific 654 server, but the objects that this server hosts or offers. If exactly 655 the same data (e.g. content, type, quality, security, etc.) and/or 656 associated service (i.e., functional and not functional matching) can 657 be provided in another way (e.g. from another server or method), it 658 is also acceptable and in many cases even preferable if the actual 659 quality is better (or cost lower). 661 Moreover, the current ID/LOC approach only deals with hosts and can 662 not provide a method to ensure that an entity is the one claiming to 663 be or, even worse, they disclose a fixed identifier that can be 664 easily traced by any other network element to know the operations 665 that an entity performs, thus violating its privacy. 667 In near future, naming and addressing as a design principle should be 668 extended to unambiguous identify hosts, resources, data, services. 670 3.7 Extending the end-to-end principle 672 Historically, the "end-to-end principle" has been one of the most 673 controversial issues in the Internet innovation. Many experts in the 674 area insist that the "end-to-end" principle is still valid as it 675 applies as the communication is divided at autonomous legs. However, 676 the clear definition of communication end-points becomes more and 677 more complex to delimit, as middle boxes and application layer 678 gateways are deployed at the edges of networks. 680 AAnother challenge concerning this principle is that IP overlay 681 applications such as IP multicast and mobile IP (MIP), require that 682 specific functionality (RP in ASM, and Home Agent in MIP) is 683 supported and provided by (at least some)intermediate nodes. It is 684 important to notice though that some of these functions and their 685 spatial location (in the end-to-end communication chain) are purely 686 driven by arbitrary choices, e.g., Proxy MIP for mobility management 687 or delayed migrations, e.g., NAT instead of rolling out IPv6. Another 688 challenge comes from the Internet of Things/Smart objects 689 communication, where the end-to-end communication may be 690 significantly modified by intermediate gateways and sensor networks 691 sink nodes. 693 It is also well perceived that for many modern applications (e.g. 694 mobile applications, distributed searching, certain aspects of 695 collaborative computing) maintaining state information within the 696 network may now be desirable for efficiency if not overall 697 performance effectiveness. To argue today that the only stateful 698 elements that may be active in the Internet environment should be 699 located at the edges of the Internet is to ignore the evolution of 700 software and other technologies to provide a host of services 701 throughout the Internet [WGIG04]. 703 Finally, as stated in the [FIArch] and further analyzed in [RFC6077], 704 support of congestion control cannot be realized as a pure end-to-end 705 function: congestion is an inherent network phenomenon that in order 706 to be resolved efficiently require some level of cooperation between 707 end-systems and the shared communication infrastructure. Instead of 708 placing specific functions in specific positions either at end 709 systems or on routers in the network core, these functions must be 710 allowed to be deployed anywhere they are needed [RFC3234]. 712 As a result, we believe that motivations to "update" or augment this 713 principle increase; however even if this principle is challenged, due 714 to the heavy consequence in terms of scalability, survivability and 715 robustness on the Internet at large departing from this principle 716 remains open. 718 4. Conclusions - Evidences of emergence of new seeds 720 In this draft, we have analyzed the evolution of existing design 721 principles and evaluate their potential evolution. From this 722 analysis, we have determined through qualitative but also (and when 723 available quantitative arguments) the design principles that should 724 be preserved, adapted or even augmented. 726 Yet, evidences show that the Internet (and its architecture) 727 progressively evolves from a pure network architecture to an 728 ecosystem interconnecting resources of any type(forwarding, computing 729 and storage and/or their combination) and any type of content or 730 information and be extended to even socio-economic dimensions. 731 Realising such Internet Architecture ecosystem involves new design 732 principles that go well beyond the networking primitives. In this 733 context, new design principles will progressively appear and shape 734 the evolution of the Internet Architecture. However, before being in 735 a position to formulate such principles, one has to explore a 736 multitude of seeds proposed by various architectural work and efforts 737 conducted during the last two decades (some of which are documented 738 in [Papadimitriou12]). A seed for a new design principle refers to a 739 concept or a notion at the inception of a well formulated design 740 principle. The term seed acknowledges that i) formulating principles 741 is a complex exercise, ii) research is still ongoing in proving their 742 value and utility (some of our analysis and exploitation of research 743 results may not be mature enough) but also their impact, and iii) the 744 proposed seeds may not be flourishing (a lot of proposal came in and 745 very few will materialize). 747 The risk is not negligible though that without well formulated and 748 commonly accepted design principles, evolution might lead to hamper 749 the commonality and the genericity of a system that is inherently de- 750 centralized but also organically participative. We consider thus that 751 initiating systematic investigation/analysis on new (seeds of) 752 becomes crucial as the diversity of protocol design choices and 753 decisions in such environment (that would combine more dimensions 754 than network connectivity functionality) becomes such that it may 755 even non-voluntarily harm interoperability 757 5. Acknowledgements 759 This draft has been based on the work from the EC Future Internet 760 Architecture (FIArch) group. The work leading to these results has 761 received funding from the European Union's Seventh Framework 762 Programme (FP7/2007-2013) by a number of projects, including FP7-ICT- 763 COAST, FP7-ICT-REVERIE, FP7-ICT-EINS, and FP7-ICT-EULER. 765 6. References 767 [Clark05] D.D. Clark, J. Wroclawski, K.R. Sollins, R. Braden, Tussle 768 in Cyberspace: Defining Tomorrow's Internet. IEEE/ACM Trans. 769 Networking, Vol.13, Num.3, pp.462-475, June 2005. 771 [Clark88] D.D. Clark, The design philosophy of the DARPA internet 772 protocols, ACM SIGCOMM Computer Communication Review, 773 Vol.18, No.4, August 1988, pp.106-114. 775 [Conti04] M. Conti, G. Maselli, G. Turi, and S. Giordano, "Cross- 776 Layering in Mobile Ad Hoc Network Design," IEEE Computer, 777 Special issue on Ad Hoc Networks, February 2004. 779 [Dening05] Peter J. Denning, The locality principle, Communication 780 of the ACM, Vol.48, No.7, July 2005, pp.19-24. 782 [Feldman07] A. Feldman "Internet Clean-Slate Design: What and Why?" 783 ACM SIGCOMM Computer Communications Review, Vol.37, No.3, 784 July 2007, pp.59-64. 786 [FIArch11] EC FIArch Group, "Fundamental Limitations of current 787 Internet and the path to Future Internet," March 2011. 789 [Fogel66] L.J. Fogel, A.J. Owens, M.J. Walsh, Artificial 790 Intelligence through Simulated Evolution, John Wiley, 791 1966. 793 [Goldsmith02] A.J. Goldsmith, S.B. Wicker, "Design challenges for 794 energy-constrained ad hoc wireless networks," IEEE 795 Wireless Communications Magazine, Vol.9, No.4, 2002, 796 pp.8-27. 798 [Haapola05] J. Haapola, Z. Shelby, C. Pomalaza-Raez, P. Mahonen, 799 "Cross-layer energy analysis of multi-hop wireless sensor 800 networks," 2nd European Workshop on Wireless Sensor 801 Networks (EWSN), Istanbul, Turkey, 2005. 803 [Hakala06] I. Hakala, M. Tikkakoski, "From vertical to horizontal 804 architecture - a cross-layer implementation in a sensor 805 network node," InterSense'06, Proc. of 1st International 806 Conference on Integrated Internet Adhoc and Sensor 807 Networks, Nice, France, May 2006. 809 [Hilborn04] R. Hilborn, "Sea gulls, butterflies, and grasshoppers: A 810 brief history of the butterfly effect in nonlinear 811 dynamics", American Journal of Physics, Vol.72, No.4, 812 pp.425-427. Bibcode 2004, doi:10.1119/1.1636492. 814 [IEEE-610] IEEE Std 610.12.1990 - IEEE Standard Glossary of Software 815 Engineering Terminology. 817 [ISO-27002] International Organization for Standardization (ISO), 818 "Information technology. Code of practice for information 819 security management," ISO 27002, 2005 (replaced ISO-17799). 821 [Jacobson09] V.Jacobson, D.Smetters, J.Thornton, M.Plass, N.Briggs, 822 R. Braynard, "Networking Named Content," Proceeding 823 of ACM CoNEXT 2009. Rome, Italy, December 2009. 825 [Johnsson03] K.B. Johnsson, D.C. Cox, "An adaptive cross-layer 826 scheduler for improved QoS support of mixed data traffic 827 on wireless data systems," in: Vehicular Technology 828 Conference, 6-9 October 2003, pp.1618-1622. 830 [Kempf04] J.Kempf, Ed., R.Austein, Ed., "The Rise of the Middle and 831 the Future of End-to-End: Reflections on the Evolution of 832 the Internet Architecture", IETF, RFC 3724, March 2004. 834 [KISS] "Keep it Simple Stupid". The Jargon File, version 4.4.7. 836 [Liu05] Y. Liu, H. Zhang, W. Gong, D. Towsley "On the Interaction 837 Between Overlay and Underlay Routing," Proc. IEEE INFOCOM 838 2005. 840 [Papadimitriou12] D. Papadimitriou, Th. Zahariadis, P. Martinez-Julia, 841 I. Papafili, V. Morreale, F. Torelli, B. Sales, P. 842 Demeester, "Design Principles for the Future Internet 843 Architecture", Lecture Notes in Computer Science, Vol.7281, 844 May 2012, pp.55-67. 846 [Prasad08] R. Prasad "A Perspective of Layerless Communications," 847 Wireless Personal Communications, 2008, pp.95-100. 849 [RFC793] J. Postel, "Transmission Control Protocol", IETF, RFC 793, 850 September 1981. 852 [RFC1122] R. Braden, Ed., "Requirements for Internet Hosts -- 853 Communication Layers", IETF, RFC 1122, October 1989. 855 [RFC1631] K. Egevang, P. Francis, "The IP Network Address Translator 856 (NAT)," IETF, RFC 1631, May 1994. 858 [RFC1925] R. Callon, "The Twelve Networking Truths," IETF, RFC 859 1925, April 1996. 861 [RFC1958] B. Carpenter, "Architectural Principles of the Internet," 862 IETF, RFC 1958, June 1996. 864 [RFC2775] B. Carpenter, "Internet Transparency", IETF, RFC 2775, 865 February 2000. 867 [RFC3234] B. Carpenter, "Middleboxes: Taxonomy and Issues," IETF, 868 RFC 3234, February 2002. 870 [RFC3439] R. Bush, D. Meyer, "Internet Architectural Guidelines," 871 IETF, RFC 3439 (updates RFC 1958), December 2002. 873 [Saltzer84] J.H. Saltzer, D.P. Reed, and D.D. Clark, "End-To-End 874 Arguments in System Design", ACM Transactions on Computer 875 Systems (TOCS), Vol.2, No.4, November 1984, pp.277-288. 877 [Stevens74] W. Stevens, G. Myers, L. Constantine, Structured Design, 878 IBM Systems Journal, Vol.13, No.2, 1974, pp.115-139. 880 [WGIG04] "The End-End Principle and the Definition of Internet", 881 Working Group on Internet Governance (WGIG) Contribution 882 of Corporation for National Research Initiatives. 883 Prepared by: Patrice A. Lyons, November 10, 2004. 885 [Willinger02] Walter Willinger and John Doyle, "Robustness and the 886 Internet: Design and evolution", 2002 888 [Zahariadis11] Th. Zahariadis, D. Papadimitriou, H. Tschofenig, S. 889 Haller, P. Daras, G. Stamoulis, M. Hauswirth, "Towards 890 a Future Internet Architecture," Book Chapter, "Future 891 Internet Assembly," Lecture Notes in Computer Science, 892 Vol.6656, Springer, 2011, pp.7-18. 894 Authors' Addresses 896 Dimitri Papadimitriou 897 Bell Labs, Alcatel-Lucent, Belgium 898 EMail: dimitri.papadimitriou@alcatel-lucent.com 900 Bernard Sales 901 Bell Labs, Alcatel-Lucent, Belgium 902 EMail: bernard.sales@alcatel-lucent.com 904 Theodore Zahariadis 905 Synelixis, Greece 906 EMail: zahariad@synelixis.com