Scribd Logo
Upload

Welcome to Scribd!

  • 29 views

    Readme

    Uploaded by

    sameer43786
    SDN controllers provide the network operating system (NOS) functionality for software-defined networks. They implement an abstraction of the network for applications, provide control over underlying hardware using protocols like OpenFlow, and manage network resources. OpenDaylight is an open source SDN controller that uses a modular architecture and supports multiple southbound protocols through plugins. It provides a REST API to access its network database for configuration, monitoring, and control.

    Copyright:

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

    Readme

    Uploaded by

    sameer43786
    29 views22 pages
    SDN controllers provide the network operating system (NOS) functionality for software-defined networks. They implement an abstraction of the network for applications, provide control over underlying hardware using protocols like OpenFlow, and manage network resources. OpenDaylight is an open source SDN controller that uses a modular architecture and supports multiple southbound protocols through plugins. It provides a REST API to access its network database for configuration, monitoring, and control.

    Original Description:

    donattte

    Copyright

    © © All Rights Reserved

    Available Formats

    PPTX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    SDN controllers provide the network operating system (NOS) functionality for software-defined networks. They implement an abstraction of the network for applications, provide control over underlying hardware using protocols like OpenFlow, and manage network resources. OpenDaylight is an open source SDN controller that uses a modular architecture and supports multiple southbound protocols through plugins. It provides a REST API to access its network database for configuration, monitoring, and control.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    29 views22 pages

    Readme

    Uploaded by

    sameer43786
    SDN controllers provide the network operating system (NOS) functionality for software-defined networks. They implement an abstraction of the network for applications, provide control over underlying hardware using protocols like OpenFlow, and manage network resources. OpenDaylight is an open source SDN controller that uses a modular architecture and supports multiple southbound protocols through plugins. It provides a REST API to access its network database for configuration, monitoring, and control.

    Copyright:

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

    SDN controllers

    AppAppAppAppAppAppAppAppAppAppApp • Network elements has


    two components:
    Northbound Interface
    OpenFlow client,
    forwarding hardware
    SDN with flow tables.
    controller
    • The SDN controller must
    OpenFlow
    implement the network
    OS functionality
    – Provide abstraction to
    the upper layer
    – Provide control to the
    underlying hardware
    – Managing the resources
    SDN controllers (NOS) .vs. OS
    OS Network OS
    • Resources managed • Resources managed
    – CPU, memory, disk, IO devices, – Connected
    etc switches/routers/NICs
    • Applications: • Applications
    – User programs that use the – Firewall, migration, network
    resources
    virtualization, NAT, TE, etc
    • OS functionality (abstraction):
    • NOS functionality?
    – CPU virtualization
    – Network abstraction – this is
    – Memory virtualization
    a new thing that is not well
    – IO virtualization understood.
    – File systems
    NOS functionality
    • From: “NOX: towards an Operating System to
    Networks”

    – NOS should present application programs with a


    centralized programming model
    – Programs should be written in terms of high level
    abstractions, not low-level parameters
    Existing SDN controllers
    • NOX/POX • Some artificial
    • Ryu differences: language
    • Floodlight • More important
    • Pyretic differences:
    • Frenetic • API
    • Open Daylight • Functionality
    • And many more
    SDN controller: NOX/POX
    • Originally developed by Nirica
    • NOX: C++ version; POX: python version
    – Nox for performance; Pox for rapid prototyping.
    • POX comes with Mininet – the simulation
    infrastructure
    • OpenFlow v.1.0
    • Programming model:
    – Controller registers for events (PacketIn, ConnectionUP,
    etc).
    – Programmer write event handler
    • NOS does little for the applications
    NOX/POX component

    NOX/POX controller

    Connection Event OpenFlow DSO


    Manager dispatcher Manager Deployer

    Input/output Socket OpenFlow Threading and event Other


    Asynchronous File API management utilities
    NOX/POX Events
    • FlowRemoved • User write event handlers
    • ConnectionUP • E.g. ConnectionUp:
    record in the database,
    • PacketIn PacketIn: compute the
    route, setup flow table
    • etc along the path, etc

    Abstraction? Global view build from control program, fairly low level.
    Open Daylight controller
    • Industrial strength SDN controller
    • Heavy industry involvement and backing
    • Focuses on having an open framework for
    SDN/NFV innovations
    – Not limited to OpenFlow
    What is OpenDaylight?
    • OpenDaylight is an open source project under the
    Linux Foundation with the mutual goal of
    furthering the adoption and innovation of
    Software Defined Networking (SDN) through the
    creation of a common industry supported
    framework.
    • Enjoyed broad industry support
    • Information from:
    https://wiki.opendaylight.org/view/OpenDaylight
    _Controller:[Overview|Architectural_Framework
    |...]
    OpenDaylight Architectural Framework
    Some Notes on the Architectural
    Framework
    • Extensible south-bound interface beyond
    OpenFlow through SAL (service abstraction
    layer)
    – Benefit?
    • North-bound interface: REST API.
    • Controller platform seems to provide more
    than other controllers.
    Open Daylight Controller
    • Written in Java and runs on anything that supports Java.
    • Southbound support multiple protocols as plugins.
    • Modules linked dynamically into a Service Abstraction layer (SAL)
    • Main function in the controller: topology manager – topology, device
    capabilities, and reachability, etc with many supporting modules
    Service Abstraction Layer
    • Supports multiple protocols on the southbound and
    provides consistent services for other modules and Apps.
    • SAL exposes basic services from the plugins
    • SAL maps service request to the appropriate plugins.
    • Plugins are independent and loosely coupled with SAL.
    Plugins provide portions of the overall
    network model tree
    Access information in the network
    model tree
    The REST API
    • A REST API is not a protocol, language, or standard.

    • The concept of a REST API or an API that is RESTful means


    that API adhere to the contrains of REST (defined by Roy
    Fielding)
    – Client-Server: maximize the portability of server-side functions
    to other platforms.
    – Stateless: states are kept in the client side.
    – Caching
    – Layered System: client only interacts with its neighbor (not two
    layers apart)
    – Uniform interface
    – Code-on-demand
    OpenDaylight REST API
    • https://wiki.opendaylight.org/view/OpenDayli
    ght_SDN_Controller_Platform_(OSCP):Rest_R
    eference
    • The REST API provides access to the network
    database that includes configuration data for
    the controller (e.g. static flow table entries),
    data for dynamically discovered network
    entities (e.g. switches, hosts), and statistics
    and logging data.
    OpenDaylight REST API
    • Querying items
    – HTTP GET method
    – URL form: "http://<domain-or-ip-
    address>/rest/v1/model/<data-type>/<optional-
    id>?<optional-query-params>“
    – Example:
    http://<host-name-or-
    ip>/rest/v1/model/switch/00:00:00:00:00:00:00:01
    Return Text {"tables": 1, "socket-address": "/192.168.2.104:50663",
    "connected-since": "2012-07-16 03:46:28.572000", "capabilities":
    71, "active": true, "controller": "02a32314-7a75-44fe-9412-
    6bcb36b25367", "actions": 2367, "ip-address": "192.168.2.104",
    "dpid": "00:00:00:00:00:32:90:11", "tunneling-capable": false,
    "buffers": 256}
    OpenDaylight REST API
    • Creating and updating items
    – HTTP PUT method
    – URL form: "http://<domain-or-ip-
    address>/rest/v1/model/<data-type>“
    – The PUT data is in the JSON format, each item is a
    JSON object.
    • Such HTTP JSON REST API can then be
    mapped to different languages such as java,
    python, etc.
    Classes or OpenDaylight REST API
    • Topology REST APIs
    • Host Tracker REST APIs
    • Flow Programmer REST APIs
    • Static Routing REST APIs
    • Statistics REST APIs
    • Subnets REST APIs
    • Switch Manager REST APIs
    • User Manager REST APIs
    • Container Manager REST APIs
    • Connection Manager REST APIs
    • Bridge Domain REST APIs
    • Neutron ML2 / Network Configuration APIs
    Example of REST API binding to
    • Check out
    – http://hp-sdn-client.readthedocs.io/en/latest/api/of.html
    Conclusion
    • SDN controller’s basic function is to create the
    global view of the network, mainly by
    maintaining the global topology/routing
    information.
    – Getting the information
    – Maintaining the information
    – Allow access and update of the information
    • Network operation logics should be built in
    SDN applications.

    You might also like