"SDN Controller Analysis II" Onos network status statement

Overview

The key information maintained by the control plane is the network state. The control plane must aggregate this information and make it available to the application. In addition, in order to maintain scalability and component reuse, applications should be exempt from protocol details, even though network state information is obtained through a specific protocol.

The Onos topology of the protocol is implemented by two complementary mechanisms: Network Discovery and configuration. The former uses the network protocol to let Onos identify the location and/or performance of the network elements, and take the initiative to carry out the relevant collection work when the function is enabled. The latter allows applications and operators to configure the intended topology or to provide hints for network components that cannot be found in the network by typical methods.

The next section first explains how Onos describes the topology and state of the network. Then we discuss how Onos establishes the topology.

the network to express

Onos maintains the protocol-independent and protocol-specific network elements and status representations that can be converted between each other. The former is the core layer to build, is called Model Object, the latter is appropriate provider to construct. For example, Devicestore (analogy to DeviceManager and Devicelisteners) sees a network device, and openflowdeviceprovider the device as a openflowswitch. Recall that the previous section described the passing of devicedescription between provider and the core. Model object is Onos exposed to applications.

In addition, where possible, rich data types are used to replace Java basic types to prevent ambiguity and improve code readability. For example, an IP address is described by a description of the IPAddress class, not an int, and the MAC address is described by the MACAddress class instead of the byte [] or long type. These rich data types provide conversion methods to convert objects to Java basic types where needed.
The remainder of this section focuses on model objects.
Onos defines different subsystems:

Receptacle topology
Many of the objects in the model have graphic properties, and Onos represent the network with a graph.

device--network infrastructure elements, such as switches, routers, access points, or intermediate boxes. The device has multiple interface/port and DeviceID. Device is the internal vertex of a network diagram. The network port on the port--device. A port and a DeviceID pair form a connectpoint, which represents an endpoint of the edge of a graph. host--Network Terminal station, which has an IP address, MAC address, VLAN ID, and Connectpoint. The host is the external (leaf) vertex of the network diagram. Link-a forward link connecting two devices (connectpoints). A link is an inner edge of a network diagram. edgelink--a special link that connects the host to the device specifically. Edgelinks is the outside of the network diagram. Path--a list of one or more adjacent links, including edgelinks. Edgelinks, if in the path, can only be an external link (at the beginning and end of the list). Topology--Represents a snapshot of a network traversal diagram. Path calculations can use any graph traversal algorithm for this graph, such as BFS, Dijkstra, or Bellman-ford.

Port:
The port is located on the 1th layer of the OSI model, the physical layer. This layer defines the electrical and physical specifications of the equipment, such as copper or fiber media and voltage, line impedance, signal time, and physical placement of pin connectors such as twisted-pair, coaxial or fiber-optic cable single-mode or multimode.
Interface:
The interface is located on the 2nd layer of the OSI model, the data link layer. This layer defines the methods of transmitting network device data between the functions and programs, such as serial port, Ethernet, FDDI and Token ring. In addition, this layer may provide the ability to detect and correct errors that may occur in the physical layer.

Receptacle Control
At the application level, the instructions for the network are expressed as high-level flow rules in the form of the Criteria (Match) and treatment (Action) pairs. A Onos instance has a role for any given device that allows or denies the application of instructions for changing the device.
flowrule--A high-level flow rule, giving a matching and action pair. If necessary, an action can be a combination action. This abstraction is different from the concept of flow rule in OpenFlow, for example, the number of tables and the pairs of match-action.
Intent-Intent is a high-level network configuration or connection action that affects a subset of network traffic. It allows applications to specify what they want to happen instead of specifying the way they want things to happen.
rolevalue--represents the role of a Onos instance relative to the device.
The structure of manipulating network logic and its construction is further discussed in the Intent Framework section. The role is explained further in the Cluster coordination section.

Receptacle Packets
Network packets, such as traffic from the network and those injected into the network, resemble OpenFlow Packetin and Packetout.
outboundpacket--synthetic packets are protocol-independent, representing information that is emitted from the controller to the network. This information includes information about where the package should be issued.
inboundpacket--Packet Protocol independent representation of packets sent from the device to the controller. This allows the controller to passively provide messages via packetins to provider and applications on demand, such as host tracking, link detection.

Model Object Dependencies
Some entities rely on the presence of other entities, such as port, which cannot exist without devices. Similarly, links and topologies cannot exist if there is no port as the endpoint of the connection. So we think device is the first entity in the Onos network.

Receptacle Found

Given certain types of devices, links, and hosts, the topology of the network can be discovered by Onos without administrator intervention. A device is configured to automatically connect to the specified controller using the OpenFlow protocol. When a connection to the latter is established, Onos will "see" the device and add it to its network view. Depending on the protocol used to establish the connection, further cases, such as device capability and port number, can also be transmitted to the Controller through a series of information on the handshake.

To discover links and hosts, Onos relies on collecting information on devices and configuring network devices. This section focuses on the discovery of these elements, as onos details and interactions about the discovery of the device are analyzed in Devicesubsystem.

Link Discovery
The link is detected by jumping the probe frames on all ports that are sent by the managed devices. The device ID of the sending device is added to the probe to identify the end of the link. The other end is sent back to the controller after the adjacent device receives the probe. For example, given devices A and B are controlled by the same controller and connected through a direct link, the following steps are used to locate a link from A to B:

The

controller constructs a probe that contains the device ID. The controller sends the next probe packetout instruction as payload. A receives instructions and sends probes to all ports. b receives a probe and sends it back to the controller. The controller receives the probes it sends from A and B, looking for the other endpoint of the link.

The reconnaissance in the opposite direction is also done according to the same events as above, from B to a. The link finds One direction at a time because the link cannot be assumed to be bidirectional.

Link subsystem interface and device subsystem through a lldplinkprovider subscribed Deviceservice deviceevents (that is, by implementing Devicelistener), To obtain device information about the OpenFlow feature. After that, Lldplinkprovider assigns a Linkdiscovery object to each device that is found.

Linkdiscovery implementation is actually through the LLDP or BDDP to do the link discovery mechanism. The detection rate is a millisecond (default 3000ms), and the Linkdiscovery instance sends Lldps and BDDPS probe messages in packetout form. The probe message is intercepted by the adjacent switch and sent to its corresponding Linkdiscovery instance in the form of packetins, and the sender and receiver of the corresponding probe message are converted to the source and destination endpoint of link.

SDN Cayman and Legacy NX

Sdn Island is a part of the network controlled by Sdn. Islands and islands may consist of one or more traditional networks.

After the LLDP probe is emitted, it is discarded between the SDN network and the traditional network. This could prevent a connection between two islands from being discovered, allowing the controller to believe that it manages two disjoint networks. Onos, like Floodlight, uses the BDDP probe to find the path between the islands. Because traditional devices do not discard BDDP, they do not modify it in any way, but rather pass the message through. As a result, connections between legacy networks will appear as a single hop, regardless of how many legacy devices are on the path.

Control domains
In the case of Multi-domain, multiple independent control plane control network adjacent domain, the domain is different from the Sdn island, the latter is controlled by the same logical control plane, in the former case, a Onos controller may receive not the probe information that it creates, the controller will identify the related link as edgelink.

Probe message Fingerprinting
Onos adds fingerprint identification to each logical control plane to identify its own cluster. The ability to add fingerprint information to probe messages since Onos version 1.4 has been added to Lldplinkprovider to assist in identifying external devices and ID aliases. Specifically, the fingerprint is encoded into the source MAC address of the probe message. The Probedlinkprovider interface allows provider implementations to access the MAC address that has been fingerprinted. The fingerprint comes from a stable cluster name that automatically generates a hash, and the cluster name is automatically generated at this time. Only a fixed MAC address (de:ad:be:ef:ba:11) can be used when the cluster name is not determined (if possible if the Clustermetadata subsystem is not available).

The

Host Discovery
Device subsystem discovers that a network host detects packetins ARP and DHCP messages, and the network device ports that describe their location are called connectpoints. Hostlocationprovider uses the same mechanism as LLDP to implement this function by implementing Devicelistener.