Embedded Communication Channelfor Node Communication in WDMNetworks

(1)

IN

DEGREE PROJECT DEGREE PROGRAMME IN INFORMATION AND , SECOND CYCLE COMMUNICATION TECHNOLOGY 300 CREDITS

STOCKHOLM SWEDEN 2015,

Embedded Communication Channel for Node Communication in WDM Networks

ANDERS ROSÉN

(2)

Abstract

Optical Transport Network is a set of Optical Network Elements (NE) connected by optical ber links able to provide support for optical networking using Wavelength-Division Multiplexing (WDM). In order to be able to introduce link-level applications that require NE-to-NE communication in a packet-optical network, an embedded communication channel is needed. Ex- amples of such applications are dual-ended protection, remote conguration and path trace.

By implementing a NE-to-NE communication channel, the exchange of commands and information will allow for implementation of applications that will increase the data link stability in the network. The purpose of this work has been to prove the feasibility of such a channel.

This thesis discusses the possibilities of implementing such a channel adjusted to Transmode's layer 1 products without causing disturbance in the regular trac or aecting any existing embedded communication. It also proves the channels function in a proof-of-concept manner by demonstrating a simple Path trace application run upon an implementation of the channel on hardware.

The chosen solution is an Embedded Communication Channel driver intended to provide termination points for an Embedded Communication Channel (ECC), supervising the connectivity of the channel and relay messages to applications.

This thesis project has been carried out at Innera Corporation (earlier Transmode Systems AB) during summer/autumn 2015.

Keywords

Embedded Communication Channel, NE-to-NE communication, ECC-Driver, Socket programming, Linux kernel

(3)

Sammanfattning

Optical Transport Network är ett antal Optical Network Elements (NE) sammankopplade av optiska ber-linor som tillhandahåller stöd för optiska nätverk som använder sig av våglängdsmultiplexering (WDM). För att kunna introducera applikationer på länk-lagret som kräver nod-till-nod-kommunikation i ett paket-optiskt nätverk behövs det en inbyggd kommunikationskanal. Ex- empel på sådana applikationer är dubbel-sidigt beskydd (dual-ended protection), fjärrstyrd konguration och vägspårning (path trace).

Genom att implementera en NE-till-NE-kommunikationskanal, kan ut- byte av kommandon och information tillåta implementering av applikationer som ökar stabiliteten av datalänkar i nätverket. Syftet med detta uppsatspro- jekt har varit att bevisa funktionaliteten av en sådan kommunikationskanal.

Denna uppsats tar upp möjligheterna till att implementera en sådan typ av kanal anpassad till Transmodes lager 1-produkter utan att förorsaka störningar i den reguljära traken eller påverka den redan existerande inbyggda kommunikationen. Den visar också på kanalens funktion på ett koncept- bevisande sätt genom att demostrera en enkel Path trace-applikation som körs på en implementation av kanalen på hårdvara.

Den valda lösningen är en drivrutin för en inbyggd kommunikationskanal ämnad att tillhandahålla ändpunkter för den inbyggda kommunikationskanalen (ECC), övervakning av kanalens anslutningar och skicka vidare meddelanden till applikationer.

Detta examensarbete har genomförts på Innera Corporations (tidigare Transmode Systems AB) under sommaren/hösten 2015.

Nyckelord

Embedded Communication Channel, Nod-till-Nod kommunikation, ECC- Driver, Socket-programmering, Linux kernel

(4)

1 Introduction

This project aims at coming up with a general solution for a low-level communication channel between nodes in a network. Link-level applications or protocols would get a standardized way of communicating with each other, which leads to more features supporting the link-level layer in network elements. The project will investigate whether such a channel would be possible, plausible or even needed at all. We will design a solution, try out the concept and evaluate it. A possible solution will be implemented on Transmode's equipment, and be formed after their node architecture. The project is carried out at Innera Corporation (earlier Transmode Systems AB). Innera delivers packet-optical network solutions to tier 1, mobile and Cable TV operators. A big part of the project research is going to utilize Innera's proprietary systems and equipment.

In this introducing chapter, a background to optical networking is presented as well as a general problem description, the purpose and the goals of the project.

1.1 Background

From internet trac and optical networking to low-level node structure.

The following subchapters introduce the most important parts needed to understand the background area of the problem.

1.1.1 Internet Trac Today

The Internet constantly grows in terms of users and data trac. The Internet trac itself is estimated to grow by 50% annually in the upcoming decade[1].

Years ago telecommunication was equal to the telephone network, but as we know it today Internet video, online gaming and le sharing (peer-to-peer trac for example) is taking up the majority of the network bandwidth.

According to Cisco's annual global IP trac forecast from 2015, the global IP trac will exceed the one zettabyte limit in 2016. Preparation towards this more and more connected society is in Sweden where the residential broadband access is at least 1 Mbit/s today[2]. The deployment of 100 Mbit/s is an ongoing project by Post- och telestyrelsen (PTS), a Swedish authority responsible for mail and electronic communication. Their goal is to provide at least 90% of the households in Sweden with access to at least 100 Mbit/s by 2020[3]. Cisco also predict that already in 2019, the two zettabyte limit will be reached and the number of non-wired devices will exceed the

(7)

number of wired devices connected to the Internet. A contributing factor is the Internet of Things (IoT) trend meaning that all the things around us are going to be connected to the Internet. IoT will become more mainstream the upcoming years. Internet trac in the future is not going to be more geographically balanced than today even if the number of Internet users on the other side of the globe increases, Cisco predicts. The most intense period of the day, the so called busy hour, will keep getting more intense.

This period will increase by a factor 3.4 versus the average Internet trac that will grow by a factor 2.8[4].

Cisco also predict that the popularity of content delivery networks (CDN) networks will continue over the years and more than half of the Internet trac will go through CDN networks by 2019[4]. A CDN delivers web content, music, live video, on-demand video and les to users based on their geographical location. The purpose is to decrease the distance between re- quested content and end users, and achieve a lower response and download time. A CDN system is composed by distributed servers, spread around the world. The majority of the trac from a service using CDN is therfore kept inside of a metro network.

Innera (Transmode) is mainly working with equipment for metro, or metropolitan, networks that interconnects locations in a large city, cities in a region, large company sites, links to mobile cell sites and so on. A long- haul network connects regional metro networks, i.e. countries and bigger regions with a thousands of kilometers between its nodes[1]. The increasing popularity of CDNs in combination with the fast growing Internet trac makes Cisco predict that metro trac is going to surpass long-haul trac already this year, in 2015. This is of big interest to Innera's (Transmode) and puts pressure on their equipment performance.

1.1.2 Fiber-optical Communication

When building a long distance network today, like a long haul or metro network, optical ber is the most commonly used communication medium[1].

This includes Innera's networking solutions as well.

Fiber-optical communication has existed since 1970 when the American glass company Corning Inc. developed optical ber suitable for communication purposes, and has since then taken the telecommunication industry to the next level with great performance over long distances. Pulses of light, i.e. signals, sent through transparent, exible ber made of glass or some- times plastic creates an optical communication channel. This core channel is dressed in an optical material that reects the light back into the core. An

(8)

outer material made of plastic protects the channel from damage and dirt.

Cable TV systems introduced optical ber in 1976 which was a cost ef- fective alternative for long distance trac. Fiber in the trunk cables had some great advantages compared to coaxial cables. The ber delivered fewer signal losses and many ampliers could be removed. This resulted in a highly improved signal quality and reliability[5]. In the early 1990's an optical repeater device called Erbium-Doped Fiber Amplier (EDFA) that boosts the intensity of light signals appeared and quickly reduced the cost of ber optic systems. A single amplier could replace the current regenerators required for each wavelength. This was especially satisfying when the number of data- carrying wavelengths increased. The EDFA works by dopeing an optical ber with erbium (Er³⁺) and then using a light source, a laser, that pumps out light of 980 or 1480 nm to the doped ber to excite the erbium atoms[6][7].

Another important technology for optical ber communication is wavelength division multiplexing. The telecommunications network today carries telephone, Internet and TV communication, in contrast to before when it only carried telephone networking. Internet and TV communication form a big majority of the total trac ow.

Optical ber is better than traditional copper wires in the sense that they can carry much more bandwidth and deliver signals faster. Signals travel approximately 200 000 kilometer per second[8]. Standardized data rates exist of 10-100 Gbit/s. Because optical bers carry light, they are less susceptible to electromagnetic interference and less sensitive for attenuation of signals during transmission. The large downside of ber relative copper wires is the cost. However, with today's development it will get cheaper in the near future. From a technical point of view, optical ber is the preferred choice when dealing with data rates of more than a few Mbits/s over a distance more than a kilometer. In 2014, ber passed copper in supplying both companies and individual households with network access[1][9].

There are transport protocols specially intended for optical ber networks. The most popular one today is the Optical Transport Network (OTN) protocol that frames any client signal into OTN packets for transportation over optical ber[10]. Another example is Transmode's proprietary transport protocol called intelligent WDM (iWDM).

1.1.3 Wavelength Division Multiplexing

WDM is an important technology for optical networking that gives a signi- cant higher throughput by passing multiple signals through the same optical

ber cable at the same time. It multiplexes signals, joining them together,

(9)

and sends them on dierent wavelengths to a demultiplexer where they are split up into dierent channels as shown in Figure 1[11]. This diers from Time Division Multiplexing (TDM) where each incoming channel are allo- cated a time slot where they are allowed to send their data. TDM was used in the rst optical networks but nowadays, WDM is more used¹.

Figure 1: Wavelength Division Multiplexing

There are two types of WDM depending on how the multiplexing of signals is done, Coarse WDM and Dense WDM. Coarse WDM (CWDM) typically provide up to 8 channels in the 1470 to 1610 nm range for bidirec- tional communication. Dense WDM (DWDM) has a denser spacing between channels than CWDM has, and uses a smaller transmission window. The channels are located between 1530 to 1565 nm frequencies, which is specied in the ITU-T G 694.1 recommendation[12]. This technique makes it possible to allow for many more channels. The disadvantage is that DWDM systems has to keep the wavelengths more stable than in a CWDM system due to closer spacing between channels, and that equals a higher cost. DWDM was enabled by the introduction of the EDFA technology[6].

1.1.4 Node Structure

The network elements (NE) that Innera (Transmode) is developing for ber- optical networking, and that this work is going to encounter is primarily composed by two types of hardware parts. These parts are typically residing in a subrack. They are called Trac Units (TU) and Control Units (CU).

Trac units work at the bottom level abstraction of the node taking care of the trac ow to and from the node. The responsibility area of TUs includes trac monitoring, connectivity to adjacent nodes and alarm handling. Con- trol units receive status reports and updates from one or more TUs. They

1Data rates STM-1, STM-16 in SDH and OC-3, OC-48 in SONET are typical TDM systems

(10)

also manage the node by sending commands to its inferior TUs. The subrack is responsible for the node interconnection i.e., the connection between CU and TU. All nodes are connected to another system for user congurations, called Trac Network Management (TNM), that sends commands to the CU. The most interesting node part for this project is the TU, where all low level functionality is operating. They are the ones handling the trac on a data link level according to the Open Systems Interconnection model. More about trac units can be read in chapter 2.3.

Figure 2: Network element with CU and TU components

End points for data transmissions are called terminating nodes or end nodes. Another kind of nodes, intended to amplify the signal on its way to the destination, are called repeater nodes. However, their structures do not dier a very much. The internal communication inside of a node are performed with the help of proprietary protocols and an Internal Communi- cation Channel (ICN).

(11)

1.1.5 OSI Layer Model

When talking about link-level applications or protocols that this research is going to encounter, it is often referred to the protocols that belongs to the data link-layer in the Open Systems Interconnection model. The Open Sys- tems Interconnection model (OSI model) is a layer-based conceptual model for network communication. Seven levels of abstraction partitions a communication system into layers independent of each other's appearance. Data produced by an application starts in the top layer, and traverse all the way down before it is sent out on the network. An incomming payload from the layer above is called a service data unit, SDU. This SDU together with a header becomes a protocol data unit, PDU. The PDU created in the layer is then sent as a SDU down to the next layer. The two layers of interest to this project are the Physical layer, and the Data link layer.

# Layer 7 Application 6 Presentation 5 Session 4 Transport 3 Network 2 Data link 1 Physical

Table 1: The OSI Model

Layer 2 The second layer is called the Data link layer and provides support for data transmission between adjacent nodes. The data link layer is medium-independent in contrast to layer 1, that handles the delivery of data- link frames to devices within a LAN. The data link layer is divided into two sublayers, Media Access Control (MAC) and Logical Link Control (LLC).

These two sublayers have an internal hiearchy, where LLC is on top of MAC.

LLC provides data link control, addressing and some optional features while MAC decides which frames that may access the media. Examples of protocols that belong to the data link layer are High-level Data Link Control (HDLC), Address Resolution Protocol (ARP) and Point-to-Point Protocol (PPP). Ethernet also provides some services included in the data link layer.

Layer 1 The lowest layer, called the Physical layer, handles the incoming and outgoing raw bit streams directly from the physical transmission

(12)

medium. It functions as a standardized interface for physical signals and handles the translation between physical signals and bits. It also performs character encoding, bit synchronization, multiplexing and so on. Examples of physical layer protocols are USB, Bluetooth and DSL. Even optical transport protocols belong to this layer.

1.1.6 Link-layer Applications

Link-layer protocols, or applications, handles the transfer of data between adjacent nodes in a WAN and provides some services for error control, protection, link verication and so on. There are several applications of interest that could use a communication channel like the one investigated in this project. Some of them are discussed here below.

Point-to-Point Protocol The Point-to-Point Protocol (PPP) is used for point-to-point communication between nodes. It can be set up in the CU.

However, it is not built to oer the broad functionality that we are looking for in this project. Transmode have both ftp and remote access GUI that runs over PPP. PPP does support error detection and error correction at Layer 2.

Path-trace A path trace application's mission is simply to trace the path of packets. By sending a static message to a receiver, the sender can verify itself and its connection to the receiver in a very simple way, node to node.

ICCC iCCC is a simple continuity check protocol that checks if the link is up or down. It sends small messages at a specied interval and gets a response containing the same message. As long as the link is up, it will just keep going but if the link goes down, it will notify its node.

Dual-ended Protection To be able to know when to switch between the links to listen to when one link goes down, the dual-ended protection unit will notify its corresponding application in the neighbouring node. The delay in one of the nodes may disturb client applications if the switch is not made at both nodes. In dierence to single-ended protection, double-ended protection needs the communication to work in both directions.

Forward Error Correction FEC is an error detection and correction technique used for xing errors that occur during data transmission. In

(13)

OTN, FEC is a major feature and an essential technique preventing a severe amount of retransmissions. By encoding a bit into a serie of bits in a re- dundant way, the receiving node is allowed to decode the bit serie with the help of an algorithm and detect possible errors, and in that way reduce the risk of transmission errors received. If there would be a need for switching FEC congurations, or other congurations, you have to do it manually by connecting to the node's user interface and there will be a delay between the two conguration changes. A conguration application on every node would be able to make the change in conguration at the same time in both nodes, and avoid disturbance.

1.2 Problem

Today, there is no standardized and general way of sending information to an application on another node at a data link-layer level. The exchange of information between link-layer applications is either done in a pre-dened application-specic eld in the protocol used or non-existent. In order to take advantage of features like dual-ended protection for example, this problem has to be solved. The main problem in this project is therefore to nd a solution for an embedded, NE-to-NE communication channel able to support applications that require nodes to exchange status and commands at a low layer level. We call it Embedded Communication Channel (ECC).

All transport protocols have a restriction on what they can put in their overhead, which is understandable. Because of that many desired, specic functionality be impossible to implement. This problem also applies for applications that by any reason would want to send more data than what the transport protocol allows for. An ECC channel, that various applications can take advantage of, could be the solution.

One additional problem is to keep the communication channel design from getting out-of-date already by tomorrow. In order for the ECC to work as long as possible, we have to strive for a exible solution border-crossing between transport protocols with as few dependencies as possible. Another one to keep in mind is the risk of a complex design that is hard to implement and/or interferes with the existent communication.

1.3 Purpose

The purpose of this thesis project is to prove the feasibility of a NE-to-NE communication channel feature in optical networks.

The purpose of a NE-to-NE communication channel is to open up for

(14)

the possibility of introducing new link-level application protocols that can improve the security and reliability of the data link, even if they are not supported directly by the transport protocol of interest. Transmode has not had the opportunity before to utilize many link-level protocols, dual-ended protection in iWDM for example. Other link-layer applications that could be introduced and contribute to the data link security are Path trace, iCCC for continuity checks and conguration management from a distance. If an ECC can be proven to both work appropriately and be implemented, Transmode would be able to use this solution in their future products.

1.4 Goals

To be able to prove the feasibility of an ECC channel the following goals, that lay the foundation for this whole project, have to be fullled.

1. Find a solution, if any, for implementing a NE-to-NE communication channel with the following restrictions

No change of TU rmware No change of line format

2. Implement a proof-of-concept model able to run a simple Path Trace application for test purposes

3. Demonstrate the implementation on hardware with the following requirements

Run the simple Path trace application successfully No regular trac disturbance

Minimum aection on other services, i.e. PPP

Goal 1 The purpose of the rst goal is to nd a general design solution that is adaptable to Transmode's own existing hardware and software on implementation. A general solution means that it should provide functionality regardless of which big transport protocols, which type of WDM or which type of Transmode network node that is used. On the other hand it must not require any changes that makes it unnecessary hard to implement into an existing network node, like a change in the existing rmware for example.

The stated restrictions, subgoals, will assert that this does not happen.

Goal 2 The second goal is a proof-of-concept model of the design. The functionality is proven by running a simple link-level application, a path trace, on top of a proof-of-concept model of the design solution. Without the implementation of the design, we can not prove that the solution works as

(15)

expected. The path trace application will help us through the demonstration of the ECC channel, and put load onto the ECC channel.

Goal 3 The third goal states the minimum requirements in order to call the ECC a succesful solution. At demonstration, the tests shall establish that the channel works whitout breaking any of the requirements at normal usage.

The rst subgoal veries that the ECC channel works as intended. The developed path trace application shall be able to use the ECC by sending messages to a counterpart through the ECC channel and receive messages in the same way. The goal is fullled when it is proven that the path trace application successfully can take advantage of the ECC on Transmode equipment.

The most important objective of the ECC channel is to not aect the customer trac. During the demonstration, trac will be generated and monitored at the same time as link-level application trac ow through the ECC channel. The regular trac shall not be aected by the ECC trac at all.Other services running in parallel to the ECC shall not be severely dis- turbed by the trac ow on the ECC channel during regular circumstances.

This means that packet losses and too long delays that occurs because of trac in the ECC channel is not acceptable.

1.4.1 Ethics and Sustainability

There are no apparent risks of ethics or sustainability problems. The result of this project will answer Transmode's questions regarding the implementation possibilities of an embedded (NE-to-NE) communication channel into their equipment. The solution developed during this project may be released together with Transmode's products in the future and if so, this project will benet the end users, customers, of Transmode as well.

1.5 Methodology

This research will follow a qualitative method with an interpretative philo- sophical assumption, meaning that the research will be viewed out of an investigating perspective intended to solve the problem through studying and reasoning. An analytical research method will be used for testing pre- planned requirements with an inductive research approach. Further more, data will be collected by running tests. These data will be analyzed with

(16)

grounded theory by comparing test results to expected outcomes, i.e. the minimum requirements. At the very end, analyzed test results and the research material will be validated[13].

1.6 Delimitations

The area of study will be limited to the implementation of a communication channel at a TU-level. Development of functional applications will not be a part of this project, only applications for testing and demonstration purposes are of interest.

1.7 Outline

The following chapters will discuss more about the problem, the possible solutions, the outcome of the implemented solution and nally a conclusion to summarize the project.

The next chapter goes through the theoretical background of the problem to give the reader a broader perspective on the problem area and the problem itself. The chapter after that describes the approach of the problem solving and how the solution is found, the actual work and its proceeding. After that comes a chapter about the results and a discussion about them. At last is a concluding chapter containing a short summary along with future work suggestions.

(17)

2 Theoretical Background

The theoretical background to the problem is briey described in the last chapter. Here we go deeper into the problem area.

2.1 Former Work

Former work in this area is limited. Work that corresponds to this problem area exists within Transmode's code base and as written specications but these documents are condential.

There are data sheets specifying the basic functionality of the equipment used in the testing session of this project that can be accessed. They are describing the trac unit boards in a general way, how to use them and information about their performance. For example, the data sheets for the 100G OTN Transponder and Muxponder both provide an explanation of their integrated platform solution and a number of technical specications about trac formats and interfaces[14] [15].

There is a paper written that has contributed to the eld of failures in optical networks called Optical Switching and Networking[16]. In this paper, the deployment of fault recovery mechanisms and their accompanying problems that occurs due to these mechanisms are discussed. The authors write about the importance of the signalling capability and the supervisor functionality. Most of the current optical networks use a supervisory control channel for monitoring and management, where it is a common practice to place this within a Digital Communication Channel (DCC) section of the STM-1 header or the General Communication Channel (GCC) of OTN. This is the kind of functionality that would be possible to easily implement with the help of an ECC channel.

2.2 Optical Network Transport Protocols

Transport protocols make sure that data arrive at the correct destination.

Customer data, the payload, takes up a big part of the bandwidth while the rest is used for an overhead that contains transport-specied information about the packet. There are several dierent transport protocols that oper- ate over optical ber. The most common one today is the optical channel wrapper OTN, that has replaced the two former giants Synchronous Digital Hierarchy (SDH) and Synchronous Optical Networking (SONET). Another important member of this type of protocols is Transmode's protocol iWDM.

(18)

It is important that a solution to this project satises all of the popular transport protocols so that we get a general solution.

2.2.1 Optical Transport Network Format

OTN is a digital wrapper technology designed to transport IP, Ethernet and SDH/SONET trac for example over optical ber, specied in ITU-T recommendation G.709[17]. OTN is mainly used in long-haul networks. Optical Channel Data Unit (ODU) is travelling inside Optical Channel Transport Unit (OTU). Line rates, dened in OTU, diers from SDH/SONET line rates. There are also dierent kinds of ODU signals. Unlike the predecessor SDH/SONET, OTN was designed to provide support for WDM. OTN also supports error correction and functions for monitoring a connection from end to end[18].

Format Line rate

OTU4 100G

OTU3 43.018G

OTU2e 11G

OTU2 10.709G

OTU1 2.666G

Table 2: OTN formats and their corresponding line rates[1]

2.2.2 Intelligent Wavelength Division Multiplexing

Transmodes proprietary format Intelligent WDM (iWDM) was invented to provide cost-optimized transport of multiple services[19]. It supports bit rates of 2.5, 4 and 10 Gbit/s. iWDM supports the WDM technology and error correction but does also provide for layer 2 functionality such as VLAN management. Compared to OTN, iWDM has a smaller overhead which makes it more ecient in using the bandwidth. The drawback compared to OTN is of course that iWDM is not a standard protocol. iWDM is only supported by Transmode's own products.

2.2.3 Synchronous Digital Hierarchy

Synchronous Digital Hierarchy (SDH) and Synchronous Optical Network- ing (SONET) are both standardized transport protocols over ber. SDH are more commonly used than SONET except for in the United States and

(19)

Canada, even though they are essentially the same. They use TDM technology instead of WDM. They were developed for the rst generations of optical networking. The clocks in a network are perfectly synchronized to a single master clock.

2.2.4 General Communication Channel

All of the above mentioned optical transport protocols provide support for a general communication channel within their overhead where various types of data can be stored and sent. This channel is typically used for PPP or Link Access Protocol D-channel (LAP-D) trac. In OTN, this channel is called general communication channel (GCC). Although, in iWDM and SDH/SONET the same kind of channel is called Dedicated Communication Channel (DCC). We will further on refer to these channels as GCCs.

In Transmode's GCC channel today runs a PPP-channel with trac as well. The trac comes from applications like File Transfer Protocol (FTP), Ping and a remote access Graphical User Interface (GUI). The maximum HDLC bandwidth to the CPU is 18 Mbit which is limited by the bandwidth of the two HDLC channels to the CPU. The data bit in the GCC word, 6, divided by the OTN frame period, which is 12.191 micro seconds, gives us the total GCC bandwidth for OTU2 (10G), which is 0.49 Mbit. The bandwidth of each GCC channel is congurable, but in this project, we are going to work with the default conguration. OTN has three GCC channels in Transmode's TU boards (GCC0, GCC1 and GCC2).

The DCC format in iWDM is delivered as shown below, as an HDLC frame.

Transmode is working with packet-switching optical networks and is developing products thereafter. The TM-serie is a packet-optical platform that supports both single ber, bi-directional communication over one ber (two dierent wavelengths for each direction), and ber pairs (one ber for trans- mit direction and one for receiving direction). The last one is used more often since ampliers in long-distance networks only work in one way. To be able to implement a solution into Transmode's equipment, we need to go deeper into the structure of the boards that belong to this platform.

As mentioned in the introducing chapter, there are hardware components called Control units (CU) and Trac Units (TU) residing in subracks. Each

(20)

subrack forms a node. A subrack has a backplane for communication and some slots for boards that most often contain one CU and one or more TUs.

The maximum number of TUs that can be used together with a CU depends on the number of free slots in the subrack. In some cases it may be interesting to insert more than one CU in a subrack. This extra CU then becomes a so called slave CU. The CU can be seen as the head of the node that handles all of the communication with the TNM via the Management Information Base shell (MIB shell) or the GUI, and makes most of the decisions regarding the node.

The TUs, the bodies of the nodes, are responsible for the trac ow through a node. Their biggest task is the link surveillance. The TU takes a frame in client format and wraps it into the line format, such as OTN or iWDM. An embedded communication channel needs to be set up between two nodes at their respective TU-level, and that is why the TU is of high interest to this project. There are dierent types of TU-boards with dierent functionalities.

2.3.1 Trac Unit Boards

The four most common layer 1 transponders and muxponders, TU boards, in Transmode's TM-serie are listed below. They are all intended for dierent kinds of situations. All of the boards have about the same software architecture, but the hardware architecture diers. This project must take them all into consideration. However, this dierence in hardware and software is not going to aect our specic case. It is still good to know about what they look like when the testing session begins.

The TPHEX10GOTN is a 10G board that oers six transponder functions in one slot, saving both space and becomes more energy ecient. As a transponder, it takes client trac in one input and turn it into OTU2 line format. The TPHEX has a total of six input ports and six output ports, mapped one to one as gure 3 shows below. The TPHEX support a wide range of SFP+ transceivers, from short haul client interfaces to CWDM and DWDM tunable line interfaces[14].

The MXP100GOTN is a 100G OTN Muxponder that takes the client trac of several input ports and put it into an OTU4 line format. The MXP100 has ten input ports and one output port, as can be seen in gure 4[15].

The MXP10GOTN works exactly like the MXP100 except for its outgoing line format. Instead of putting client trac into OTU4 packets, it uses OTU2 and transmits data on a 10 Gbit rate.

(21)

Figure 3: Sketch of the TPHEX10GOTN trac unit board

Figure 4: Sketch of the MXP100GOTN trac unit board

The TP100GOTN is a regular OTN transponder which enables mapping of 100G client services to an OTU4 line signal with very small footprints. It has one input port for client trac and one output port for 100G trac.

2.3.2 Hardware Architecture

There are many hardware components used to design the boards. To implement a software design on the TU, it is good to have a brief understand- ing about the hardware architecture. The main components are a Control FPGA, an ASIC, a CPU, Clocks, SFP+ modules and a daughter board with CFP as line interface for the MXP100GOTN board. The most important one among these components is of course the CPU. The CPU contains most of the software running and controls the events of the board. Data sent from the CPU out on the physical ber will go through an interface, a separate module, that is called small form-factor pluggable transceiver (SFP).

SFP is a small external transceiver module for both tele and data communication. The module is used on network devices facing a network cable of any kind. It replaces the older standard Gigabit Interface Converter. SFP+

is an enhanced version of SFP that provides support for higher data rates, OTU2 and 10 Gigabit Ethernet among others. There are many dierent

(22)

transmitter types but SFP+ is a popular format in the industry today[20].

2.3.3 Software Architecture

The software architecture in the TU consists of two major processes, Cong- uration manager (CM) and Hardware (HW). There is a parent process which forks CM and HW at start up. Both CM and HW are then running during the up time. The CM process is of less interest since it almost only handles the communication to the CU. HW handles all hardware specic functionality, i.e. control FPGA, power modules, and CDRs. The HW process itself consists of a few subblocks described in the section below. There are also a few proprietary libraries that provide the boards with important, general functionality that every type of board can take advantage of.

The HW process is composed by the software subblocks listed below among others. Most of these blocks contribute to the safety of the transportation through dierent kinds of functionality.

• Fault manager (FM)

• Laser

• Protection

• Port

• Performance monitoring (PM)

• OTN-specic PM

• FPGA

• Persistent Memory (PMEM)

Some subblocks use libraries to support their functionality. The libraries are called Up_util, Alib and Nlib. Up_util handles the warmstart of the board meaning a start or restart caused by the software. It also provides support for FEC, performance monitoring and so on. The Alib and the Nlib both provide more basic functionality. Nlib for example provide support for linked lists that any application can take use of. The software runs upon a Linux kernel which makes this project a little bit easier, since there is a lot of standardized Linux commands available. High-Level Data Link Control (HDLC) interface against the Linux kernel.

All communication inside of a node goes through a so called Internal Communication Network (ICN) channel. ICN supports several interfaces for dierent kinds of communication used by various processes within the node.

An ICN server register supported interfaces in ICN, and then client services, like processes, can connect to an interface in ICN by making a request to the server. Some examples of interfaces are UBI, UCI and UOI.

(23)

The TM communication platform looks like in gure 5.

Figure 5: Communication platform, CU to TU

2.4 Bit Interleaved Parity

Bit Interleaved Parity, BIP, is a bit eld for validating messages and detecting errors in a frame. In a BIP-8 eld, an eight bit eld is calculated. The calculation is made by counting ones and represent the sum in terms of odd or even numbers. The part of a frame that should be checked for errors are divided into 8-bit blocks and the ones at index 0 of all blocks are summed together, the ones at index 1 are summed together and so on. The total sums become one if they are odd and zero if they are even numbers. The resulting code becomes a 8 bit long serie of one's and zero's.

A BIP-8 functionality does not exist already in any of Transmode's libraries so it has to be implemented in one of the big libraries, nlib. By calling for NlibSys_bip8() with a part of the frame and its size as parameters, a BIP-8 code can be returned. The function can be used for calculating the content in the 8-bit big eld in the ECC header, as well as verifying the BIP-8 codes of the incoming ECC packets.

2.5 Management Software

A management software running on the node is going to handle incoming and outgoing ECC messages to and from link-layer applications. There are two dierent solutions presented below regarding software handling message distribution, both incoming and outgoing. They have both advantages and disadvantages over each other.

(24)

Solution 1 The rst solution is an ECC driver that handles all ECC trac and distributes the trac to its correct destination, in combination with an ECC relay component that will forward the trac if the destination is not yet reached.

The key component for this solution is the ECC driver. The driver should be responsible for setting up termination points for ECC channels, supervising the connectivity of the ECC, providing an interface for the application layer allowing them to register for the service and notify subscribers when the ECC is available or unavailable. Trac with another destination address is forwarded by the ECC relay towards the correct node.

Solution 2 The second solution lets applications subscribe directly to the Linux kernel. It is then the application's responsibility to process the ECC header, either by themselves or by using a library.

Instead of forcing each application to do their own supervision of the ECC link, an ECC supervisor does this by running the ICCC protocol and then notify applications if the link status changes. Again, we got the relay for forwarding trac with a destination address further away.

(25)

3 Design approach

This section covers the method used, design decisions and other engineering- related work.

3.1 Method

With the help of the theoretical background given in the last chapter, we can now start to design the ECC channel. To begin with, we are going to come up with a design for the actual channel. Thereafter the protocol can be specied so that we will know what to expect from incoming and outgoing packets from the ECC channel. This shall be specied at a detailed level.

Then the design of the actual software can begin, at rst purely conceptual, then in a higher abstraction layer where the design can be divided into parts and be briey described. At last the design goes into a more detailed level like functions and low level design decisions.

3.2 Design

To solve the problem, there are a few design approaches to choose between.

This subchapter discusses the best way to construct and design the communication channel, related protocols and the managing software process that handles the incoming and outgoing packets on the channel. The design choices are motivated in the each chapter respectively.

3.2.1 Channel Structure

The goal of the channel is for it to be able to transport messages from an application in one end, to a corresponding application in the other end. Since every modern packet optical transport protocol has a place for a general communication channel, GCC or DCC, in the overhead (see chapter 2.2.4), this is an obvious choice of a place for an embedded communication channel.

In this way, trac on the ECC channel will not have any theoretical contact with the payload trac sent by the customers. On the other hand it will have to share the GCC/DCC channel with other services. In Transmode's case, it would be PPP. By encapsulating application-specic messages or packets into an ECC channel, we are creating a channel carrying packets inside of the general communication channel able to transport application specic messages over GCC. One can say that there is three layers of communication channels to be observant about, as gure 6 is showing.

(26)

Application-specic messages can be seen as they are encapsulated in separate Application specic Communication Channels (ACC's). An ACC channel leads directly to a specic application. However this is a case for the application itself. Application specic packets may contain information about version, message identication and message length. The exact information that are needed depends on the application. It is the applications responsibility to encapsulate, decapsulate and handle the information in the ACC overhead. There is no dened maximum number of ACC channels that an ECC channel shall be able to carry.

The embedded communication channel is what is left. The ECC needs to be able to handle several applications, i.e. ACC channels, at the same time.

It also needs to be transparent to carry any application specic communication channel. An ACC ID eld in the ECC header allows for dierent ACC protocols to be multiplexed on the same transport channel. Further on, the ECC channel needs to be implementable within the GCC channel. This is a minor problem from a design point of view.

Figure 6: Channel structure design

3.2.2 Protocol design

A separate protocol for each channel is a necessity. However, the data from the ACC channel is, as described above, all handled by each application using the ECC channel. The data in the GCC/DCC channel is handled by the internal software, on the Linux kernel, before it arrives as an ECC message. Some managing software described below is then handling the ECC

(27)

messages.

The ECC shall oer transport between its termination points, at least one hop, and everything that this includes. It shall therefore also be able to validate the integrity of the content. A BIP-8 validation eld in the ECC protocol solves this problem. To be able to navigate to the correct ECC managing software, the most important mission, we have to add a VLAN tag and an Ether type. The VLAN tag will identify the ACC ID. The ether type will identify the type of embedded channel used, in case that other embedded channels are implemented in the future. The ether tag will be 0x6001 for the ECC channel. In case of new versions of this ECC channel, there is going to be a version number in the ECC header as well. This number is currently set to 1. The last part of the ECC packet shall be the message and the length of the message. The message length is limited to 1480 byte including a null character in case of a string input. Longer messages than that will probably not be sent at any time. If so would be the case, it is a good idea to divide the message into two or more messages instead.

ECC Format Baked into the GCC payload is an ECC packet that looks like this.

Version | Message ID | Counter | Source ID | Dest ID

Implementation This ECC protocol for communication within the ECC channel is implemented with the help of a specially designed structure, i.e. a so called struct in the C programming language. The payload length depends on the size of the ACC message, but is initialized to its maximum length for the sake of simplicity, 1480 bytes.

Code 1: The structure ecc_pack s t r u c t ecc_pack {

i n t vlan_tag ; // I d e n t i f i e s the ACC ID short ether_type ; // Ether type

char bip8 ; // V al ida tes the ECC message char v e r s i o n ; // Version number

(28)

short len ; // Number o f bytes in ACC message char acc_id ; // ACC message ( Protocol ) ID char ∗ acc_msg ; // ACC Payload

} ;

ACC messages, sent to and received from applications, may look like the following depending on the application.

Code 2: The structure acc_pack s t r u c t acc_pack {

i n t appl_id ; i n t len ; char ∗ msg ; } ;

3.2.3 Management Software Decision

The two solutions for a managing software process handling the ECC trac on a node are briey described in chapter 2.5. We will have to chose one of them.

Both solutions are possible to implement without further issues. The advantage of the rst one is that a separate unit handle the ECC trac instead of putting responsibility on the Linux kernel. This also reduces the dependency on the Linux kernel and would contribute to a more exible solution in the end. The second one minimizes the context switching and the copying making it both faster and more consistent. However, it puts more work and responsibility on the applications themselves.

To promote the modularity and avoid putting more functionality and responsibility on the Linux kernel, as on of the goals is to make a solution as general and as exible as possible, this project will implement the solution number one.

3.2.4 Subscription

Applications that want to use this embedded channel need to subscribe to the service. By calling a subscribe function, you get on a subscribers list and can start to use the service. This subscription feature is managed by the management software, the ECC driver. The list is also used for notify- ing applications about important updates about the channel and delivering incoming messages.

(29)

3.2.5 Implementation Tasks

The total implementation can be divided into the following tasks.

1. Implement an ECC-driver in TU, the main component of the ECC- channel

2. Connect the driver to the Linux kernel with the help of MAC-addresses and Ether types.

3. Implement a simple Path Trace application

The rst task means implementing the software process, ECC-driver, that handles all incoming and outgoing packets in the ECC-channel. The second task is to get this software process to communicate with the rest of the system through MAC-adresses and Ether types. The last task is a simple application, a Path Trace application, that can be run upon the ECC-driver and the ECC channel to later be able to prove that the ECC works as it is supposed to.

3.2.6 Software Management Flow

The process, course of events, of the software is the foundation of the software architecture. First of all, a new connection needs to be set up in order to be able to communicate with the outside world. Opening a new connection means setting up and listening to the right interfaces, when an open GCC channel is available. The next step is to handle incoming packets, strip them down and forward them to their destination application. The same thing applies to the other way around, while sending packets to the ECC channel.

ACC packets received need to be wrapped up and sent out on the ber.

The ECC driver can be implemented as a library in the existing software since it is only used upon request. In this way, it will get easy for users to

nd the driver whenever they want to.

When a call from the HW process to set up a new ECC channel is received, together with a MUX and a VLAN, a new socket i created, a new interface is created and ags are set to keep up the interface. When the set-up is nished, it will start a receiving process for data reception. The sending process will be intiated for every new send request. The set-up part and the sending part are a one time events, for each connection and request, while the reception process shall work continuously as long as the connection is up. A fourth part must handle the subscription for concerned applications.

By calling a subscription function with information about the desired ECC channel, an application shall get access to a send function that this application can use. When the channel is no longer used, there should be a way to

(30)

shut it down correctly. A function call to a clean up function may be used.

This function call has to be initiated by the HW process.

A main thread in the HW process may call the one time set-up function, setting up the connection and then create the continuous reception part.

A separate subscription function may handle the subscriber requests and notications. In conclusion, this gives us three main parts except for the starting set-up part.

Figure 7: Use case diagram

Below, the functions of this library are described. Further down, you can read more about the functionality divided into groups of driver, protocol and interconnection.

3.2.7 Functions

The ECC driver library is divided into several small blocks and functions that together forms the whole feature of this library.

new_connection() The rst function called when a GCC channel is available is the new_connection(). This function sets up a connection for ECC trac towards its corresponding node in the other end. It takes the desired HDLC MUX and VLAN interface as parameters, and thereafter sets up the interface in the OS, creating a le descriptor to write to and a sockaddr struct for internet addresses communication. The le descriptor and the sockaddr struct are passed on to the receiving function of the ECC channel.

close_connection() In the same manner as new_connection(), there is a close_connection() function that can be called by either the hardware

(31)

process or the new_connection() if something would go wrong. The function makes sure that all connections related to the specied VLAN are shut down correctly, removes the concerned interfaces and that the thread is killed.

subscribe() The subscribe() function is used by link-layer applications who wish to use the ECC channel service. By calling this function, they enable the option to send and receive packets to their corresponding application through the ECC channel to another node. They also subscribe to important status updates regarding the ECC, if the link goes down for example.

receive() This function manages the reception of packets over the ECC channel. It directs them to an unpack() function and hands the unpacked ACC message over to the correct application. The unpack() function divides the incoming packet of bits into its corresponding elds and stores them in variables. A check() function checks the overhead before the ACC message is delivered to an application. The BIP-8 eld are checked to a BIP-8 function in the nlib, see chapter 2.4. If there would be something unexpected, like an incorrect BIP-8 eld, the packet is discarded.

send() In contrast to receive(), the send() function aims to send packets from applications within the node to their corresponding applications through the ECC channel. It receives an ACC message and wraps this message into an ECC packet before sending it out on the ber. It uses the pack() function for wrapping up the application message. This is a function called by the application that wishes to send the message.

3.2.8 Parallellism

To be able to listen for incoming messages and go on with the normal program at the same time, some kind of parallelism needs to be implemented. There are two main options to consider when it comes to parallel programming, processes or threads. POSIX threads, also called Pthreads, is a standardized programming interface for threaded applications and is dened in the IEEE POSIX 1003.1c standard[21]. The dierences between threads and processes are that processes oers no shared memory nor resources when forking, those are completely isolated from each other. The same thing goes for the address space. Shared memory segments are not guaranteed to attach at the same virtual address in every process. Threads duplicates only the essential

(32)

resources that need to be independently schedulable. Those are registers, the stack and thread specic data.

3.2.9 Subscription

The subscription functionality is built up by linked lists. A handle is used to access the right list for a specic VLAN and port, ECC driver. By calling for the subscription function, the application puts its application ID together with a callback function in the linked list. The callback function is used when messages for the application are received by the driver and shall be forwarded to this application. It is also used when applications are notied by the ECC driver about the status of the ECC channel.

3.2.10 Start-up

When a GCC or DCC channel is opened, an ECC channel opens up au- tomatically. The ECC driver is subscribed to GCC channel updates and new_connection() is called with essential parameters when the HW process creates a new GCC. The HW process can, theoretically, also call to set up a new connection even when it is not in connection with a GCC channel set-up. After this start-up phase, applications can subscribe and start to utilize the channel.

3.2.11 Path Trace Application

This simple application whose only purpose is to prove the functionality of the ECC driver is developed as an external unit to work exactly as any other link layer application. The Path Trace application calls subscribe() and sends a small auto-generated message over ECC. The response that it gets is the same message as it sent. It also validates received messages so that it corresponds to the earlier sent message.

3.3 Conditions

To be able for this channel to work as intended, it supposes that the GCC is completely set up. It is also assumed that this GCC channel is set up correctly. Interfaces and similar connection-related parts do not need to be set up in advance. Another premise is that link-layer application knows how to subscribe and send messages and what parameters to use. For the ECC channel to work, it is assumed that another node is reachable in the other end that also has an implemented active ECC driver.

(33)

4 Results

The resulting outcome of the project is issued in this chapter. The objective of the acquired results is to prove the communication channel feasible by accomplish the stated goals. Another expectation is to nd the limitations of the ECC channel. First of all follows a description of the demonstration environment and procedure, then the test cases and at last the actual results will be presented.

4.1 Demonstration

The solution's feasibility was demonstrated and tested by setting up a realis- tic hardware environment and sending trac through an ECC channel as it would be used in a real environment. It was done in Transmode's laboratory room.

4.1.1 Set-up

The set-up used during the demonstration basically consists of two TU boards, loaded with the latest software, connected to each other through

ber cables.

The two TU boards are residing in subracks. They are of two dierent types, TPHEX100GOTN and MXP100GOTN. Each subrack also contains a CU board. The subrack's backplanes are connected to the network in order for us to access the node's GUI and monitor their activity and trac ow.

One of the TPHEX line ports is connected directly to the MXP's client port with a ber cable. The MXP line port is in its turn connected back to the same line port as in a loopback construction, RX to TX, also through

ber. An instrument for generating trac is connected to a client port of the TPHEX board. This instrument sends packets of random bytes to simulate real customer trac. Figure 8 shows a sketch of the set-up. Figure 9 shows the real hardware set-up with two trac unit boards connected to each other through ber cables. More pictures of the set-up and the hardware used can be found in Appendix A.

(34)

Figure 8: Sketch of hardware set-up

Figure 9: Two trac unit boards in dierent subracks connected with ber Both of the TU boards are updated with the latest Transmode software from the latest release (r25). In addition to this it contains the ECC driver, the simple path trace application developed in this project and the BIP-8 functionality in the library nlib. Noting else of value has been changed or added.

The trac is monitored using a computer with a shell connected to both TU boards through a Telnet session. This session is showing a command line

(35)

user interface, and is often used among the developers at Transmode. An example of what this interface looks like is shown in Figure 10. The ECC trac is initiated from the TU board, through the same Telnet session. In addition to this, all activity is logged with the help of Transmode's internal logging system, called te_log, to be able to see possible error messages that may appear. The simulated customer trac is controlled through the generator's own web interface as can be seen in Figure 11.

Figure 10: Telnet session connected to one of the TU boards

Figure 11: Trac generator interface

4.1.2 Procedure

A GCC channel and an ECC driver is created on both of the TU boards through their respective interfaces so that the ECC service becomes enabled.

After that, it is free for all applications to subscribe. We then let the path trace application subscribe with 254 as application id, a made-up id for path

(36)

trace applications. The path trace application then sends a message from one point to the other, and continues with the sending until the testing session ends. This will put load onto the ECC channel. To be able to prove the impact on real customer trac when the ECC channel is out on the market, there will be generated trac as mentioned above. This generated trac is not only monitored by a user web interface, but also validated in real time.

If the trac sent is not the same as the trac received, the web interface will notify us about the error.

We will use the well-known ping feature for trac congestion monitoring.

Ping measures the round-trip time and packet losses by sending two types of ICMP packets, one echo request and one echo reply. A ping contains an arbitrary amount of data together with the 20 byte IP header and 8 byte ICMP header[22]. 64 byte ping packets will be sent over PPP as any other kind of PPP trac, from CU to CU, over the PPP interface. The default values for TTL and seconds to wait for the rst response, 64 and 10 respectively, is kept.

A window of 20 measurements at each test run, i.e. 20 cycles of Ping, will be included in the results. One cycle of ping means the process of sending an echo request and then receiving an echo reply. 20 cycles should be enough to observe the eects of the ECC trac before it has nished and the neighbouring/customer trac ow goes back to normal. We are going to measure the response time in milliseconds and the number of lost packets, if any, caused by the congestion. The response time will show a relative delay in packet transmissions if the ECC trac is taking up to much space in the GCC. This will, in other words, give us a hint about the impact of the ECC trac on other services.

The bandwidth is calculated by sending a known, large amount of data through the ECC channel together with timestamps to determine the start and the end times. With the help of the dierence between them, we can calculate the bandwidth. In an ideal world, the bandwidth would be 0.49 as the theoretical bandwidth calculated in chapter 2.2.4.

4.2 Test Cases

The test cases will be used to explore the behaviour of the regular trac and the limits of a network using the ECC channel. At rst the ping will run alone in order to get a reference value. Then we will apply the ECC trac in dierent stages, described below. The same thing goes for when the generated customer trac is applied.

(37)

• 1. Simple ping

• 2. Simple ping w. ECC trac

• 3. Simple ping w. generated trac

• 4. Simple ping w. generated trac and ECC trac

Since there is not a way to nd out how big the load on the ECC channel actually is going to be when the channel is in use, the numbers for the test cases testing the channel during a regular ECC trac ow have been estimated by Transmode employees. We aim to get as close as possible to a real situation. During regular circumstances for ECC trac, the load can be estimated to around 10 packets containing 100 byte big messages at a time.

A conguration or a dual-ended protection application for example would use maximum 100 bytes per message. A path trace application would not need more than 16 bytes, and the same thing goes for a continuity check application, ICCC. If, however, one would want to be able to send a whole conguration to another node, up to 1 000 bytes might be needed. This is however not a probable case. The number of applications running during regular circumstances is estimated to 10. Since applications will not send more than one message at a time, the number of incoming packets to the ECC driver to send at the same time during regular circumstances can be estimated to be 10 as well. That the number of applications, or messages sent over the ECC channel, would exceed 100 is very unlikely. We are also interested in nding out the limits of the ECC channel. We want to know how much load that can be put onto the ECC channel before it causes a too big of an impact on the other services running in parallel. We will use the maximum size of a message, 1 479 bytes, combined with three very high number of packets sent, from 10 000 up to 1 000 000.

The size of the messages vary from 20 to 1479 bytes, as stated in table 3. 1479 bytes is the maximum number of bytes excluding null character that can be sent in a message as stated in the design chapter above. Note that this is message sizes sent to the ECC driver by an application and not ECC packet sizes sent on the channel. The total packet size is the message size plus 26 bytes of ECC overhead. The number of packets sent to the ECC channel by the test application vary from 10 up to 10 000 000, as stated in table 4. This will simulate the number of incoming packets to the ECC driver at the same time. An application will for most of the time only send one message at a time, so this can be seen as equal to the number of running link-level applications in parallel. A complete list of all the cases that are tested can be seen in appendix B.

(38)

Size Bytes

Small 20

Medium 100

Very Large 1 000 Top limit 1 479

Table 3: ECC message sizes to be tested Circumstances No of pkts

Standard 10

Busy 50

Very busy 100

Low limit 10 000 Medium limit 100 000 High limit 1 000 000

Table 4: Number of incoming packets to ECC driver to be tested 4.3 Outcome

Through the demonstration explained above, the following outcomes can be ascertained. The results have been divided into several graphs for the sake of clearness. See gure 12 below as an example. Every graph represents an ACC message size. The results in numbers can be found in appendix C. The results are presented in graphs in the subsections below. The labels of the lines indicate the load on the ECC channel. The rst number is the number of packets sent to the ECC driver which in its turn then forwards them out onto the ber. The second number is the size of the messages in bytes that the application has sent to the ECC driver. As mentioned earlier and as can be seen on the graphs, they are divided into dierent message sizes.

(39)

Figure 12: Ping performance aected by 20 bytes ECC messages In short, the results show that as many as 1 000 000 packets is never accepted to send at the same time regardless of how big the packets are.

The channel will be overloaded and unreachable. More than 100 packets at a time will have an impact on neighboring trac and should be avoided.

However, the trac in the ECC channel will never have an impact on the customer trac.

4.3.1 Without Customer Trac

First up is gure 12. The dark blue reference line (0x0), hidden behind the other lines, represents when there is no ECC trac at all in the ECC channel. That line keeps a steady state of 5.7 ms response time, which is the response time to expect when the ECC trac does not disturb the other services running.

Both 10, 50 and 100 requests to send 20 byte messages does not aect the neighbouring PPP trac. When sending a message of 20 bytes 10 000 times, we get a peak of 95 ms (i.e. 90 ms more than usual) before all packets has been sent through the ECC channel. Then it keeps on as normal. This is indicated by the rest of the line that shows a response time of 5.7 ms, just like the reference line that was steady on 5.7 ms when there were no trac

(40)

on the ECC channel at all. The same thing goes for when we send 100 000 packets, just a little bit higher response time. These two results show that congestion occurs for a short time when sending too many packets through the ECC channel. When increasing the number of packets to 1 000 000, the delay will continue for 8 cycles. What we can not see in the graph, but can be seen in the corresponding table (gure 13), is that the packet loss is huge before we return to the normal response time, 35 packets are lost.

What we also can not see is that at the eighth cycle, the network becomes totally unreachable for about 20 seconds. 1 000 000 messages of 20 bytes were clearly too much to handle for the PPP service.

Figure 13: Results in numbers. Change in neighboring channel response time when applying a load of 1 000 000 20-byte packets onto the ECC channel

Next graph, gure 14, shows what happens when we increase the size of the messages to 100 bytes. All of the three extreme cases (10 000, 100 000 and 1 000 000 packets) show a clear extra delay when ECC trac is initiated. The response time has increased remarkably compared to the 20 byte messages. A delay of an extra 100 ms has become 180 ms instead. A total number of 25 packets, spread all over the 15 ping cycles are lost at the last test (1 000 000 packets). At the 15th cycle, the network link can not take it any more and goes down again for about 20 seconds, just like it did in the previous graph.

(41)

Figure 14: Ping performance aected by 100 bytes ECC messages When increasing the packets size drastically, gure 15, we see that the response time increases even more. However, the number of cycles that it took before a test goes back to the normal state is very few. Again, the light blue 1 000 000 packets test looses packets in the beginning before it crashes, this time for around 30 seconds. 1 000 byte messages also aects the PPP trac response time when only 100 packets is sent. An extra delay of 260 ms is added when the ECC trac is initiated.

(42)

Figure 15: Ping performance aected by 1 000 bytes ECC messages The last test without customer trac, when maximizing the packet size, is shown in gure 16. Just like in the last case, the number of cycles that the PPP trac has aected are very few, but the response time in the rst cycle is very high. The green 10 000 packets curve is hidden behind the brown 100 000 curve whose values where very similar. Packets as few as 50 will now aect the delay of the PPP, just because of their size. This delay is notable.

(43)

Figure 16: Ping performance aected by 1 479 bytes ECC messages 4.3.2 With Customer Trac

Now, we apply customer trac to simulate a real environment with the help of the trac instrument. The dark blue reference curve in gure 17 is again at 5.7 ms, which indicates that this is its normal state even with generated trac.

The rst chart with 20 byte messages, gure 17, shows about the same response time as we got without the customer trac. The huge 1 000 000 packet test is an exception, since it does not crash the network link. It keeps the PPP trac delay on 105 ms while the ECC trac is active. The other test cases of 20 byte ECC trac are about the same.