Achieving Path Reversal in OTN By Control Plane Programmability

I. INTRODUCTION

Global mobile data traffic forecast by ITU, indicates data traffic to grow at an annual growth rate of around 55% in 2020-2030. Bandwidth demand is rapidly increasing by up-to 4x per year (predominantly between data centres). As per Cisco statistics [9], the fastest growing component of data-centre traffic is Global cloud traffic. It is seen growing by a huge 40% annual growth rate. Today's cloud, mobility and content services offered by service providers have dynamic needs. In order to meet those needs, Telecom operators require more dynamic and programmable network infrastructure with high capacity. It is essential to support rapid service deployment and provide real-time responsiveness to capacity changes.

Optical Transport Networks (OTN) promises the high capacity and reliable bandwidth fulfilment. But they are not flexible to dynamic needs as they are static and mostly manually provisioned. Optical networks are operated with wavelengths fixed in place and not designed to dynamically change. So, they are not capable of adapting to rapid changes to deliver the flexible services like cloud. Modern Network traffic consists of short bursty traffic, as well as very high bandwidth, high-duration data flows that continue for minutes. Common examples of such high bandwidth persistent traffic are VM migrations, data migrations, or Data warehousing function (MapReduce). [10]. On the other hand, OTN is traditionally a circuit switched network and the Path is set at initial design time. Changes to path requires long time and network can't adapt to dynamically to varying traffic conditions mentioned above.

Software Defined Networks (SDN) paradigm promises flexibility and programmability in network operations. SDN was originally conceived for packet-based IP networks. Hence it is difficult to apply SDN to OTN as is. SDN achieves the programmability by decoupling the data plane and the control plane. In most of the OTN these planes are currently vertically integrated and inseparably hosted along-with data-plane. Even if some designs attempt separately hosted optical control plane, it only allows network management software interactions . It does not expose its services to operator directly i.e. no API or interfaces exposed for issuing commands to control plane. Hence optical control planes cannot be programmed dynamically in present OTN.

This paper presents a design that attempts separation of optical control plane from data plane in OTN. The paper also explains the programmability of optical control plane through software instructions or configurations. The design helps control plane to get centralized view that enables it to take decisions at network domain level (instead of at network each element level). The uniqueness of design in achieving flow control (path reversal) programmability in OTN ring.

Traditionally, the design approach for IP-plus-Optical network has been, to place all the network functions within the IP layer (routing, signalling, protection). Such design uses static optical trunks interconnecting these IP layer devices. The network controller which controls IP domains does not have capabilities to configure OTN. It treats OTN merely as a fixed pipe carrying data. This paper takes a unique approach in designing OTN Ring to perform flow-control by programming OTN. Moreover, this design ensures adherence to key concepts of SDN (such as control plane separation, centralized view of control plane, software-based programmability etc), it does not mandate OpenFlow or another southbound interface (SBI). OpenFlow is not yet a complete standard, it is still undergoing significant changes to adapt to OTN. Hence it can be incorporated in this design as a future scope.

II. LITERATURE REVIEW

A detailed analysis of multiple articles was carried out in regards to specific architectures or models proposed by other researchers. Abhinava Sadasivarao and others have proposed programmable architecture that tries to integrate with the deployment of SDN within the Data Centres. It abstracts a transport node into a programmable virtual switch and leverages the OpenFlow protocol for control. It can be extended to packet-switched transport architectures including MPLS. But the time involved in setting up the path using SDN Controller showed a high latency (between 5s to 7s). Also, this architecture has implicit mode where the SDN controller has a view of only the edge nodes.

Cheng, Xu and Zang from China mobile in their paper have explained the requirements for advanced network architecture of Packet Transport Network. It has good focus on fast provisioning, end-to-end multi-domain and multi-layer network view. Although, there is no consideration given to optical transport networks.

S. K. N. Rao in his white-paper has provided a survey of SDN and its use cases explaining benefits and limitations. It explains that a typical SDN architecture has the network intelligence logically centralized in software-based controllers. This enables the control logic to be designed and executed on a global network view. This was a key takeaway from this whitepaper. But the architecture described in it was just high level block-diagram. Moreover, it only described few options without specific recommendations, hence it was found to be closer to study-paper.

R. Vilalta et. al. in their paper proposed a network control architecture for multidomain and multivendor network which is organized in layers (Refer fig.1) The abstract network layer and the control-specific layer, results in a mesh of generic SDN controllers. This uses generalized multiprotocol label switching (GMPLS) protocols as their east/west interfaces. This architecture was tested for its performance on service provisioning latency and control plane overhead. As a limitation, the authors have clarified that application of this architecture are confined and scoped to a single or reduced number of operators with peering agreements. Verizon has deployed similar hierarchical architecture for moving to 100G Packet-optical transport network.

Fig. 1: Hierarchical SDN Architecture for OTN

Industry body Open Networking Forum (ONF) has also proposed an architecture with a parent "super" controller. The network orchestrator will abstract the details of the optical transport layer. It also enables end-to-end provisioning of services and provides open interfaces to client SDN applications. It is possible to have multiple technology controllers per domain, with this architecture.

Optical network model based architectures claim to provide open and vendor agnostic management of optical equipment. Thomas Szyrkowiec et. al. have investigated Optical Network Models and their application to SDN Management. They have surveyed and compared important optical network models. They proposed an intent interface for creating virtual topologies which is integrated in the existing model ecosystem. This is an interesting architectural approach. It makes it easy to achieve software-based control but requires the network topology virtualization. In paper , a similar virtual modelling using VOLTHA was described. VOLTHA is emerging as a standard for virtualization of OLT (online termination). The modelling approaches in and has limitations, as assumptions like every cross-connection between input and output ports is possible, does not hold for a realistic optical network model. Also on a physical network level, the analogue nature leads to network constraints, which can't be modelled accurately.

A simplified architecture is proposed and analysed by RK Jha and Burhan NML in their paper . In this architecture, control of ethernet elements (routers) and optical ring is performed by a single SDN controller. Moreover, the architecture includes standardized hardware for OpenFlow switches and standard interface for OpenFlow communication. Communication between ethernet switches and optical network devices is setup using OEO converter. Communication between SDN controller and optical network devices is setup using OpenFlow agents. Hence this architecture will need enhancements before applying to all-optical network. It can also be noted that the optical hardware (ROADM), based on banyan architecture switch, combines the data plane along with switching control inside it.

III. METHODOLOGY

The experimental design methodology was used to implement the design, run tests, collect the results and demonstrate outcomes. The type of experimental design chosen was Absolute Experiment. The input was given (in the form of WDM lambdas) and output was observed by changing the control bits (or configurations). The output was recorded in the form of signal graphs and compared with expected result. Controlled variables of this experiment included input signal wavelength, OADM's drop channel setting, selection of Optical cross-connect ports. Factors not controlled include signal characteristics (like attenuation, dispersion, noise) which were not influencing factors.

This experiment was carried out in a high-end Simulator called OptiSystem. (Design section 4.2 gives more information on choice of this simulator tool.) The results were captured in the form of signal graphs shown on optical spectrum analyser (OSA). Multiple runs (iterations) were executed that gave consistent output that matches with expected output. To decide number of test-runs by using same input and to decide the variation of inputs for additional test-runs, techniques similar to sampling techniques were used. E.g. sample size of 5 test-runs with same input is considered. non-probability sampling is used for choice of input lambdas as these are in the least attenuation region (1550nm) wavelength. Judgement sampling is used for deciding add and drop channels for alternate test runs. (Note: Even though the term 'sample' is used here, it actually refers to 'test-run' or simulator iteration).

All the observations collected from these test-runs forms the empirical data collection by experiment. Simple comparison method was used to analyze the test run results. First result was compared with the theoretically expected result of the design. Following results were compared with the first result to check if any deviation. The data storage was done inside the simulator tool using the file system.

IV. DESIGN

Before proceeding to detailed design description, it is imperative to a indicate the high-level design aspects like topology and components. The type of OTN that is considered here is long-haul transport deployment e.g. between major cities. This is a very common deployment of OTN and generalizes other types (e.g. DCN = Data Centre network) also well. Bidirectional Ring topology was considered, since most of the OTN deployments follow Ring topology .

The key components in any ring are OADM (Optical Add-Drop multiplexer) and OXC (Optical Cross connect or Optical Switch). Some vertically integrated devices contain OADM, OXC, transponders etc in the same physical chassis. They perform forwarding (data-plane) and switching (control-plane) activities together inseparably. Hence as a design choice, such integrated devices were avoided. When the same signal was to be replicated on other fiber (or other direction), simple fork was utilized. Its possible to replace it with switch if any setup so requires. Since the experimental setup and outcomes are not influenced by physical characteristics like noise, BER, dispersion, there is no specific assumption on type of fiber or repeaters or amplifiers etc. The Ring input is in the form of WDM signal with four channels viz 193.1 THz, 193.2 THz, 193.3 THz and 193.4 THz. The drop and add channels of each OADMs are as shown in Table.1:

Table 1: OADM channel configuration

4.1 Detailed Design

The key design considerations include:

• Data-plane and control-plane separation: Data plane focuses only on data-forwarding.

• Controller having central view instead of one node (and neighbouring nodes): This helps in deciding network domain level functions like path traversed in the ring.

• Controller issuing software instructions (configurations or scripted commands) to bring programmability, allowing change of flow dynamically.

To accomplish these key considerations, following layers are envisaged. (Refer Fig.2) The bottom layer is Data-plane, formed by four OADMs. On top of that resides a Control plane. It consists of OXC (optical switches) which are software-controlled by the controller. Controller has a full network domain view. It issues software commands to switches in control plane and accordingly the switches control the path flown through the data-plane.

Fig. 2: Design showing control and data planes

The three OXCs are co-located i.e. placed nearby the OADMs B, C and D. But they are not hosted on or tightly couples with OADMs, like in traditional OTN. Based on instruction from controller, the OXC selects different ports and the signal coming from OADM is put onto one of the ports selected. One port allows the flow in one direction (A-B-C-D) while other port enables a reverse flow direction (A-D-C-B).

This allows to change the flow direction dynamically based on controllers input to switches in control-plane. As can be seen, OADM has no participation in flow-control. It just processes (drops a channel and adds new channel) irrespective of flow direction. This design can be used by researchers as a starting point in their SDON (Software Defined Optical Network) research, or for training others about SDN, or for integration testing in larger network setup. This design is implemented and tested using the simulator environment and output graphs are collected.

4.2 Simulator Selection

Simulation are technology tools and they help with the unreal and real-life entities to be modelled on to the computer and run under certain predefined conditions Network simulators are widely used by the research community to evaluate new theories and hypotheses. Selection of simulator can impact the outcomes, hence sufficient analysis is required before selection, especially in optical network research. The author has analysed many simulators and has come up with detailed approach to select simulator for research in OTN. Using a simulator selection tool that the author himself created for ranking the simulators, OptiSystem simulator was ranked highest for implementing this design, testing it and collecting the results/measurements of test-runs.

OptiSystem is specialized simulator for optical communication systems and includes all layers of Optical Transport Network [15]. It has comprehensive library of components. It offers high model accuracy, wide range of modulation formats, powerful simulation environment and hence good fit for research purpose. It has a truly hierarchical definition of components and systems including Optical sub-system. As per author's self-experience, this tool is quite easy to install and run. The GUI is intuitive and user-friendly and provides ability to quickly design optical Networks.

4.3 Environment Setup

Latest OptiSystem (v21.0) is used for implementing this design and setting up the test-run.

• The global parameters related to optical characteristics (such as attenuation, insertion loss, power levels) were maintained as default. (as shown in Fig. 3)

• The global parameters related to simulator model are evaluated. Some minor modifications done to bit rate, padding by no of leading/lagging zeros, central frequency (as shown in Fig. 4)

• Execution related parameters are changed as: set iterations to 2 within every run. Accordingly set the signal buffer value same as iterations (=2). Set location to store the results and filename to end with the test-run number, timestamp.

Fig. 3: Global parameters: Optical characteristics

Fig. 4: Global parameters: Simulation Model characteristics

V. RESULTS

There are two iterations carried out to test run the two flows: First flow is OADM A-to-B-to-C-to-D and second flow is reverse, OADM A-to-D-to-C-to-B. Both flows worked as designed and successfully showed the designed output.

Results are collected as the graphs from Optical Spectrum Analyzer (OSA). Depending upon the test, the OSA is placed at various points to traverse the flow of signal step-by-step and check the correctness of channels for that step. The resulting graphs at OADM A, B, C and D are shown below for both the test runs. These results are stored in flat file. The file names end with test-run, iteration number, timestamp information. OADM A is a common Ring ingress point for both the flows. In both the test-runs, same input signal (WDM) is given to Ring at OADM-A as shown in fig.

Flow 1 Output: Output taken at OADM-A, B, C and D shows each OADM drops a channel and adds a channel on its input signal. So, at output of D (i.e. Ring output), as expected the original four channels are dropped and new four channels are added, as seen in fig 6 (OADM A & B) and Fig 7 (C & D).

{"image_source":{"path":"images/4f6f4f0f5b14f032521b521e2d9abe9290e734729e6c13c4ffe2da9f8def4dfa.jpg"},"content":"","chart_caption":[{"type":"text","content":"Fig. 5: Ring Input (WDM) at OADM-A"}],"chart_footnote":[]} {"image_source":{"path":"images/a1c63cadd2027936a95e531de6bb2bb18d8133353a572f340da283178103d7da.jpg"},"content":"","chart_caption":[],"chart_footnote":[]}

{"image_source":{"path":"images/1fa193c36dfc2d08485adcf1ae53199816106f599fa17c05a689f91e202bcca3.jpg"},"content":"","chart_caption":[{"type":"text","content":"Fig. 6: Output at OADM-A & B for flow 1"}],"chart_footnote":[]} {"image_source":{"path":"images/42a25727187727220392b49f42e9d61af3844f34d148a65e90bb63f8f7441556.jpg"},"content":"","chart_caption":[],"chart_footnote":[]}

{"image_source":{"path":"images/5161167612e8fbce98d1de51ba85a57e3741c1ef2df4af72be3acbd7504b7cff.jpg"},"content":"","chart_caption":[{"type":"text","content":"Fig. 7: Output at OADM-C & D for flow 1"}],"chart_footnote":[]} In the reverse flow test-run, output of OADM-A is same (as same input is provided). Thereon, there is a difference in flow. Output at B is now Ring output due to flow reversal and B shows only new four channels added (as expected for reverse flow). Output of OADM A, D show in Fig 8 and output of OADM C & B is shown in Fig 9.

{"image_source":{"path":"images/55e68560279f65bf47f8e043918bda5d1d79142cf05b4a3d609247e73519599d.jpg"},"content":"","chart_caption":[],"chart_footnote":[]} {"image_source":{"path":"images/8f282e5ab93b79e5ef7bb5a10858a02618931588cd44a56ad307eaa648808b7e.jpg"},"content":"","chart_caption":[{"type":"text","content":"Fig. 8: Output at OADM-A & D for flow 2"}],"chart_footnote":[]}

This confirms that flow-reversal design has worked as desired. The controller changes the configurations and sends instruction (bit-sequence) to switches to reverse the flow. This shows that the programmability of flow in the OTN can be achieved by control-plane.

{"image_source":{"path":"images/2bcdad8b3238179cf8bf91198dd42c7db1114845da1aa58544a056baee6a9495.jpg"},"content":"","chart_caption":[],"chart_footnote":[]} {"image_source":{"path":"images/8d81b8d1ed9d5110f64f00e7476f89b92363d4a4b83fa38e3369b45cbba7f3b9.jpg"},"content":"","chart_caption":[{"type":"text","content":"Fig.8: Output at OADM-C & B for flow 2"}],"chart_footnote":[]}

VI. CONCLUSION

It was experimentally shown that the proposed design is capable of achieving flow-control in OTN with the help of programmability offered by its central control plane. The design when implemented works as desired and flow reversal in Ring topology was observed. This unique design follows key concepts in SDN (like control-data plane separation, software-based programmability, central view of network domain etc). Hence it can be inferred that it is possible to apply SDN concepts to OTN, although SDN can't be applied to OTN in the same way it is applied to IP networks. SDN expects optical networks to be modified to adapt to SDN e.g. by clear separation of data-plane and control-plane. This paper presents a design with optical control-plane and data-plane logically separated. Flow control is dynamically achieved by programmability offered by central control-plane that has full view of optical ring network. Thus, the paper has illustrated SDN-like programmability in OTN using flow-control scenario. Researchers can reuse this design in their SDON research work as-is or by modifying as per their needs, the design is flexible. Academician can use it for training SDON concepts or for integration testing with another network setup. This tested, working and flexible to modify network design acts as a reliable starting point. With it, researchers can make alterations with confidence and refer back to this reliable stratum. It can also be concluded that OptiSystem simulator was suitable choice for implementing and testing this OTN design. As a future work, OpenFlow can be added to this design for SBI (southbound interface)

VII. ACKNOWLEDGMENT

The author wishes to thank OptiWave OptiSystem for allowing temporary access to licensed copy of the latest version (v21.0) of OptiSystem Simulator.