Krzysztof Szarkowicz, Principal Product Manager, Juniper Networks

Cloud Metro: Architecture, Use Cases, Customer Case Studies

Cloud Metro5G
Krzysztof Szarkowicz Headshot
A slide titled Layer 2 Business Access - Migration Scenarios, from a presentation by Krzysztof Szarkowicz, Principal Product Manager, Juniper Networks. A diagram shows network, data center, and cloud architecture and lists key features of network components.

Why is Cloud Metro such a big deal?

The acceleration of digitalization opens the door to incredible opportunities—and new challenges. This session offers a look into Cloud Metro architecture, providing architectural details for different use cases including MEF (Business Ethernet) services, backhauling for residential subscriber management services, network slicing, and more.

Show more

You’ll learn

  • Architectural details for a traditional and emerging metro use cases

  • Cloud Metro for mobile 4G/5G transport

  • Customer case studies based on Cloud Metro architecture

Who is this for?

Network Professionals Security Professionals


Krzysztof Szarkowicz Headshot
Krzysztof Szarkowicz
Principal Product Manager, Juniper Networks


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]

Show more