Introduction And Overview At W3C Open Day
OpenFog ConsortiumIntroduction and Overview at W3C Open DayMay 2017
Agenda What’s Fog Computing? OpenFog Consortium OpenFog Reference Architecture Technical WG Focuses (Security, Smart Objects,Manageability) Moving Forward. Q&A
What’s Fog Computing?
What is fog computing?System-LevelArchitecturefrom Things to the Edge,and over the Core to theCloud, spanning multipleprotocol layers(works over and insidewireless and wirelinenetworks)for distributing,orchestrating, managing,securing resources andservices(not just placing servers,computing resources, apps,or small clouds at the edges)CLOUDFOG COMPUTINGA system-level horizontal architecture that distributescomputing, storage, and networking closer to users, andanywhere along the Cloud-to-Thing continuumHorizontalSupports multipleindustries(not limited to anyspecific industry, networktype, or applicationdomain)Cloud-to-Thing ContinuumDistributes resources andservices to anywhere along thecontinuum(not just at the edges)Converged Cloud/Fog platformsand services(not just isolated edgecomputing devices / apps)
Why Fog?It’s necessary to run IoT, 5G and AI applications
Selected fog scenarios123Use CasesTraffic Congestion?FogTechnologySmart Buildings 160B cost of traffic delaysin US aloneCloud doesn’t scale to support widescale surveillance (highways, cities,airports, etc.); rapid securitydecisions must be made on locationSafety, security, energy efficiencyand comfort in buildings is anongoing concernSolutions developed in silos hinderinformation sharing; data sourcesare bandwidth intensive andcomplexHD cameras generate terabytes ofdata per dayTelemetry data is sent fromthousands of sensors simultaneouslyFog computing ensures sharing ofdata from vehicles and alongroadwaysFog nodes intelligently partitionvideo processing between camerasand cloud, enabling real-time,latency sensitive analyticsFog computing creates smart,connected spaces; fog nodes forindividual rooms can perform allmonitoring and response functionsProblemChallengesVideo Surveillance
Why fog? Beyond necessary, it enables growththrough new business modelsReshape the IndustryLandscapeRouters, switches,application servers, andstorage servers convergeinto unified fog nodesCreate DisruptiveNew Service ModelsIntegrate andConverge Cloud–FogServicesEnable RapidDevelopment andDeployment of FogSystems and ApplicationsPlayers of all sizes, not justmassive cloud operators,build/operate fogs andoffer fog services “WiFiModel” and the rise oflocal/regional fog ecosystems and operators?For a business to functionas a cohesive whole, cloudand fog will converge intoone common infrastructurefor integrated and unifiedcloud and fog services:development, deployment,monitoring, management,security, Rapid deployment oflocalized applications shifting from “build thecloud and see whatservices we can put on it”to “find what customerswant and quickly puttogether a fog for them”
To work, fog computing must have universalinteroperabilityTCP/IPWWWFog Computing andOpenFog ConsortiumA standard and universalframeworkA standard and universal frameworkA standard and universal frameworktototoaccess files anywheredistribute resources and servicesdistribute packetsandManage, pool, orchestrate, andsecure these distributed resourcesand servicesWas it necessary to create aTCP/IP-for-wireless telecom? aTCP/IP-for-wired? a TCP/IP-forenterprise? NOWas it necessary to develop a HTTPfor-wireless? a HTTP-for-wired? aHTTP-for-enterprise? NOIs it necessary to develop a fog-likesystem for 5G? another for wiredtelecom? another for enterprises?another for smart city? another formanufacturing? NO
OpenFog Consortium
Building this necessaryinteroperability offog-enabled applicationsrequires a collaborativeapproachProprietary or single vendorsolutions slows down adoptionand innovation.An open architecture will: Provide a robust new platform forproduct development Increased quality and innovationthrough competition in the openenvironment Lead to a vibrant, growing supplierecosystem Accelerate market adoption Lower system costs
OpenFog missionBuilding the Cloud to Things Mission Statement: To drive industry and academic leadership in fog computing architecture,testbed development, and a variety of interoperability and composability deliverables thatseamlessly leverage cloud and edge architectures to enable end-to-end IoT scenarios.
OpenFog ConsortiumAffiliationsA growing, global ecosystem of fog expertsFoundersContributing Members57 members strong, headquartered in 15 countries as of May 2017
OpenFog Consortium goalsTechnologyInnovationEducationDevelop, Solve,Identify & CreateFoster, Initiate,Provide & InfluenceGain, Promote,Evangelize & Educate
Organizational structureBoard of ionCommitteeOfficers: President, Chairman, Treasurer,SecretaryTechnicalCommitteeSocial ImpactCommitteeAmericasCommitteeGreater eArchitectureFrameworkWGSW Chair(s)Chair(s)Chair(s)Chair(s)
Japan Region CommitteeAlt. Voice of the RegionalCommitteeConduit to BoDDeputy LiaisonJeffFeddersHost/FundOperational ModelAssist InitiativesVoice of the Regional CommitteeLeads Committee MeetingsCo-Conduit to daArchitecture Framework LeadsSW Infrastructure LeadsHost/FundOperational ModelAssist InitiativesTech-SeatLead technical agendaIncl. collaboration withglobal teamTech-LeadsMasahiroShimohoriJapan Regional CommitteeCommunication LeadsSecurity LeadsManageability LeadsTestbed ChampJapan IoT R&D, Standards,Ventures and PoliciesLocal ConsortiaTech LiaisonSeatLiaison toRegional Standards BodiesOsamuOgasaharaNiki AgataMarketingSeatOrchestrates MarketingActivitiesGovernmentSeatAcademicSeatHost Annual Fog EventConduit to Local GovernmentsConduit to Global Initiatives /ActivitiesRepresentsAcademic / University/ ResearchProjectsInnovatorsSeatRepresentsInnovators / Makers
Japan Country Team: Priority Focus AreasUse-CasesRegionalCollaboration- Transportation- Industrial Focused use cases of regionalinterest Car Share Connected Smart FactoryTestbeds-Work-in-progress- Local Consortia- Government Affiliation with IoTAcceleration Consortium(more than 28,00members) backed by METIand MIC Works in alignment to theOpenFog global TestbedWorkgroup & TechnicalCommittee
OpenFogReference Architecturewww.OpenFogConsortium.org/RA
The OpenFog Reference ArchitectureFramework1Unified framework & roadmap to help software developers andsystem architects create the first generation of open fog computingsystems develop compute, network, storage and controltechnologies for the cloud-to-things continuum.2First step in creating standards to enable interoperability in IoT,5G, Artificial Intelligence and other complex data and networkintensive applications.3Creates a common language for fog computing and will help unifythe edge/fog ecosystem under a single, interoperable, testableset of hardware and software standards.
Key pillars of the OpenFog architecture frameworkThe pillars describe requirementsto every part of the fog supplychain: component manufacturers,system vendors, softwareproviders, application developers.StorageComputeNetworkSecurity TrustAttestationPrivacyScalability Localizedcommand, control& processingOrchestration& AnalyticsAvoidance ofnetwork taxesOpen Resource visibility& controlWhite box decisionmakingInterop & DatanormalizationControlAutonomy FlexibleCognition& agilityValue of dataAcceleratorsRAS ReliabilityAvailabilityServiceabilityAgility Tactical &strategic decisionmakingData to wisdomHierarchy Fully cloudenabledComputational &SystemAutonomy at alllevelsProgrammability ProgrammableSW/HWVirtualization &multi-tenantApp Fluidity
Architecture description with perspectives
Architecture description with perspectivessystem viewnode viewperspectivesperspectivessoftware view
A closer look at fog nodes They form a mesh toprovide load balancing,resilience, fault tolerance,and minimization of cloudcommunication. They communicatelaterally (peer to peer, eastto west) and communicateup and down (north tosouth) Are able to discover, trust,and utilize the services ofanother node in order tosustain reliabilityavailability-serviceabilityFog nodes in a Smart City: Buildings, neighborhoods & regions are connected toprovide an infrastructure that may be optimized for service delivery.
Technical WG focusesSecurity, Smart Objects and Manageability
Security WorkgroupOverview
Reference ArchitectureContributions
Node Security 27Node Security is the basis of Fog Security A Hardware Root-of-Trust is the foundation Physical Security needs to be considered for alldeployments Trusted hardware executes immutable trustedfirmware Extends the Chain-of-Trust through instantiation ofcomponents
Network Security Aspect Communications SecurityAll communications run throughTCP/UDP/IP stack Node-to-Cloud WS* / REST over TLSNode-to-Node HTTP over TLS COAP over DTLSNode-to-Device IP Adaptation WLAN/WPAN: 6LowPAN PLC: PRIME IPv6 SSCS Automation: CIP EtherNet/IP Services SecurityNFV Security Appliances SDN Service Provisioning
Data Security Aspect Data in Use Data in memory undergoing processing Data at Rest Encrypted MemoryData in storage Full Disk Encryption File / Database ProtectionData in Motion/Transit Data exchanged via (virtual) interfaces Communication Security Content Security
Cryptographic Functions A Base Set of Standardized Crypto Functions must be supported byall Fog Nodes to ensure interoperability. An initial base list was selected from FIPS 140-2 spec.; A complete list including regional standardized functions from Europe,China, Japan, will soon be created.Based Set must be updated regularly. NIST Recommendation for Transitioning the Use of Crypto Algorithms andKey Lengths will be followed; Subsequent revision will include transition approaches work for regionalcrypto functions.Compliance does not guarantee security! Crypto Functions selected for fog components should be appropriate fortheir use and in agreement with stakeholder’s threat assessment.Formal Validation of Crypto Modules is left as an option to vendors.
New Work & Taskforces
Security Requirement TaskforceMission statementStrategyThe mission of the Security Requirement TF is todefine sets of requirements that has to expressthe fundamental security (and in the futureevaluation) requirements for an OpenFogcompliant (in the future certified) node andsystem.As a reminder, this work shall support both brownand green field implementations.The strategy is define on a 2 phases basis.The requirements will be split into 3 sets, each onecovering a specific domain of the OpenFogarchitecture: Node SecurityNetwork/Communication* SecurityService Management* We refer to a network of virtual or physical entities within the Fog.1.Compliancy program: In a first phase, the groupwill focus on the delivery of an OF securitycompliancy program. A security compliancy programconsists of guidelines on security functionalrequirements for an OF node and system to promotea good level of security.2.Certification program: In its second phase, thegroup will then focus on delivering a certificationprogram. A certification program consists of precisesecurity functional and evaluation requirements foran OF node and system to assure a measurable levelof insurance of security.
Security Requirement TaskforceMethodAs the plan is eventually to obtain a certification programin place, the compliancy phase methodology shall bedelivering content that will fully compatible for thecertification phase.ToE TOE: Target of evaluation, defining the product orsystem that is the subject of the evaluationPP: Protection Profile, defining the following Securitypoints: Problem definition (Threats, assumption, ) Objectives (ex. protected storage, comm ) Functional Requirements (protecting the TOE in thecontext of the Problem definition to ensureObjectives)* Dependent on reference architecture formal definition progress.PPEvaluateThe Common Criteria methodology has been identified asa viable method to build a Security Certification. Thus thefollowing CC compatible documents will be produced in the1st phase for each OF domain listed previously:certifiedDeliveries and reportingThe deliveries of the group are defined by themethodology and so consist of: TOE for the 3domains PP for the 3 domains Planning for the SecWGPlanning*Node Sec.nowJul 17Dec17Net./comm. Sec.Serv. mgt.
Security MVIs Security MVIs A Functional Description of Security MVIs is required Requires a description of how the other system components utilize them.The functional requirements need to be expressed in such a way that they are testable.OpenFog systems Must be described in such that they allow for both innovation and diversity in the solutionsprovided by different vendors and products, both now and in the future.The MVIs will trace the Security MVIs from power-on until the full system is instantiated.The components chosen must interoperate with the rest of Fog Computing infrastructure.Security MVIs First pass: Will describe the hardware features minimally needed in order to provide asecure base for fog nodes.The Second pass: will define Security MVIs in terms of functions/services from a softwareperspective
Smart Objects for an OpenFog Architecture:SW Infrastructure WG – Task GroupJeff Sedayao, Eve M. SchoolerIntel IoTGMay, 2017
Smart Objects for an OpenFog ArchitectureSW Infrastructure WG – Task Group What are Smart Objects? Why do we care about Smart Objects? Smart Object Landscape Smart Object Issues Task Group Charter
What’s a Smart Object? Smart Object: An object that describes itsown possible interactions[1] Objects can be physical, e.g., sensor,computing device, wearables Objects can be cyber, e.g., data, executablecode, apps, services, clouds A Smart object’s description and metadataneed to be stored and maintainedsomewhere A Smart Object Framework includes ways todescribe, identify, and interact with smartobjectsQ.How do you turn on a light bulb?A. Get a description of how tointeract with the light bulb and thenturn it on in accordance with thedescription
Why do we care about Smart Objects? Without some form of self-description, IoT object interactionmust be built into application logic Code must be added for new object types A problem that really exists[2] A Smart object approach promises away to quickly build and maintainapplications Commonly cited needs: Data interoperability Service, object, and SW compositionYou shouldn’t have to hardcodethe logic of turning on eachdifferent kind of light bulb oreach different light bulb vendorReduce time and cost to develop, deploy, and maintain IoT applications
Smart Object Landscape Standards bodies and alliances: e.g., Intel recent History NIST Cyberphysical Systems Initiative - Data Interoperability WG IETF/IAB Workshop on Semantic Interoperability NSF-Intel ICN-WEN program(Information Centric Networking in the Wireless Edge Network)
Smart Object Issues Frameworks: Standards: So many to choose from! Ontologies: Even more to choose from! Interoperability: What form of interoperability(syntactic, semantics, object, etc.)? How to develop distributed IoT services usingmetadata? Discoverability at scale Naming, Lineage and Access Semantic Interoperability – does setting alight bulb to “on” give you usable light? Maybe not if lumens output is set really low Maybe if light bulb only has two output levels –off or some set amount of lumens SecurityQ.A. Can you turn on a light bulb?Maybe:if you use the right standard andif you use the right ontologyor if you have a bridge to another frameworkand semantics matchIf you can discover the light bulbIf you can address the light bulbIf you have permission
Charter Assess the Smart Objects landscape and contribute to a living survey Highlight the most relevant models and frameworks Identify commonalities, taxonomies, gaps Capture minimal/optimal requirements for Fog-inspired use cases Object framework (e.g., discoverability, bridging, registries) Fog formation Work orchestration Data economy Build tools and demonstrate viability of Smart Objects approach POC(s) implemented (on OpenFog testbed) Open SourceIdentify, coordinate with, influence, extend, and drive relevant standards
Transaction Management &Orchestration PrinciplesKatalin KB Walcott – Principal Engineer, Intel IoTGIntel Fog SW Architecture Technical Leadkatalin.kb.Walcott@intel.comIntel Corporation – Concept Recommendation
Logical Transaction Layers – conceptProject 2Project 4Project 1Project 3Fog Transaction & ManagementRepoRepoRepoRepoData, Object, Interface & AccessNot AvailableAvailableAvailableAvailableAvailableNot AvailableAvailableAvailableMicroservice Logical Fabric teComputeComputeStorageFog Platform Infrastructure – Shared ResourcesIntel Corporation – Concept Recommendation
What is a Transaction?Contract Management of Transaction based Agreements Service name will be available #% of time during hrs of operation during hrs and days of the week. Individual service outage in excess of time period or sum of outages exceeding time period will constitute violation #% of service name transactions will exhibit #seconds or less response time, defined as the interval from the time the user sends a transaction to the time a visualconfirmation of transaction completion is received. Missing the metrics for business transactions measured over any business week will result in a violation.Transaction based TLA time10 secondsInternet3 secondsExample Metrics: Customer testsconnected throughmajor ISPNetwork2 secondsApplication3 secondsSystems Storage2 secondsExample Metrics:Example Metrics:Example Metrics: Transaction responsetime CPU Utilization % oftotal process I/O response time inms Memory utilization Bandwidth utilization- % of total protocols Throughput in msExample: Transaction Response Time for Promised Service LevelsService Elements:Management Elements: Include the specifics of services provided:- Conditions of service availability- Standards such as time windows for each level of service- Responsibilities of each party- Escalation procedures- Cost/service tradeoffs Include the definitions of measurements:- Methods- Standards,- Reporting process- Content- Frequency- SLA breachesMetrics to Monitor: Monitoring schemas may include:- Service availability – amount of time the service is available for use- Usability – timeliness, transaction completion, latency, refresh rate- Delivery - Performance , Availability, Reliability- Defect rates – percentages of errors in major deliverable- Technical quality – measurement of quality in delivery (time, response rate etc )- Security /Trustworthiness -44Intel Corporation – Concept Recommendation
Transaction Level Management ElementsTransaction Level AgreementOrchestration & Intelligent PlacementTransaction Management SMINUTESMINUTESTLATLAScheduling &OrchestrationLayerFOGComposition& AssemblyLayerHOURSTLO apeNETWORKAtomic Resource& Allocation LayerCPURAMNICDISKPhysical LandscapeIntel Corporation – Concept RecommendationPOWERFANCNTRLIOTMetric
Placement flow analysis Placement metadata Object ESTRATIONsFog InfrastructureSoftwareFog PlatformHardwareNetworkSensors Microservice Composition Fog microservice dynamicplacement & optimization Real-timeA
Introduction and Overview at W3C Open Day May 2017 OpenFog Consortium . Technology Innovation Education. Chair(s) Architecture Framework WG Chair(s) Communications WG Chair(s) SW Infrastructure WG Chair(s) Security WG Chair(s) Manageability WG Chair(s) Testbed WG Organizational structure Chair(s)
3.2 W3C: HTML 3.2 Specification 1997-01-14 4.0 W3C: HTML 4.0 Specification 1998-04-24 4.01 W3C: HTML 4.01 Specification 1999-12-24 5 WHATWG: HTML Living Standard 2014-10-28 5.1 W3C: HTML 5.1 Specification 2016-11-01 Examples Hello World Introduction HTML (Hypertext Markup Language) uses a markup system composed of elements which represent .
What is W3C? The World Wide Web Consortium (W3C) was founded in October, 1994 at the Massachusetts Institute of Technology (MIT) with support from the Defense Advanced Research Projects Agency (DARPA)andtheEuropeanCommission. The World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web .
W3C Web of Things Soumya Kanti Datta Research Engineer, EURECOM Coordinator, TF-DI in W3C WoT IG Email: dattas@eurecom.fr W3C Auto WG F2F Meeting April 2016
HTML Timeline 1991 HTML first publicly described in a CERN document called "HTML Tags" 1993 Formally defined by IETF 1995 HTML 2.0 defined by IETF 1997 HTML 3.2 published as a Recommendation by W3C 1997 HTML 4.0 published as a Recommendation by W3C 2000 XHTML 1.0 published as a Recommendation by W3C 2001 XHTML 1.1 published as a Recommendation by W3C
B. W3C WoT and IETF CoRE Directories Both the IETF (in the CoRE working group) and the W3C (in the WoT working group) are currently standardizing resource description and discovery in IoT environments. Con-cretely, the IETF proposes the CoRE Link Format [3] while the W3C proposes the Thing Description [10] format. Both
7 2011-12: W3C splits witWHATWG oHTML5 W3C wanted an "HTML5 Recommendation" A final specification WHATWG wanted a "Living Standard for HTML" An evolving specification Presently: there are two HTML5 specifications WHATWG's is evolving W3C's is a "candidate recommendation" "Cherry-picks" portions of WHATWG's A Brief History of HTML
Technology Overview for W3C WoT Group Juan Carlos ZUNIGA Senior Standardization Expert –Sigfox 10.07.17. 1 INTRODUCTION 2 USE CASES AND DEPLOYMENTS 3 TECHNOLOGY 4 KEY FEATURES 5 IoT: ONNE TING THE “I” WITH THE “T” .
a paper animal. She tried over and over until she could finally fold a paper dog and wished that she could see Son just once more even though she knew that it was not possible. Looking at the paper dog she had made, she felt so weird that the paper dog seemed smiling at her. She felt that she would make more, many more animals out of paper. She collected all the papers in the house and started .
