 Okay. Hello. Good morning, everyone. I'd like to welcome you to the Open Networking and Edge Summit sponsored by the Linux Foundation. Today's talk will be on Cloud Federation and IoT and Edge applications by Dr. Sharif Mamoudi from Siemens and myself, Robert Bond from NIST. Next slide, please. Today's talk will show a slight introduction to Federation. Then it will give the promise of Federation and what we can expect to have in the future. It will describe a collaboration between NIST and the IEEE on the development of a Cloud Federation reference architecture and standards around that. I'll give a fuller description of Federation. Then I will describe the NIST Cloud Federation reference architecture. After that, I will describe the IEEE and the P2302 work on standards for Inter-Cloud Interoperability and Federation and its current status, and finally the use cases. Next slide, please. In early 2010, NIST was charged by the USCIO to develop a roadmap for Cloud computing standards and technology. In this roadmap, which was developed with a group of stakeholders in industry, academia, and the government, we were able to develop a reference architecture and this roadmap. The roadmap shows 10 requirements that are needed for fast, safe, and quick adoption of Cloud computing into the federal government. Earlier, the NIST had defined Cloud computing and in that document, defined community Cloud as supporting organizations that have a common set of interests. For example, mission, security, or policy. Sometimes the community Cloud cannot be implemented in one public or private Cloud, which is why multiple Clouds are needed to support the governance and processes which enable Federation and Interoperability. This was the core requirement of requirement five, frameworks to support federated community Clouds found in the NIST US Government Cloud Computing Technology Roadmap, NIST SP 500 293 Volume 1. Next slide, please. When we talk about Federation, we understand there's a need to connect real-world collaborations, data, and resources with practical collaboration methods and tools. Data exists all over and people need to get access to that. What is the easiest way to be able to do that? Well, Federation addresses how to securely manage collaborations when the resources being shared are inherently distributed. We realize, of course, that there's a spectrum of collaboration needs, approaches, and sizes of Federations. For example, we could say there's a bare-bones Federation which is small and manually managed. One might think of a couple of students in a dorm room who develop a small Federation where they can share services amongst themselves. On the other hand, there are industrial-sized Federations, very large-scale, highly distributed. Many things are automated. There's accounting, there's auditing, and there's legal controls because we exist in a regulatory environment. Next slide, please. The NIST and IEEE collaboration consisted of two parts. As I described earlier, NIST recognized the importance of the frameworks to support seamless implementation of Federated Community Cloud Environments, and in discussions with IEEE, decided that NIST would continue working on that requirement, but IEEE would take the output from NIST and then go on to develop standards around that. You can see from the IEEE P2302 project authorization request, the purpose was to create an economy amongst Cloud Providers. An economy is something that is bought and sold and traded. What could that be? That could be services or resources amongst other Cloud Providers. This should be transparent to users and applications, so a user does not want to have to stop and think. They want this to be simple and dynamic for them. Again, this will be a dynamic infrastructure that can support evolving business models. The standard itself will define the topologies, functions, and governance for Cloud-to-Cloud Interoperability and Federation. Next slide, please. Here are the goals. As I mentioned, the NIST group will develop a Cloud Federation Vocabulary and Conceptual Model. This interim output will be contributed to the IEEE P2302 working group in real-time, and the ultimate output will be in this special publication. The IEEE P2302 working group will develop a Cloud Federation Standard based on the previous scope and purpose. The P2302 initial output then will be an IEEE Standard, and with plans to contribute this to the ISO JTC-1 to create an international standard around Cloud Federation. Next slide, please. The essence of Federation is more or less an identity management problem. As we see two systems here on the left and right, system A and system B, we see how does user A essentially manage to find the services from system B? How can system B manage its discoverability, and how can system B or service provider B validate user A's credential and make access decisions? This is what the essence of Federation boils down to. Next slide, please. In addition to that, we will find that there are also other essential characteristics of a Cloud Federation. A Federation is a virtual security and collaboration context that is not necessarily owned by any one user or organization. Since only specific users, sites, and organizations collaborate for common goals, these participating entities have membership in the Federation and identity credentials that are linked to each member. The user, sites, and organizations can participate in a Federation by choosing to share some of their resources, metadata, and making them discoverable and accessible to other Federation members. Participating members agree upon the common goals and governance of the Federation based on well-known roles, attributes, and policies. Next slide, please. Here's a simple three-plane model of Cloud Federation. As we see at the bottom slide, this is the Trust Federation Plane. This is where the two site administrators decide that they will trust each other in order to carry out a Federation. What that Trust relationship is and the exact structure and governance of the Federation is to be decided by the governance structure. We can say this occurs in the Trust Management Plan. In the Federation Management Plane above, once this is done, each site admin or Federation operator deploys a Federation manager. Initially, these Federation managers are empty since they are not hosting any federations yet. They can be called internal since they are deployed and operated internally to each site. Once deployed, secure communications must be established between the Federation managers and any way suitable to ensure that their communications are not susceptible to eavesdropping or interception. This is necessary since the Federation managers must exchange information concerning the management of federations that is valid and trusted. This can be called the Federation Management Plane. Once a secure communication has been established, the two site admins can create a common Federation. In this example, this is called Federation FU. When initially created, it's empty and unconfigured. What is important is that both Federation managers maintain a consistent state for FU over its lifetime. From a practical perspective, one site admin may invite another site admin to join through their Federation manager, or one site may ask the other to be allowed to join. For this example, this is how this happens is not critical. Once Federation FU has been created across all Federation managers, what is actually being created is a virtual administrative domain and illustrated in the top Federation usage plane. In this plane, Federation FU is neither blue nor red, but purple. Federation FU is also empty or unconfigured. However, immediately after creation, a Federation's first member would typically be a Federation admin. We know that there could be one or more Fed admins that are users from site A or B. Once the Federation has been created and its management is in place, it can be populated with members and services to accomplish its business goals. The Federation admins could grant management and authorizations to other users. Resource service owners from A and B can make services available in FU by registering their service endpoints and defining the associated discovering access policies. These users, services, policies, authorizations could change dynamically over the course of the Federation lifetime. Next slide, please. The NIST Cloud Federation Reference Architecture published in NIST SP500-332 in February 2020 is presented here. As you know, as you notice, this is a actor role-based model, much like the original NIST Cloud Reference Architecture that was published in 2011. The commonalities we have between those two models are we have a cloud service consumer, we have a cloud service provider, we'll have a carrier, an auditor, and a broker. Now, when we increase the complexity to talk about having a cloud Federation, we need to have some methodology or actor who will manage the Federation and that will be the Federation operator. The Federation Manager is a software system that manages the Federation instances and all those small rectangles inside the membership, the policy management, the resource monitoring, accounting and billing, and portability and interoperability. Next slide, please. The objectives of the IEEE Standards for Inter-Cloud Interoperability and Federation Working Group, as I mentioned, the purpose was to create an economy amongst cloud providers, which is transparent to users' applications and provides for a dynamic infrastructure that can support evolving business needs. So, in essence, this group would like to create cloud Federation standards which support the transparent infrastructure, much like the Internet and phone network. It would need to be cloud implementation independent like Internet routers based like the phone network. It would have to be a simple protocol set and easy to join. There should be support for generalized resource Federation, not just virtual machines, but all services up and down the stack and also support for multiple Federation topologies through network abstraction and finally globally scale capable. Next slide, please. Some of the possible deployments that we have been investigating. On the left, you see a third-party centralized trust model. On the right, you see peer-to-peer cloud Federations. On the left-hand side, the third-party trust model, each site is participating through its own through a centralized Federation manager and then becomes part of the Federation that way, whereas on the other side, the two sites are equivalent. Next slide, please. One description that the IEEE is working on now is this third-party centralized trust model and you can see there are Federation members up at the top that connect into the Federation hosting service. First, they're authorized by coming in through the authorization endpoint and checked out through the OpenID Connect server. Once they're permitted to go and use these services, there's a policy enforcement point which is set down by the service owner and he registers his service. Finally, there's a list of services in the service catalog and finally, we see in the Federation instance database, there's three catalogs, a member catalog, a roles and attributes catalog, and a service catalog and those are set up so a member can only see what he's allowed to see. Next slide, please. We are working on an API development in the P2302. Currently, we have a small core API that was finished in May. We were looking at the, we completed the Federation operator and the Federation hosting service, the Federation hosting service APIs which will help with the peer-to-peer model. We are currently undergoing development of the monitoring API. Which is going to be key when we move on to do other things like auditing and billing. Next slide, please. And thank you. And I'm going to introduce Dr. Sharif Mamoudi to describe use cases. Yes, thanks. So from my side, Sharif Mamoudi, so I'm working as a software architect for intelligent systems for services. For Siemens corporate technology in the US. And when I had a few years back at discussion regarding cloud and Edge Federation with Bob, that was quite interesting on what kind of use cases could be enabled by this technology, both for industrial application and also some general purpose application. So we'll spend like the 10, 15 next minutes talking about some of those use cases that I had the chance to work on. But first, let's revisit the differences of what this Federation is introducing in terms of features or functionalities compared to the current deployment. That slide, it mainly captures on the right hand side a classical or a current deployment from the cloud to the Edge where we can see that services from the Edge are communicating with cloud services and the same services from the Edge are also accessible for the field devices. And here in Instance, a camera can record some videos send it to an Edge node which can run, for example, some AI inference on this data before sending the results back to the cloud. What the Federation is introducing at that level is that we are not talking about vertical silos in such a way that we have a typical path to go but we can share resources at the Edge and at cloud in such a way that we can leverage services that are either owned by someone else or that's our path or that's our third-party development that the application needs to run in the better in an optimal way. So the point is we are trying to leverage this kind of new interactions possibilities that are provided by the Federation to build use cases on top of them. And I will start or one of the use cases it's not an industrial application it's more looking at how we could enable multiple small farmers or multiple small nodes to leverage a processing capabilities from their neighbors. And case study here it's mainly for two fights that we trust diseases. And here we are talking about an underserved area where there is no reasonable connectivity infrastructure that links the different farms together and also to a city where we can have a reasonable internet connection. So zones here what I'm referring to zones like these blue areas and also the yellow areas are independent zones where we have some connectivity where the drone for example can fly to inspect the different plants and see what is going on over there. However there is no obvious link between the different zones. So we worked into a networking technology based on data networking to allow the communication in a kind of opportunistic connection between the zones and also between the city where that is providing like the external internet access. However the implementation of that was mainly we had a challenge which is the resources the compute resources that are available are not enough. The smaller medium farmers cannot afford having a huge networking infrastructure or use a cloud in a classical way. So the federation here was a kind of interesting solution in such a way that the different zones are considered as participant to the federation and they can materialize their resources in such a way that they can use a computing power or services from other zones as much as available. This effort was done as an early stage experiment in collaboration with some universities from Europe and from Africa. The next use case it's mainly for some applications for some industrial applications for perception and the main challenge here is that how we could compose some or enhance the perception where we are when we are having multiple inputs that are potentially owned by multiple stakeholders. And here assume that the field devices are devices that are owned by multiple entities and also the infrastructure at the edge. It's not owned by a single entity. And the point here or what we looked at it's how we could enable federation between those edge services and field devices and to push that to use specific services from the cloud mainly machine learning services from there. And what we looked at more especially is could we break the inference in two levels like a level it's done. First we are collecting the data doing some binding from protocols because the sensors are not using the exact same protocol from all the stakeholders and then do a first layer of inference. Then mutualize that or put or aggregate those data from a central node to be able to exchange with cloud. And here the assumption is that these different nodes are not owned by the same entities. So cloud federation allow a dynamic way to map those different resources together and also have a kind of view of what is available and what could be used for the application not from the participant's perspective but from a federation perspective which enhances the capabilities or the optimization in term of resource usage and resource deployment. The next use case is a federation in term of platform. And here at Siemens we are developing or we have a cloud solution called Minesphere which is mainly dedicated for industrial applications and some of our customers have already deployment using other major cloud provider and they want to use Minesphere for some specific purpose and also they want to have the possibility to leverage their processing or their infrastructure that they have already on this cloud provider and leverage all that with the application that they are building on top of Siemens Minesphere. So here the experiment that we use for that use case is mainly how we could enable a kind of lightweight version of the federation in such a way that we could use for example IoT devices or IoT connectivity that is already set up from a third party cloud provider and use that as if it was a device onboarded into a Minesphere, a Minesphere cloud. And here we looked also to some aspects in term of binding and protocol. Binding mainly for some protocols relevant for industrial applications but federation was a kind of interesting way to explore how we could simply link dynamically services that are external to the Siemens Minesphere and still be able to leverage them to build some application or to build an application for our customers. My last use case it mainly addresses the scalability and the point here is I assume that you have some service providers that have a workflow and this workflow might be reading from a sensor like implementing a control loop in a kind of cyber physical system. Reading from an IoT device or reading from a sensor doing some processing to that data and then writing it to an actuator. If we take as simple a use case as simple as that in cloud there is we can aggregate this use case or this workflow in term of a unique big workflow that can be executed. However, to be able to enhance its performance and also its scalability that might be limited by the bandwidth or the availability of the bandwidth to cloud the idea here is to break it down in multiple subcomponents and those subcomponents like delegate them or make them run and use services from dedicated cloud provider. And here like the service provider is deploying the workflow or requesting information from the Federation Manager regarding where the difference what are the capabilities of the different participants and then according to these features or these capabilities decides where every component or every specific piece of the workflow should run to have an optimal to have an optimal results. We experimented at that level mainly the local programming platforms like Mendex and Node Red and the results was quite interesting in term of distribution as it reduces the need of communication or exports and imports between different cloud provider and also adds some kind of near real-time capabilities. So with that those were the main use cases that I wanted to share during this presentation worth also to mention that my contact and Dr. Bond contacts are here and if you want to get more information or to get involved into this cloud Federation activity there is links right here for the IEEE between E302 working group and also an email to request to join that group. And lastly Dr. Bob Bond is the chair and there is also a contact from Marshall Michel which is the core share for that working group. I think with that it's all from my side Bob you want to have a last word on that presentation? I just want to thank everyone for their attention and interest in this talk. Thank you. We still have a minute or so that we can answer the potential quick question each share with you. So yeah if there is any quick question we could answer it right now if not we would be happy to continue this chat on this on Slake channel. Bob seems to be... Well no I'm still here. I was waiting for questions. Is it okay if I ask the audience a question? Is anyone out there interested in doing something like this? I think that anyway it's out of time for this presentation. We had just a minute or so for a potential question. I think we could we could safely continue this chat on the Slake channel. Okay. Okay cool. So yeah I think that's it for the presentation with Sufis team. Thanks everyone for attending. I appreciate it and hope that the Slake channel would be active and we will try to do our best to answer your questions over there. Anything from your side Bob? Good. No I'm already in the Slake channel so... Excellent. Excellent.