 Hello everyone, my name is Vinay and I'm working in NIC which is an Indian government organization. Since last seven years I'm working there and today my talk is based on network orchestration using blockchain. So here's the agenda, I will talk about permission less blockchain and permission blockchain and which blockchain is suitable for our use case. It means which blockchain we can use in network orchestration. And then I will talk a little bit about hyperledger fabric and then we will talk about multi-domain and single-domain orchestrator and then I will talk about like I will give you some introduction about ONEP and how we can use hyperledger fabric in ONEP. And the last we have a multi-domain orchestrator live demo and I have used hyperledger fabric in this. So let's get started. So why we need a blockchain in network orchestration? So in a traditional system in telecom industry we have a very complex operational framework and in which involves many party involves like TNN and customers and service providers. There is no end-to-end mechanism to identify the problems between them and there is no SLA management like unified solution. So blockchain provides distributed trust between these entities and it also provides, so based on the consensus mechanism of the blockchain, everyone can trust to each other in one ecosystem. So any transactions when done through these entities on to the like if I will talk about a single domain orchestrator that is ONEP which works for in a single domain. So every transactions will be done on to the central repository. So there is always a issue of trust between these entities. So this trust can be provided through the blockchain and the transaction consistency between these entities. So anyone can check the transactions, what is going on on to that orchestration. So which blockchain for orchestration, whether we are going to use public or private blockchain. So first of all, we have to identify the use case and then we have to choose the blockchain whether we are going to use public or private blockchain, it is totally depend on the use case and so before going to choose that blockchain we have to identify the difference between a permission less which is a public blockchain and permission which is a private blockchain which is used for consortium. So to identify the use case, there is a very subjective case. So I will talk in a general term and a business perspective. So let us take a first from two which is permission less blockchain. So permission less blockchain, in this blockchain anyone can create and access the data and anyone can publish the smart contract onto the blockchain network and it provides 100% transparency between the entities who is involved into the blockchain and it also provides a high level of anonymity. So there is no way to know who is transacting onto the blockchain, who is this entity. So no one can, no one get to know this. And anyone can run our node into the permission less blockchain network. So it is a very slow permission less blockchain network. So it is very slow and scalability is very massive challenge in permission less blockchain network like example Bitcoin and Ethereum. So always there is a challenge of scalability and the speed of the network. So come to the private which is a permission blockchain, it is very close to the ecosystem and because every participant is well defined into the system. So it also, there is no anonymity because every participant is well defined into the network. So every entity known to each other. So there is no anonymity and the degree of the decentralization and transparency is up to the consortium use case who gonna configure and run the blockchain network. So it does not provide a mining concept to validate and execute the smart contract. And so it does not provide economic crypto economic incentives to execute to running the nodes into the networks as well. And both permission less blockchain are very decentralized and secure database. But each with its own capability and philosophy and the adoption both are different from each other. So in network orchestration it is about a single domain. So we cannot use a public blockchain in this. So we have to take a consortium blockchain which is permission blockchain. So because there is a multiple entities involved in the single domain. So we have to take it that permission blockchain and there are other advantages to taking the permission blockchain is the scalability and the performance which is very fast rather than permission less blockchain. So hyperledger, hyperledger fabric we are gonna use in on app. So it's a hyperledger projects on top in the second row you can see that Boro hyperledger fabric and grid in D. So these are the frameworks of the hyperledger and it also provides a tools as well like Caliper which is performance measurement tools and composer which runs on top of hyperledger fabric it also provides explorer which is not working on this. And so these are the tools and these are the frameworks. So we are gonna take hyperledger fabric into the single domain orchestrator. So here is the transaction flow diagram of hyperledger fabric. So in this hyperledger fabric provides there is a membership service and sorry and it also provides ordering service and there is a peers which can be endosers and committers. It also provides a hyperledger fabric SDK, hyperledger fabric SDK is available in many programming languages like Java, Node.js and Golang. So in this transaction flow first of all SDK applications have to enroll with the blockchain network by taking the sorry but taking the digital certificate from the MSP. So MSP provides motion of identities and so who gonna provide the certificates to the SDK one peers also involved and peers also have the identities from the MSP which is a membership service provider and all these entities get involved to each other by the digital certificate. So digital certificate provided by the certificate authority it can be an external certificate authority it can be a fabric also provides its own certificate authority. So let's suppose there is a Bob wanna ask that digital certificate from the fabric authority then it asked to the fabric authority to give me the certificates and then these certificates can be later used in signing the transactions validating and verifying the transactions. So the certificates play an important role in this. So first of all SDK will ask will enroll into the membership service providers and then it will create after getting the certificates it to get it generates the transaction proposal by signing with its public key and send to the network blockchain network. It means to the endosing peers. So endosing peers have the chain code and so it takes the transaction proposal from the SDK and then it executes the chain code on that and it generates the read set against it and it also signed the output of the transaction right after executing the smart contract some output will come out and then it signed that output and send back to the SDK application and then this endorse response back to the SDK application then SDK application broadcast this signed and those response to the ordering service. So ordering service like here is only four nodes of ordering service it can be more than four it's depend on the configuration and architecture level. So it's totally depend on the use case and the number of resources available for the use case. So it broadcast that and those response to the ordering service and then ordering service take the take every endorse transaction and keep it into the block and for actually ordering service keep a batch of transactions into a block and then these blocks I mean these transactions are ordered into the block and these blocks send to the committing peers. So these committing peers take the block from the endosers and then it validates against the endorsement policy which is available into the peer and it validates and it's check what kind of endorsement policy was used at that at the time of adjuvation of a smart contract means so it takes the sorry it's not working. So it's take the order transaction from the order and validates against the endorsement policy and then it let's suppose it whether this transaction is validated or not it's committed onto the ledger right and endorse ordering service is also providing the double like what is what is called double spending issue it also resolved because let's suppose a transaction one want to try change the element and let's suppose simultaneously transactions to want to change the same attribute and that time these transactions has been ordered into the block and then block will be executed by the committing peers like a transaction it will validate transaction one means transaction one has been modified that element and then transaction two once come at the validation phase it checks that transaction one already modified that so it automatically reject the transaction two. So it also removes the double spending issue of the data on the data so it's so so we have in high pleasure fabric we have peers and each peers can have a smart contract which is a chain code in our high pleasure fabric terms it every peers have its own ledger and so all peers is connected to the channel on some channel because it's a it is a concoction and let's suppose they are three organization one two three one two do business which either each other then multiple channels will be created and let's suppose organization one two three is connected to channel one so an organization one has a peer one and a smart contract and it has a ledger as well and this channel is connected with the ordering service as well so as I told you that peers and peers also has their identity from the MSP service they once it is that I once the cone at the time of configuration of the blockchain network it ask the certificates from the MSP so every peers has its own identity and every peer is connected to the orders like you can see and there is there is a channel see and every peer is connected to the channel and order that is you can see here order is also connected with the channel so it's it was about high pleasure fabric so now comes come to the domain which is a single domain and multi-domain orchestrator so here we will talk about if we talk about single domain orchestrator we are going to talk about menu or we can say on app so inside domain one you can see there is a single domain we are talking about a single telecom entity single telecom telecom organization so it is the architecture here for a single domain and on top of we have a own app and below then we have a VNF's virtual network functions it also managers which manages the services of the VNF's and at bottom we have Veeam so Veeam is a virtual infrastructure manager if you I'm hoping that you all are familiar with the NFP I and component of the NFP is so for multi-domain orchestrator we have a multi-domain orchestra on top of multiple domains like there is a telecom airtel we have a telecom China mobile like we have multiple domains below that multi-domain orchestrator and this is the overall architecture of the multi-domain orchestrator so what is single domain it refers to a single telecom company or inside in a single telecom company we have subdomains like we have a BSS support OSS supports and we have a TNNs and customers and network service providers and we have that operators as well so inside single domain we have subdomains as well so the single domain represents a new approach like it's like for single domain if I'm going to talk about on app it's on app provides a network service onboarding VNF onboarding and for the various you know that service providers for which so it's come into the single domain so it's a architecture of it's a on app in which you can see that we have a on app portal and left side you can see that we have a design functions and right side you can see that we have a runtime and on top of that we have a e-services and BSS OSS systems and big data to analyze and that data inside the on app so in on app we have a multiple that we have a multiple components and modules inside on app like we have a active and available inventory we have a service orchestrator and then we have a DCAE which is data collection and analytics events which takes the events from the VES which is a VNF event stream from the VNFs and in the right side we have a SDC which is used for VNF onboardings like it is used at the time of the creation of the VNFs on to the on app so before going to let's suppose some customer wants need a service network service then before that everything has to be running up on to the on app like so SDC provides models as well for boarding of VNFs and it's a models like TOSCA model and heat model so let's move on to the next slide so that we can get to know better so it's a on app SO which is a service orchestrator and it's a unified diagram like you can see at your left hand side and there is the SDC which is used for onboarding the services and it takes the it is a it also provide a VID which is a virtual and virtual development for the for the vendors vsp vendors so that they can upload upload the models to the on app and it's provide the models for everything like model for VNF and model for a model for VNF descriptors and model for closed loop automations model for network services and model for it's basically provides a model for everything right so on top of SO we have an on app portal and OSSBSS systems as well and it also provides the external API so here is the API handler which is the first component of the SO and it has a database data catalog in which data catalog all models are has been uploaded into the catalog database and there is a request db request db used for the incoming and outgoing request status into the request db it has a sorry it has a bp l exhibition engine which in which their recipe has been maintained recipes means the overall flow of the services and blow we have a controllers as well like VNFM adapters and controllers and VNF resource adapters for a multi-cloud currently it is showing open stack it can be a Kubernetes anything it can be so it is a high-level architecture you can see here on top of we have a vid here you can see vid is used for it's a it's a GUI for the customers to upload the models onto the on app and it also provide the interfaces to the customers so that they can bring up their services onto the on app right so so we have a as I told you that in the left side left side we have a design time environment and the right side we have a runtime environment at the time of design time environment service vendors they can upload their that VNF models onto the on app and once these are ready and network is running up then a customers can request for a service network services and so it supports TOSCA heat and young model for the models to upload the models into the catalog it also it also at the time of SDC the models has been uploaded it will be up it will be updated into the ANAI which is active and available inventory which is a part of on app so these are two main paths with the design time and runtime means I told you that pre-on boarding of the VNFs and resource onboarding we have virtual functions creations and after the VNF on boarded onto the through the SDC they can be sent to the testing team and then for the governance approval so too many rules are there at the at the design time and runtime is services network service instantiation request and they add when the request come to the on app through the external API or VID it checks whether this VNF services is available into the inventory or not so based on based on that data on app decides and takes the decision and will bring up the services so instantiation and infrastructure services like through the VID instantiation flow means through the VID GUI customer can request for our network services it can also call the external API as well so here is the dependency between the every module of the on app you can you can check here here is a portal platform calling ANAI so there is a VID calling SDC and there is a VID calling ANAI and there is a VID calling that SO which is a service orchestrator so main part of VID is it is used at the time of design time it will be used at the time of runtime as well so so you can see that it's a very complicated dependency diagram everyone get confused so and in the lower level you can see that active and available inventory so active and available inventory will be called by every module of the on app like app C is calling the ANAI SO is calling the ANAI and SDC is also calling the ANAI so it's a very complicated diagram you you cannot grab easily but it's for say so on app ANAI on app ANAI is a sub module of on app which provides the real view of the resources and services and the relationship between them but it is a what is the central repository means it is provided by the AT&T and the every VNF onboarding and network services is defined into the ANAI as assets and based on asset we're going to talk about how we can create assets on blockchain as well so you can see that SDC is uploading the models onto the ANAI so ANAI is very huge and very big repository by AT&T and so ANAI is also called by MSO DCAE and BSS OSS system so it it makes system very very slow in term of calling one ANAI central repository so so ANAI means like information supplied by ANAI need to be accurate it means it is the central repository anyhow that but it has to provide the accurate information to the on app at the time of service creation so it is it does not need to be invalidate information for on app SO and it maintains the view and it maintains the relationship between the assets which we call like vendor VNF onboardings and anything can be asset in the on app but it is the relationship between the assets it provides by ANAI and so this is all about ANAI so again it is the on app diagram which which I saw you I showed you two previous slides but here what I'm gonna giving you as with a blockchain here you can see that on the right side we have a blockchain and first call is that is audit and SLE management which provides the auditability and SLE management between the customers and you know that tenants and who are requesting for the network services and after getting the network services they can be valid for the for the required period so everything can be we can manage SLE between the customers through the blockchain rather than writing separate programs into the on app and we have a service specification verification means once the at the time of SDC everything will be go will be uploaded to the ANAI and we are taking some part of the ANAI onto the blockchain like we are taking some assets onto the blockchain so as so called ANAI rather than it can be called that blockchain as well so that it can get the information as a distributed information no one can temper this information onto the blockchain like as I told you that ANAI is central repository we everyone doesn't trust on the central repository but in this as so can call that blockchain APIs and rather than calling the ANAI APIs force in some cases I'm not removing the ANAI totally but I'm telling you that some part we can take onto the blockchain some assets take onto the blockchain and we have a once the service has been onboarded and has been instantiated through the on app these events can be come up from the VES which is VNF event stream to the to the that DMAP through their DMAP service and DMAP service sends the data to the ANAI so rather than sending to the sorry it's sent to the orchestrator then orchestrator make decision based on that events and send to the response to the that business support system for for further that operations so so DMAP can call blockchain smart contract to give the information to the blockchain and blockchain take some you know operations on into the smart contact and then after getting the output of that smart contract it can send to the BSS to the BSS based on the event of the smart contract and the last we have SDC so as I told you that SDC we are maintaining the assets onto the blockchain as we are maintaining the as on app maintaining the assets on ANAI so we are also creating the assets on the blockchain and it is very easy to create the asset on blockchain and maintain the relationship between them so what we are providing through the blockchain the solutions using blockchain we can see that we smart contract for available resources and services for the BSS and the OSS right so all resources and services are as assets as I told you in previous slide in blockchain as like everything is asset in the ANAI we are creating the assets in the blockchain as well and the smart complex provide automation as a limit is meant for BSS like we don't need to write the separate code for this and we don't need to write that code inside the on app so on app is already busy with multiple modules as well so we can take this thing separate from the on app and take this onto the blockchain so that trust can be built with the BSS OSS and between the customers and vendors as well so and for any automation inside on app we can write a smart contract for that as well and the future of blockchain is one contract like we can manage the reputation of the VNFs like once the VNF has been onboarded and the service has been initiated on onto the VNF we can manage like let's suppose within a particular time VNF get down and event has to be sent to the on app but we can manage the reputation by showing that this this vendor VNF reputation is this in the in the numbering like we are providing the numbering of VNF to the BSS so that before initializing those or instantiating the services through the customer it can be it can be visible to customers so that they can check which VNF reputation is better and smart contracts for provisioning the reliability between the sdc and so even it provides the reliability between each modules of the on app and automation of validations and the service time instantiation by SO as I already covered this but it also provide the trust between on app modules and the future expectation is of blockchain is we can use blockchain in authenticity from ANAF which is a module of on app so this is this is the some part I have created onto the blockchain like you can see that tenent asset there is a tenent ID tenent name tenent context you can see so these these assets has been created onto the ANA same we are creating onto the blockchain so here is the flow of sorry so here is the flow of registration and sdc distribution using blockchain like as I told you that through the external api and vid external systems like BSNOS can create can upload their vendors can upload their models to the on app so these are the apis between them and you can see that that through the external api sdc for VNF is sending to the sdc module and then sdc module send this information to the SO catalog and to the ANA so here that sdc is when sending to the SO catalog and ANA is simultaneously sending to the blockchain as well in term of asset I am talking and once the sdc get the response from SO catalog and ANA blockchain is response to the external api then external api is sent to the response to the that OSSBSS systems so with the distributed you can see that there is a distribution ID with all parameters I am not I did not mention here it is a very complicated parameters so after distribution of that VNFs onto the on app and so OSSBSS can query that assets onto through blockchain apis directly rather than going to the SO and ANA so that BSSOSS can call the external api then external api call the blockchain api directly to provide the information to the OSS and based on this information OSS can perform their further operations and it is the service creation at the at the runtime means I have talked about like how we are using blockchain at the time of sdc now how you are using the blockchain at the time of runtime so once the distribution has been done any customers wants network services in slight instantiations then it come through the OSSBSS then call to the external api and then external api will call to the sdc for metadata and then external api call the SO for for requesting the service instantiations network service instantiations and then SO will call the blockchain rather than calling the api it call the blockchain to get the metadata of the of the information about the VNFs and the services which was uploaded at the time of sdc and then it it takes the response from the blockchain and then it it send the request to the controllers of the on-app so that service can be instantiated and then after fulfillment of the services by the controllers the response get back to the on-app and then on-app SO and then on-app SO send this data to the NAI and simultaneously send to the data on to the blockchain like service instantial ID you can see here on on the right side so these information has been updated on to the AI and blockchain as well and the same response has been written back to the external api and then BSS system so here is the service order state tracking so BSS can check the status of the service has been which has been instantiated through the SO so it can call blockchain api you can see at the bottom that it is calling the blockchain api and in the bottom and so rather than calling the as ANAI the information can be directly given by the blockchain apis to the OSS system so it fastens the on-app functionality as well and here is the service inventory inquiry by the OSS through the blockchain so external api will not call that ANAI to get the information about the instantiated services and VNF on boarded in the previous steps it directly called to the blockchain and then get the response from the blockchain like service instance let's suppose BSS won't the service instance like service instance ID sent by the BSS to the external api then based on that service instance ID data can be fetched out from the blockchain and the status of the that service inventory can be given to the back to BSS so here i'm going to talk about multi-domain orchestrator as i talked about like on-app so we have multi-domains like multiple telecoms and we have a multi-domain orchestrator so multi-domain orchestrator is connected with the blockchain through the blockchain apis what the multi-domain orchestrator is providing it's providing the end-to-end path between the between two destinations like we have a we have some office in India like we have some office in another country like we want some end-to-end path between these so there are multiple telecoms involved in this so so multi-domain orchestrator have a overall that view of the domains of each domains like what what is the you know links between these domains so on a so multi-domain orchestra have overall view of the links and paths between the that multi domains that domains multiple domains so here you can see that once the request has been initiated so first of all first of all every domain has to register itself with the multi-domain orchestrator and then multi-domain orchestrator send this data to the blockchain so that trust can be built between these entities because we are talking about the multiple domains and multiple domains not gonna trust on multiple on MDO which is multi-domain orchestrator so we have to provide some transparency and trust between these domains so we are using the blockchain here and we are also maintaining the SLA through the blockchain smart contract and we are also maintaining the automatic payout through the smart contract as well and we are also maintaining the multi-constrained of the request asked by the any client so is the flow diagram of the here the restriction part has already been done so now after restring each domain sends their information like domain name and domain ID every every information related to the restriction has has to be sent to the multi-domain orchestra and then these information send to the blockchain as well and then it every domain sends their as pure details which is a staple paths which is the paths within the domains like how how many paths within the domains so it so so up to here that domain all domains has to be registered onto the blockchain with their spo and links information to the to the MDO and blockchain as well so let's suppose if domain one wants N2N path then it's sent to the request N2N request to the MDO and then MDO will calculate the N2N paths it generates the N2N path ID and then it will send to this N2N path ID to the blockchain so that a domain can every domain can get to know that what's going on onto the MDO so it's to provide the trust between these and domains so here's the API flow that domain and multi-domain orchestra and the blockchain I'm running out of time I think so so it is the it we API flow I can see later like registration request sent to the MDO and then service has been N2N path has been established between between two domains and then for a particular period of time and let's suppose that any SDN get down and that path that path has been breached then how SLA will be fulfillment then SDN send the events to the MDO and then MDO will call the smart contract and the smart contract will automatically pay out to the domains so so this diagram is related to the links between the domains these you can see in the yellow and red color there are the multiple links between two domains it provides a multi-constrained quality of parameter as well so this is over I don't have time for our demo so that I can show you but if you have any questions you can ask me and this is my mail id we are also running a telecom sick group I want to tell you about this as well that we have a special interest group of telecom which is supported by hyperledger and Linux foundations in this group in this group we discuss how we can solve the telecom problems existing telecom problems through the blockchain and so this so we have bi-weekly calls on Thursday and if anyone want to join this group we are most welcome thank you so do you have any questions so this is the demo I want to show you but I don't have time for this it will take more time my question is what's the advantage of using blockchain technology to solve the telecom problem I think most of the problem can be solved or already solved but leveraging blockchain technology what's the advantage yeah it's providing the advantages between the multiple entities involved in the telecom like there is a trust and you know there is no easy way to provide the SLA management between between the telecoms there is a you know a long-term process to managing the SLA between telecoms so through blockchain we are providing automatic SLA management so there is no long way to solve the SLA management and it also providing the trust between the entities is also establishing that trust between the entities so so here each telecom involved in the business they are running their own north of the blockchain so every every telecom get to know that what's going on onto the network right thanks thanks for the presentation thank you you used on up as an as an example there yeah for for for for this application of of blockchains then do you foresee this being totally transparent to own up or is there something that should be done within own app project to support what you were describing you mean to say why I'm using blockchain in own app it is supported by own app as well is it no but the thing is that when you showed this one picture where you had the red arrows yeah moving out from own up to to the blockchain yes and so is it something that happens no transparent to own up or is it something that own up should be capable of supporting yeah actually it's it is i'm doing my own so your question is about on app is capable to call the ipis of blockchain right so why not actually in on app as i show you that diagram the dependency diagram between the own app modules each modules is calling to each other and there are a lot of apis rest apis between these modules so why not we take the blockchain api as well so that why i'm taking the blockchain here i can i can give the information to the os s directly rather than calling the external api and so and an ai so rather going through this we can call blockchain api from the external api and then give information to the bss as well so it it it overcomes the you know slowness of the on app i was going through the on app documentation and that that issue related directory someone mentioned that a and someone tried to install the on app and they were using on onboarding and service instantiation so they are saying that a and a is very slow it's not providing the data on time it's getting very slow so what i what i think that time that we can use blockchain here so that we can take some part of the ai onto the blockchain so it also provides the trust and the transparency between the modules and transparency with the the customers and network service provider as well so who was providing the who is providing the vnfs onto the on app okay so do you have any thoughts of bring this ideas into the on app community no recently i was working on this and i don't know will there will be support but i will present it to the on app as well