Control Architectures for Multi - PDF document

1 Control Architectures for Multi - layer
Control Architectures for Multi - layer Networking: Distributed, centralized, or something in between? Ori Gerstel, CTO Sedona Systems 24 - Mar - 2015 1 OFC 15 tutorial - Sedona Systems What is SDN (in 1 slide) • A control architecture that is based on centralized control instead of distributed control • Why? • Simpler design/code than a distribu

2 ted solution • Opportunity to commodit
ted solution • Opportunity to commoditize the hardware • Open for 3 rd party app development • More optimal global decisions 24 - Mar - 2015 2 CP CP CP Distributed architecture (PMO) Centralized architecture SDN Data Data Data Data Data Data OFC 15 tutorial - Sedona Systems What is SDN (more realistic definition) • A control architecture that is ba

3 sed on some centralized control instea
sed on some centralized control instead of fully distributed control • Why? • Existing gear will live in the network for many years • Some functions are better implemented in distributed fashion • The risk of moving to a disruptive new architecture is too high 24 - Mar - 2015 3 Hybrid architecture SDN OFC 15 tutorial - Sedona Systems CP CP CP Data

4 Data Data Different forms of control di
Data Data Different forms of control distribution (outline) • Network control architecture • Internal controller architecture • Multi - layer/vendor architecture 24 - Mar - 2015 4 OFC 15 tutorial - Sedona Systems Sweet - spot for distributed and centralized control Distributed control sweet - spot • Real - time: optimized for restoration • L

5 ocalized changes • Good enough for cus
ocalized changes • Good enough for customers with basic agility needs • Highly survivable – even during large scale disasters • Harder to extend Centralized control sweet - spot • Slower: good for optimization • Global network changes • Adds value for customers expecting advanced features • Less available – unless significant compl

6 exity is added • Ease of extending th
exity is added • Ease of extending the code A combination of both can provide an optimal solution 24 - Mar - 2015 5 Hybrid distributed and centralized control – not our invention… Centralized control Distributed control 24 - Mar - 2015 6 R 1 R 3 O 1 O 2 O 3 SDN controller 3 . GMPLS - UNI creates the optical circuit leveraging WSON 3 2 . SDN contr

7 oller triggers creation of new link by
oller triggers creation of new link by provisioning the router with policies 2 Hybrid control example 1 a 1 . SDN controller learns optical network from (a) Optical layer, (b) IP layer 1 b 24 - Mar - 2015 7 4 . Upon failure GMPLS acts according to the policies Hybrid control – a spectrum of architectures Distributed model Central path compute (PC

8 E) model Policy provisioning model Ce
E) model Policy provisioning model Centralized model Hybrid control models 24 - Mar - 2015 9 Initiation Policy decision Path selection Path setup Distributed model Central path compute model Policy provisioning model Centralized model • Initiation : who decides to set up the path? • Policy decision : who decides about the constraints for the path? â

9 €¢ Path selection : who decides how to r
€¢ Path selection : who decides how to route the path? • Path setup : who configures the nodes along the path – and (typically) who restores it? Hybrid control models • Setup initiated by the head - end of the path • It decides on the constraints (min latency? max diversity?...) • The head - end computes the path based on local info (or this could

10 be a collaborative effort with other no
be a collaborative effort with other nodes along the path) • The path is set up via distributed signaling (RSVP ) • The network retains autonomous actions (e.g., restoration ) 24 - Mar - 2015 10 Initiation Policy decision Path selection Path setup Distributed model D D D D Central path compute model Policy provisioning model Centralized model Hybrid con

11 trol models • Setup initiated by the h
trol models • Setup initiated by the head - end of the path • It decides on the constraints (e.g., based on user request) • The head - end asks for a path from centralized path computation (PCE) • PCE may provide an strict path (C) or a loose path (C+D) • The path is set up via distributed signaling (RSVP ) • The network retains autonomous action

12 s (e.g., restoration ) 24 - Mar - 2015 1
s (e.g., restoration ) 24 - Mar - 2015 11 Initiation Policy decision Path selection Path setup Distributed model D D D D Central path compute model D D C [+D] D Policy provisioning model Centralized model Hybrid control models • Setup initiated by the central controller • It decides on the constraints and provisions the head - end with one or more poli

13 cies • The head - end computes the pat
cies • The head - end computes the path based on the policies • The path is set up via distributed signaling (RSVP ) • The network retains autonomous actions (e.g., restoration) 24 - Mar - 2015 12 Initiation Policy decision Path selection Path setup Distributed model D D D D Central path compute model D D C [+D] D Policy provisioning model C C D D Ce

14 ntralized model R 1 R 3 O 1 O 2 O 3 SDN
ntralized model R 1 R 3 O 1 O 2 O 3 SDN controller 3 . GMPLS - UNI creates the optical circuit leveraging WSON 3 2 . SDN controller triggers creation of new link by provisioning the router with policies 2 Hybrid control example (recap) 1 a 1 . SDN controller learns optical network from (a) Optical layer, (b) IP layer 1 b 24 - Mar - 2015 13 4 . Upon f

15 ailure GMPLS acts according to the pol
ailure GMPLS acts according to the policies Hybrid control models • Setup initiated by the SDN controller • It decides on the constraints • It computes the path based on global info • It sets up the path by provisioning each node separately • Most (all) network control functions are centralized 24 - Mar - 2015 14 Initiation Policy decision Path s

16 election Path setup Distributed model D
election Path setup Distributed model D D D D Central path compute model D D C [+D] D Policy provisioning model C C D D Centralized model C C C C Different forms of control distribution (outline) • Network control architecture • Internal controller architecture • Multi - layer/vendor architecture 24 - Mar - 2015 15 OFC 15 tutorial - Sedona Systems

17 Carrier grade requirements • Typical
Carrier grade requirements • Typical carrier - grade req.s for the controller: 1. It must survive HW/SW failures 2. It may have to keep working during SW upgrades 3. It may have to scale to a large number of transactions • (Some of these req.s are not mandatory if the controller is not involved in real - time operation) Distributed systems address

18 these req.s • A failure of one copy d
these req.s • A failure of one copy does not affect other ones • Upgrade of one copy allows other copies to continue working • The workload can be distributed amongst multiple copies Distributed systems address these req.s • Typical solution: use distributed database to keep all copies in sync Controller Adapter NE Adapter NE Apps Network DB Contr

19 oller Adapter NE Adapter NE Apps Control
oller Adapter NE Adapter NE Apps Controller Adapter NE Adapter NE Apps Controller Adapter NE Adapter NE Apps Distributed network DB Are we back to complex distributed control? • One of the main promises of SDN was to simplify SW development by not having to deal with the complexity of keeping a distributed sys

20 tem in sync • Are we reintroducing thi
tem in sync • Are we reintroducing this complexity? • Answer: no • Distributed state management is handled by the distributed database in a unified fashion – no need to reinvent the wheel for every protocol • The application works the same as in a centralized system • All changes are under transactions, limiting possible inconsistencies Diffe

21 rent forms of control distribution (out
rent forms of control distribution (outline) • Network control architecture • Internal controller architecture • Multi - layer/vendor architecture 24 - Mar - 2015 20 OFC 15 tutorial - Sedona Systems Example for ML control: Router bypass • Based on traffic conditions, skip intermediate routers and connect directly routers that were not connec

22 ted before • Result: cost savings and
ted before • Result: cost savings and better adaptability to changing traffic conditions 24 - Mar - 2015 21 Example for ML control: Router bypass • Consider a network and 2 end - to - end traffic flows • What happens when a new bypass is added? • Case 1 : routing metric too low • The new link will attract unexpected traffic • Result: conge

23 stion 24 - Mar - 2015 22 Example for ML
stion 24 - Mar - 2015 22 Example for ML control: Router bypass • Case 2 : routing metric too high • The new link will not attract sufficient traffic • Result: wasted resources • Case 3 : routing metric in the right range • The new link may not attract sufficient traffic due to load balancing • Result: (less) wasted resources 24 - Mar - 201

24 5 23 Example for ML control: Router by
5 23 Example for ML control: Router bypass • Should the purple link be added to bypass router N 3 ? • Not simple to answer – it depends… • On the end to end IP traffic • On the routing metric assigned to the link • On use of IP load balancing • On share risks between the new link and existing ones • On protection capacity elsewhere 24

25 - Mar - 2015 24 Example for ML control
- Mar - 2015 24 Example for ML control: conclusions • Whenever IP topology changes  network simulation must be done • To ensure the new topology can support the traffic in an efficient manner and under all failure scenarios • This requires collection of a lot of global data • Therefore must be done via a centralized controller • It also requir

26 es a controller smart enough to accurat
es a controller smart enough to accurately simulate IP layer behavior 24 - Mar - 2015 25 Monolithic SDN architecture Monolithic SDN controller ML App 26 • Monolithic approach: • Single controller controlling multiple layers and vendors • Concerns: • Complex to manage • Complex to troubleshoot • Complex to upgrade • Recreating some of the iss

27 ues SDN was meant to solve 24 - Mar - 2
ues SDN was meant to solve 24 - Mar - 2015 L 3 NEs L 0 / 1 NEs OFC 15 tutorial - Sedona Systems Monolithic SDN architecture Monolithic SDN controller ML App 27 • More concerns: • Optical feasibility “must” be computed by the optical vendor • Simulation of IP layer behavior “must” be computed by a tool that understands its complexity â€

28 ¢ No single vendor can provide all of t
¢ No single vendor can provide all of this 24 - Mar - 2015 L 3 NEs L 0 / 1 NEs OFC 15 tutorial - Sedona Systems Modular Hierarchical SDN architecture • IETF proposal for rest API between controllers • May work well for single vendor at each layer • No “vendor lock - in”  no vendor at the top of the pyramid • (Still leaving the question

29 of open: who will develop ML apps?) L
of open: who will develop ML apps?) L 3 SDN controller L 3 NEs L 0 / 1 SDN controller L 0 / 1 NEs Modular Hierarchical SDN architecture • Very complex with several vendors and controllers ( MxN problem) • Each API change affects many systems • How are race conditions avoided? • Does every vendor create their own ML apps? • Very complex t

30 esting L 3 SDN controller L 3 NEs L 0
esting L 3 SDN controller L 3 NEs L 0 / 1 SDN controller L 0 / 1 NEs L 3 SDN controller L 0 / 1 SDN controller L 3 SDN controller L 0 / 1 SDN controller Modular Hierarchical SDN architecture Orchestrator L 3 SDN controller L 3 NEs L 0 / 1 SDN controller L 0 / 1 NEs ML App 30 • Modular approach: • Specialized SDN controller for each la

31 yer • Separate SDN orchestrator which
yer • Separate SDN orchestrator which relies on single layer controllers for single layer services • More open and flexible solution • Leaves room for vendor expertise and innovation 24 - Mar - 2015 OFC 15 tutorial - Sedona Systems Modular Hierarchical SDN architecture Orchestrator L 3 SDN controller L 3 NEs Vendor 2 controller Vendor 2 NEs

32 ML App 31 • In fact, in some layers
ML App 31 • In fact, in some layers (E.g., DWDM), a controller per vendor is likely • We have failed to agree on a common way to model transmission impariments 24 - Mar - 2015 OFC 15 tutorial - Sedona Systems Vendor 1 controller Vendor 1 NEs Summary • Both distributed and centralized control systems have valuable attributes for network cont

33 rol • It is possible to keep some func
rol • It is possible to keep some functions distributed while centralizing others • The entire controller may become distributed to meet carrier grade req.s • Multi - vendor systems are likely to be more distributed to allow for vendor innovation • Typical network control is likely to be hybrid for the above reasons Thank you! 24 - Mar - 2015 33 OF