Docker Networking

• Install Docker
1. exec ifconfig

• 
  

• Run Docker
1. Docker can expose container services through port mapping
2. docker run -it --rm busybox

Network Virtualization

What is Network Virtualization?

Network virtualization is a specific abstraction of a physical network that allows the support of multiple logical networks running on a common shared physical infrastructure.

How to implement Network Virtualization?

In order to virtualize network, we first build virtual nodes or machines on physical infrastructure.

One particular approach for doing that is the Xen Virtual Machine Monitor. Another is User-Mode Linux, with something called network namespaces. Network namespaces were originally an add

on to the Linux kernel and they're now part of the main line Linux kernel.

KVM is another virtualization technology. And there's certainly others as well. VMWare of course makes their own commercial virtual machine technology. And Virtual Box is one that free choice.

The examples of Network Virtualization

SDN Control Plane

Introduction to SDN Control Plane

The network consists of routers, switches and controllers. 

The controller speaks to the switch over a secure control channel and the SDN protocol effectively instructs the switch to update its flow table entries to take different actions on various traffic flows that pass through the switch.The purpose of the control channel is effectively to update this flow table and all of the logic concerning how the flow table entries are updated are contained at the controller.

SDN Controllers

When a packet arrives at the switch, it parses the header fields, and based on the values of those header fields, it will attempt to match that packet against flow table entries in any one of several flow tables. If there is no match in any of those tables, the traffic is sent to the controller.

NOX was a first-generation OpenFlow controller. It is open source, stable, and fairly widely used. There are two flavors of NOX. One, Nox-Classic, was the original NOX, and was implemented in C++ and Python. It's no longer supported. The new NOX is C++ only.

POX is essentially NOX in Python. It currently supports only version 1.0. An advantage of POX is that it's widely used, maintained and supported and it's relatively easy to read and write code. The main disadvantage of POX is performance.

Ryu is an open source Python controller. It supports all versions of OpenFlow from 1.0 to 1.4 as well as various mysteria extensions. A disadvantage of Ryu with respect to some of the other commercial grade controllers is performance.

Floodlight is an open-source Java controller that supports OpenFlow 1.0. It's a fork from the Beacon Java OpenFlow controller. And is maintained by Big Switch. Some of the advantages include good documentation and integration with the REST API. It's also production level, and supports and

provides support for OpenStack and Multi-Tenant Clouds.

OpenDaylight (ODL) is to provide a common industry supported platform with a robust, extensible open source codebase and common abstractions for northbound capabilities. OpenDaylight is written by Java and has many advantages including widespread industry acceptance and integration with OpenStack and other types of cloud applications. However, it's extremely complex. 

Frenetic

Pyretic = Python + Frenetic

Customize Network Control

NFV Service Chaining

SDN Control and Data Separation

SDN Control and Data Separation

What is the control/data plane separation?

The control plan is logic that controls the forwarding behavior in the network.

Examples of the control plane are routing protocols, network box configuration such as firewall configuration or load balancer configuration, and so forth. One can think of it in some ways as the brain of the network.

The data plane on the other hand forwards traffic according to the control plane logic.

Examples of data planes are IP forwarding layered to switching and so forth.

Why we need the control/data plane separation?

One reason of the control/data plane separation is that control plane and data plane can evolve and be developed independently. In particular the software control of the network can evolve independently of the hardware. That means one can buy a router, switches, middle boxes, and so forth deploy them in the network and not be bound by capabilities of software that ship with the hardware at that particular time.

The second reason to separate the control and data planes is that it allows the network to be controlled from a single high level software program. The higher order programs could easily control or debug  the behavior of the entire network instead of reconfigure/check each network component one by one.

The opportunities and challenges of control/data plane separation

The first opportunity of separating the data and control plane can help in data centers and in routing. The second advantage of the control and  data plane separation can help make certain applications in enterprise networks easier to manage.

There are also challenges to make the control and data plane separation being a reality.

The first is scalability, once we separate the control elements from the forwarding elements. The other challenge is reliability or security what happens if a controller fails or is compromised?

Reference:

1. Intelligent Route Service Control Point (IRSCP) 
2. Rate Control Protocol (RCP)

Software-Defined Networking (SDN) Layers and Architecture Terminology

Introduction

     Software-Defined Networking (SDN) is a term of the programmable networks framework. The key differences between SDN and the common network are abstraction and virtualization. SDN separates the network function into management plant, control plane and data plane. The goal of SDN is to leverage this separation, and the associated programmability, in order to reduce complexity and enable faster innovation at all planes.

Terminology

• Forwarding Plane (FP) - The collection of resources across all network devices responsible for forwarding traffic.
• Control Plane (CP) - The collection of functions responsible for controlling one or more network devices. CP instructs network devices with respect to how to process and forward packets. The control plane interacts primarily with the forwarding plane and, to a lesser extent, with the operational plane.
• Management Plane (MP) - The collection of functions responsible for monitoring, configuring, and maintaining one or more network devices or parts of network devices. The management plane is mostly related to the operational plane (it is related less to the forwarding plane).

SDN Model View

• ForCES

The IETF Forwarding and Control Element Separation (ForCES) framework [RFC3746] consists of one model and two protocols. ForCES separates the forwarding plane from the control plane via an open interface, namely the ForCES protocol [RFC5810], which operates on entities of the forwarding plane that have been modeled using the ForCES model [RFC5812].

The ForCES model [RFC5812] is based on the fact that a network element is composed of numerous logically separate entities that cooperate to provide a given functionality (such as routing or IP switching) and yet appear as a normal integrated network element to external entities.

ForCES models the forwarding plane using Logical Functional Blocks (LFBs), which, when connected in a graph, compose the Forwarding Element (FE). LFBs are described in XML, based on an XML schema.

• NETCONF/YANG

The Network Configuration Protocol (NETCONF) [RFC6241] is an IETF network management protocol [RFC6632]. NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices.

NETCONF protocol operations are realized as remote procedure calls (RPCs). The NETCONF protocol uses XML-based data encoding for the configuration data as well as the protocol messages. Recent studies, such as [ESNet] and [PENet], have shown that NETCONF performs better than SNMP [RFC3411].

Additionally, the YANG data modeling language [RFC6020] has been developed for specifying NETCONF data models and protocol operations. YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications.

YANG models the hierarchical organization of data as a tree, in which each node has either a value or a set of child nodes. Additionally, YANG structures data models into modules and submodules, allowing reusability and augmentation. YANG models can describe constraints to be enforced on the data. Additionally, YANG has a set of base datatypes and allows custom-defined datatypes as well.

• OpenFlow

OpenFlow is a framework originally developed at Stanford University and currently under active standards development [OpenFlow] through the Open Networking Foundation (ONF). Initially, the goal was to provide a way for researchers to run experimental protocols in a production network [OF08]. OpenFlow has undergone many revisions, and additional revisions are likely. The following description reflects version 1.4 [OpenFlow]. In short, OpenFlow defines a protocol through which a logically centralized controller can control an OpenFlow switch. Each OpenFlow-compliant switch maintains one or more flow tables, which are used to perform packet lookups. Distinct actions are to be taken regarding packet lookup and forwarding. A group table and an OpenFlow channel to external controllers are also part of the switch specification. With respect to Figure 1, the OpenFlow switch specifications [OpenFlow] define a DAL for the forwarding plane as well as for CPSI.

The OF-CONFIG protocol [OF-CONFIG], based on the YANG model [RFC6020], provides a DAL for the forwarding and operational planes of an OpenFlow switch and specifies NETCONF [RFC6241] as the MPSI. OF-CONFIG overlaps with the OpenFlow DAL, but with NETCONF [RFC6241] as the transport protocol, it shares the limitations described in the previous section.