SDN control of disaggregated optical transport networks

thank you and thank you for the invitation and the introduction I'm out lead from advocate any networking we are a vendor of optical and Ethernet devices and in this talk I will talk about software-defined network control a new network management and control paradigm for transport networks focusing on is there a laser pointer focusing on the disaggregated optical transport networks and I see that this talk is maybe a little bit different we go now towards more the lower networking layers layer 1 layer 2 so I will explain the different topics in the talk this is the agenda the the structure I will first talk a little bit about transferred Network transferred Sdn architectures then up to the network the segregation I focus and discuss a little bit the different data models there are in order to to specify and then to configure and control disaggregated optela transport networks and finally I give a few highlights and views from ongoing as the end interoperability events field trials and latest info from some research projects so first of all what is software-defined networking what are we talking about and this is a general emerging network architecture emerging is it started already several years ago where the network control is to be decoupled from forwarding directly programmable logically centralized and it's abstracted for applications and network services and therefore based on opens and the diced api's this definition is from the open networking foundation the sensation body or group that took on its banner to standardize the activities around Sdn and the the architecture on the right hand side is that at the lowest layer you have the infrastructure layer with the devices this may be routers switches or optical wavelength switches devices talking wire southbound interfaces to the control layer the southbound interface protocol is either used on open flow which is nowadays only used for packet networks anymore for transport network gear net confuse and is right now the most prominent protocol which most vendors are supporting and this protocol may also be vendor specific like old SNMP implementations or any CLI implementation so it this southbound interface could also be vendor specific the control layer has network services platforms abstraction and is communicating with a opened the standardized northbound interface towards different applications for transport network carriers networks optical long-haul or more Metro networks the open networking foundation defined a few use cases ranging from service management in order to do an automatic service creation covering layer 3 layer 0 to layer 3 network so from the optical OTN networks Ethernet and IP the elastic bandwidth provisioning is we are very far from that in the optical layer but for Ethernet this this bandwidth breathing of the of the bandwidth pipes that can be configured or seen as a use case data center interconnect in order to have the transport network more agile have service provisioning in the network is one use case and then the next one have this transport network as a service in order to integrate it with different other networking frameworks the two most prominent use cases for the optical network is multi-layer network management where you have a light pass you may have an TDM switched ODU path or an Ethernet path and all these three systems typically are different boxes different vendors and you would like to have one network management system which is able to configure all the boxes in order to have an end-to-end service over these different technologies and the same with the multi vendor support typically you have a vendor distinct domains in a transport network operator these domains can be either based on on the area in the network and access network domain has one vendor Accord Metro network domain has another vendor it can also be for dual vendor or strategies that you have at the same time two core network vendors in your network and those are separated in network domains but you will still have a single control layer in order to control this and currently this has to be done by very complex very expensive umbrella management systems and the idea here is to have this using standardized open source interfaces and protocols so how does the architecture look like again we have in the lowest infrastructure layer the network elements the devices with the IP routers Ethernet switches and rotom's record reconfigurable optical add-drop multiplexer the domains i already mentioned them you have the different technologies you may have different vendors for the IP layer for the optic layer and you have the network domains in the control you have typically a hierarchy of domain controllers a domain controller is responsible for one domain subtended to a multi domain controller which can then be integrated into a cloud Orchestrator taking into consideration also compute resources or storage resources in an end-to-end design so the main point here is the hierarchy of the controllers with open a api's and sanitized models that model is defined by the own F the open networking foundation there's also in the IETF and activity which is the actn abstraction control of traffic engineer networks this is based on all the works from from the gmpls standardization in order to have a distributed network control bringing it also into a centralized approach so that you have all this instead of having all these distributed protocols you now have a centralized configuration and control again it is very similar to the onf you have in this case while your own terminology of course physical network controller is the same as the Sdn domain controllers in the onf they talk to a multi domain service coordinator this can also be talking horizontally to other multi domain service coordinators and then they talk to a customer network controller and downwards you have all the southbound interfaces open flow path computation element protocol BGP or proprietary protocols and using this architecture here again is the goal to go between multiple domains also between multiple technologies from the IP layer for example to the optic layer in order to have an end-to-end light path there's the lot of activity in the ITF of course the ITF model is more straightforward if you have an IP over optical network and you're very much focused on the IP protocol mode of operation then the this can be seen because it is it uses the terminology it uses a lot of the specifications from the gmpls so it's rather straightforward to introduce this into your product so that was the ITF models were the first models being introduced in also in our optical devices but now most of the interoperability events from the big vendors are focusing on the O&F model which is what I will explain and they in the third part but before just looking at the time some views about optical network disaggregation this is a second big trend next to to the Sdn control and what is optical network the segregation a few years ago there were already first introduction of alien wavelengths last year there was a talk from gas line about alien wavelengths transport of services terminated or let's go to the next slide before sorry and as not everyone knows about optical network devices how these devices are set up for the terminology so we we talked about transponders in this case coherent transponders they take gray interfaces towards the switches and routers and have a long distance coherent colored WDM interface towards the optical network then they go into a filter with 80 or 96 channels have a booster and preamp amplifiers then they go to the optical fibre network every 80 kilometer or so you have to have an inline amplifier which is boosting the optical signal due to attenuation so you have then these ILA's amplifiers if you have a mesh network not only point-to-point connectivity but real meshed connectivity you need to have a reconfigurable optical add-drop multiplexer which has again these the amplifiers at the at the ingress and egress and this what is here is simply drawn as a kind of a cross connect in fact is built up from several different modules which are cabled wire fibers in a modular structure and you have again here you can have local air drop or you go to the other outgoing directions so this is just for terminology now for the disaggregation instead of having one big closed system god box all the devices are have their distinct functionality for the different layers and technologies and the optic layers in the circuit layer packet layer and they talked about open api in a current in a common infrastructure now still the optic layer traditionally is operated and to end from a single vendor from the transponder to the end of the transponder maybe on a line of point-to-point connectivity or mesh connectivity and now we add the Sdn api's the Sdn API is here on top which gives you the opportunity to have an end-to-end service setup over this network but this network is still one system from one vendor and the alien wavelength system now users have the possibility transport signals from one vendor over the network of a different vendor and there is one approach which goes into more detail the fully disaggregated mode now looks that all the different devices transponders filters inline amplifiers they can come from any different vendors they are specified and they have their own api's and are controlled individually and there are a few api's or our models propagate distributed and discussed which are focusing on this model this goes even that far that the individual degrees the outgoing lines of a Rotom are individually configured with their own api's the intermediate term is based on the alien wavelength concept so you have the transponder as one device from one vendor with a direct API and the open line system so the the analog photonic system distributed system has is operated with its own end-to-end API you can have full visibility and monitoring but you are not configuring individual power levels of EDF ace of inline amplifiers but you can set up an end-to-end service across the network and all the the inline activities are done by the system itself there's a good reason for this alien wavelength or partially disaggregate intent work and this is also based on the technology generations so the transponders typically have a shorter life time than the optic line system typically transponder generations are every three to five years you have the next line speed you have the next better energy efficiency of the transponders so the the the lifetime is much shorter than the lifetime of a fiber network with all the amplifiers which are distributed or nationwide so here you have 10 years 20 years of daeviation depreciation time and the transponders are much faster so even from this point financially from the from the logistics of purchasing this disaggregated model where you have the transponders make sense there have been several from the operators some visions on how they would like to to build their network in future here on this slide you see four different views and what they presented about their network views from Google in a talk Google is also as was Microsoft they see that the optical network should be configured as a whole they support the notion of a domain management system and domain controller and controlling then the transponders and integrating this into a automated network control environment Microsoft is very much pushing for the open line system again with a line system network management system which is controlling this end-to-end and then you have either transponders in a pizza box set up all you have colored interfaces in the layer two or three switches or routers attached to this open line system there's a nice paper from Mark filer at the Journal of optical communication networks already in 2016 so this was the vision idea Facebook and AT&T they propagate this fully disaggregated model where you have an API and a specification of down to the to the EDFA down to all the different devices and AT&T also have the specification MSA multi-source agreements on these technical specifications on road ohms on EDF phase with all their parameters together with the the data models in order to configure this so these two in the upper line and in the lower line upper line is model partially disaggregated model Facebook an eighteen team or the fully disaggregated Model S division for these visions the sensation bodies and also the industry Alliance has developed the data models the ITF that was kind of very early and very straightforward for all the IP over optical network operators so this was in our case the first step the onf was the transport ATI matured over time and is now very prominent because also I to TM EF and o if' also all propagating this transport API in the transport API you have different network services topology dissemination connectivity service path computation you can specify a virtual network and you can subscribe to notifications for alarming thank you and in addition to these standards ation bodies you have industry alliances I already mentioned Google and AT&T Facebook they are kind of separate because they do not specify their own models they want to to find an agreement and find models which are coming from the others and use this in an integrated way and to see how you can work with them so as time is running short slowly faster I already mentioned the transport API with the different services here you see one continue of the controller which has the network information context from the directly attached devices and from subtended sub domain controllers and then it has can use the same transport API towards the northbound application so you can use it in a hierarchical manner all these data models are published in the open domain and developed in in a community so in the own F transport API the data models are specified in in UML and generated out of the UML there's a young specification being generated and you can use code generators in order to generate from these young data models your code stops for the client and the server what you have to do still is to do the backend logic from the the server of these API in order to interconnected with your device and there's even though it's very deeply specified there's a lot of interpretation area so everyone who's even says they are 100% implemented all the latest api's still they may not inter work so the interoperability events are the most important thing in order to get people together and to test out their api's and their code generations in order to use the same semantics for these terminology on for these data's that is the open the Transport API there's currently a lot of development going on to add here a photonic media model for the optical network the other two models briefly open config I I think this the the link is on the next slide is also in github you can get all the models for the different terminal devices so they have this alien wave link model of the terminal is running over an outline system with the optical transport parameters driven by operators there is no no vendor a direct member vendors can participate but the the the core of the driving membership is from operators open config from what we see is quite prominent in the layer 2 and Ethernet switches and specification of IP routing protocols for the optical transport it is not seen as fully sufficient on its own so there are some deficiencies in the open config where you cannot set the modulation format or the forward error correction scheme that is being used all that is possible with open config but it has to be a vendor specific augmentation and then you end up with eight different vendor specific augmentations and again you lose the interoperability so we are not a fan when we do as the end we want to have interoperability so every vendor should use the same model with open road them they go one step further and they really define everything in detail with their mighty sauce agreement specifications for all the different network elements detailed technical specification and then they have the data models in the open Roden so they are constantly updating it the last one was updated October 5 this year so - yeah roughly two months ago was released for they are so close also to the technology that for each technology advanced they have to update the model the first two models were not suitable for flex squared data models so they had to be updated but now it seems that a open cornrowed model is more comprehensive than the open config so the challenges are 5 minutes left the challenges are that you have many heterogeneous network elements rodents have different levels of flexibility and especially in cost sensitive network areas metal networks data center interconnect the less flexible devices are in so we think data models have to be abstract from the technology in order to allow technology advances and people should agree on a small set of data models and this is what's being done in inter up events so currently the own F has a big working group open to segregated transport network which is now in the Phase two looking at mesh row demand here you see that they look either at the direct connection to all the devices like EDF A's or to have this subtended subtended as the end control below and the direct configuration of transponders and terminals all these models can be extended to multi domain transport of signals in this case you have two domains which are interconnected by gray optics so these domains are optically terminated and you have at the end they transponder pairs of of the vendors with an integrated multi hierarchical domain this was taken one step further in one recent multi vendor as the end trial in this case was to vendors current and at fun and here the rodents were back-to-back optically interconnected at the line side so you could transport an a light pass from vendor a over domain of vendor a transparently optical into domain of vendor B in this case alpha terminating at the same transponder as it started so the transponder pairs had told me from the same vendor but you could cross transparently different domains you see that this is most suited to regional network domains but this was done over fiber deployed in the stock area so real fiber again with the domain control into an open source as the end controller open daylight with a network planning application running as a micro service in the open daylight system which was able to do an inter domain path planning pass calculation of the optic layer we think that this is going in the right way we used own F transport API 2.0 with physical media extensions so the OTS eye layer was specified in order to allow optical performance planning and the optical performance parameters were disseminated through the domain controllers to this multi domain as the N control that was successfully live demonstrated at several events at akak this year at the SDN n ms world congress and gives kind of a nice view where we can go with these as an interoperability and looking into the future this is the final slide kind of that this is again from from a metro whole research project we have the optical domain the blue one the green is the transponder which has an agent their own models to configure transponder in this case open config we use a transport API to configure the optical the open line system integrated again in a other open source as the end controller on us and here then we attach or connect each data centers Metro data centers and this is then in a whole orchestration environment integrated into yeah OpenStack and NFV or open source mono so summarizing transferred Sdn and env orchestration there are already commercial solutions available and being deployed they are successful into optimized for partially disaggregated networks supporting distributed data centers and edge clouds and there are ongoing research activities in order to have the interoperability in order to go ahead with optical transparent domain interconnection there's an ongoing standardization effort required especially to harmonize all these different young models a lot of or all of these activities are being done in the open source domain so all of these data models are in github publicly available and yeah so we also see that partially variation in the open line system with per device data monitoring and the visibility into the network allows a good visibility and simplifies operation of the network we have shown that this is a working approach we are doing interrupts we are doing first steps tests with with customers with vendors sorry with network operators we would like to slim down the high number of different data models as it really is hard on the testing and delays the implementation so having a common model where everyone agrees to ideally I think this will be a combination of the different industry alliances and standardization bodies that we right now have we also are a little bit critical about the full desegregation as the the individual configuration of the individual network elements in an optical network is very complex error-prone and we propose that you have a network service which allows you to configure an end-to-end service through the optic layer thank you very much [Applause]

Channel: Sniper Network

Views: 112

Rating: 5 out of 5

Keywords: SDN, Software, defined, networking, sdn in iot, sdn tutorial, sdn architecture, sdn and nfv, sdn and nfv for iot, sdn and openflow, sdn basics, sdn based iot, sdn benefits, sdn cisco, sdn controller architecture, sdn concepts, sdn demo, sdn datacenter, sdn design, sdn example, sdn full course, sdn for dummies, sdn how it works, sdn in networking, sdn in data centers, sdn juniper, sdn kubernetes, sdn lectures, sdn load balancing, sdn network

Id: GuolCfvWyL4

Length: 28min 30sec (1710 seconds)

Published: Fri Aug 09 2019