Cloud Metro: Architecture, Use Cases, Customer Case Studies

00:05 [Music]

00:11 so let me introduce myself i'm christoph

00:12 sharkovich i'm principal product manager

00:15 but actually working in some solution

00:17 groups as uh so we have some solution

00:19 architecture team uh working on the

00:22 transport architectures focusing on the

00:24 mobile transport architecture

00:26 specifically undertake a cloud so

00:30 so we will be talking about cloud metro

00:32 uh

00:33 architecture so including you know cloud

00:35 metro for the business a customer

00:36 especially for inspection subscribers

00:39 and cloud metro for the

00:40 mobile transport

00:43 so going to more details

00:46 so okay lego described at the beginning

00:48 so i will be talking as well about some

00:50 roadmap items and the juniper is you

00:53 know they're free to change these

00:55 roadmaps what we can tell you what will

00:57 be actually implementing nothing

00:59 inventing so some legal disclaimer

01:01 disclaimer about that

01:03 and the agenda for this short

01:05 presentation is um we'll discuss the

01:07 cloud metro overview in general

01:09 what kind of use cases we have for the

01:12 cloud metro and then

01:14 we'll go in more specific to different

01:16 areas of the cloud metrics as mentioned

01:18 business services is the first area that

01:20 we'll be discussing residential services

01:23 is a segment area and here we as well

01:26 discussing more data's unified pond

01:27 solutions

01:28 and the mobile 4g 5g transport this is

01:31 three areas of the cloud metro that

01:33 we're going to discuss and of course at

01:35 the end some case studies from the real

01:37 customers without naming the customers

01:39 of course that's something that we we

01:41 are working with with their customers

01:43 so what is cloud metro yes for

01:46 traditional and emerging material use

01:47 cases so we divide cloud metro

01:49 applications

01:50 or architectures into three

01:52 free kind of

01:54 use cases that we are addressing

01:56 one use case is business services so we

01:58 have a cloud metro architecture for the

02:00 business services so here we are talking

02:02 about the internet business services so

02:04 some sort of meth defined services like

02:07 e-line ilan

02:09 is or ethernet and npls high capacity

02:12 and as well some isolated free services

02:14 like ipvp and ip services then sd1 and

02:18 cloud connect so interconnect the cloud

02:20 and here we are talking about you know

02:22 additional

02:23 services the required features required

02:25 like telemetry a ptp and so on

02:29 then the second bigger use case for use

02:31 case groups is residential services so

02:33 here we are talking about fiber to the

02:35 home so fttx in general aggregation and

02:38 again this aggregation could be using

02:40 some inline elan service so based on

02:42 internet mpls so it could be vpn or vpls

02:46 and as well so you know important here

02:48 is the multicast as well because we need

02:49 to deliver typically to residential

02:51 services residential subscribers we need

02:53 to deliver iptv so so multicast

02:56 capabilities required and ptp as well

02:59 the jeep on so we here will turkey more

03:01 data later about juniper unified

03:03 solutions so how we how we implement

03:06 that gpu how we unify that and there's

03:08 as well some cable yes what happens in

03:10 the cable space

03:12 when it goes to the cloud metro

03:14 and the third one is the mobile

03:16 transport so here we are talking about

03:17 4g and 5g especially 5g mobile transpose

03:20 of 5g mobile transfer bricks new

03:22 capabilities that are required

03:25 on the transport especially on the front

03:26 hold side so in 5g i will discuss later

03:29 on in the data so we divide the 5g

03:30 transport into three pieces front hold

03:33 mid hole and the back coil piece and

03:35 especially on the front side we have

03:37 very strict requirements when it comes

03:39 to latency that we need to provide over

03:41 the frontal and as well when it comes to

03:43 the timing and synchronization precision

03:45 so here we're talking about class c that

03:47 is required for the timing

03:48 synchronization but i will talk later in

03:50 more data so this is just a small

03:52 introduction and of course on top of

03:54 that we need to have automation suite

03:57 and this is our paradigm automation

03:59 suite so in this presentation i will not

04:01 cover the franklin automation suite but

04:03 paragon automations will be covered

04:04 later on by peter in subsequent

04:07 presentations one of the subsequent

04:09 presentations

04:11 great so let's start with the business

04:13 services so what we have in the business

04:15 services so basically we see you know

04:18 the transport network the cloud network

04:21 has converged metro so basically we have

04:24 one

04:25 transport one the converged cloud metro

04:27 transport that's supposed to cover

04:29 different use cases as you see here

04:31 there's a transport

04:33 you know built from from acx and mx

04:35 devices

04:37 and then we can connect different access

04:39 technologies to this transport that

04:42 could be other tea for example could be

04:44 some business access for the business

04:46 customers but it could be traditional as

04:48 well more traditional islam cmts and so

04:51 on so we believe that you know the

04:53 transport converge transport is there is

04:55 the future story here

04:57 the physical topology of the transport

04:59 in the cloud metro could be different as

05:01 well so here's an example of a spinal

05:03 leaf architecture then you have couple

05:06 of spines a couple of leaves here and

05:07 multiple leaves but of course depending

05:09 on the on the layout of the physical and

05:12 requirements of physical constraints and

05:15 given provider given operator could be

05:17 different topologies this could be ring

05:18 topologies urine topologies are very

05:20 frequent as well very frequently used or

05:23 it could be some combination of ring

05:24 topologies finally topologies some

05:27 passion mesh topologies as well so we

05:29 are prepared for that

05:31 on them

05:33 on all fronts and then you know from the

05:36 domain perspective from the transport

05:37 what we see

05:39 the new emerging protocols that are

05:41 emerging now as we speak is segment

05:43 routing yes all sorts of segment routing

05:45 so we're talking about segment routing

05:47 segment routing traffic engineering and

05:49 topology independent lfa so tlfa

05:52 provides full backup coverage regardless

05:55 what is the physical topology so

05:57 traditionally in the past lfa

05:59 had certain restrictions you know it

06:02 required nice topology from the physical

06:04 perspective in order to provide a

06:06 hundred percent coverage but with

06:08 segment routine introduction of segment

06:10 routing and tlfa which

06:13 segmentation brings to the table we have

06:15 the full coverage full backup coverage

06:17 and then you know the dc domain as well

06:19 we are talking as well we are the

06:21 introduction of segment routing

06:22 capabilities and as well srv6 so we're

06:25 looking

06:26 looking as well some customers you know

06:28 looking for srv6 in the dc domain to

06:31 implement srv6 in the dc domain

06:34 and then on the aggregation igp domain

06:36 you know again segment routing with

06:38 different extension segments i think

06:40 maybe a service six as well

06:42 and then for intra domain

06:43 use cases i will cover electrons one

06:45 more day

06:47 so when the network is very very large

06:49 and then we need to divide this network

06:51 the smaller domains okay because of the

06:54 scaling issues of last radius of of some

06:56 failures scenarios and so on so we're

06:58 dividing the multiple domains we are

07:01 introducing here as well new

07:02 capabilities like bgp class for

07:04 transport so i will mention that

07:06 discussion later in the latest and as

07:08 well controller-based capabilities of

07:11 creating end-to-end tunnels

07:13 using pc controllers so in our case is a

07:16 paragon

07:17 a pathfinder which will be covered in

07:19 more data in the in some subsequent

07:22 presentation

07:24 so business services so as i mentioned

07:25 so that the characteristics of the

07:27 business services

07:28 we have a basically you know on the high

07:31 level two kind of business services one

07:33 is the internet business services so

07:35 this is the

07:36 uh the layer two kind of services

07:38 internal based services and the models

07:41 for this internal based services are

07:42 defined by math metro ethernet forum and

07:45 here we are talking about e-line which

07:46 is point-to-point connection at the

07:48 layer two we are talking about e3 which

07:51 is point to multi-point connection at

07:55 layer two and we are talking about elan

07:57 which is a multi-point to multi-point

07:59 connection and layer two and these

08:01 connections could be implemented using

08:03 different technologies you know it could

08:04 be different

08:06 implemented using dpls traditionally

08:08 a subseed wire emulation speedway

08:11 emulation for the point-to-point

08:13 technologies and vpns for some sort of

08:15 multi-point technologies but the

08:17 emerging key technologies which are

08:19 emerging now is evps

08:21 international private network which they

08:24 very nicely implements all these

08:26 different

08:28 service models required for the layer

08:30 two and again the physical

08:32 infrastructure could be spinal leaf is

08:35 not such as shown here in the picture

08:37 what could be could be some more

08:38 advanced rings and so on

08:41 so

08:42 when we talk about the migration yes

08:45 scenarios for layer two business

08:47 services

08:48 so traditionally layer two business

08:50 services are implemented using some sort

08:52 of epsilon emulation subsidiary

08:55 emulation typically using ldp based

08:58 signaling

08:59 or for the multi-point services is some

09:02 sort of vpls so which are private

09:07 never switch network

09:08 so with vpls and

09:10 this is some sort of hierarchical

09:12 replays as well that we have multiple

09:14 cd-wire emulations multiple epsilon

09:16 statements in the replace instance

09:18 now we are looking to implement this in

09:21 the new way with the advanced vpn

09:24 ethernet which are private network uh

09:27 and here the question is about the

09:29 migration from the old way you know how

09:31 we implemented in the old days and how

09:34 we implemented the new days and we are

09:36 offering here different sort of options

09:39 for

09:40 supporting the migration

09:42 so basically

09:43 for the migration you know when we

09:45 support for example we support a

09:47 configurable segment routing global base

09:50 so segmentating global base is some

09:53 based use though

09:55 so segment routing is basically

09:58 in a way to

10:00 distribute the labels

10:01 through isis or ospf extensions so there

10:04 are igp extensions to distribute the

10:06 labels as opposed to the traditional way

10:08 when they separate protocol like for

10:10 example ldp a level distribution

10:12 protocol to distribute the labels

10:15 and then we're distributing the levels

10:17 of rsi size we have predictive level

10:19 values so in ldp these little values

10:21 there are some sort of dynamic and talk

10:23 so we don't you know we don't know from

10:25 the label value what is exactly meaning

10:28 with the

10:29 segment we can configure base of the

10:31 numbers that we use for the labels and

10:33 then with very predictive labels

10:35 okay

10:36 then the key features that are required

10:37 for the migration scenarios for

10:40 business services as well as segment

10:42 integrity in migration

10:44 in such a way that implements the

10:46 marketing server

10:48 and mapping client so mapping server

10:50 marketing clients are used to map the

10:51 labels between the led domain and

10:54 statement domain

10:55 it's in both directions so one you know

10:57 one direction is

10:59 the direction is not being fired as well

11:01 as and the forwarding plane we

11:03 introduced with this mapping server

11:05 magnet client

11:06 features we introduced as well

11:08 um

11:10 you know stitching at the foreign level

11:12 so this is this is what is

11:14 very important here

11:16 and there are you know a couple of of

11:18 another features so prefix anika seeds

11:20 as segment id

11:23 static replace neighbors

11:25 and as well very important features

11:26 seamlessly placed to evpn migration so

11:29 basically this is the feature that

11:31 allows to create a single instance

11:35 and in the single instance this is evpn

11:38 instance but this evp instance can talk

11:40 as well over vpls to some

11:43 legacy you know pe

11:46 legacy routers using vpns language so to

11:48 say so this using an install can talk

11:50 both evpn language and vps language so

11:53 this is very important for the migration

11:55 scenarios so this is what we what we are

11:58 introducing here

12:01 all right so for layer free residential

12:04 uh for the free business

12:05 residential access we are introducing

12:08 couple of new architecture models so

12:10 first architecture model that i'm

12:12 presenting here

12:13 is based on the flexible cross connect

12:16 as you see here fxc is flexible cross

12:18 connect so what does it mean flexible

12:20 cross connect

12:21 so traditionally when we create layer to

12:24 see the wire

12:25 from from one device like here on the on

12:27 the bottom this icx device to some

12:30 another device here and on the top some

12:32 mx device so traditionally this layer to

12:34 see the wire needs to be terminated on

12:36 single physical interface

12:38 okay and in that case see so here if i

12:40 have free physical interfaces i would

12:42 need to create free seed wires to

12:44 interconnect these three physical

12:46 interfaces to the mx

12:48 so of course if if i need to if i think

12:51 about you know large network uh with

12:53 scaling requirements uh this requirement

12:56 if i have here 48 ports for example on

12:59 this box on a6 for 54 48 or four third

13:02 access ports it would mean i need to

13:04 create 48 fcd wires out of this single

13:08 access device to my some service device

13:11 mx so this this

13:13 you know great scaling challenges if i

13:14 have many

13:16 access devices like that and from every

13:19 access device i need to create large

13:20 number of seed wires so it might be

13:22 scanning challenge on the on the on the

13:24 service p and that's a

13:28 in that scenario so we introduce a

13:30 flexible cross connect with allows you

13:32 know to

13:33 cross connects multiple physical

13:35 isotropic from multiple physical

13:37 interfaces over a single

13:40 cd-wire okay this flexible cross-connect

13:42 see the wires of vexilar cross connect

13:44 evpn vpws service which are private wire

13:48 service allows to send the traffic from

13:51 multiple physical interfaces

13:53 okay and on the only one instance here

13:55 with matica physical interfaces and mcdo

13:58 wire is attached to this one instance

14:00 so this is this is very important

14:03 then another model as well that we

14:05 introducing are we supporting is the

14:07 multi-homic yes so we can active active

14:10 multi-homing as you see here

14:12 it's introduced using evpn ethernet

14:15 segment identifier so evp and

14:17 multi-homing this is evpn based

14:18 multi-homing they could be active active

14:20 active standby defective is the is the

14:22 most popular one and then in that

14:25 example you know the pawn device is

14:27 connected to two access devices to acx

14:29 access devices in active active

14:32 commander on the phone device it behaves

14:34 like normal lag interface aggregate

14:36 interface

14:37 all right and then the again is

14:38 collected from two's axis devices sent

14:41 to some um

14:43 service pe

14:44 on the service pe we are introducing as

14:46 well the concept of

14:49 of cd-wire head and termination

14:51 so basically with c2i and then

14:53 termination we terminate the speedo wire

14:55 again regardless if this is as i

14:57 mentioned before flexible

14:59 cross-connected wire with evpn service

15:02 or a plain evpmc driver we terminate

15:05 that on the on the single epsilon

15:07 determination interface and here we can

15:10 extract different vlans from the speed

15:12 wire to different services

15:13 as you see here we extract you know

15:16 zombieland to vrf1 service some anova

15:18 vlan to vrf2 service and maybe third

15:21 will undo some vpls service so it's very

15:23 flexible way of providing the services

15:28 so

15:29 for a another way as well so we have as

15:32 well more traditional with mc lac so

15:33 multicast is lack yes we multi-chassis

15:36 lack we can provide as well

15:38 the similar services of course there are

15:40 some some restrictions here

15:42 regarding the flexibility cross connect

15:45 for example and as well with multicast

15:47 slack we can provide active standby

15:49 services but otherwise the picture is

15:51 very similar the services we can provide

15:55 and then as well a number is for delay

15:56 free business access yes they are free

15:58 business access again

16:00 we have only a layer two on the access

16:03 site

16:04 a to provide

16:06 you know active active layer to access

16:08 from the from the uh

16:10 access device or ftth device in that

16:12 case here

16:13 and

16:15 immediately on the access

16:16 pe here i acx access d we extract this

16:20 layer to traffic into layer free so

16:22 every ilv integrated routing and

16:25 bridging interface okay with the

16:27 integrated loading and bridging

16:28 interface

16:29 to provide resiliency this rb interface

16:32 on on one xsp

16:34 and lb interface on an over xsp is

16:37 configured with exactly the same values

16:39 so you see this ipad which is exactly

16:41 the same micro this is exactly the same

16:43 which means if this ftth box is doing

16:46 some load balancing and so it doesn't

16:47 really matter over which member link the

16:49 traffic is sent it will land

16:51 you know

16:52 on the on the same irb from the fth

16:55 perspective and then irb interface this

16:57 is layer three interface this is some

16:59 interface which is teaching layer two

17:01 domain with layer free domain layer free

17:02 domain that means vrf so irb is placed

17:05 in the vrf and then from

17:08 that point on onwards we send the

17:10 traffic as free vpn traffic

17:15 now quickly let's go to the residential

17:17 services

17:19 so let's discuss the residential

17:21 services so again residential services

17:24 as well the important is the block

17:25 holding of the traffic typically you

17:27 know some sort of backlink of the

17:29 traffic from the

17:31 from the homes from the residential

17:32 places up to the places where we have

17:35 some bng so

17:37 so subscriber management

17:39 devices bng or some cache servers and

17:42 some internet so this is typical way

17:45 that with that we need to do that and of

17:47 course here as well we can do vpls uh

17:50 see the wire uh

17:52 emulation backhoe link

17:54 or in a new one is evpn base backhauling

17:57 so let me discuss and here is well

17:59 important some few

18:00 q and q so double vlans because for the

18:03 residential services we typically have

18:05 very very large number of of the

18:07 subscribers so with single vlan it would

18:10 not be possible to transport all this

18:13 traffic for subscribers seeing a million

18:14 dollars on the 4k subscribers so we have

18:17 super support for qmq and as well they

18:20 say snooping so typically these

18:21 residential subscribers that will

18:23 dynamically get ip address assigned igmp

18:27 snooping for iptv for example you know

18:30 not every subscriber is interested in

18:32 the same iptv channel so into five gp

18:35 snooping

18:36 to

18:37 to snoop to what the iptv channels are

18:40 required for given subscriber

18:43 so

18:44 what

18:45 new features that we introduce so

18:46 features on on acx devices that we're

18:49 introducing here to support this one

18:51 again so active active multi-homing evp

18:54 and active active multi-homing is

18:55 similar like we had in the previous

18:58 slides for

19:00 uh

19:01 business subscribers but in addition to

19:03 that one and then irb as well sir b

19:05 interfaces as discussed before but in

19:08 addition to that we have a advanced

19:10 feature for the hcp so we have the acp

19:13 relay on these rv interfaces

19:15 placing the evpn instances

19:18 as well as we have a synchronization of

19:20 dhcp relay state between two

19:23 access ps

19:25 so because the synchronization is needed

19:27 for the heb states

19:29 eventually if you like to do the hp

19:31 snooping on some dc base protections

19:34 that's like for example our dynamics art

19:37 inspection

19:38 so if the left

19:40 if the access p on the left hand side is

19:42 distributing the ip addressing to the

19:44 subscriber

19:45 then this information needs to be

19:47 synchronized with the access the device

19:49 on the right hand side so when the

19:52 for example dynamic arp inspection is in

19:54 place

19:55 and the traffic is not balanced to the

19:57 right

19:59 access the right acx this information is

20:01 available here for for dynam cart

20:04 inspection so this is what we introduced

20:06 on this on these devices as well and

20:08 synchronization as well on the ignp mlb

20:11 state so agmpmd snooping this is for

20:14 iptv distribution again if some igp you

20:18 know initial igmp

20:21 exchange was exchanged between the

20:23 subscriber and the left b

20:25 but eventually the traffic is sent

20:27 overnight speed and then of course right

20:29 p needs to have this state as well so we

20:31 need to have synchronization and this is

20:33 what we implement

20:35 here as well

20:38 and last but not least is

20:40 as well

20:41 distributed access architecture for the

20:44 cables of the cable operators so here we

20:46 are we have different architectures that

20:48 we are looking for so first architecture

20:50 is based on sql 3 mode 5. so on remote

20:53 file we have a remote file device and

20:56 the remote file device is doing on the

20:58 very very basic processing of the of the

21:00 signal yes that we receive for the rfi

21:03 signature dc for the coax cable is

21:06 basically putting this this signal in

21:08 some sort of

21:10 you know see the wires so as you see

21:12 here dps downstream external file

21:14 interface this is based on the ipc wire

21:16 so putting the signature wires and

21:18 transporting the signal you know for the

21:21 for the core

21:22 for the converge cable access platform

21:25 core

21:26 for for the processing

21:28 okay and so the advantage of this one is

21:31 that

21:31 in this part of the network

21:33 we can use ip network yeah because here

21:36 we can put the signal in some some of

21:38 ipc the wires so npsp device ipm pls

21:41 networks ipm psp wires so we don't have

21:44 to dedicate the network here only in

21:46 this part of the network you have

21:47 dedicated this box

21:50 network

21:51 another approach and over architecture

21:53 approach is that

21:54 some

21:55 processing some mac some mac layer

21:57 processing that here and the frisbee

21:59 approach is in the center alcohol site

22:01 is moved to the remote site okay and

22:04 that's the reason we call it a remote

22:06 machine

22:07 a device so here it requires more

22:09 advanced device in the remote sites but

22:12 here we don't need to have any sort of

22:14 tunneling as before so before we had

22:16 some sort of tunneling here side piece

22:17 in the wire say it's not my ip traffic

22:19 here already

22:21 and and the third one is the

22:22 visualization so basically this

22:25 converged cable access platform in

22:27 central location is being visualized so

22:30 this instead of having physical

22:32 dedicated services here we have mutual

22:34 services

22:36 running on the conventional intel

22:38 servers and so which are you know

22:42 platforms that this is basically the

22:43 same as model one model one and three

22:46 are very similar with the difference

22:47 that here we have everything is

22:49 virtualized instead of having a physical

22:51 devices so we see what we see on the

22:53 market what the one is the most dominant

22:55 with the three is taking over yes model

22:57 two is not the dominant this is what we

22:59 see but one three these two models are

23:02 pretty dominant in the market and here

23:04 you know some some more datas are the

23:06 use cases of this distributed access

23:08 architecture use cases so one very

23:11 simple use cases is that we have this

23:13 lpd so remote file devices

23:17 on the under remote locations they

23:19 collected by the acx you know access

23:23 devices access piece

23:25 uh sending some some ipc ui and this ipc

23:28 where it's going to nx 1003 and here you

23:30 know it's terminated and then the

23:32 traffic is distributed to the decor

23:34 functions so this is very very basic

23:37 location for this see the wiring or this

23:40 you know

23:41 signaling processing to work we need to

23:43 distribute as well the clock yeah so

23:45 that's the reason there's some grand

23:46 master in the corner of the network from

23:48 the grand master without distributing

23:49 the clock the clock needs to be

23:51 distributed to the rpds and that's what

23:53 needs to be available in the central

23:54 location because otherwise we cannot

23:56 recover the the signal

23:59 i know one advance you know depending on

24:01 the size of the network but in the

24:02 remote locations and the central

24:04 location we could have more advanced

24:06 hear scenarios

24:08 using some spinal leaf architecture with

24:10 the leafs being acx and the spines being

24:14 qfx so the reason that leaves ccx is

24:16 because we need to have here some

24:19 clocking

24:21 so some boundary clock is required here

24:23 to provide the clock to lpd devices on

24:25 the spine the polymeric is not required

24:28 here we are

24:29 okay with the transparent clock as well

24:31 so that's the result which a cheaper

24:33 device with low buffering so it could be

24:35 could be used otherwise it's similar to

24:37 the previous case

24:39 and of course in more advanced even more

24:40 advanced scenarios when the transport

24:42 network you know this this central site

24:44 is much far away from the remote sites

24:47 and there are plenty of remote sites you

24:49 could have ever more advanced scenarios

24:51 using for example the rings of dwdam

24:54 rings

24:55 and with a670 100 rotaries which

24:58 recently were announced or recently were

25:02 released uh we can have colored optics

25:04 as well and with the colored optics we

25:06 can you know attach these

25:08 rings directly to the dwm this rod is

25:11 directed to the dwdm rings

25:15 all right let's go me now for

25:17 residential services

25:20 so residential services uh for

25:22 resonations this is specifically for the

25:24 uni for unified point solutions yes you

25:26 need five point solution so basically

25:28 what we are introducing is unified fund

25:31 solution what does it mean unified

25:32 unified means that we have a sfd which

25:36 supports rlt so this is modular team so

25:38 sf sfp with the ot support as you see

25:42 here this fap consumes a little bit more

25:44 power than the traditional sfp that's

25:46 the reason you know there's additional

25:47 stuff for the cooling with this sfd at

25:49 the same radiators here for the cooling

25:51 sfp then we have junos rotor when we

25:53 inject this sfp

25:55 and broadband gateway somewhere that

25:58 do subscriber management

26:01 all right and then basically in we are

26:04 replacing a traditional way of deploying

26:07 all the networks say that we have some

26:09 you know h or access rotor and this

26:11 x-axis rod is connected to some pony or

26:14 t-shelf in this finality chevy's you

26:16 know lt determination

26:19 instead of that we have still our h-axis

26:22 router which is acx so initially we

26:26 qualified this solution on the acx

26:27 service specifically on a6 5448

26:31 initially

26:32 but you know in the future we might

26:33 quantify the national devices and here

26:36 we inject this you know sfp

26:40 plus base the all t devices directly

26:43 into the uh into the router okay so this

26:45 is very efficient instead of having

26:47 separate boxes we have everything

26:49 integrated

26:50 into one box is a very efficient

26:52 solution and as i mentioned initially we

26:55 support we qualify this on ac axis and

26:57 we have three types of a6 5448

27:00 specifically and we have three types of

27:02 a6

27:03 5848 so a6 basic a6 5048 then 5448d

27:09 which has the dwdm interfaces for the

27:12 uplinks and a650 ford 48m which has a

27:16 maxx support okay so for all of these

27:18 three types of 5448 this solution is

27:23 qualified is supported

27:26 because of the cooling requirements or

27:29 power

27:30 requirements of these sfps as i

27:32 mentioned they consume more power than

27:33 traditional sfps we can they populate

27:36 only half of the ports on a6 54 48 with

27:40 that we despawn all the panels the sfps

27:43 so which means we can populate 24 uh

27:46 imports 24 sockets yes if this is a

27:49 piece remaining circuits can be

27:51 populated with something with

27:52 traditional sfp

27:53 and the because of one sfp one the

27:56 finality sfp we support up to 128

27:59 subscribers so it means that the 186

28:02 5448 can support up to 3 000 subscribers

28:05 and then subscriber management itself is

28:08 you know

28:09 taking place on dng on the mx

28:12 broadcast

28:17 so unifying the solution components

28:19 again is a sfp which is injected into

28:23 acx 5448 router so all the bases fb this

28:27 is one solution

28:28 then we have a controller says

28:30 lightweight agent on the routers

28:32 managing the sfps and this as well

28:34 manager so central database is a

28:37 software with the central manager

28:38 software managing this all dc from the

28:41 center location

28:43 so there are the three components

28:45 and because of that as you see here that

28:47 this component so we have a

28:49 panel t injected in acx routers then we

28:52 have some control processor and the

28:55 central manager to manage all the

28:57 database from online on all phones in

28:59 the network and and bng or virtualbng as

29:02 well to make a subscriber management and

29:05 everything communicates over traditional

29:07 ips network so we could have here

29:09 traditional ipm based network

29:11 whatever is is so good could be shared

29:14 this network could be shared with the

29:15 other services used in the network

29:17 doesn't need to be dedicated for the

29:19 phone rlt

29:22 all right

29:23 and the last but not least

29:24 is mobile

29:26 mobile 4g 5g transport network

29:29 so

29:31 what we see the in the mobile what's

29:32 happening in the mobile space when it

29:34 both it goes to the transport and the

29:36 radio as well itself is the shift in the

29:38 how the radius are being built so

29:40 traditionally the radius are being built

29:42 in such a way that we have a remote

29:44 radiohead so basically antenna on the

29:46 top of the tower

29:48 and the bottom of the dowel bbu basement

29:50 unit so basement unit is you know

29:52 processing the antenna signal and it's

29:54 locally on the same location so antenna

29:56 is the top of the tower bbu's bottom of

29:58 the tower and let's say 89 of

30:00 deployments is following this this this

30:02 model today

30:04 then

30:05 some of the deployments in a slightly

30:07 different in some of the deployments we

30:09 are putting away this dbu to some more

30:12 centralized location centralized

30:14 location so the reason being is because

30:16 in that case

30:17 these bbc use doesn't need to be

30:19 hardened because if you know central's

30:21 locations 20 views i can have small

30:24 you know small small central office

30:26 whatever with with proper cooling and so

30:28 on this previous doesn't handle so the

30:31 overall operational cost is slower

30:33 comparing to the hardened dbus at each

30:35 tower location

30:37 and the you know communication between

30:39 these bbus and the and the

30:41 remote radiohead antennas is based on

30:43 the front hall protocol which goes

30:45 simply common public radio interface so

30:48 common public radio interface is some of

30:50 secret switch protocols it's not not

30:52 internet based not ip based not mpls

30:54 nothing like that it's circuit switch

30:56 it's something like you know tdm kind of

30:58 of protocol something and not exactly

31:00 but something like that

31:02 and

31:03 there are strict requirements here this

31:04 bbu cannot be very far away from from

31:07 antenna because otherwise the antenna

31:09 cannot be processed correctly so we are

31:11 talking about 10 to 20 kilometers

31:13 approximately so the reason being the

31:16 latency between bbu and remote radiohead

31:18 we are talking here about around 100

31:20 microseconds so that's the reason that

31:22 it cannot be because if it's more than

31:24 these 100 microseconds for example one

31:25 millisecond latency we cannot really

31:28 recover the signal so that's that's the

31:30 challenge and we see you know this is

31:32 ten percent approximately deployments

31:34 using this model

31:36 no this model is further changed by

31:38 virtualization of the dbus so if the

31:41 instead of having the physical

31:42 appliances for bbus we are having some

31:45 small data center with some intel based

31:47 you know servers on this inter-based

31:49 service we are installing bbu

31:50 applications which are doing the signal

31:52 processing

31:53 of course a digital signal processing

31:55 requires some special computation power

31:58 so these servers need to have some

31:59 special hundred pieces uh for for

32:01 supporting this dsp processing okay this

32:04 is not the traditional server but with

32:05 some additional hybrid piece could be

32:07 based on fpga for example is this

32:10 you know additional dsp processing

32:11 capability or gpu graphical or

32:15 graphical

32:16 process unit processing unit as well it

32:18 can be used for that

32:20 and further for 5g what we are seeing is

32:23 that further this component bbu is

32:25 divided into two separate components one

32:29 component is called du so distributed

32:31 unit

32:33 and an overcome company is called cu

32:35 centralized unit so du component is

32:37 strictly used to you know to completely

32:40 process the antenna signal fully process

32:43 antenna signal and convert this antenna

32:45 signal to ip packet so extract you know

32:47 ipv packets from data snip packets cu is

32:50 used more for the coordination between

32:53 multiple antennas and so on okay so this

32:55 is that's the reason we don't see the

32:57 process here we antenna signals and

32:59 longer so which means this handle

33:00 requirements when mentioned before the

33:02 server is adequate only for the edu as

33:05 well as strict you know

33:07 clocking synchronization requirements

33:09 adequate on the du as well

33:12 so basically so this is the challenge so

33:14 this is the difference that we see yes

33:15 enough b is is you know is distributed

33:18 across them

33:20 radio you need a distributed unit and

33:22 centralized unit with additional pieces

33:24 of the transport network pistol front

33:26 hole and the mid hole and therefore the

33:28 front we have very strict requirements

33:30 here like hundred to 200 microseconds

33:32 latency another requirement for 5g as

33:36 well is a very slight timing

33:37 requirements so here time alignment

33:39 error this is a you know

33:41 timing precision required between two

33:43 radio units between the antennas again

33:46 depending what kind of radio features we

33:48 are implementing we try to implement

33:50 these requirements could be very strict

33:52 for example very typical requirements

33:53 that we see today is here for 260

33:56 nanoseconds on 130 nanoseconds between

33:59 two antennas in order to implement these

34:01 advanced features like for example

34:03 indra band continuous carry aggregation

34:06 in frequency range too intravenous

34:07 conditioner

34:09 aggregation is some sort of aggregation

34:11 of the

34:12 radio spectrum regular channels

34:15 and and it's important

34:17 we see the requirements as well for the

34:19 transport slicing so we see three

34:21 different transport slice architectures

34:23 or use cases one is tactical link

34:26 slicing so which means we have one link

34:28 i would like to know which analyze this

34:30 thing somehow another is network sharing

34:32 use case when you have in

34:34 network transport and we would say okay

34:37 green operator can use twenty percent of

34:39 capa capacity of this network and red

34:42 operator can use fifty percent capacity

34:44 of this network yeah this might be used

34:46 for example for the run sharing and in

34:49 the run sharing we have as well so

34:50 access network is shared but we multiple

34:52 operators

34:53 and then at the very end we have you

34:55 know dynamic free gpp end-to-end slicing

34:59 requirements or use cases

35:02 so from the building blocks not the

35:03 transport network you see what features

35:05 or what the building blocks we have to

35:07 implement the slicing

35:09 and in the cloud metro network so first

35:11 building block is some sort of

35:13 isolation or separation of the traffic

35:15 but in different slices is required this

35:18 is being implemented using traditional

35:19 vpns so nothing new here so we have

35:22 layer free vpns

35:23 mvp and vpns and vlans as well the

35:26 access interfaces so basically this is

35:28 business as usual then the second

35:31 building blocks the second aspect of the

35:33 transfer network slicing the cloud

35:34 network is some sort of topology

35:36 differentiation so i have one physical

35:38 topology but out of this one physical

35:41 apology i can topology can create

35:43 multiple logical topologies okay

35:46 the third one is some sort of resource

35:47 guarantees so we need to provide some

35:49 resource guarantees for the slices

35:51 uh and the fifth one the fourth one

35:53 sorry is the om monitoring so we need to

35:56 monitor the sla

35:57 of the slices

35:59 and the fifth one is end-to-end

36:01 orchestration which will be covered in

36:03 the subsequent session

36:05 so the mapping and then specifically

36:07 when we talk about the mapping of these

36:10 slices to the free gpp use cases on the

36:13 run scientific gpp you identify the

36:15 slices using using ssd sd ssds service

36:19 type as the slice differentiator

36:21 these these slices are mapped to some

36:23 vlans and there's villain handoff

36:25 between the radio site and the transport

36:27 site called metro site and then as i

36:29 mentioned so here we have this

36:30 attributes like vpns some topology

36:32 differentiation and some resource

36:34 guarantees

36:36 recently we introduced as well for

36:37 topology differentiation a new feature

36:39 in joonas this is introducing 21.1 so

36:42 this is q1 of this year

36:44 and basically we are

36:46 from q1 this year we are capable to do

36:48 multiple routing tables per topology

36:50 slice for topology so basically you know

36:52 we can create a

36:54 low latency panels using whatever slt or

36:58 or flex algo or lsvp some other tencent

37:01 unless and we install these lower tensor

37:03 panels in this orange routing table then

37:06 another set of panels you know is

37:07 created

37:09 optimized for the best for the so high

37:10 capacity the best therefore are these

37:12 standards are inside the green tracking

37:14 table and so on and then later on when

37:16 the traffic is mapped this nothing is

37:19 mapped by all the additional attribute

37:20 that is distributed with the refugee and

37:22 prefixes which is the extended humanity

37:26 so here you see our extended community

37:27 smart so which means the protocol next

37:29 call for this report these graphics will

37:32 be resolved inside of this traffic level

37:34 so this

37:47 as well the new for the um

37:50 advanced architecture with multi-domain

37:52 architectures in order to create the

37:53 slices across multiple

37:55 multi-domain cloud architectures so

37:57 transport architecture

37:59 a new

38:00 extensions to bgp which are called bgp

38:02 class classical transport so there's

38:04 reference here to the to the the draft

38:07 and this is basically enhancements of

38:08 bgplu so this is you know like vgplu

38:11 today with the addition of slice

38:13 awareness so that we can create the you

38:15 know slices end to end using bgp class

38:17 for transport across multiple domains

38:20 and as as well we have another option

38:23 if for specifically for customers that

38:25 are looking for end-to-end slt

38:27 calculations so we have some optimized

38:30 end-to-end

38:31 handles calculations when we optimize

38:33 the

38:35 topology database visibility from remote

38:39 domains in order to scale this this in

38:42 the high in the high level domains and

38:44 this is called express segment

38:46 architecture

38:49 and

38:51 and we have

38:53 traffic as well introducing a new way of

38:56 of a here called qs

38:58 so h cos here so with h cos

39:01 we can

39:02 create

39:06 h strategies over interface without the

39:08 v naught so traditionally we need to

39:10 village here sub interfaces

39:12 and

39:13 here with this h cos new h cos we can

39:16 you know classify the traffic on the

39:18 input and then based on that we kind of

39:20 specify

39:21 attach h4 and output

39:23 and that's all what i wanted to present

39:26 so thank you very much

39:32 [Music]