idnits 2.17.1 draft-t2trg-iot-workspaces-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 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.) ** There are 14 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The abstract seems to contain references ([Bergstra1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 583 has weird spacing: '...on body i.e. ...' == Line 724 has weird spacing: '... server data ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A promise-oriented architecture communicates (e.g. intent and data) by authenticated publish-subscribe (aka "pull") methods, for security and predictability. In a workspace, devices MUST not accept control commands imposed upon them by remote "push" methods, as this exposes a security risk and may lead to inconclusive results during uncoordinated pushes (multithreaded access). In the vernacular usage of "control plane" and "data plane", control is asserted through agreed service level policies, and data are exchanged within services to carry out functions. -- The document date (November 17, 2016) is 2716 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Thing-to-Thing Research Group M. Burgess 3 Internet-Draft Independent Researcher 4 Intended status: Informational H. Wildfeuer 5 Expires: May 21, 2017 Cisco 6 November 17, 2016 8 Federated Multi-Tenant Service Architecture for an Internet of Things 9 draft-t2trg-iot-workspaces-00 11 Abstract 13 This draft describes architectural recommendations for a unified 14 concept of Cloud Computing and Internet of Things, based on tried and 15 tested principles from infrastructure science. We describe a 16 functional service architecture that may be applied in the manner of 17 a platform, from the smallest scale to the largest scale, using 18 vendor agnostic principles. The current draft is rooted in the 19 principles of Promise Theory[Bergstra1] and voluntary cooperation. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 21, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements and Promises Language . . . . . . . . . . . . . 3 57 3. Definitions and concepts . . . . . . . . . . . . . . . . . . 3 58 4. Device interconnection . . . . . . . . . . . . . . . . . . . 4 59 5. Federation of agency . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Ownership . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.2. Tenancy and separation of concerns . . . . . . . . . . . 7 62 5.3. Proximity of services to location-sensitive Things . . . 8 63 6. The concept of workspaces . . . . . . . . . . . . . . . . . . 8 64 6.1. Workspaces and namespaces . . . . . . . . . . . . . . . . 8 65 6.2. Workspaces promises . . . . . . . . . . . . . . . . . . . 9 66 6.3. Workspaces as resource clusters . . . . . . . . . . . . . 9 67 6.4. Workspace maintenance . . . . . . . . . . . . . . . . . . 10 68 7. Generic Promise-Oriented Architecture . . . . . . . . . . . . 11 69 7.1. Control . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.2. Services . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7.3. Promises . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.4. Agents and their promises . . . . . . . . . . . . . . . . 13 73 7.5. Standard promises . . . . . . . . . . . . . . . . . . . . 14 74 7.6. Contextual policy-based adaptation . . . . . . . . . . . 14 75 7.7. Change of policy (system intent) . . . . . . . . . . . . 15 76 7.8. Separation of concerns versus timescales . . . . . . . . 15 77 7.9. Device roles per workspace or region . . . . . . . . . . 16 78 7.10. Connectivity and Network Policy . . . . . . . . . . . . . 17 79 8. Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 9. Summary and Outlook . . . . . . . . . . . . . . . . . . . . . 19 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 12. Normative References . . . . . . . . . . . . . . . . . . . . 20 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 The scenario we call the Internet of Things (IoT) is an inflection 89 point in the development of information local and global 90 infrastructure. We know cloud computing as a commoditization of 91 primary infrastructure resources (also `things') for flexible 92 datacentre hosting. The facilitation of a common platform for the 93 next generation of global commerce presents a challenge of both 94 technological and human dimensions. Not only do we have to solve the 95 matter of technology at scale, we must also solve the matter of human 96 dignity and participation. This is a challenge that spans every 97 layer of the software and networking stacks, yet can be described in 98 general terms without the need to specific implementations. That is 99 our goal in this (revised) draft. Only a few new ideas are needed to 100 synthesize this infrastructure, however several old technology 101 practices must be deprecated for scaling and security considerations. 103 A platform for society as a whole must be vendor agnostic at its 104 root, and must leave ample space for vendor specific creativity on 105 top. What distinguishes IoT from past scenarios is the prolific 106 contact surface it will expose to the physical world, embedding 107 devices pervasively in our close environments, and touching every 108 part of human life. At the time of writing, IoT has barely begun to 109 emerge in domestic and industrial settings; however, choices we make 110 now could help or hinder the development of an adequate platform over 111 the coming decades. The proposed architecture not only scales up to 112 large numbers, it also scales down to small devices of low 113 capability; from the largest installations to the smallest, and from 114 the tiniest amounts of data, to vast data-stores collected by 115 scientific computing at the limits of possibility. 117 2. Requirements and Promises Language 119 The term "PROMISE", "PROMISES" in this document are to be interpreted 120 as described in Promise Theory [Bergstra1] 122 When used, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 123 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in RFC 125 2119 [RFC2119]. 127 3. Definitions and concepts 129 IP endpoint A hardware or software agent that is IP addressable, via 130 a TCP/IP capable interface. 132 Static endpoint A hardware or software agent with an IP address 133 (prefix and subnet) that is fixed over the timescale of 134 application service interactions. 136 Mobile endpoint A hardware or software agent whose IP address 137 location can change on the timescale of application service 138 interactions. 140 Application server/service Any agent that promises to respond to 141 requests, from external parties, and perform services of 142 any kind, on a timescale that we may call the application 143 service timescale. 145 Multi-tenant application service A collection of agents housed as 146 tenants within a single host device, each offering 147 different services, with potentially different timescales. 149 Client application An agent that consumes data from an application 150 service, requested either by imposed query or by promised 151 schedule. 153 Application Programmer Interface (API) A set of interfaces that 154 expose remote agents to accessing and overriding of the 155 local autonomy of agents. 157 Standalone Thing (FFD) A full function device (FFD)[OneM2M], with an 158 IP address, that can present its own service gateway or 159 interface to the IP network. 161 Peripheral Thing (RFD) A reduced function device (RFD)[OneM2M], with 162 no IP address, that attaches to a host gateway device as a 163 peripheral, over an arbitrary network (USB, PCIe, CANbus, 164 Profibus, ModBus, wireless sensor network, etc). Devices 165 are addressable, only through the gateway service. This 166 includes portmapped devices. 168 Embedded network Any network (IP or non-IP) that is non-IP routed, 169 i.e. contained within a host endpoint as part of a black 170 box, e.g. isolated NAT, device bus, serial channels. 172 Transducer An agent that consumes a service from another agent, and 173 provides a new service based on the consumed service, e.g. 174 a router, encrypter, compressor, etc. 176 Trust A unilateral policy assessment of one agent by another, 177 concerning its reliability in honouring promises. Trust is 178 not necessarily a transitive property. 180 Partial connectivity A device is said to have partial connectivity 181 if it is unavailable for intervals of time, e.g. due to 182 loss of connectivity, mobility, or power napping. 184 4. Device interconnection 186 A platform that brings computing closer to users, away from 187 specialized datacentres, must be based on plausible assumptions. We 188 assume that devices live in a partially connected environment, of 189 limited reliability: they MUST be fault tolerant to loss of 190 communications, both with other devices, in the course of providing 191 application services, and with trusted sources of information. The 192 minimum level of interdependency is recommended to facilitate this. 194 For a nascent Internet of Things, our focus is naturally drawn to the 195 specialized leaf devices, where data may be produced or consumed. It 196 will take many years to commoditize these sensors and actuators, and 197 their local communication architectures. However, these are only 198 half the picture. `Thing' devices, by design, also communicate with 199 online services deployed `higher up', or `Northbound' in the system, 200 to offload analysis and decision-making. Their physical capabilities 201 thus place them into two broad categories: 203 Standalone devices These are assumed to connect by an IP (or layer 204 3) addressable underlay network. Connectivity is assumed 205 end-to-end, without reference to tunnels or software- 206 defined overlays. Policy-based routing is assumed to be 207 provided end-to-end, and fully decoupled from the hardware 208 and software running on devices. Routing paths may be 209 managed through a namespace registration abstraction which 210 we call workspaces. Segregation and firewalling of certain 211 network regions may be included as part of external network 212 governance design, but will not be considered here. 214 Peripherals These include bare sensors and actuators, which do not 215 possess sufficient onboard resources or software 216 interfaces, may attach to hosting standalone devices that 217 act as a gateway and IP (or layer 3) endpoint on their 218 behalf. 220 Transducers These pass-through devices transformers, converters, 221 encapsulation services, etc 223 +------------------+ 224 | FFD / Standalone |--> IP Endpoint 225 +------------------+ 227 +------------------+ 228 | RFD / Peripheral |--+ 229 +------------------+ | +------------------+ 230 +------| FFD / Standalone |--> IP or L3 endpoint 231 +------------------+ | +------------------+ 232 | RFD / Peripheral |--+ 233 +------------------+ 235 Devices may be standalone (FFD), with service interfaces, or hosted 236 peripherals (RFD), where data are exposed through service interfaces 237 from other buses, e.g. USB, CANbus, MODbus, Profibus, etc. 239 Figure 1 241 Standalone devices are full stack devices that provide data oriented 242 services to data clients 244 Stand-alone devices and transducers can vary considerably in their 245 processing, memory, and connectivity constraints. This architecture 246 assumes a minimum resource level at the stand-alone device, but the 247 device must support `full stack' implementations. In practice, this 248 implies that they contain an embedded OS (e.g. Linux), and are 249 capable of running an agent providing secure service and connectivity 250 interfaces. 252 5. Federation of agency 254 Centralization of intent is a natural form of coordination. However, 255 centralization of command and control (e.g. by API) is not practical 256 in environments where the density of devices and overlapping concerns 257 reaches the level of a pervasive Internet of Things. Legacy 258 technology is pervasively centralized and top-down in nature: 259 requests for domain names and name services, IP address assignment, 260 change management of information records, cloud controllers, service 261 entry points, etc. The barriers to scalable autonomous activity are 262 high. The trend has been to delegate these activities to sub- 263 authorities (multiple queues) to limit scaling bottlenecks, which 264 improves queue latency but not minimum transaction time. In the 265 future, resource management can profit by propagating intentions and 266 desires from the bottom-up, i.e. from the many points of service 267 consumption, with localization to minimize queueing and flooding 268 contention of the independent needs. 270 5.1. Ownership 272 Infrastructure ownership is an important issue in a multi-tenant 273 consumer environment. While some devices can be centrally managed by 274 providers (regardless of owner), many devices in an Internet of 275 Things will be owned by private individuals who will permit 276 management by centralized services. Devices may be managed by: 278 Their owners This applies in particular to personal consumer 279 electronics, phones, cars, domestic appliances, etc, where 280 users need to retain trusted ownership of their personal 281 belongings. 283 A service provider This applies to managed services, factory 284 machinery, fleet vehicles, set-top boxes placed in the 285 home, power controllers, etc, where users do not need to 286 interact with the devices on a management level, but there 287 is an advantage to placing a device as a local presence in 288 a smart environment. 290 5.2. Tenancy and separation of concerns 292 Federation of intent, aka multi-tenancy or diversity, all point to 293 the need for Special Interest Groups (SIG) or workgroups, who 294 specialize within organizations to develop expertise. Software 295 architectures following this pattern are sometimes called 296 microservice architectures. We shall introduce the notion of 297 `workspaces' as a federated infrastructure abstraction designed to 298 wrap one or more of these specialized services under an umbrella 299 abstraction that is easy to understand and work with. A goal of the 300 workspace is to expose only the working parts that need to interact 301 with consumers, e.g. in the same way that one does not expose the 302 inner components of a television or a car. 304 Federation is desirable along a number of lines: 306 o Geographic partitioning (location) 308 o Separation of timescales (fast and slow) 310 o By special interest group (functional) 312 See sections below for further information. 314 5.3. Proximity of services to location-sensitive Things 316 Although user-facing devices, deployed in the field, may be separate 317 from the agencies processing their sensory data, or feeding them 318 guidance (e.g. as policies), it becomes increasingly impractical to 319 transport data over long distances between leaf devices and `cloud' 320 services as the density of deployed devices grows. The logical 321 outcome is therefore a decentralization of the processing cloud 322 itself, so as to bring all necessary resources close to the field- 323 deployed data sources themselves. To scale such a distribution, the 324 data services will naturally associate with private workspaces, which 325 bound the scope of data generated by Things. 327 6. The concept of workspaces 329 6.1. Workspaces and namespaces 331 Workspaces may be thought of as a modernization and generalization of 332 the familiar network domain concept. Workspaces go beyond 333 namespacing, to include federation, collaboration, and segmentation 334 of services. Currently, name domains are typically linked to simple 335 directory services (DNS, Active Directory, LDAP etc) for name-address 336 mapping. These are assigned from some top-down agency, either within 337 an organization or even beyond it, at a regional level. The demands 338 of multi-tenant environments, where shared resources and separate 339 business-processes mix and compete, make these older services less 340 than optimal, though not inherently flawed. It is awkward to 341 separate independent collaborative activities and then manage their 342 interactions on a need-to-know/need-to-do basis, without involving 343 multiple human interventions. Cloud APIs bring some improvement, by 344 exposing arbitrary capabilities to remote operation, but the 345 remoteness also brings risks and inefficiencies by exposing an attack 346 surface, and from lack of situational awareness of actual state. 348 Workspaces are related to the more familiar notion of namespaces in 349 information technology; however, namespaces refer mainly to priority 350 name-referencing of objects, without necessitating underlying 351 resource access segmentation. Workspaces MUST support multi-tenant 352 separation of concerns within a hosted hardware resource space. 353 Today, workspace-like facilities are commonly offered as user logins 354 on computer operating systems or online services, and quasi- 355 workspace-like facilities are offered by virtual private networks, 356 and VLANs, etc, in networking. However, resource management 357 platforms do not yet bring the same level of flexibility to 358 infrastructure. Typically, resources are managed by top-down 359 agencies who design and grant resource usage manually, leading to the 360 insertion of a human processing timescale into the flow of 361 automation. 363 6.2. Workspaces promises 365 Workspaces need to be able to promise segmentation and privacy. This 366 involves some basic capabilities: 368 1. Authorization and user identification for resource access 369 control, within each workspace. 371 2. Multiple compatible user identities in case of a member node 372 belonging to several workspaces. 374 3. Resource separation that is respected by all levels of the 375 software interactions. This requires the support of operating 376 systems. i.e. segmentation at the network, application, and 377 operating system level. For example, Linux containers, systemd 378 containment, network virtualization, etc. 380 4. Service discovery, and registration of capabilities. 382 5. Resource mobility and availability tracking. 384 6. Scaling of information on a need-to-know/need-to-propagate basis, 385 avoiding costly data consistency protocols that broadcast data 386 updates, and lead to waiting. 388 6.3. Workspaces as resource clusters 390 At the time of this revision, many of the properties of workspaces 391 are being explored under the aegis of cloud application cluster 392 managers. Google's Kubernetes [K8S], for example, is presently the 393 most ambitious of these. It is plausible to imagine extending such a 394 system to cover the workspace proposal for both cloud and IoT 395 scenarios. 397 For a collaborative Internet of Things, where interests span many 398 issues from manufacturer interests, to personal ownership, service 399 provider concerns, functional responsibility, and security, etc, the 400 technologies for inter-group collaboration need to be modernized to 401 support logical segmentation, authenticated access, instrumented 402 delegation, shared name-service information, as well as private 403 naming, all across a converged palette of resources: compute, 404 network, storage and sensor-actuators. This is somewhat reminiscent, 405 but not identical, of the goals of Named Data Networking (NDN) [NDN], 406 which promotes the semantics of space above the details of its 407 interconnectivity. 409 1. Workspaces imply scope; i.e. they may or may not be private, but 410 they must be self-contained and separable, in the manner of 411 namespaces. 413 2. Workspaces may or may not be associated with multiple tenants; 414 but they are associated with multiple functional or 415 organizational issues. 417 3. Workspaces represent a context for human activity, respecting 418 separation of concerns. We need not prejudge what aspects of 419 future activity need to embed software-based technologies, but it 420 seems safe to assume no limits. Example workspaces might 421 include: online stores and services, offices, the home, a 422 children's playground, a squash court, a shop, a factory floor, 423 buildings, districts, cities, an emergency communications 424 channel, a subsystem of hot and cold water pipes, a hotel dining 425 room, a personal drinks cabinet, etc. 427 Ubiquitous computing (the Internet of Things) is all about how 428 networked devices support a wider variety of workspaces than 429 industrial scale central services. As the density of device 430 resources (compute, storage, sensors, actuators) in a workplace or 431 home environment increases, isolation of regions, and mapping of 432 resources to responsible or interested parties become more difficult 433 problems, both to implement and to understand. 435 A detailed description of workspaces will be given separately 436 [WORKSPC]. 438 6.4. Workspace maintenance 440 The following characteristics describe compatible policy update 441 processes: 443 1. Devices subscribe to policy from a trusted workspace source, 444 download changes to the policy model when they can, and cache it 445 locally so that it is always available. 447 2. Local agents implement cached policy, without any dependence on 448 remote communication, and in a fault tolerant fashion. The 449 failure to keep one promise should have minimal impact on the 450 ability to keep others. 452 3. By verifying promises continuously, the agent that runs on each 453 standalone device will know (or be able to calculate) its 454 operational context, and can decide which promises are needed 455 from the policy model, and whether or not to keep the promises. 456 This scales O(1), i.e. without bottleneck. 458 4. Each promise that documents and intended outcome of the system is 459 verified and measured in the process, providing immediate and 460 statistical feedback to policy designers about the success of the 461 policy in describing a stable desired outcome. 463 7. Generic Promise-Oriented Architecture 465 The properties we are looking for in workspaces, suggest an 466 architecture based on the principles of promise theory; such a 467 promise-oriented architecture is described implicitly in [DSOM2005] 468 and [Bergstra1]. It lays out a generic `bottom up' management 469 concept, in which devices each have the responsibility for their own 470 state and roles. It resembles Service Oriented Architecture (SOA) 471 superficially, without reference to specific technologies, 472 implementations or protocols, and relates to the modern notion of 473 microservices [MicroS] 475 By formulating architecture from the bottom up, one can easily 476 account for multi-contextual concerns, from developer concerns about 477 realtime software updates (Continuous Delivery and DevOps etc), to 478 operational service scaling, governance, and security, in a way that 479 top-down schemes cannot easily achieve. 481 The relationship between a generic promise-oriented architecture and 482 the concept of a workspace is that the former provides a necessary 483 and sufficient basis for implementing the latter. Workspaces are 484 expected to be a friendly interface to the underlying promise 485 architecture, separating interior and exterior promises cleanly and 486 intuitively. 488 7.1. Control 490 A promise-oriented architecture communicates (e.g. intent and data) 491 by authenticated publish-subscribe (aka "pull") methods, for security 492 and predictability. In a workspace, devices MUST not accept control 493 commands imposed upon them by remote "push" methods, as this exposes 494 a security risk and may lead to inconclusive results during 495 uncoordinated pushes (multithreaded access). In the vernacular usage 496 of "control plane" and "data plane", control is asserted through 497 agreed service level policies, and data are exchanged within services 498 to carry out functions. 500 Every standalone device operates autonomously, with policy guidance 501 from its owner, without direct external intervention. To form a 502 workspace, any standalone device can give up that autonomy to a 503 trusted manager, offering policy updates as a service. Workspaces 504 separate interior and exterior promises about resources and their 505 accessibility: they are a priori opaque from the exterior, and 506 transparent from the interior. By joining a workspace, any device 507 (whether a cloud server or an IoT embedded FFD, subordinates itself 508 to a bounded policy domain with a private namespace. Policy 509 determines whether a given member of the workspace will expose public 510 service entry points, or will be entirely anonymous to exterior 511 agents. This is very close to the community namespace idea currently 512 being implemented in the Kubernetes cloud cluster manager [K8S]. One 513 can imagine a meta-cluster of such cloud clusters, which are designed 514 to tolerate partial network reliability, as forming a basis for the 515 Internet of Things alongside more traditional high reliability 516 datacentre environments. Currently, cluster managers assume top-down 517 ownership, rather than autonomous self-management, and expose more 518 complexity through APIs than is appropriate for average engineers. 520 +--------------------------+-----------------------+ 521 | Workspaces | Cloud clusters | 522 +--------------------------+-----------------------+ 523 | Bootstrap server | Cluster master node | 524 | Standalone device | Application Pod | 525 | Intermittent network | Reliable network | 526 | Network by directory | Network by overlay | 527 | Converged infrastructure | Siloed infrastructure | 528 | Bottom up | Top down | 529 | Unreliable network | Reliable network | 530 | Node members anywhere | Nodes in datacentre | 531 | Master policy source | Master controller | 532 | Need to know | Full consistency | 533 +--------------------------+-----------------------+ 535 Rough correspondence between contemporary cloud clusters and proposed 536 workspace concept: workspaces are principally a bottom-up, self- 537 service collaboration over multiple clusters with more diverse 538 hardware and software. 540 Figure 2 542 7.2. Services 544 All devices provide services with varying degrees of sophistication. 545 Peripheral devices serve data or actuators to host devices, and 546 standalone devices expose functions to one another as software 547 services. Each server plays a role to be composed into the wider 548 system. 550 Services may be used both for basic infrastructure support, and for 551 driving user applications. No limitations need be stated about 552 applications. Each fully functional, standalone device is free to 553 host any application services. The result is superficially similar 554 to the Service Oriented Architecture [SOA], but without reference to 555 a specific technology or methodology. In modern parlance, the model 556 is an example of microservices [MicroS]. 558 Data collection services are also best implemented with pull methods, 559 for resource-light scalability and security. However, extremely 560 limited application devices might initially struggle to support this 561 mode of operation. 563 Service scaling is a task for workspaces. Public (exterior) services 564 can be provided in a standardized manner, through accessible points 565 of entry, whose name information is propagated publicly, analogous to 566 a DNS directory. Workspaces can hide internals (e.g. vendor or 567 implementation specific details, private internal services, load 568 sharing parallelism. 570 Interior name services deal with the registration and propagation of 571 information between workspace members, on a need-to-know basis. This 572 is never visible to the exterior network. 574 7.3. Promises 576 The basic atom of bottom-up policy is a promise. Each promise 577 consists of three things: 579 A `promiser' i.e. a resource that will affect a change by keeping 580 its promise to the system, e.g. a file, a process, a 581 transaction, a measurement, device settings, etc. 583 A description body i.e. the desired-outcome that is achieved when 584 the promise is kept. This SHOULD be implemented in a 585 convergent, idempotent manner, (see [CFENGINE], 586 [CONVERGE]). 588 A context in which the promise applies, based on time, location, type 589 and group membership of the devices referred to in the 590 model. 592 7.4. Agents and their promises 594 In a promise architecture, every device is contextually evaluated and 595 integrated from the bottom up, according to the promises is keeps, 596 e.g. the services it provides, its behaviours and properties, etc. 597 Thus every device is modelled by its individual degree of agency to 598 act as a proxy for human intent (policy). 600 Standalone devices are assumed to be equipped with policy-keeping 601 software agents. Peripheral devices, such as sensors or actuators, 602 are assumed to be integral parts of the standalone devices, and hence 603 maintainable by the their software agents. 605 NO system MUST push changes or data to such agents ad hoc, without a 606 documented promise to accept; thereafter, `fault tolerance' demands 607 that we reject the word `must' from most descriptions, and replace it 608 with `promise of best effort', as to reply on perfect behaviour leads 609 to brittle systems with unrealistic expectations. For human safety 610 in a rapidly expanding sphere of human involvement, the only `must' 611 is for each agent to be stable and self-correcting, subject to the 612 guidance of policy. 614 7.5. Standard promises 616 The following characteristics describe the cooperation between 617 agents: 619 1. Standalone devices promise to bootstrap to some trusted 620 bootservice, i.e. register to one or more workspaces. 622 2. Standalone devices promise to refuse direct commands imposed from 623 network peers (as mentioned above). 625 3. Policy consists of a collection of promises that apply in 626 labelled contexts, each of which describes a unique desired end- 627 state. 629 4. Promises are kept in a convergent manner, so that all promise- 630 keeping actions lead to the desired end-state, no matter what the 631 initial state of the device. 633 5. Agents that live on every device have drivers/renderers and make 634 all changes without remote communication. 636 7.6. Contextual policy-based adaptation 638 Each policy agent promises to maintain a context evaluator that 639 computes a set of classifying `tags' or `labels' that characterize 640 the state of the agent. This is updated every time the agent 641 verifies policy, as its state may change as a result of repairs. 642 These may be used as conditionals for distributed policy-based 643 decision-making. 645 Contextual labels characterize the device, its environment, and its 646 location and time. The labels can then be used in policy to make 647 certain promises apply only in specific contexts. 649 When promises, within a policy, are tagged by issue or context, 650 agents can select those that apply to its condition, within a larger 651 trust relationship implied by policy sourcing. This simplifies logic 652 and promotes stability, as evidenced by experience with software 653 agents [CFENGINE]. 655 7.7. Change of policy (system intent) 657 Policy change can be initiated from within a workspace, subject to a 658 defined quality assurance, or fit-for-purpose review. Thus change of 659 infrastructure may be instigated from the bottom-up also, as a self- 660 service request. 662 1. Human operators (owners or managers) decide on a policy model for 663 all devices in an organization or policy group. This may be 664 informed by the feedback about the success rate of previously 665 kept promises. 667 2. The changes are edited into a model, which consists of a 668 collection of promises that should be kept by all resources on 669 all devices. 671 3. Changes are checked and tested before publishing. 673 4. Once changes are approved, they are published by a policy service 674 for download at the convenience of the standalone device. 676 7.8. Separation of concerns versus timescales 678 Infrastructure stability is supported by a separation of systems into 679 agencies that act in alignment with specific, separable timescales. 680 Separation of fast and slow timescales avoids tight coupling and 681 associated complex behaviours and should be considered a priority for 682 maintaining safe, stable systems for human dependence. 684 Systems scale along two broad lines, which a promise-oriented 685 architecture helps to resolve: 687 Dynamical scaling Workload timescales concern the quantitative 688 activity of the system: how fast requests are handled, how 689 quickly service is delivered, and promises are kept. 691 Semantic (functional) scaling Semantics are normally the concern of 692 software engineers and system designers. This facilitates 693 functional understanding. It is a form of human interface 694 or knowledge management. It is sometimes at odds with the 695 needs of dynamical scaling. 697 Changes to semantics should generally be slow compared to the 698 workload related dynamical activity, in order to maintain functional 699 stability. Cooperative design of workspaces may observe this 700 principle to foster functional stability and workload efficiency. 702 7.9. Device roles per workspace or region 704 A number of functional roles are required to maintain a service 705 lifecycle in a distributed environment. Making these roles self- 706 managed within each workspace is how one scales the diversity of 707 human intent and concerns. Roles are defined by the kinds of 708 promises kept by devices: 710 Bootstrap server To provide trusted need-to-know data and local 711 contacts so that clients can begin working within a policy 712 domain. 714 Bootstrap client To accept essential directory information on trust 715 in order to join a local policy domain. 717 Policy server To deliver current policy from an authorized source, 718 appropriate for each client (tenancy terms) from its global 719 perspective 721 Policy client To subscribe to the policy, selectively, depending on 722 context from its local perspective. 724 Data server data server (aka ``Thing'') To offer a catalogue of data 725 streams to different tenants This includes sensors, 726 actuators. 728 Data Client To subscribe to the policy, selectively, depending on 729 context from its local perspective. 731 Identity server Manufacturer User Description service is promised by 732 all Things providing a URI that points to a description of 733 the device, its serial number characteristics, service 734 details etc. 736 Identity client Identity clients promise to make use of data schemas 737 and encodings involved in the interpretation of data 738 pertaining to the device. 740 Directory service A mutual binding service of published-subscribed 741 registry information, enabling mutual discovery of interior 742 services. 744 "Control data" "Application data" 745 +--------------------------------------------------------------+ 746 |+------------------+ +------------------+ +----------------- +| +-----------------+ 747 || Bootstrap server | | Policy server | | Directory server || | Data client(s) | 748 |+------------------+ +------------------+ +----------------- +| +-----------------+ 749 +--------|---------------------|----------------------|--------+ | 750 | | | | 751 +----------------+ | | | 752 | | | | 753 +------------------+ | | | | 754 | FFD / Standalone | | | | | 755 | Bootstrap client|--+ | | | 756 | Policy client |-------+ | | 757 | Directory server|------------------------------+ | 758 | Data client |--------------------------------------------------+ 759 +------------------+ 761 "Thing(s)" 763 The roles in each collaborative workspace. Devices at the bottom of 764 the figure typically coordinate through workspace services hosted in 765 the "cloud" or any nearby compute resource. Efficiency suggests 766 avoiding long data paths, instead moving computational resources 767 closer to data collection points. 769 Figure 3 771 Bootstrapping new devices into a workspace represents the beginning 772 of a device lifecycle. Devices must begin with the location of a 773 known bootstrap server. Devices must also promise to advertise their 774 nature and capabilities, called `identification'. This may include 775 Manufacturer Usage Description (MUD) identifiers [MUD]. 777 7.10. Connectivity and Network Policy 779 So far, much as been said on how the application devices provide 780 services via promises, and how system intent can be described and 781 orchestrated via policy. There is also a connectivity (transport) 782 fabric for these devices that operates on a set of promises that 783 underly the described service framework, i.e. the network. Each 784 network endpoint can be seen as providing its own set of promises 785 that are used by other network elements to deliver routing and 786 switching capabilities [PromiseNet]. The simplest form of SDN is 787 simply name registration and route management. 789 Intent driven networking is becoming more relevant as Software 790 Defined Networking (SDN) deployments proliferate. In the described 791 IoT architecture, service policies that describe the IoT system 792 intent can be used as an input to derive partial network policies 793 (e.g. Group Based Policy or some other model-based approach), with 794 modulation by other data discovered from bootstrapping, etc. The 795 figure below illustrates the relationship between the service and 796 network layer policies for IoT. 798 +--------------------+ 799 | IoT Service Policy | 800 +--------------------+ 801 | 802 +---------------------+ | +--------------------+ 803 | Topology / Location | | | Orchestration | 804 | +-+-+ 805 | Bootstrap data | | | Organization policy| 806 +---------------------+ | +--------------------+ 807 | 808 \|/ 809 v 810 +--------------------+ 811 | IoT SDN policy | 812 +--------------------+ 814 Service policy could be partially rendered as an SDN baseline for 815 simplifying dependency management. The simplest form of SDN is 816 simply name registration and route management. 818 Figure 4 820 8. Remarks 822 The architecture, described in this draft, enables densely clustered 823 IT resources to form arbitrary self-service communities that span 824 local or wide area networks. This is decouples a logical patchwork 825 of segments on top of a plain end-to-end IP network. By basing on 826 principles of fault-tolerance, including publish-subscribe 827 dissemination semantics, this may be scaled, without bottleneck, by 828 only the well-known methods currently employed by the World Wide Web. 830 IPv6 and successors will play a key role in recapturing network 831 simplicity from the many workarounds that have been stacked on top of 832 IPv4 and its limitations. However, currently missing are adequate 833 directory services to support a transparent workspace concept. The 834 present Internet architecture is still geared principally towards a 835 shared single-tenant, top-down management model, with host authority 836 at the top. Top down methods require the leaf domains to trust (and 837 hence always be exposed to attack from) the layers high up in the 838 network. However, shrink-wrapping workspace boundaries closer around 839 their private resources, this management can be simplified, speeded 840 up, and become less exposed. 842 9. Summary and Outlook 844 The issues discussed and laid out in this draft address key issues of 845 scalability, fault tolerance, separation of concerns, and federation 846 of intent within networked information systems. The platform, 847 described here, is a synthesis of well-known techniques, and is 848 deliberately aligned with the needs of agile commercial spaces, as 849 well as large industrial distributions, and small domestic needs. We 850 purposely leave open vendor specific concerns, which can easily fit 851 into the described architecture, on top of this common set of 852 principles. 854 Interest in using IT to stimulate smart spaces (homes, buildings, 855 vehicles, cities, etc., necessitates a scalable approach to 856 interactive services, in which the service clients are not only 857 humans but sensors and actuators. This cannot be scaled reliably 858 without the segmentation of spacetime itself. Centralized cloud 859 controllers, as we understand them today, cannot plausibly manage 860 stable services for a society to rely on. We propose extending the 861 notion of cloud and IoT to become a single seamless vision, without 862 centralization as the core paradigm. 864 10. Acknowledgments 866 We are grateful for helpful conversations with K. Burns, M. 867 Dvorkin, D. Maluf, and E. Lear. 869 11. Security Considerations 871 With a pervasive contact surface onto both the Internet and the real 872 world, security is obvious a major concern. Experience with 873 pervasive frameworks like [CFENGINE], as well as theoretical studies 874 of pull-based architectures, suggest that the promise-oriented pull- 875 only architecture can reduce the exposure to denial of service 876 attacks and data-based overflow attacks, by rejecting all external 877 data sent without invitation. Moreover, the tie-in between service 878 and network policy reduces the likelihood of errors in policy across 879 the layers. 881 Workspaces can play a role too here, as a shrink-wrapping of service 882 scope around minimal set of endpoints, thus reducing the logical 883 contact surface for data communications, and publishing information 884 purely on a need-to-know basis. We take is for granted that 885 workspace data are encrypted with workspace authorized credentials. 887 12. Normative References 889 [Bergstra1] 890 Bergstra, J. and M. Burgess, "Promise Theory: Principles 891 and Applications", 2013. 893 [CFENGINE] 894 Burgess, M., "A site configuration engine, Computing 895 Systems", 1995. 897 [CONVERGE] 898 Burgess, M., "Configurable immunity model of evolving 899 configuration management, Science of Computer 900 Programming", 2004. 902 [DSOM2005] 903 Burgess, M., "An Approach to Understanding Policy Based on 904 Autonomy and Voluntary Cooperation, Lecture Notes in 905 Computer Science", 2005. 907 [K8S] Various, , "Kubernetes, Open Source Project", 2015-. 909 [MicroS] Richardson, C., "Pattern: Microservices Architecture", 910 2014. 912 [MUD] Lear, E., "Manufacturer Usage Description", 2015. 914 [NDN] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy, 915 K., Crowly, P., Papadopoulos, C., Wang, L., and B. Zhang, 916 "Named Data Networking", 2014. 918 [OneM2M] OneM2M, , "Standards for M2M and the Internet of Things", 919 2015. 921 [PromiseNet] 922 Borrill, P., Burgess, M., Craw, T., and M. Dvorkin, "A 923 Promise Theory of Networking", 2014. 925 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 926 Requirement Levels", BCP 14, RFC 2119, 927 DOI 10.17487/RFC2119, March 1997, 928 . 930 [SOA] Open Group, , "SOA Reference Architecture Technical 931 Standard : Basic Concepts", 2016. 933 [WORKSPC] Burgess, M., Dvorkin, M., and K. Burns, "Self-Service 934 Workspaces for Federated IT Infrastructure", 2016. 936 Authors' Addresses 938 Mark Burgess 939 Independent Researcher 940 Oslo 941 Norway 943 Herb Wildfeuer 944 Cisco 945 San Jose 946 USA