Motivation for Management of Network Slicing and IETF COMS work from Operator s View Point

Transcription

1 Mtivatin fr Management f Netwrk Slicing and IETF COMS wrk frm Operatr s View Pint Luis M. Cntreras (Telefónica) luismiguel.cntrerasmurill@telefnica.cm IETF 101 COMS BF, Lndn, March 2018

2 Multi-dmain prblem / COMS use case Vertical custmers can request services that lay utside the ftprint f their primary prvider Hwt reslve this? Dynamic and autmated interactin with ther prviders are needed but Hw we can charge and bill fr that service? Hw we can ensure SLAs amng prviders? Hw we can knw abut the capabilities f ther prviders fr a cmprehensive e2e service prvisin? Current whlesale and intercnnectin services and mechanisms are nt enugh in the era f virtualizatin and prgrammability In the case f Telefónica multi-dmain refers t either intercnnectins with ther prviders as well as intercnnectins amng affiliates (up t 15 Netwrks in Telefónica grup!) IETF 101, Lndn, March 2018

3 Intercnnectin mdels in place Nwadays, intercnnectin is cnceived as pure IP traffic interchange, which limits the capability f taking advantage f new advances like netwrk virtualizatin The current intercnnectin mdel is nt aware f peer s netwrk resurces (i.e., lad cnditins, etc) Nt feasible t implement an ptimal delivery f traffic (/service) amng peers All these envirnments are static, requiring lng interactins fr setting up any inter-prvider cnnectin Manual peratin f current intercnnectins prevents any flexibility Autmatin fr bth the intercnnectin sessins and the service deplyment n tp f that is needed t reach the gal f flexibility IETF 101, Lndn, March 2018

4 Challenges f multi-dmain service prvisin Strict SLAs, assciated t penalties guaranteed service is a must (latency, bandwidth, availability) High custmizatin in prvisining autmatin as the way fr simplifying the prvisining and prgrammability t reduce time t market ( time t revenue) Need fr segregatin Physical separatin (e.g., dedicated backbnes) nt cst efficient Overlay, in the frm f VPN as verlay slutin nt flexible nr agile Slicing, thrugh netwrk resurce (including SF) allcatin dedicated resurces per custmer/service t ensure islatin n tp f the same infrastructure Need fr standardized Slice aware Custmer / Tenant Service Interface and Service Delivery Interface in a single and multiple dmain Need fr interperable slicing prtcls and enablers Other netwrk segments / slices becme an integral part (E.g., Radi fr IT) Need fr a truly cnvergent netwrk IETF 101, Lndn, March 2018

5 New intercnnectin mdel Frm dedicated physical netwrks with dedicated cntrl and dedicated services and resurces fr different applicatins t a netwrk factry where resurces and netwrk functins are traded and prvisined New business and partnership ecsystem enabled thrugh APIs New ptential revenue surces New ptential revenue surces Deplyment f SFs wrking cleanly in IT PPs Capability fr trading slices f resurces

6 Multi-dmain prblem Cnventinal Carrier Netwrks des nt have the tls t cpe with custmized multidmain service creatin and delivery with very shrt lead times IETF 101, Lndn, March 2018

7 Multi-dmain prblem Cnventinal Carrier Netwrks des nt have the tls t cpe with custmized multidmain service creatin and delivery with very shrt lead times IETF 101, Lndn, March 2018

8 Multi-dmain prblem Opprtunity fr instantiating SFs in prximity Better service fit Cnventinal Carrier Netwrks des nt have the tls t cpe with custmized multidmain service creatin and delivery with very shrt lead times Resurces (incl. SFs) need t be allcated fr the new situatin Prper Cntrl and Mngmt Interfaces shuld be ffered by the remte dmain Need fr scaling SFs in the rigin dmain It culd nt be sufficient IETF 101, Lndn, March 2018

9 Multi-dmain prblem Cnventinal Carrier Netwrks des nt have the tls t cpe with custmized multidmain service creatin and delivery with very shrt lead times IETF 101, Lndn, March 2018

10 Multi-dmain requires standard mechanisms Multi-dmain implies integratin f distinct administrative dmains Standard prcedures are required t minimize integratin csts Flexibility, agility, etc E.g., BGP Different functinal behavir t be cnsidered Cntrl f resurces and SFs Tplgy f resurces and SFs Lifecycle management f the slice Mnitring etc IETF 101, Lndn, March 2018

11 Cncluding remarks Expecting realizatin f Multi-dmain netwrk slices - Standard prtcls and service interfaces are required t minimize integratin csts and maximize interperability Grup f slutins are needed (e.g. COMS slutins) IETF is an apprpriate and unique SDO place fr creating it. COMS area NS Tenant SDI NS Prvider NS Orchestratr (NSO) Custmer Service Interface (CSI) Service Delivery Interface (SDI) NSO Netwrk Cnfiguratin Mdel Tech A cntrller Tech B cntrller Device Cnfiguratin Mdel Underlying Netwrk Resurces/Functins IETF 101, Lndn, March 2018

12 Backup 12

13 Evlutin f whlesale services Operatrs start deplying its wn cmputing capabilities UNICA envirnment in the case f Telefónica Operatrs can leverage n these capabilities fr creating service fferings t external (vertical / whlesale) custmers E.g., by deplying (r requesting) specific service functins and service graphs It is necessary t find prper mechanisms fr trading these capabilities (at resurce and service functin level) It is necessary as well t implement prtcls / APIs that culd allw this t happen in an autmated way And it is als necessary t prperly cnfigure and manage them either frm the prvider r the custmer perspective!! Adaptatin t variable demands and changing service endpints require mre dynamic and respnsive mechanisms fr service delivery IETF 101, Lndn, March 2018