manuals/user-guide/ch_service_provider_edition.xml

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <!DOCTYPE section [
   3  <!-- Some useful entities borrowed from HTML -->
   4 <!ENTITY ndash  "&#x2013;">
   5 <!ENTITY mdash  "&#x2014;">
   6 <!ENTITY hellip "&#x2026;">
   7 ]>
   8 <section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
   9     xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="ovsdb_project">
  10     <title>Hydrogen Virtualization User Guide</title>
  11     <para><emphasis role="bold"><emphasis role="underline">Overview and
  12             Architecture</emphasis></emphasis></para>
  13     <para>The Service Provider edition of OpenDaylight is designed for network operator use. It does
  14         not include OVSDB, VTN or DOVE, but does include SNMP, BGP-LS, PCEP, and LISP southbound and
  15         the Affinity Service and the LISP Service northbound. The following diagram shows
  16         OpenDaylight Service Provider edition architecture in details:</para>
  17     <para><inlinemediaobject>
  18             <imageobject>
  19                 <imagedata fileref="../../../../800px-Serv-arch.png"/>
  20             </imageobject>
  21         </inlinemediaobject></para>
  22     <para><emphasis role="bold"><emphasis role="underline">Installation
  23         Guide</emphasis></emphasis></para>
  24     <para>The installation instructions for Service Provider Edition can be found here.</para>
  25     <para>The installation instructions for the Virtualization edition can be found here</para>
  26     <para><emphasis role="bold"><emphasis role="underline"
  27         >Configuration</emphasis></emphasis></para>
  28     <para>To configure OpenDaylight Service Provider edition using the OpenFlow 1.3 plugin, start
  29         Opendaylight Controller with the -of13 option. If you do not use the option, the controller
  30         will use the OpenFlow 1.0 version.</para>
  31     <para>
  32         <itemizedlist>
  33             <listitem>
  34                 <para>To start mininet for the OpenFlow 1.3 simulation, use the following command:
  35                         <emphasis role="italic">mininet&gt; sudo mn --controller=remote,ip=a.b.c.d
  36                         --topo tree,2 --switch ovsk,protocols=OpenFlow13</emphasis></para>
  37             </listitem>
  38             <listitem>
  39                 <para>To start mininet for the OpenFlow 1.0 simulation, use the following command:
  40                         <emphasis role="italic">mininet&gt; sudo mn
  41                         --controller=remote,ip=10.125.136.52 --topo tree,2</emphasis></para>
  42             </listitem>
  43         </itemizedlist>
  44     </para>
  45     <para><emphasis role="bold"><emphasis role="underline">Web / Graphical
  46             Interface</emphasis></emphasis></para>
  47     <para>The graphical user interface is the same as the one for Base edition.</para>
  48     <para><emphasis role="underline"><emphasis role="bold">Release Notes
  49             (link)</emphasis></emphasis></para>
  50     <para>The release notes for the Service Provider Edition can be found here.</para>
  51     <para><emphasis role="bold"><emphasis role="underline">SNMP4SDN</emphasis></emphasis></para>
  52     <para><emphasis role="bold">Overview and Architecture</emphasis></para>
  53     <para>Current SDN technology is usually assumed to be based on network infrastructures using
  54         OpenFlow switches. Actually, SDN is not limited to OpenFlow, for example OpenDaylight SAL
  55         can support multiple southbound protocols. To fulfill the scope of underlying switches
  56         supported in OpenDaylight, Ethernet switches should also be considered.</para>
  57     <para>Commodity Ethernet switches have the advantage of low price and is programmable to some
  58         extent (i.e. using CLI and SNMP to modify the ACL, MAC table, forwarding table, etc). In an
  59         SDN built on commodity Ethernet switches, the upper layer applications could be responsible
  60         for making all the forwarding decisions for each switch, and the switches execute data plane
  61         forwarding as assigned. Therefore, we believe that commodity Ethernet switch has its
  62         advantage and warrants a position in SDN technology development.</para>
  63     <para>Off-the-shelf commodity Ethernet switches are commonly allowed to be configured by SNMP,
  64         and the Ethernet switch can actively report its status to the administrative computer (i.e.
  65         OpenDaylight controller) using SNMP trap. Therefore, we propose an SNMP southbound plugin to
  66         control underlying devices supporting SNMP using off-the-shelf commodity Ethernet switch. In
  67         addition to SNMP support, this plugin will provide capabilities to manage configurations
  68         that can only be accessed via CLI, e.g. ACL, disabling flooding, etc., since such
  69         configurations are necessary for using Ethernet switches for SDN. Therefore, there will be
  70         three phases in this project, as follows. (1) Creating an SNMP SouthBound Plugin: to
  71         configure Ethernet switches via SNMP. (2) The plugin configures Ethernet switches via CLI,
  72         for settings that SNMP cannot access. (3) SAL extension: for (1) and (2) we will contribute
  73         extensions to the SAL configuration APIs to provide additional API to support SNMP and CLI
  74         usage as specified above.</para>
  75     <para>The below diagram shows the described components: </para>
  76     <para><inlinemediaobject>
  77             <imageobject>
  78                 <imagedata fileref="../../../../717px-SNMP4SDN_Architecture.jpg"/>
  79             </imageobject>
  80         </inlinemediaobject></para>
  81     <para>An overview of the project can be found here.</para>
  82     <para><emphasis role="bold">Installation Guide</emphasis></para>
  83     <para>Guide to installation and testing can be found here.</para>
  84     <para><emphasis role="bold">Tutorial / How-To</emphasis></para>
  85     <para>
  86         <itemizedlist>
  87             <listitem>
  88                 <para>User Guide</para>
  89             </listitem>
  90             <listitem>
  91                 <para>Developer Guide</para>
  92             </listitem>
  93         </itemizedlist>
  94     </para>
  95     <para><emphasis role="bold">Programmatic Interfaces</emphasis></para>
  96     <para>Proposed SAL API for the SNMP SouthBound Plugin can be found here.</para>
  97     <para><emphasis role="bold">Help</emphasis></para>
  98     <para>Sign up for snmp4sdn-dev mailing list.</para>
  99     <para><emphasis role="bold"><emphasis role="underline">BGP-LS PCEP</emphasis></emphasis></para>
 100     <para>You can find basic howto and guide here.</para>
 101                <para>Lisp Flow Mapping</para>
 102     <para><emphasis role="bold">Overview and Architecture</emphasis></para>
 103     <para>Locator ID Separation Protocol (LISP) is a technology that provides a flexible
 104         map-and-encap framework that can be used for overlay network applications, such as data
 105         center network virtualization, and Network Function Virtualization (NFV). LISP introduces
 106         two name spaces: Endpoint Identifiers (EIDs), and Routing Locators (RLOCs). In a
 107         virtualization environment, EIDs can be viewed as virtual address space and RLOCs can be
 108         viewed as physical network address space.</para>
 109     <para>The LISP framework decouples network control plane from the forwarding plane by providing:
 110         (1) a data plane that specifies how the virtualized network addresses are encapsulated in
 111         addresses from the underlying physical network, and (2) a control plane that stores the
 112         mapping of the virtual-to-physical address spaces and the associated forwarding policies,
 113         and serves this information to the data plane on demand. Network programmability is achieved
 114         by programming forwarding policies such as transparent mobility, service chaining, and
 115         traffic engineering in the mapping system, where the data plane elements can fetch these
 116         policies on demand as new flows arrive. In this presentation we explain how the LISP Flow
 117         Mapping project in ODL can be used to enable advanced SDN and NFV use cases.</para>
 118     <para>The Lisp Flow Mapping service provides LISP Mapping System services. This includes LISP
 119         Map-Server and LISP Map-Resolver services, to store and serve the mapping data to data plane
 120         nodes as well as to OpenDaylight applications. Mapping data can include mapping of virtual
 121         addresses to physical network address where the virtual nodes are reachable/hosted at.
 122         Mapping data can also include a variety of routing policies including traffic engineering
 123         and load balancing. To leverage this service, a northbound API allows OpenDaylight
 124         applications and services to define the mappings and policies in the LISP Mapping Service.
 125         This project also includes a southbound LISP plugin that enables LISP dataplane devices to
 126         interact with the OpenDaylight via the LISP protocol.</para>
 127     <para>The below diagram shows the described components:</para>
 128     <para><inlinemediaobject>
 129             <imageobject>
 130                 <imagedata fileref="../../../../LISP-ODL-02.jpg"/>
 131             </imageobject>
 132         </inlinemediaobject></para>
 133     <para>An overview of the project can be found here.</para>
 134     <para>Please see the LISP Flow Mapping User Guide for more details on how to install and use
 135         this project.</para>
 136     <para><emphasis role="bold">Tutorial / How-To</emphasis></para>
 137     <para>Please see the Tutorial section of the LISP Flow Mapping User Guide for more details on
 138         how to use this project.</para>
 139     <para><emphasis role="bold">Programmatic Interfaces</emphasis></para>
 140     <para>Lisp Flow Mapping API can be found here.</para>
 141     <para><emphasis role="bold">Help</emphasis></para>
 142     <para>Sign up for lispflowmapping-dev mailing list.</para>
 143 </section>