JOURNAL OF LIGHTWAVE TECHNOLOGY, VOL. 37, NO.
24, DECEMBER 15, 2019
Building a Truly Dynamic Filterless Metro Network
by Reusing a Commercial PON’s Data-Plane and a
Novel SDN-Enabled Control-Plane
Evangelos Kosmatos , Dimitris Uzunidis , Chris Matrakidis, Alexandros Stavdas , Sebastian Horlitz,
Thomas Pfeiffer , and Andrew Lord
Abstract—The migration of DataCenters into Metropolitan Area
Networks creates new challenges which include the need for rapid
service provisioning and recovery and new, cost-effective, connec-
tivity schemes. Here we propose and demonstrate a truly dynamic
transportation platform tailored for a metro network. The nov-
elty of the proposed architecture is that the dynamic data-plane
exploits available commercial PON technology while the dynamic
control-plane is SDN-enabled using OpenFlow/Netconf. The dy-
namic operation of the platform in several interesting scenarios is
demonstrated on an experimental test-bed.
Index Terms—Control-plane, filterless network architecture,
metropolitan area networks, netconf, openflow, optical
communications, SDN.
I. INTRODUCTION
HE migration of DataCenters (DCs) into the metro
T marks the first step of a longer–lasting decentralisation
process that brings cloud resources and operations (such as
storage, processing, content and application execution) pro-
gressively closer to the end-user to ensure superior Quality-
of-Service/Experience (QoS/QoE) performance. As the cloud
becomes more dynamic, two distinctive traffic profiles are
emerging in the metro: (i) legacy ‘user-to-content’ (or “South-
North”) traffic, (ii) a new ‘content-to-content’ (or “East-West”)
profile [1]. The bursty character of the latter is attributed to
cloud operations like Data-Base (DB) synchronization, Virtual
Machine (VM) migration and mirroring services etc with strict
Manuscript received May 12, 2019; revised August 20, 2019; accepted
September 24, 2019. Date of publication October 4, 2019; date of current version
December 10, 2019. This work was supported in part by the 5G-PPP METRO-
HAUL project under EU Grant 761727. (Corresponding author: Evangelos
Kosmatos.)
E. Kosmatos, D. Uzunidis, and C. Matrakidis are with the OpenLightComm,
London, U.K. (e-mail: vkosmatos@gmail.com; duzunidis@hotmail.com;
cmatraki@gmail.com).
A. Stavdas is with the Department of Telecommunications Science and
Technology, University of Peloponn, Tripolis, Arcadia Greece (e-mail:
astavdas@uop.gr).
S. Horlitz is with the Nokia FN RBC, Nokia FN RBC, Stuttgart Germany
(e-mail: sebastian.horlitz@nokia.com).
T. Pfeiffer is with the Nokia Stuttgart ZBL/OA, Stuttgart Germany (e-mail:
thomas.pfeiffer@nokia-bell-labs.com).
A. Lord is with the Research and Innovation, BT, Ipswich, Suffolk U.K.
(e-mail: andrew.lord@bt.com).
Color versions of one or more of the figures in this article are available online
at http://ieeexplore.ieee.org.
Digital Object Identifier 10.1109/JLT.2019.2945410
0733-8724 © 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: UNIVERSIDAD CARLOS III MADRID. Downloaded on February 19,2020 at 08:22:23 UTC from IEEE Xplore. Restrictions apply.
6033
latency and connection set-up requirements. For these services,
data is exchanged back and forth between two network equip-
ment terminals within a specific time window, otherwise perfor-
mance degradation or even service disruption may occur. Actu-
ally, the corresponding interconnections should be dynamically
initiated in a timeframe of the order of seconds [1]–[3] to match
the reconfiguration speed of DCs. Moreover, in a metro network,
connections with transportation granularities ranging between
sub-1G and 10 G will still be present in the near future [2].
These mean that cloud-integrated metro networks should en-
sure rapid service initiation (of the order of seconds or less) while
simultaneously accommodating traffic with a bursty profile. His-
torically, two alternative methods have been considered to meet
these requirements: either via over-provisioning of connectivity
resources or via a dynamic scheme.
In the former case, dedicated, semi-permanent, OTN/
FlexEthernet point-to-point connectivity resources are used,
regardless of their utilisation level. As these connections never
meant to be dynamic, any change in network status or recon-
figuration is implemented only via the Network Management
System (NMS). Conventional bandwidth provisioning exploits
a GMPLS-based NMS that incorporates advanced control-plane
(e.g., routing control, resource discovery, connection manage-
ment) and network management functions (like control-channel
management, link-property correlation, link-connectivity veri-
fication, fault management). In a typical case, the NMS collects
connections statistics that are fed into off-line traffic engineering
tools to plan the demand for the coming weeks and months.
To make this framework more adaptable to changes, intense
research efforts have been invested to make the control-plane
dynamic, resulting in routing control algorithms that may return
solutions at a sub-second speed. However, when physical layer
awareness is introduced to these routing control algorithms,
longer times are needed which, for the scale of national networks
could be of the order of minutes.
As a result of all these, service set-ups no faster than a few
minutes have been reported [4], [5]. Last but not least, the data-
plane of these circuit-switched connections is also equally slow
as it may take seconds or even minutes to reconfigure the data-
plane underneath (by considering e.g., effects like laser tuning,
training sequences for digital chromatic compensation, optical
switching matrix reconfiguration) [6]. Moreover, although OTN,
in principle, allows for sub-wavelength multiplexing that can be
6034 JOURNAL OF LIGHTWAVE TECHNOLOGY, VOL. 37, NO. 24, DECEMBER 15, 2019

used to reduce the number of wavelength channels needed to

transport bursty traffic and to restrict the over-provisioning, there
are complications when these tasks are assigned dynamically:
a) small size flows with a granularity less than an ODU0, are
inefficiently transported; b) the grooming, that provides the 1:1
mapping between the circuits from the tributary link and the
available circuits of the trunk links, is done via the NMS which
is slow, as explained above, compared to the duration of the
bursts; c) constantly adding or removing granularities at the
ODU level from OTN links will unavoidably result in channel
capacity fragmentation and management complexity.
To overcome these limitations, dynamic networks exploiting
Optical Packet/Burst Switching (OPS/OBS) were proposed in
the past. These solutions were never progressed to commer-
cialisation due to the widespread belief that the corresponding
data-plane technology is still immature and/or due to lack of
standardized norms which is key especially for core and metro
networks. For example, the potential of slotted optical switching
to provide statistical multiplexing gains in the optical layer are
elaborated in [7]–[9] albeit non-standardised optical slot sizes
were considered.
In this work, we demonstrate that dynamic networking is
feasible today, utilizing a mature and standardised, data-plane
technology. In particular, we are exploring the DuFiNet (Dual Fi- Fig. 1 A high-level representation of a DuFiNet Metro network architecture
bre Network) filterless network architecture of [10] to construct a for a (a) ring-like topology; (b) horse-shoe topology.
dynamic, point-to-multipoint (P2MP) Metro transportation plat-
form that is capable to support both the rapid service set-up and
an efficient accommodation of bursty traffic. Here, we report, for systems as well as dynamic systems exploiting burst-mode (BM)
the first time, to the best of our knowledge, a proof of concept dy- technology which is of interest to this work. Thanks to the
namic metro platform that consists of: a) a data-plane that is built filterless transit “through”) path in all metro nodes, the architec-
by reusing elements of a commercial Passive Optical Network ture is transparent to modulation format and channel bandwidth
(PON); b) a novel, dynamic, SDN-enabled control plane that while there is no degradation due to filtering effects, as is the
is used to configure and manage the data-plane. The fact that case in [16]. In [10] the main interest was on circuit-switched
a commercial PON data-plane with mature and standardised connections that support slowly varying service provisioning.
technology is employed proves, beyond any doubt, that such Here, we are considering only dynamic, P2MP connections
solutions can be explored by Operators in their networks. based on BM technology.
This paper is organised as follows: in Section II, we present an In DuFiNet, the metro network comprises the Access Metro
overview of the DuFiNet architecture upon which the dynamic Edge Nodes (AMENs), the Metro-Core Edge Node (MCEN)
metro network is built. In Section III, we elaborate the details of and two separate fibre bus links. One fibre is used exclusively
a small metro network test-bed exploiting a PON’s data-plane for adding traffic/channels (US) and a second one for dropping
while in Section IV we present the details of a novel SDN- traffic/channels (DS). Apparently, in DuFiNet, there is no direct
enabled control plane that is necessary to dynamically operate connectivity between AMENs; instead, AMEN interconnection
the platform. Finally, in Section V we present the measured is made as follows: the channel(s) transporting the “add” traffic
performance of the integrated platform. An earlier version of are inserted onto the US-fibre by means of a 3 dB coupler in the
this work was presented in the 2018 European Conference on ADD section of an AMEN.
Optical Communication [11]. The channels from all AMENs are transported and hubbed to
the MCEN and are then broadcast via the DS-fibre to all AMENs.
A copy of the entire wavelength comb is tapped-off by a 3 dB
II. THE ARCHITECTURAL DETAILS OF A METRO NETWORK coupler in the DROP part of every AMEN.
Several filterless platforms have been proposed [10], [12]– Therefore, the proposed architecture allows for a complete de-
[15]. In particular, the DuFiNet metro architecture [10] is coupling between the ADD and DROP transportation paths. This
depicted in Fig. 1 for ring-like (Fig. 1a) and for horse-shoe is of somewhat lesser importance when P2MP connections are
(Fig. 1b) network topology layouts. The DuFiNet architecture exclusively considered as standardised PON systems are using
may support all transportation modes and granularities envi- different optical bands for the US and DS traffic. However, it is
sioned in a metro network [10] such as: point-to-point (P2P), envisaged that in DuFiNet both P2MP and P2P connections will
dedicated, channels employing coherent (100 G and above), simultaneously co-exist. Since the P2P connections utilise only
direct-detection (10/40 G, NRZ), multi-level (e.g., PAM-4) the C-band to transport both US and DS traffic, the decoupling

Authorized licensed use limited to: UNIVERSIDAD CARLOS III MADRID. Downloaded on February 19,2020 at 08:22:23 UTC from IEEE Xplore. Restrictions apply.
KOSMATOS et al.: BUILDING A TRULY DYNAMIC FILTERLESS METRO NETWORK
Fig. 2. The DuFiNet Metro network with TDMA-shared channels.
between the ADD and DROP transportation paths is mandatory
to ensure a collision-free operation.
As a final remark, it is pointed out that the ‘hubbing’ of US
and DS paths at the MCEN is implemented either in the opaque
mode (channels terminate at the MCEN) or in the transparent
mode (channels bypassing the MCEN). In the latter case, both
receiver and transmitter modules need to operate in BM while
in the former case only the transmitted signal uses BM tech-
nology. Here we are only considering the case of the opaque
interconnection mode.
III. A NOVEL DYNAMIC METRO DATA-PLANE
The main objective of this work is to demonstrate that truly
dynamic metro networks can be built today„ exploiting ma-
ture, standardised technology. To this end, we are reusing the
data-plane of a commercially available PON to emulate the
DuFiNet Metro illustrated in Fig. 1 and 2. In particular, we
have developed a test-bed built upon a commercial GPON
(Alcatel-Lucent/Nokia, ISAM 7330) as depicted in Fig. 3.
As sub-1G/1G rates will still be employed in the short and
midterm future in the Metro [2], the layout of Fig. 3 is used to
prove the principle of operation of the Metro architecture shown
in Fig. 2. In our test-bed, thanks to the mode of operation of
standardised PON systems in the downstream, no BM receivers
are employed in the DS path.
The configuration shown in Fig. 3a consists of an MCEN
node, three sub-equipped AMENs and two disjoint PON lines.
In particular, one PON line and the ADD blocks of AMEN #2
and #3 form the US path while a second PON line together with
the DROP block of AMEN #3 form the DS path. The DROP
blocks of AMEN #2 and #3 and the ADD block of AMEN #1
have not been implemented in our test-bed.
The ADD/DROP sections of the AMEN have been imple-
mented by means of three Optical Network Units (ONUs) that
are arranged as follows: The ONU #2 and ONU #3 emulate the
ADD sections of AMEN #2 and AMEN #3, respectively, while
ONU #1 emulates the DROP section of AMEN #1. Moreover,
we assume that AMEN #2 and AMEN #3 host DCs so the
southbound ports of ONUs #2 and #3 receive the incoming client
traffic of AMEN #2 and #3 from their corresponding DCs while
the southbound port of the ONU #1 delivers the outgoing traffic
Authorized licensed use limited to: UNIVERSIDAD CARLOS III MADRID. Downloaded on February 19,2020 at 08:22:23 UTC from IEEE Xplore. Restrictions apply.
6035
Fig. 3. DuFiNet’s US/DS paths adapted on a TDM-PONs layout (a); the
emulated Metro network and the connectivity paths (b).
of AMEN #1. As shown in Figs. 2 and 3, the physical north-
bound ports of the ONUs are interfaced to PON lines via 3 dB
couplers.
For the particular Nokia fixed-line access product we use,
the ISAM (Intelligent Services Access Manager) consists of an
Optical Line Termination (OLT) unit together with a built-in
Ethernet switch, employing a non-blocking switch backplane
architecture, and other support elements. In the test-bed, the
ISAM in Fig. 3 emulates the MCEN of Fig. 2 and in this
respect the MCEN is a fully functional networking node. In our
configuration, two Line-Termination (LTs) cards are employed
and each LT port is made to support two wavelengths (in different
bands) per each US and DS path. However, as shown in Fig. 3b
and in compliance with the DuFiNet architecture, only one
wavelength is carrying traffic in each path: in the US path, only
the upstream wavelength (1310 nm) is carrying traffic while
in the DS path, only the downstream wavelength (1490 nm) is
carrying traffic (solid line in Fig. 3b). It is important to point
out that although the downstream wavelength in the US path
and the upstream wavelength in the DS path (broken line in
Fig. 3b) are not transporting any real traffic, they are active “on”
state) to transport Dynamic Bandwidth Allocation (DBA) con-
trol and management data because this is necessary for a faultless
operation of the PON circuitry. The bandwidth allocation and
scheduling functionalities are realized using the standard DBA
mechanisms of the PONs, appropriately configured to fulfill
the traffic requirements of the metro network (as presented in
Section V).
6036
Fig. 4. (a) Schematic representation of PON abstraction; (b) The logical de-
composition of a Metro network into a cascade of L2 switches/PON abstractions.
In the test-bed we have implemented, the AMENs #1 to #3
were placed at distances 10 km, 20 km and 30 km, respectively,
from the MCEN. Under this setup, the traffic from AMEN #1
and #2 in the US path is terminated at the LT-1 where it is steered
in the DS fibre by means of the ISAM switch and the LT-2. In
the DS fibre, the flow is terminated at AMEN #3. Apparently,
AMEN #1 and #2 may dynamically share the capacity of the
US path, in a (packet) lossless mode. Please note that only
one wavelength channel is used to transport traffic in the US
path. In comparison, if the same connectivity is implemented
using circuit-switched P2P connections, two (under utilised)
wavelength channels would be needed: one channel between
AMEN-2 and the MCEN and a second channel between AMEN-
1 and the MCEN. So, our current test-bed provides savings in
the number of channels used.
As the proposed Metro network test-bed is built based on a
GPON data-plane, the scalability of this platform is limited to
7–8 AMEN, at best, due to the differential loss restrictions
between the most remote nodes. Although not demonstrated
here, the deployment of an amplification scheme like the one
in [17] will overcome this limitation.
To demonstrate that in this test-bed the provisioning and
instantiation of services is performed dynamically in compliance
to the framework set by [1]–[3], a ‘light-weight’ SDN-enabled
control-plane has been developed based on standardized Net-
Conf and OpenFlow (OF) protocols as elaborated in the next
section.
IV. THE SDN-ENABLED CONTROL PLANE
The SDN architecture exploits the abstraction scheme de-
scribed in [18] where the active elements in the US/DS paths
i.e., the LTs and ONUs, are represented as legacy OF/Netconf
L2 switches as depicted in Fig. 4. Under this abstraction, the
north/southbound physical ports of a PON that are used for its
interconnect to a network infrastructure i.e., the upstream port
Authorized licensed use limited to: UNIVERSIDAD CARLOS III MADRID. Downloaded on February 19,2020 at 08:22:23 UTC from IEEE Xplore. Restrictions apply.
JOURNAL OF LIGHTWAVE TECHNOLOGY, VOL. 37, NO. 24, DECEMBER 15, 2019
of the OLT (p1) and the downstream ports of the ONUs (p2-p5),
are portrayed as the logical ports of a switch (Fig. 4a).
The proposed abstraction scheme offers two advantages: a) it
hides the PON specific details related to forwarding and con-
trol/management operations; b) vendor-specific configuration
commands are automatically translated and executed by the
PON components. Therefore, the forwarding command mes-
sages are exchanged by means of the standard OF protocol, while
(re)configuration is realized by means of the NetConf protocol.
In detail, the Metro abstraction was realised using the legacy-
switch YANG model to which the BroadBand Forum’s GPON
QoS queue models [19] were incorporated. This allows us to
capitalize on the extensively developed SDN-framework while
offering two advantages: a) standard OF/NetConf protocols are
used without extensions; b) the vendor-specific configuration
details are automatically translated and executed, based on the
OF forwarding flows and NetConf model.
The proposed abstraction allows a logical decomposition of
the metro network layout of Fig. 3 into a cascade of L2 switches
as proposed in [18] and in this way to develop a comprehensive
method for designing the control-plane of the platform.
The building blocks of the SDN control-plane are depicted
in Fig. 5 and they consist of: the ConfD [20] configuration
management system, the Metro Configuration Agent (MCA),
the Metro Network Flow Agent (MNFA) and the Open Network
Operating System (ONOS) [21].
ConfD is responsible for retaining the configuration status of
the metro network. The ConfD framework is a model driven
framework; therefore it automatically renders all the manage-
ment interfaces from a data-model (the Metro YANG abstracted
model in our case). When the configuration/status parameters of
this model change, the changes are automatically updated to the
corresponding management interfaces. As ConfD also supports
transactions, it provides transaction-safe configuration changes
on the Netconf interface toward the ONOS platform.
This means that the configuration state of the metro network
rolls back to the previous stable state in case of unsuccessful
configuration attempts due to connection failures or unexpected
problems. These operations offer operational simplifications to
an operator since they ensure a fully consistent configuration
state for the metro network.
As mentioned, the entire metro test-bed is configured as a
switch using NetConf. The entire configuration status of the
test-bed is stored at the Core engine DataBase (CDB) of ConfD.
When configuration requests arrive from the application layer
via the North Bound Interface (NBI), the ConfD Core Engine
Agent retrieves the data stored in CDB and updates the con-
figuration. Moreover, through the Application Programming
Interface (API) of the CDB, it informs the other entities, in real
time, of the changes made in the configuration status.
Further, the MCA, that communicates with the ConfD via the
API of the CDB, it is responsible for realizing the requested
configuration changes in the US/DS elements using the Com-
mand Line Interface (CLI): when the configuration is modified,
the CDB engine informs the MCA of the changes and the MCA
generates the appropriate CLI commands and executes them
directly on the corresponding Metro network elements.
KOSMATOS et al.: BUILDING A TRULY DYNAMIC FILTERLESS METRO NETWORK
Fig. 5. A schematic representation of the SDN architecture.
TABLE I
MCA CONFIGURATION CAPABILITIES
The MCA we have implemented in the test-bed provides a set
of configuration capabilities that enable the dynamic operation
of the Metro network (see Table-I). These functionalities are
exposed to ConfD and ONOS through the appropriate YANG
representation while their realisation is implemented via a set of
callback modules that trigger specific actions at the CLI.
Moreover, the MCA exposes through the available REST
interface, the port configuration details to the MNFA, which
in turn is responsible for presenting to the OF Controller an
abstracted view of the network (as L2 switch). Similarly, the
Authorized licensed use limited to: UNIVERSIDAD CARLOS III MADRID. Downloaded on February 19,2020 at 08:22:23 UTC from IEEE Xplore. Restrictions apply.
6037
MNFA implements the flow management of the infrastructure.
The MNFA uses the OF protocol to receive flow requests from
the OF controller of ONOS and forwards them to the MCA.
The MCA is responsible to translate these requests to the ap-
propriate element mapping (e.g., VLAN to queue) and execute
the appropriate commands. When a new AMEN is activated, the
MNFA is also responsible for informing the OF-controller of the
activation of a new abstraction switch (AMEN) and to setup the
initial configuration of OF flows.
Finally, in our test-bed the ONOS controller platform is the
central management system/orchestrator of the entire network:
It stores the topology and the running configuration of the
entire network, while it uses abstraction in order to provide
management capabilities in a unified way. It also includes the
intent framework that allows operators to specify their network
control strategy in form of policy rather than mechanism. The
ONOS core accepts the intent specifications and translates them,
via intent compilation, into installable intents, which are es-
sentially actionable operations on the network environment. In
addition, it includes resource management functionalities, while
on the northbound it exposes its capabilities through the REST
interface towards the Management and Control applications built
on top.
In our test-bed the ONOS southbound communicates with the
MNFA through the OpenFlow protocol for the transmission of
OF flows and the retrieval of OF related network information,
while it also communicates with the ConfD framework through
the Netconf protocol for the realization of the specified config-
uration actions on the metro network.
The events and interactions between the different aforemen-
tioned components are illustrated in the sequence diagram of
Fig. 6.
6038 JOURNAL OF LIGHTWAVE TECHNOLOGY, VOL. 37, NO. 24, DECEMBER 15, 2019

Fig. 6 Sequence diagram of the interactions between the components.

TABLE II
THE DBA CONFIGURATION

V. RESULTS
To validate the test-bed and to demonstrate the requested
dynamic operation, we register the response time of the platform
under different configurations and operational conditions. The
measurements of the response times were realized by making use
of the iperf traffic generator. Actually, three different configura-
tions were studied with reference to the configuration shown in
Fig. 3b:
In the first configuration set-up, flow A is launched from
AMEN #2 towards AMEN #1 which, at a steady-state, consumes
the maximum capacity of the link as shown in Fig. 7a. Then, flow
B from AMEN #3 towards AMEN #1 is also activated over the
TDMA-shared US channel. As observed in Fig. 7a, at this stage
the capacity of the link is equally shared between AMEN #2
and AMEN #3 in the US path. Evidently, the response time of
the data-plane is faster than the measurement resolution which is
100 ms demonstrating the truly dynamic sharing of the available
capacity. When flow B, that of AMEN #3, is switched off, flow
A regains the full capacity of the link with a similar response
time. Fig. 7. (a) Performance in flow activation scenario; (b) Control/data layer
performance for TCP traffic; c) Control/data layer performance for TCP traffic.
In the second set-up, the service recovery time of the platform
is measured. Now, the two queues of the AMEN #2 and AMEN
#3 are preconfigured with a capacity limit of 700 Mb/s (Flow A)
and 300 Mb/s (Flow B) respectively, as shown in Table II. Then, the test-bed, carrying 10 Mb/s and 20 Mb/s. This traffic load
the flows are reconfigured to mirror the initial operational con- is low enough to ensure that no packets are lost. The queue
ditions i.e., a maximum capacity of 300 Mb/s and 700 Mb/s for reconfiguration procedure is repeated as above and in this case
Flows A and B respectively. Since the scope of this experiment the response time of the control plane was measured between
is to utilise the full capacity of the link, we have used TCP traffic 3 and 5 seconds (Fig. 7c). Comparatively, the response time
for creating the flows, as with UDP traffic the link utilization is of the platform when reconfigurations are performed via the
considerably lower due to excessive packet loss. The results are corresponding NMS is of the order of 50–80 seconds.
illustrated in Fig. 7b, showing a service recovery of 4–9 seconds, Therefore, the results demonstrate that this metro network
a timeframe that includes the overhead for TCP reconnection. test-bed, that exploits a standrardised data-plane with <100
Finally, in order to measure the response time of the control- msec connection set-up and a 3–5 sec control-plane reconfig-
plane as a standalone entity i.e., without taking into account the uration thanks to the ’light-weight’ SDN framework we have
TCP reconnection time, two small UDP flows are injected in developed, may support service provisioning of the order of 4–9

Authorized licensed use limited to: UNIVERSIDAD CARLOS III MADRID. Downloaded on February 19,2020 at 08:22:23 UTC from IEEE Xplore. Restrictions apply.
KOSMATOS et al.: BUILDING A TRULY DYNAMIC FILTERLESS METRO NETWORK
seconds. As such it is capable to dynamically support inter-DC
traffic within a metro network.
VI. CONCLUSION
The architectural framework for a truly dynamic transporta-
tion platform tailored to a metro network has been elaborated and
a proof-of-concept test-bed has been implemented. The test-bed
was built by reusing a commercial PON’s data-plane and a
novel SDN control-plane based on open protocols such as Open-
Flow and Netconf. Three different experimental configurations
were studied and a dynamic connection set-up/release has been
demonstrated. In particular, it was shown - for the first time - that
a metro network can be built today with a control-plane response
time of the order of 3–5 sec and a service set-up/recovery time
of 4–9 sec.
ACKNOWLEDGMENT
The GPON/ISAM 7330 was provided by Nokia-Hellas.
REFERENCES
[1] W. Lautenschlaeger et al., “Optical ethernet—flexible optical metro net-
works,” J. Lightw. Technol., vol. 35, no. 12, pp. 2346–2357, Jun. 2017.
[2] G. Shen et al., “Ultra-dense wavelength switched network: A special EON
paradigm for metro optical networks,” IEEE Commun. Mag., vol. 56, no. 2,
pp. 189–195, Feb. 2018.
[3] A. Roy, H. Zeng, J. Bagga, G. Porter, and A. C. Snoeren, “Inside the social
network’s (datacenter) network,” in Proc. SIGCOMM, Aug. 2015.
[4] F. Galán and R. Muñoz, “An automatic model-based reconfiguration and
monitoring mechanism for flexible GMPLS-based optical networking test-
beds,” in Proc. 11th Int. Conf. Opt. Network Design Manage., Athens,
Greece, May 2007.
[5] J. Wu and M. Savoie, “Recovery from control plane failures in the RSVP-
TE signaling protocol,” Comput. Commun., vol. 34, no. 16, pp. 1956–1967,
Oct. 2011.
[6] Y. Pointurier, N. Benzaoui, W. Lautenschlaeger, and L. Dembeck, "End-to-
end time sensitive optical networking: challenges and solutions,” J. Lightw.
Technol., vol. 37, no. 7, pp. 1732–1741, Apr. 2019.
Authorized licensed use limited to: UNIVERSIDAD CARLOS III MADRID. Downloaded on February 19,2020 at 08:22:23 UTC from IEEE Xplore. Restrictions apply.
6039
[7] J. D. Angelopoulos, K. Kanonakis, H. C. Leligou, Ch. Linardakis, I.
Pountourakis, and A. Stavdas, “Slotted optical switching with pipelined
two-way reservations,” J. Lightw. Technol., vol. 24, no. 10, pp. 3616–3624,
Oct. 2006.
[8] A. Stavdas et al., “Dynamic CANON: A scalable inter-cluster multi-
domain core network”, IEEE Commun. Mag., vol. 46, no. 6, pp. 138–144,
Jun. 2008.
[9] A. Drakos, T. G. Orphanoudakis, and A. Stavdas, “Performance bench-
marking of core optical networking paradigms,” Opt. Exp., vol. 20, no. 16,
pp. 17421–17439, 2012.
[10] D. Uzunidis, C. Matrakidis, A. Stavdas, and A. Lord, “DuFiNet: Architec-
tural considerations and physical layer studies of an agile and cost-effective
metropolitan area network,” J. Lightw. Technol., vol. 37, no. 3, pp. 808–
814, Feb. 2019.
[11] E. Kosmatos, C. Matrakidis, A. Stavdas, S. Horlitz, T. Pfeiffer, and A. Lord,
“A dynamic transportation platform for metropolitan networks exploiting
PON technology and a novel control-plane,” in Proc. Eur. Conf. Opt.
Commun., 2018.
[12] S. Sygletos, C. Skoufis, C. Matrakidis, A. Stavdas, N. LeSauze, and D.
Chiaroni, “Physical layer performance benchmarking of two metropolitan
area network configurations,” Opt. Switch. Netw., vol. 2, no. 1, pp. 19–33,
May 2005.
[13] É. Archambault, D. O’Brien, C. Tremblay, F. Gagnon, M. P. Bélanger, and
É. Bernier, “Design and simulation of filterless optical networks: problem
definition and performance evaluation,” J. Opt. Commun. Netw., vol. 2,
no. 8, p. 496, Jul. 2010.
[14] G. Serafino et al., “Semi filter-less drop & waste network demonstration
with integrated SOI optical filter,” in Proc. Eur. Conf. Optical Commun.,
2017.
[15] C. Develder, A. Stavdas, A. Bianco, D. Careglio, and H Lønsethagen,
“Benchmarking and viability assessment of optical packet switching
for metro networks,” J. Lightw. Technol., vol. 22, no. 11, p. 2435,
Nov. 2004.
[16] T. Rahman et al., “On the mitigation of optical filtering penalties originat-
ing from ROADM cascade,” IEEE Photon. Technol. Lett., vol. 26, no. 2,
pp. 154–157, Jan. 2014.
[17] R. Bonk, H. Schmuck, W. Poehlmann, and Th. Pfeiffer, “Beneficial OLT
transmitter and receiver concepts for NG-PON2 using semiconductor
optical amplifiers,” in Proc. OFC, 2014.
[18] C. Matrakidis, E. Kosmatos, T. Orphanoudakis, and A. Stavdas, “Building
a converged access network based on openflow,” IEEE SDN Newslett., Jul.
2016.
[19] “ITU-T PON YANG Modules”, BroadBand Forum, WT-385, May 2017.
[20] ConfD. Available: http://www.tail-f.com/management-agent/
[21] ONOS Project. Available: https://onosproject.org/