O2V-Mapping Framework

• O2V-Mapping is an SDN-oriented framework that dynamically maps multi-tenant virtual optical networks onto shared optical and ethernet resources.
• It leverages real-time, multi-layer monitoring and cross-layer adaptation through extended OpenFlow protocols and optimization algorithms to ensure capacity, OSNR, and QoS constraints.
• Experimental validations demonstrated up to 80% hardware cost savings and sub-1.1 second reconfiguration times, ensuring uninterrupted service continuity.

O2V-Mapping (Optical-to-Virtual Mapping) is a software-defined networking (SDN)-oriented framework that enables the dynamic, holistic mapping of virtual optical networks (VONs) onto a shared optical and ethernet substrate. Designed to coordinate resources across both the optical (e.g., flex-grid spectrum, optical paths, modulation formats) and ethernet (e.g., switch ports, traffic grooming) layers in real time, O2V-Mapping incorporates multi-technology monitoring, cross-layer adaptation, and SDN-driven configurability. Its key objective is to maximize the accommodation of VONs while maintaining constraints on capacity, optical signal-to-noise ratio (OSNR), and end-to-end quality of service (QoS)/quality of transmission (QoT) (Ou et al., 2017).

1. Conceptual Foundations

O2V-Mapping formalizes the mapping of multi-tenant virtual optical network requests—each defined by source/destination MAC addresses, data-rate, and QoS/QoT demands—onto physical resources at both the ethernet (packet/ethernet switch ports) and optical (fibres, spectrum, modulation) layers. It leverages a three-layer architecture:

• Application Plane: Implements a monitoring and (re-)configuration application (“Management Block”) and maintains a traffic engineering database (DB).
• Control Plane: Utilizes an OpenDaylight (ODL) SDN controller, expanded by northbound REST interfaces and southbound OpenFlow (OF) and extended-OF modules.
• Data Plane: Consists of OpenFlow-enabled ethernet switches, network interface cards (NICs) with deep packet inspection (DPI), wavelength-selective switches (WSS), fibre switches, and variable bandwidth virtual optical transceivers (V-BVTs).

This structure allows O2V-Mapping to coordinate resource allocation and rapidly adapt to time-varying demands and impairments, such as fluctuations in ethernet traffic or optical channel degradation (Ou et al., 2017).

2. Monitoring, Data Collection, and SDN Integration

A distinguishing feature of O2V-Mapping is its multi-technology monitoring infrastructure:

• Optical Monitoring: Uses “Wave Analyser” modules to measure real-time per-channel OSNR and spectrum occupancy. Data are uploaded to the central DB via REST APIs.
• Ethernet Monitoring: NICs with DPI capture per-flow data-rate, MAC addresses, and packet sizes. OpenFlow-enabled switches periodically report per-port traffic statistics to the DB.

The Management App in the Application Plane polls these data sources at a typical interval of 1 s, enabling fine-grained, up-to-date cross-layer visibility. The control plane enacts decisions via standard and extended OpenFlow messages. For optical elements, new match/action fields—central frequency (OF_OCH_SIGID), slot width (OF_OCH_SIGBW), and spectral identifiers—are encoded in the protocol, and supported by the Service Abstraction Layer and a Forwarding Rules Manager within the SDN controller (Ou et al., 2017).

3. Mathematical Model and Optimization Formulation

O2V-Mapping models the virtual-to-physical allocation problem as a constrained optimization (mixed integer linear program):

• Sets and Parameters:
  • $V$: VON requests (indexed by $v$)
  • $E$: substrate optical links
  • $S$: ethernet switch ports
  • $M$: modulation/baud-rate options
  • $C_e$: available spectrum on link $e$
  • $Cap_s$: capacity of switch port $s$
  • $d_v$: requested data rate of $v$
  • $\ell_v$: maximum permissible latency
  • $OSNR_{req}(m, d_v)$: minimum required OSNR for modulation $m$ at $d_v$
  • $OSNR_e$: monitored OSNR for $e$
  • $P_v$: candidate physical paths for $v$
• Decision Variables:
  • $x_{v,p,m} \in \{0,1\}$: allocation of $v$ on path $p \in P_v$ with modulation $m$
  • $g_{v,s} \in \{0,1\}$: allocation of $v$ to ethernet port $s$
• Objective:

$$\max \sum_{v \in V} \sum_{p \in P_v} \sum_{m \in M} U_v \cdot x_{v,p,m}$$

Usually, $U_v = 1$ for admission control.

• Constraints:

1. Spectrum: $\sum_{v,p,m} slots(m,d_v) x_{v,p,m} \leq C_e$ for each $e$
2. OSNR: $x_{v,p,m} = 0$ if $\min_{e \in p} OSNR_e < OSNR_{req}(m,d_v)$
3. Latency: $x_{v,p,m}=0$ if $path\_latency(p) > \ell_v$
4. Ethernet Port: $\sum_{v} d_v \cdot g_{v,s} \leq Cap_s$ for each $s$
5. Consistency: Each $v$ mapped once (or blocked): $\sum_{p,m} x_{v,p,m} = \sum_s g_{v,s} \leq 1$

A heuristic search (greedy or rule-based) is used for tractable real-time operation (Ou et al., 2017).

4. Adaptive (Re-)Configuration Algorithms

O2V-Mapping continuously adapts the mapping in response to monitored changes:

• For new VON requests, it computes feasible path/modulation/port combinations, verifying spectrum, OSNR, and port constraints.
• Ethernet traffic adaptation: When flows decrease in rate, traffic is aggregated onto fewer switch ports, reducing hardware utilization and cost.
• OSNR adaptation: Upon OSNR degradation, the algorithm selects alternate optical paths or more robust modulation formats, reconfiguring the data plane to maintain QoT.

All reconfigurations are executed by the Management App, which issues REST calls to the ODL controller. The controller programs both ethernet and optical devices via (extended) OpenFlow. The typical end-to-end reconfiguration time is less than 1.1 s, including monitoring and device updates—sufficient for most carrier-grade use cases (Ou et al., 2017).

5. Protocol and Workflow Details

Relevant protocol details include:

• Ethernet Switches: Standard OF 1.3; match on in_port, eth_dst, VLAN, etc.; actions include set_queue, output:port, etc.
• Optical Devices: Extended OF with new TLV fields for central frequency and bandwidth. Actions include setting OF_OCH_SIGID, OF_OCH_SIGBW, and outputting to the appropriate WSS port. Optical path and slot allocation are tightly integrated into the SDN flow tables and coordinated with ethernet flows.

Workflow summary:

1. Event detection (new VON request, OSNR change, traffic shift)
2. Monitoring data update
3. Management App computes mapping/re-mapping
4. REST API to ODL
5. ODL issues OF/extended-OF commands to all relevant data-plane devices.

6. Experimental Validation and Observed Benefits

O2V-Mapping was experimentally validated in a mesh network with:

• 4×16 WSS topology, fibre lengths 50–150 km
• 25-sub-carrier pool, 20 GHz grid, multiple modulation formats (10–40 GBd BPSK, 16-QAM, 10 GBd QPSK)
• Real-time OSNR monitoring, Pica-8/SDN ethernet switches, SolarFlare NICs

Key results:

Metric	Baseline (Static)	With O2V-Mapping
Switch ports used (agg.)	2–5	1
Modulators/transceivers	2–5	1
Port cost saving	–	50–80%
OSNR-triggered outage	Yes (static)	None (adaptive)
Reconfig. latency	–	<1.1 s

Key observations:

• Efficient flow aggregation led to a 50–80% reduction in switch ports/modulators used.
• Zero service interruption under OSNR degradation; BERs remained below FEC thresholds after adaptive switching.
• Fast end-to-end reconfiguration, typically under 1.1 s.
• Overall, O2V-Mapping allows dynamic, programmable, and vendor-agnostic management of joint optical/ethernet virtual network provisioning, improving resource utilization and service continuity (Ou et al., 2017).

7. Summary of the O2V-Mapping Framework’s Significance

O2V-Mapping demonstrates the operational and architectural benefits of tightly integrated, SDN-controlled, cross-layer virtual network mapping with real-time multi-technology monitoring. By fusing ethernet- and optical-layer data in a unified database, and orchestrating resources with extensible SDN protocols, it delivers substantial improvements in cost-efficiency, service availability, and reconfigurability relative to static virtualisation. The approach’s reliance on programmable V-BVT hardware and fully software-driven control positions it as a scalable solution for next-generation, multi-tenant optical transport infrastructure (Ou et al., 2017).