Your SlideShare is downloading. ×
  • Like
  • Save

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Dynamic Service Chaining

  • 5,389 views
Published

Jan Lindblad's presentation at Layer123 SDN and OpenFlow World Congress in Bad Homburg, Germany. Focusing on a multi-vendor SDN deployment at a Tier 1 Service Provider in Asia. …

Jan Lindblad's presentation at Layer123 SDN and OpenFlow World Congress in Bad Homburg, Germany. Focusing on a multi-vendor SDN deployment at a Tier 1 Service Provider in Asia.

Tail-f Network Control System (NCS) use case:
• Dynamic control of L3-L7 devices using service- oriented network API
• Service chaining using OpenFlow
• Virtualized appliances

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
5,389
On SlideShare
0
From Embeds
0
Number of Embeds
8

Actions

Shares
Downloads
0
Comments
0
Likes
9

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Dynamic Service Chaining SDN OpenFlow World Congress, Oct 2013 Jan Lindblad, Tail-f October 10, 2013 1
  • 2. About Tail-f •  90+ customers since foundation in 2005 •  Roughly equal numbers in US, Europe and Asia •  HQ in Stockholm, US Office in Santa Clara •  Software products company targeting •  Service Providers •  Enterprise Data Centers •  Network Equipment Vendors •  Strong activity in standardization October 10, 2013 2
  • 3. About the Presenter Jan Lindblad is the Principal Solutions Architect at Tail-f Systems where he advises on the design of devices and network management solutions. He is a device and network management system expert with extensive knowledge in information and data modeling in Yang, XML Schema, UML and interfaces include carrier class Command Line Interface (CLI), NETCONF, WebUI and SNMP. Jan is an active member of TeleManagement Forum (TMF), Internet Engineering Task Force (IETF), Service Availability Forum (SAF). For more than 25 years, he has worked as developer, applications engineer and product manager for IBM, Ericsson, Enea. Jan received his Masters in Computer Science from the Royal Institute of Technology (KTH) in Stockholm, 1995. He has taught hundreds of training classes in various programming languages, operating systems, high availability, and network management and acted as long term Swedish government industry advisor for the Vinnova program on Advanced Software Technology (ASTEC). October 10, 2013 3
  • 4. Use Case: VPN with Service Chaining Customer   Customer A   B   Service  Provider   FW   APP  FILTER   IDS   Internet   WAN  ACCEL   Customer   C   POP  1   Customer   C   POP  2   To  sell  a  bit-­‐pipe  is  nice.     To  sell  a  bit-­‐pipe  plus  value   added  services  is  nicer.     If  you  can  scale.   October 10, 2013 4
  • 5. Use Case: VPN with Service Chaining Traffic Shaper A Content Filtering WAN acceleration Firewall A B IPS/IDS B How would you implement this? •  with short time to market •  in existing networks •  consisting of multiple-vendors •  across multiple technology domains •  providing end-to-end visibility from customer to network resources •  and back from resources to customer and SLA October 10, 2013 •  allowing gradual introduction of future technologies like OpenFlow •  permitting service changes with minimal network impact •  automatically cleaning up unused resources at service retirement •  in a highly-available configuration •  at low cost 5
  • 6. Use Case: VPN with Service Chaining Traffic Shaper A Content Filtering WAN acceleration Firewall A B IPS/IDS B ImplementaMon   steps  and  opMons:   Implement  service  chain   and  configure  flow  route:   -­‐  Policy  based  rouMng   -­‐  OpenFlow  applicaMon   Select  L4-­‐L7  devices  and   set  Set  flow  ow  each:     up   up  fl on   on  each   -­‐  Many  brands  available     L4-­‐L7  device   -­‐  Physical  or  virtual   That’s  enough  to  add  flows.  Maybe  also  think  about  the  life-­‐cycle?   Once  setup,  what  if   a  parMcular  service   chain  needs  to  be   reconfigured?  Or   decommissioned?   October 10, 2013 What  if  the     VPN  service   definiMon  is   upgraded  with   more  opMons?   What  if  one  of  the   service  chain   devices  is  replaced   with  a  different   brand  device?   So  how  can  SDN  and  OpenFlow  help  us?   6
  • 7. SDN Architecture SpecificaMon  Layer     Logically  centralized,   transacMonal,  global   specificaMon  model   SDN  Inventors  and  Gurus   Casado,  Shenker,  McKeown,  Koponen,  et  al.   describe  the  SDN  architecture  like  this:   Network  OperaMng   System  Layer     Logically  centralized,   transacMonal,  global   device  model   Forwarding  Layer     Distributed  mulM-­‐ protocol  flow   forwarding   October 10, 2013 www.slideshare.net/marMn_casado/sdn-­‐abstracMons   7
  • 8. SDN Specification Layer VPN  Service  AcMvaMon  Portal:  Add  Flow                              Flow  Profile  Name:  HQDC  Inbound                                          From  Networks:  Internet                                                  To  Networks:  116.54.16.128/26                        Reserved  bandwidth:  2.5  Gb/s                                                        QoS  profile:  RealMme                            SLA  Level:  Gold          ✓  WAN  Accelera@on                            Content  filtering                Office          ✓  SAP              Citrix              Backup                    Skype              Video                  File  Transfer                ✓  Firewall         Configure…   Cancel   AcMvate     October 10, 2013 8
  • 9. Service Application: Model-to-model mapper VPN  Service  Model   Flow  Profile  Name:  unique  string   Key  SDN  ProperMes   •  Logically   centralized  APIs   •  Model-­‐to-­‐model   mapping   •  Transac@ons   VPN  Service  AcMvaMon  Portal:  Add  Flow   From  Networks:  [  IP-­‐address/mask  ]   To  Networks:  [  IP-­‐address/mask  ]   Reserved  bandwidth:  integer  >  0   Service  ApplicaMon   Traffic  Steering  Device  Model   db   Nice  if  APIs,  UIs,   DB  schemas  are   rendered  from   service  model   Firewall  Device  Model   Port:  unique  integer  0..47   Src:  IP-­‐address/mask   Dst:  IP-­‐address/mask   AcMon:  drop  |  output(N)  |  …   October 10, 2013 Src:  IP-­‐address/mask   Dst:  IP-­‐address/mask   Port:  integer  1..65535   AcMon:  drop  |  allow   9
  • 10. Service Application executing Network-wide Transaction Service  ApplicaMon   Network-­‐wide  Transac@on   Rule  #46:  Port=1,  Src=*,  Dst=116.54.16.128/26,   AcMon=output(6)   Rule  #117:  Src=*,  Dst=116.54.16.128/26,   Port=80,  AcMon=allow   Rule  #47:  Port=7,  Src=*,  Dst=116.54.16.128/26,   AcMon=output(8)   Rule  #118:  Src=*,  Dst=116.54.16.128/26,   Port=*,  AcMon=drop       Network  OperaMng  System   Internet   October 10, 2013 1 2 3 4 5                6        7        8        9    10   Customer  A   In Customer  B                                    Out   10
  • 11. Network Operating System executing Network-wide Transaction Network-­‐wide  Transac@on   Rule  #117:  Src=*,  Dst=116.54.16.128/26,  Port=80,   Rule  #46:  Port=1,  Src=*,  Dst=116.54.16.128/26,   AcMon=allow   Rule  #117:  Src=*,  Dst=116.54.16.128/26,  Port=80,   AcMon=output(6)   Rule  #46:  Port=1,  Src=*,  Dst=116.54.16.128/26,   Rule  #118:  Src=*,  Dst=116.54.16.128/26,  Port=*,   AcMon=allow   Rule  #47:  Port=7,  Src=*,  Dst=116.54.16.128/26,   AcMon=output(6)   AcMon=drop   Rule  #118:  Src=*,  Dst=116.54.16.128/26,  Port=*,   AcMon=output(8)   Rule  #47:  Port=7,  Src=*,  Dst=116.54.16.128/26,   AcMon=drop   AcMon=output(8)           October 10, 2013 Cisco  CLI   NETCONF   Cisco  CLI   Network  OperaMng  System   OpenFlow   Key  SDN  properMes   •  Transac@ons   extend  to  devices   •  Model-­‐to-­‐   mul@ple  protocols   •  Device  type,   vendor  and   protocol   irrelevant  to   operators  and   network  apps   11
  • 12. SDN and OpenFlow October 10, 2013 OSPF   Learning   Switch   Controller   Controller   Controller   Behavior   Behavior   Behavior   OpenFlow   OpenFlow   •  Pure  OpenFlow   networks  are  and   will  remain  rare   •  New  OpenFlow   behaviors  very   convenient  for   solving  specific   network  problems   Service   Chaining   OpenFlow   Key  SDN  properMes   •  Controller   implements  a   specific  behavior   •  In  NOS,  each   behavior  appears   as  a  device  type   Network  OperaMng  System   12
  • 13. Tail-f NCS solution: SDN and OpenFlow controller October 10, 2013 13
  • 14. Asia Tier 1 SP: Managed Services for Enterprise customers NCS use case: Business drivers: •  •  •  Value-added services to enterprise customers More agile and dynamic service provisioning NCS •  •  SW   SW   SW   SW   SW   SW   HW   Dynamic control of L3-L7 devices using serviceoriented network API Service chaining using OpenFlow Virtualized appliances HW   HW   SW   Branches Core/Edge (Data Center) October 10, 2013 14
  • 15. SDN Use Case: Service Chaining Management Applications NETCONF, REST, Java Network Engineer Network-wide CLI, WebUI Tail-f Network Control System Service Models Service Manager Flowlet Models Flowlets Device Models Device Manager OpenFlow Controller Cluster Network Element Drivers Flowlets Flowlets Traffic Shaper A October 10, 2013 Content Filtering WAN acceleration Firewall A B IPS/IDS B 15
  • 16. SDN Technology Summary SDN is about Network Evolvability, splitting the Network Problem into manageable pieces The Specification Layer, a.k.a. Service Layer provides a business-level interface for operators and applications. The interface •  is logically centralized to hide the complexities of distributed systems •  feeds a model-to-model mapping taking high-level concepts to specific device objects •  is transactional to protect operators and applications from having to deal with the complexities of error recovery and activation orchestration The Network Operating System Layer provides a device-level interface for operators and applications. The interface •  is transactional to protect from error recovery and activation orchestration complexity •  feeds a model-to-multiple protocols mapping where device type, vendor and management protocol is irrelevant to operators and applications The Forwarding Layer can be controlled through OpenFlow or traditional protocols like Cisco CLI •  In reality there is a mix of traditional and OpenFlow devices •  Speaking multiple device protocols is key in real networks •  All device behaviors are described with device data models October 10, 2013 16
  • 17. Customer Quote: DT TeraStream SDN Goal The reason for us doing SDN is that we can program services instead of re-architecting the network and the OSS for every new service. We are not necessarily interested in programming the network, but programming the network services is key for us - this concept drastically reduces our time to market from years to weeks. - Axel Clauberg VP & CTO, Deutsche Telekom (the TeraStream project) October 10, 2013 17
  • 18. October 10, 2013 18
  • 19. Further information Service Provider Links (Deutsche Telekom, AT&T) •  www.pipelinepub.com/webinars •  www.layer123.com/download&doc=ATT-SDNVirtualization_Webinar_final SDN Links •  www.nec-labs.com/~lume/sdn-reading-list.html •  www.youtube.com/watch?v=YHeyuD89n1Y •  www.slideshare.net/martin_casado/sdn-abstractions NETCONF & YANG Links •  www.tail-f.com/education/what-is-netconf •  www.tail-f.com/education/what-is-yang Tail-f Links •  www.tail-f.com/education October 10, 2013 19