Scribd Logo
Upload

Welcome to Scribd!

  • 33 views

    Software Defined Networking

    Uploaded by

    Jorge Armando Soto García
    This document discusses the history and evolution of software defined networking (SDN). It explains that early work like FORCES proposed separating the control plane from the data plane using new protocols but required custom hardware. The Routing Control Platform used existing routing protocols like BGP for control, making deployment easier but limiting innovation. Ethane proposed custom switches for a centralized controller but required adoption of new hardware. OpenFlow was developed to leverage standard Ethernet switches by exposing the flow table through a simple open protocol, allowing innovation while reusing existing hardware.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    Software Defined Networking

    Uploaded by

    Jorge Armando Soto García
    33 views9 pages
    This document discusses the history and evolution of software defined networking (SDN). It explains that early work like FORCES proposed separating the control plane from the data plane using new protocols but required custom hardware. The Routing Control Platform used existing routing protocols like BGP for control, making deployment easier but limiting innovation. Ethane proposed custom switches for a centralized controller but required adoption of new hardware. OpenFlow was developed to leverage standard Ethernet switches by exposing the flow table through a simple open protocol, allowing innovation while reusing existing hardware.

    Original Description:

    M1.4

    Original Title

    M1.4

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document discusses the history and evolution of software defined networking (SDN). It explains that early work like FORCES proposed separating the control plane from the data plane using new protocols but required custom hardware. The Routing Control Platform used existing routing protocols like BGP for control, making deployment easier but limiting innovation. Ethane proposed custom switches for a centralized controller but required adoption of new hardware. OpenFlow was developed to leverage standard Ethernet switches by exposing the flow table through a simple open protocol, allowing innovation while reusing existing hardware.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    33 views9 pages

    Software Defined Networking

    Uploaded by

    Jorge Armando Soto García
    This document discusses the history and evolution of software defined networking (SDN). It explains that early work like FORCES proposed separating the control plane from the data plane using new protocols but required custom hardware. The Routing Control Platform used existing routing protocols like BGP for control, making deployment easier but limiting innovation. Ethane proposed custom switches for a centralized controller but required adoption of new hardware. OpenFlow was developed to leverage standard Ethernet switches by exposing the flow table through a simple open protocol, allowing innovation while reusing existing hardware.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 9

    Software Defined

    Networking
    Dr. Nick Feamster
    Professor

    In this course, you will learn about software defined networking and
    how it is changing the way communications networks are
    managed, maintained, and secured.
    Software Defined Networking

    Module 1: History of SDN


    ž  ThisLesson: Control of Packet-Switched
    Networks
    ž  Why separate control?
    ž  How to control a packet-switched network?
    —  Separate control channel: FORCES (2003)
    —  In-band protocols: Routing Control Platform (2004)
    —  Open hardware: Ethane (2007),
    OpenFlow (2008)
    2
    Software Defined Networking

    Why Separate Control?


    ž  More rapid innovation: Control logic is not
    tied to hardware

    ž  Network-wide view: Easier to infer (and


    reason about) network behavior

    ž  Moreflexibility: Can introduce


    new services more easily
    Software Defined Networking

    Custom Control: IETF FORCES (2003)


    ž  First RFC in 2003, three implementations
    ž  Protocols for multiple control elements (CE)
    and forwarding elements (FE)
    -------------------------------------------------
    | | | | | | |
    |OSPF |RIP |BGP |RSVP |LDP |. . . |
    |

    |
    | | |

    ForCES Interface
    | |
    -------------------------------------------------
    |

    |
    Problem:  Requires  standardizaQon,  
    adopQon,  deployment  of  new  
    -------------------------------------------------
    ^ ^
    ForCES | |data

    hardware  (same  problem  observed  


    control | |packets
    messages| |(e.g., routing packets)
    v v
    -------------------------------------------------
    |

    |
    ForCES Interface
    -------------------------------------------------
    | | | | |
    |

    |
    by  previous  work!)  
    |LPM Fwd|Meter |Shaper |NAT |Classi-|. . . |
    | | | | |fier | |
    -------------------------------------------------
    | FE resources |
    -------------------------------------------------

    J.  Salim,  H.  Khosravi,   A.  Kleen,  of


    Examples A.  CE
    Kuznetsov,   Linux  Netlink  as  an  IP  Services  Protocol,  RFC  3549,  July  2003  
    and FE functions.
     
    H.  Khosravi,   Ed.,  T.  Anderson,  Ed.,  Requirements  for  Separa:on  of  IP  Control  and  Forwarding,  RFC  3654,  November  2003  
    L.  Yang,  R.  Dantu,  T.  Anderson,  R.  Gopal,  Forwarding  and  Control  Element  Separa:on  (ForCES)  Framework,  RFC  3746,  April  2004  
    Ran  Giladi,  Niv  Yemini,  A  programmable,  generic  forwarding  element  (GFE)  approach  for  dynamic  network  func:onality,  PRESTO  2009   4
    Software Defined Networking

    Routing Control Platform (2004)


    ž  Computes routes on behalf of routers
    ž  Uses existing routing protocol (BGP) to
    communicate routes to routers
    Inter-­‐AS  Protocol  
    RCP   RCP   RCP  
    iBGP  

    AS  1   AS  2   AS  3  
    Physical  
    peering  

    Feamster,  Nick,  et  al.  "The  case  for  separaQng  rouQng  from  routers."Proceedings  of  the  ACM  SIGCOMM  
    workshop  on  Future  direc:ons  in  network  architecture.  ACM,  2004.  
    Software Defined Networking

    Using In-Band Protocols for Control


    Before:  convenQonal  iBGP  
    eBGP  

    iBGP   Problem:  Control  is  


    constrained  by  what  exisQng  
    A@er:  RCP  gets  “best” iBGP  routes     protocols  can  support.  
    (and  IGP  topology)  
    eBGP  

    RCP  
    iBGP  
    Software Defined Networking

    Customized Hardware: Ethane (2007)


    ž  Network architecture for the
    enterprise
    —  Direct enforcement of a single,
    fine-grained network policy
    ž  Domain controller computes
    flow table entries based on
    access control policies
    Problem:  Requires  custom  
    ž  Custom switches: switches  that  support  Ethane.  
    OpenWrt, NetFPGA, Linux

    Casado,  MarQn,  et  al.  "Ethane:  Taking  control  of  the  enterprise."  ACM  SIGCOMM  Computer  
    Communica:on  Review.  Vol.  37.  No.  4.  ACM,  2007.   7
    Software Defined Networking
    Open Hardware: OpenFlow (2008)
    ž  Layer two forwarding table (flow
    OpenFlow  
    table entries)
    Controller  
    ž  Switch exposes flow table though
    SSL   OpenFlow   simple OpenFlow protocol
    Protocol   —  Keep it simple
    —  Vendor can keep platform closed,
      Flow  table   but expose an open interface to
      control forwarding table
    OpenFlow-­‐enabled  
    Layer-­‐2  Switch   Matches  subsets  of  packet  header  fields  
    Switch   MAC   MAC   Eth   VLAN   IP   IP   IP   TCP   TCP  
    Port   src   dst   type   ID   Src   Dst   Prot   sport   dport  

    McKeown,  N.,  Anderson,  T.,  Balakrishnan,  H.,  Parulkar,  G.,  Peterson,  L.,  
    Rexford,  J.,  Shenker,  S.,  and  Turner,  J.,  OpenFlow:  enabling  innova:on  in  
    campus  networks,  SIGGCOMM  Comput.  Commun.  Rev.  38,  2  (Mar.  2008)  
    Software Defined Networking

    What have we learned about control?


    ž  Control and data plane should be decoupled
    —  Vertically integrated switches make introducing new
    control planes difficult (FORCES)
    ž  Using existing protocols makes deployment
    easier, but constrains what can be done (RCP)
    ž  Open hardware allows decoupling
    of control, can spur adoption (OpenFlow)

    You might also like