Packet Optical Architecture

This section describes the design, implementation, and operation of the packet optical use case and the calendaring application.

Overview

The Path Computation Engine (PCE) and ONOS will utilize the global network graph abstraction to find capacity and/or create capacity on demand. Together, they will respond to network triggers and events such as failures or network anomalies and new traffic demands, “finding” spare capacity to recover and adapt.

ONOS and the PCE will process event changes and check resource availability before new intents are compiled into match/action pairs for the packet and optical devices. The following figure represents the steps involved in translating service intents into a set of actionable flow mods that are pushed to the devices:

Service Provider Calendaring Application

The calendaring application must have access to usage, state information, reach, capacity availability, and alarms on specific ports, links, packet and optical network elements. In order to support these requirements, ONOS must be able to:

• Acquire information about the optical network's topology, capacity (Lambdas, or λ), and constraints, and
• Correlate packet and optical equipment events in real time to maintain accurate information about the physical network's state.

In addition, resource utilization and resource control requires awareness of the status of the optical transport equipment’s and their performance states. To allow this, ONOS must track active paths and resources in use, as well as the configuration status of match/action flow tables on both packet and optical elements.

The Service Provider Portal

User(s) will potentially use the bandwidth calendaring Service Provider Portal to make service intents or path requests. The bandwidth calendaring provides means for scheduling service request by specifying  parameters such as:

• Start time & Date, End time& Date ,
• Start point (DC#), End point(DC#) ,
• potential Constraints  including  possible Protection Type, QoS, Capacity,delay.  ( Note: We have not implemented all the constraints for this release)

 The Service Provider Portal translates path requests into a set of REST API calls, which are passed to ONOS intent frame works for execution. In addition, the Portal maintains the status of the path requests as Pending, Active, or Inactive. Today, ONOS with its default internal PCE will coordinate and compile the service request into actionable flowmods for both packet and optical layer. ONOS's Global Network Graph is used to maintain the network topology, along with active paths and their states. In the future the graph can be extended to support other related abstractions for demands from the user or service provider, such as policy, security, and related constraints.

Note that the current ONOS Global Network Graph is constructed using initial topology files which have been configured by the service provider. The configuration file includes both initial packet and optical topology. This file can be modified using packet-optical topology script file that we have provided as use case example. Currently, we have not implemented the Reach consideration between the optical end points. In the future, it will be possible to manipulate the reach, topology, and links failure via the "Mininet".  

The figure below represents the actual physical path for communication between the data centers. The actual traffic between Data center (DC) A and Z travel across the packet (green) and optical (blue) layers.

As shown Start/End point routers are basically connected only through optical layer where optical layer provides λ (optical routers Per ROADM path) connection for routers.

Typically, the path between routers should meet the constraints initiated by the path service request.

Return To : Packet Optical
Home : ONOS Use Cases