Future Proof Access Networks for B2B Applications

Abstract

The paper offers an innovative approach for building future proof access network dedicated to Business to Business applications. The conceptual model of considered network is based on three main assumptions. Firstly, the authors present a network design based on passive optical LAN architecture utilizing proven Gigabit-capable Passive Optical Network (GPON) technology. Secondly, the new business model is proposed. Finally, the major advantage of the solution is an introduction of Software-Defined Networking paradigm to GPON area. Thanks to such approach network configuration can be easily adapted to business customers' demands and needs that can change dynamically over the time. The proposed solution provides a high level of service flexibility and supports sophisticated methods allowing users' traffic forwarding in efficient way. The paper extends a description of the OpenFlowPLUS protocol proposed in "Towards networks of the future: SDN paradigm introduction to PON networking for business applications" in Computer Science and Information Systems. Additionally it provides an exemplary logical scheme of traffic forwarding relevant for GPON devices employing the OpenFlowPLUS solution.

Headnote

Keywords: SDN, GPON, Optical LAN, B2B

Received: December 10, 2013

The paper offers an innovative approach for building future proof access network dedicated to B2B (Business To Business) applications. The conceptual model of considered network is based on three main assumptions. Firstly, we present a network design based on passive optical LAN architecture utilizing proven GPON (Gigabit-capable Passive Optical Network) technology. Secondly, the new business model is proposed. Finally, the major advantage of the solution is an introduction of SDN (Software-Defined Networking) paradigm to GPON area. Thanks to such approach network configuration can be easily adapted to business customers' demands and needs that can change dynamically over the time. The proposed solution provides a high level of service flexibility and supports sophisticated methods allowing users' traffic forwarding in efficient way. The paper extends a description of the OpenFlowPLUS protocol proposed in [18] . Additionally it provides an exemplary logical scheme of traffic forwarding relevant for GPON devices employing the OpenFlowPLUS solution.

Povzetek: Prispevek uvaja nova omrezja B2B z zajamcenim dostopom.

1 Introduction

In recent years one can observe skyrocketing of Internet traffic (its growth is exponential) as end users are consuming more and more Internet services (e.g. video or cloud based solutions). Growth is visible for all types of access, especially mobile but also fixed (fixed still account for vast majority of traffic). The situation is often highlighted by telecommunications providers but also organizations like enterprises, universities, governmental entities have to deal with high growth.. At the end many institutions have to adapt and bolster their traditional IT and network infrastructure in order to handle that phenomenon and to provide needed services and solutions More and more aspects of economy and our life is dependent on Internet thus assurance of quality and reliability as well methods to deal with its growth is crucial.

In the following chapter the overview of legacy campus networks, typically used by institutions, is given. Also LAN (and WAN access) solutions provided to business customers are described.

1.1 Office networks overview

Nowadays access to Internet is prevalent among companies. Moreover many enterprises have own intranet used for number of different purposes. In order to provide connectivity to end devices likes PC, laptops or tablets in-building network infrastructure is needed. It can be composed of a single modem/router but also tens of devices and substantial amount of transmission medium (optical fibers, twisted pair cables etc.). In case of big organizations all those components form a campus network - computer network interconnecting LANs (Local Area Networks) within a limited geographical area. The infrastructure is usually owned by campus owner / tenant e.g. enterprise, university, hospital.

Early LANs were large, flat networks with peer to peer Layer 2 (L2) communication based on Ethernet standard [4] . It was a simple approach but with network continuous growth ultimately led to dismptions (e.g. due to broadcast storms). Over the time Layer 3 (L3) has been introduced dividing campus network into smaller segments (allowing avoiding such problems). Additionally numbers of different solutions like VLANs (Virtual LANs [5] ), RSTP (Rapid Spanning Tree Protocol [6] ) or IP subnets have been developed making campus networks easier to maintain and manage, but with the cost of additional complexity

Also the topology evolved towards more hierarchical and structured design. 4-tier network architecture (see Figure 1) lias become coimnon ([8] , [10] ). In that approach access layer provides connectivity to end devices with copper twisted pairs (usually UTP CAT. 5 - Unshielded Twisted Pair Category 5, nowadays also CAT. 6 cables are gaining popularity). Fast Ethernet or Gigabit Ethernet (100BASE-TX or "lOOOBASE-T [4] ) are commonly used. Access layer contains multiple L2 switches (usually managed and configurable). They are located nearby users, e.g. in communication closets on each floor of the building. At the next level additional switches aggregate traffic for each building (concentrating multiple access layer switches and providing access to higher levels equipment) Interconnection between access layer switches and building aggregation switches can be provided with copper cables, or with fibers. Building aggregation switches are connected to campus aggregation and distribution switches which then connect to router (or routers being a gateway to external networks). As a transmission medium for interconnecting building aggregation with campus aggregation segments fiber optic cables are often used due to higher bandwidth requirements (i.e. 10 GbE interfaces) and longer distance.

Tiered network design gives flexibility in terms of supporting numerous functions and plethora of end devices (for example growth of client population can be accoimnodated by adding access layer switches, but that approach is costly). The logical division for different layers does not need to be done with physical tiers; access and aggregation can be provided on the same equipment. It can be especially useful in case of smaller campus simplifying management of reduced number of devices [9] . However such approach requires equipment supporting, in many cases, complex functions as well as some expertise for design and configuration (meaning additional costs).

Important to note is fact that legacy Ethernet-based campus networks have significant limitations. Maximum length of copper Ethernet cables is restricted to 100 meters. In fact 4-tier topology with switches on each floor is an answer to that drawback. Ethernet LAN requires a cable connection to every single user port. Tliis means significant number of access layer switches and wires (copper cables) and at the end it results in high costs. High-frequency signals (used for Fast and Gigabit Ethernet) require more sophisticated copper cable constructions which are physically larger than for lower frequencies (necessary to avoid signal disturbances). In consequence the space required for racks, communication closets is significant. Crucial amount of heat is produced (in many cases requiring additional air conditioning), power consumption is high. Management of high number of active devices is not easy. For those reasons legacy Ethernet LAN is not always the best answer for campus network requirements. That is why an important issue is to find a more effective approach for office networks infrastructure. It especially relevant nowadays when all companies are seeking savings also in IT costs but requirements are getting higher and higher due to the importance of network and IT for business.

1.2 Scenarios for B2B services

B2B (Business to Business) telecommunications services' landscape is diverse. It includes services like Internet access, POTS (Plain Old Telephony Service), VoIP (Voice over IP), dedicated links, VPN (Virtual Private Network), etc. One can distinguish large (Enterprise), medium (SME - Small and Medium Enterprises) and small (SOHO - Small Office Home Office) market segments. However service overlapping (the same services) is possible, but often there are special offers for different segments.

Services' requirements largely depend on type of customers. Big entity owning campus network (and considerable number of network equipment) has other needs than company with small branches scattered around the country (and with lack of its own interconnection) and than small company located in single office building.

For entity with campus network usually telecommunications operator provides its services to location where campus edge router is placed, further propagation is the responsibility of the entity itself (compare Figure 1). In the second case (several branches) it is important to provide secure interconnection among branches.

For office building, in which many companies are located, there are two most common infrastructure scenarios (see Figure 2). First one is based on existing copper CAT. 3 cables which reach customers' desk / office and can be reused by telcos. Modem or router is the termination point of the services (Figure 2 Scenario A).

In the second scenario office building has infrastructure based on active Ethernet LAN with copper cables CAT. 5 (Figure 2 Scenario B). Telecommunications operators need to provide its interconnecting cables up to building's technology room. Separation of services / between different operators can be provided on logical level e.g. by means of VLANs.

For both scenarios the only responsibility of telco is to somehow access business customers. Herein, one could think of a new role for operators targeting office buildings environment: what added values are possible to be identified if telcos take the responsibility of building and administrating the entire in-building office network?

2 Optical LAN

Optical LAN is a new approach for office networks infrastructure and an answer to limitations of legacy Ethernet LANs. All-fiber LAN interconnecting existing Ethernet end devices allows reducing costs and making the network more reliable and future proof.

Proposed solution is based on GPON [1] . It is standardized, well known and widely adopted telecommunications access technology, used by many operators worldwide with millions of end customers. GPON uses point-to-multipoint topology and employs fiber optics as a transmission medium. As a real passive solution - no active equipment is used in-between GPON Access Node: OLT (Optical Line Termination) and line termination at customer side: ONT (Optical Network Termination). The campus network based on Optical LAN number of active equipment is significantly reduced comparing to traditional LAN scenarios. From OLT GPON port a single strand of fiber goes out to a passive optical splitter(s) which splits the signal onto fibers terminating at up to 64 (or even 128) ONTs (see Figure 3). All the fibers, splitters connected to one GPON port on OLT form a GPON tree. ONT device terminates GPON transmission and provides 10/100/1000-BaseT Ethernet connectivity to desktop equipment such as PC computers, laptops, voice over IP phones, and video phones using regular copper patchcords (or by 802.11 WiFi). ONT can be located on customer's desk (ONT per desk) or in office closet (ONT per office). Those two options are called respectively: Fiber-to-the-Desktop (FTTD) or a Fiber-to-the-Communications (FTTC) room. High flexibility of Optical LAN solution allows reusing existing copper infrastructure in buildings (for example GPON access is terminated on ONT located in the floor communication closet, from where existing copper cables are used up to customer's desk, see Figure 3 - Floor #2).

Thanks to fiber optics-based transmission Optical LAN is a long reach access solution - maximum reach is equal to 20 km in a standard mode. It is a tremendous improvement comparing to traditional copper Ethernet (100 m.). It allows placing OLT in distant locations, giving high flexibility in network design (in case of campus network OLT no longer need to be installed in the same building in which customers reside).

GPON technology assures 2.488 Gbps of downstream bandwidth and 1.244 Gbps of upstream bandwidth. Bandwidth is shared among customers connected to the same GPON tree. Advanced GPON QoS mechanisms assure appropriate bandwidth distribution among many users and different applications. In the future even higher bandwidth will be available with next generation of GPON standard. It will require exchange of end equipment (ONT and OLT) but with preservation of fiber optics.

Optical LAN solutions are present in portfolio of several vendors (e.g. Motorola [11], Tellabs [12], Zhone [13] ). According to vendors estimations introducing of Optical LAN will reduce power consumption by up to 65%, space requirements by up to 90%, capital costs related to network elements by up to 74% [13] . Optical LAN is seen as a new paradigm in campus networking allowing optimization of investments and at the same time improving overall efficiency of the networks. Advances in Optical LAN and size of potential market leaded the main players to start standardisation efforts in order to get even higher adaption and better interoperability. As so one can expect that Optical LAN in the future become important contender for Ethernet.

3 FutuFutu proof access networks for B2B

In tliis chapter we formulate three postulates (see Figure 4), which are, from our perspective, cmcial for deploying future proof access networks for business applications:

3.1 Applying Optical LAN concept

Currently Optical LAN vendors target big entities with large campus networks. In typical deployment Optical LAN is used by only one organization - the owner and the administrator of the campus network. Office buildings with many tenants, each of them having its own LAN network (at least up to some point) are not yet addressed.

In tliis paper we propose a solution to that deficiency. It is based on concept known from telecommunications world where many customers are connected to the same Access Node (different users served on the same equipment). In our proposition enterprises no longer need to operate any active network equipment or to build networks itself. LAN becomes a service, provided in similar fashion as e.g. Internet access. LAN service provider is responsible for service creation, administration and adjustment according to needs of customers (enterprises using LAN). That also means that network infrastructure is built for offices by LAN service provider. In fact such network is similar to GPON access networks used by telecommunications operators to provide services to its customers. For B2B scenario different customers are also served by the same GPON OLT unit.

3.2 A new business model

Telecommunications operators are well positioned to play the role of Optical LAN service providers. Usually they have necessary experience with GPON technology, operational resources and existing access network. Telcos are able to deploy optical fiber LAN in office buildings and to provide flexibility in management, service creation and administration.

Such approach has many advantages in terms of optimal usage of network resources. Single OLT can be used for several buildings, even if they are located in distant areas (due to long reach offered by GPON technology which capabilities in terms of maximum physical reach are not fully used in current optical LAN implementations). Also interconnection of distant branches becomes easier (in specific cases they can be served by the same OLT). Additionally a new type of services can be introduced called Office LAN services: e.g. on-demand LAN connections between companies located in the same building, access to in-building monitoring system, etc.

Tliis novel approach also creates a new business model for telecommunications companies who become Optical LAN operator (builder and administrator). The main assumptions for such model are as follows:

· a telco company signs a contract with a building owner for building a complete office network based on Optical LAN solution (it covers all passive components like horizontal and vertical ducts, optical fibers, splitters, in-building Optical Distribution Frame, etc.); additionally copper CAT.5 infrastructure for office rooms (ducts, copper cables, sockets, connectors) can be built by telco company it does not exist in the considered building

· a telco company is responsible for administration and maintenance of the network

· business companies that rent space for their offices in the building sign contracts with a telco company for providing them with telecommunications services

· business customers are given GPON ONTs which are installed in their offices, ONTs are connected to OLT (which is typically located in distant Central Office owned by telco company)

· telco company offer is assumed to cover wide range of services which can be optimized for particular B2B customers

· tenants that do not decide to be provided with services by telco company are also connected to Optical LAN-based in-building network (via ONTs which they are also given), they are free to be served by other telcos or service providers that establish a connection to considered OLT from their own networks - in such cases services' related traffic is transported in dedicated logical "channels" (e.g. in the sense of VLANs) over the considered optical access network

Tliis opportunity to find new B2B market seems to be a good argument in convincing telco players to work on such solutions.

3.3 User-centric flexible network (based on SDN)

Another assumption for the presented approach is that it is based on user-oriented access network design. Service portfolio dedicated to business customers is typically more complex than the one for residential users. For business applications customized services need to be taken into account. Moreover, customer demands can change dynamically over short periods of time. That is why a challenge for networks deployed in business environments is to provide a high level of service flexibility and to forward user traffic in efficient way. To meet those requirements we present in this paper an access network architecture based on SDN (SoftwareDefined Networking) paradigm which assumes data plane and control plane abstractions separation ([16] ). Thanks to such approach network devices become programmable units. In practice it means that network configuration can be easily adapted to the fast-changing needs.

4 SDN-based GPON solution for business applications

In order to introduce SDN paradigm to GPONs area one can propose different methods to accomplish that. One of the possible ways would be to develop a brand new protocol allowing GPON devices to become programmable units. Such approach is supposed to be an appropriate one for designing an optimal logical architecture of OLT and ONT in the scope of data processing and forwarding. However, development of generic SDN-based protocol for GPON would require a lot of standardization efforts and probably it would take a few years to obtain a solution being ready for deployment.

In this paper we present another approach. We propose a solution based on OpenFlow ([16] ) which is the most widely deployed SDN-based protocol. OpenFlow Switch architecture consists of at least three parts ([15] ) - see Figure 5:

· Flow Table(s) - a structure within switch implementation covering actions associated with each flow entry; the Flow Tables define the ways of how the traffic flows have to be processed by the switch

· Controller - an external unit running a remote control process that manages the switch via the OpenFlow protocol; the Controller can add, remove and update flow entries from the Flow Table(s)

· OpenFlow Channel - a channel which enables a communication (i.e. sending packets and coimnands) between the Controller and the switch

For a more detailed description of OpenFlowspecific logical components and functions please refer to [15]·

OpenFlow was originally designed for L2/L3 switches (or routers) equipped with native Ethernetbased physical interfaces. That is why it is important to notice that it is useless to implement pure OpenFlow in GPON OLTs and ONTs. The reason for that is simple: although GPON effectively carries Ethernet frames, in practice it operates at Layer 1 (according the OSI model) with its own dedicated framing and GEM (GPON Encapsulation Method) protocol used for encapsulation higher-layer Protocol Data Units (e.g. Ethernet frames) into GTC (GPON Transmission Convergence) layer. The above mentioned specification of OpenFlow protocol does not support such kind of non-Ethernet-based physical interfaces. That is why some additional GPONrelated functions have to be introduced to OpenFlow.

4.1 GPON-specific traffic instances

A single logical connection within the GPON system is called GEM Port and it is identified by GEM Port-ID. A GEM Port can be considered as a channel within GTC layer and is capable to transport one or more traffic flows. In the upstream direction GPON system also utilizes T-CONTs (Transmission Containers) corresponding to allocated timeslots within TDMA multiplexing existing in GPON. Each T-CONT represents a group of logical connections (GEM Ports) that appear as a single entity for the purpose of upstream bandwidth assignment on the PON (see Figure 6 - GPON-specific traffic entities identifiers are pointed in brackets).

Each T-CONT can be seen as an instance of upstream queue with a certain bandwidth profile (a set of bandwidth parameters). The bandwidth assignment model applied in GPON system effectively introduces a strict priority hierarchy of the assigned bandwidth components ([2] ):

· fixed bandwidth: with highest priority

· assured bandwidth

· non-assured bandwidth

· best-effort bandwidth: with lowest priority

Five T-CONT types which are defined by ([2] ) are presented in Table 1.

Each T-CONT instance is associated with a bandwidth profile. Bandwidth profile is described using the traffic descriptor, which lias the following components ([2] ):

· fixed bandwidth RF (bandwidth that is reserved exclusively for a given T-CONT and no other T-CONTs can use it; this bandwidth is statically allocated to a T-CONT)

· assured bandwidth RA (bandwidth that is available for a given T-CONT on demand; this bandwidth is guaranteed)

· maximum bandwidth RM (maximum amount of bandwidth, that can be allocated to a given T-CONT on demand; this bandwidth is not guaranteed)

· additional bandwidth eligibility χAB (type of additional bandwidth that a given T-CONT is eligible to get, can have the following values: none - no additional bandwidth, NA - non-assured bandwidth, BE - best-effort bandwidth)

Depending on the traffic type (latency-sensitive traffic, data transmission, etc.) the most appropriate T-CONT type should be selected to cany considered traffic flows. For instance, T-CONT type 1 characterized by fixed bandwidth component (RF) only is dedicated to carry fixed-rate traffic which is sensitive to jitter or delay (e.g. ToIP traffic). Such kind of bandwidth is the only one which is allocated statically. In practice it means that it is reserved and always fully available for ONT for which mentioned T-CONT instance was created. Other T-CONT types (from 2 to 5) have to respect the volumes of bandwidth which they are assigned by DBA (Dynamic Bandwidth Allocation) algorithm. This mechanism takes a control over the bandwidth assignment within the entire PON tree. T-CONT type 2 is characterized by the assured bandwidth component (Ra) only and can be utilized for on-off type traffic with well-defined rate bound having no strict delay or jitter requirements. T-CONT type 3 is characterized by assured bandwidth component as well. Additionally it is supposed to be included in non-assured bandwidth sharing. It is suitable for carrying variable-rate traffic with requirement of average rate guarantee. T-CONT type 4 is assumed to participate only in best-effort bandwidth sharing. It is dedicated to carry variable-rate bursty traffic without strict delay requirements. T-CONT type 5 can be considered as a consolidation of other T-CONT types. It can be utilized for wide range of traffic flows [2] . It is worth noting that above described traffic-type-related applications for T-CONTs should be considered only as general recoimnendations, expressed in [2] . However, it is possible to use a T-CONT of particular type for different sort of traffic flows. Still, it is important to take into account that the T-CONT type specifies capabilities and limitations of the T-CONT instance and thus not all kind of traffic will be appropriate for it.

Upstream user traffic (Ethernet frames) is encapsulated into GEM Ports and then into T-CONTs. Each GPON ONT uses its own set of T-CONTs and GEM ports, a unique one within a GPON tree which ONT belongs to. A single GEM Port can be encapsulated into only one T-CONT, however a single T-CONT may encapsulate multiple GEM ports. In downstream direction only GEM Ports are used to carry traffic flows since no TDMA multiplexing exists there and thus the notion of T-CONT is not relevant for GPON downstream transmission. For a more detailed explanation please refer to [2] .

As described above one of the key aspects of GPONbased network applications is to ensure effective traffic forwarding on the GTC layer. Traffic incoming from end users (upstream) and "from the network" (downstream) should be carried over passive optical network making use of the capabilities offered by this layer. In practice it means that a significant number of GTC-related traffic instances (GEM Ports and T-CONTs) should be utilized globally within the entire PON tree, especially if a high level of traffic diversity is assumed. By applying such approach it is possible to gain the following advantages:

· separation of traffic flows corresponding to different applications (by using multiple GEM Ports)

· improving QoS performance in upstream (by using multiple T-CONTs)

Thus, such approach improves security and QoS performance in the PON. In order to make it possible it is important to define appropriate rules (consistent and unambiguous ones) allowing to map traffic flows incoming from users to appropriate GEM Ports. In most of commercial implementations mapping rules "built-in" GPON ONTs are mo no-criterion i.e. mapping is based on only one of the following criteria like: VLAN ID (Virtual LAN identifier), p-bit ([5] ) or UNI (user port number on ONT). For some cases also double-criterion combinations of aforementioned parameters are available (e.g. VLAN ID + UNI) for the mapping purpose. Since GPON was originally designed for B2C (Business to Customer) market segment for which only Triple-Play (Internet, ToIP and IPTV) services are considered such approach was sufficient. For business applications where not only service portfolio is more complex but also customized services are taken into account, much more sophisticated methods (i.e. mapping rules) are required in order to ensure effective traffic forwarding through the system ([14] ). In most scenarios currently deployed GPON ONT with limited set of hardcoded mapping and forwarding functions would not be able to address such needs. In such cases software upgrade is needed but it leads to higher operational costs - especially if business customer demands changes dynamically and it is possible that new set of functions is required. For such a scenario multiple software upgrades have to be taken into account.

4.2 SDN-based protocol for GPON

The solution for the issue is SDN-based protocol for GPON allowing OLT and ONT to become programmable units. In this paper we propose OpenFlow -based solution. As mentioned before the current specification of OpenFlow protocol does not support GPON natively. That is why our vision is to introduce GPON-related functions to the specification in order to develop a protocol extension which we called OpenFlowPL US.

The main assumption for the OpenFlowPLUS is that it inherits all the functionality, architecture and capabilities of original OpenFlow. The essential improvement is an introduction of GPON-related functions to the protocol in terms of traffic forwarding in order to make the solution relevant also for GPON technology.

According to OpenFlow Switch architectural assumptions each device (OLT, ONT) within considered GPON tree contains Flow Table(s) and communicates over a OpenFlowPLUS Channel with remote Controller via OpenFlowPLUS protocol (see Figure 7).

For that purpose OLT and ONTs are supposed to have IP address configured. Since Controller and OLT are assumed to be connected to IP/Ethernet network they can establish L3 connection. ONTs are accessible by Controller only via OLT. One could take advantage of that and for the purpose of OpenFlowPLUS messages exchange between ONTs and Controller make use of GPON-specific mechanisms defined by [3] . In such a scenario protocol messages are transported through the PON via a dedicated OMCI (ONT Management and Control Interface) channel towards OLT and then they are sent directly to the Controller using OLT's OpenFlowPLUS Channel. Obviously, employing OMCI by OpenFlowPLUS for some new applications does not mean that the protocol takes the control over the entire GPON system. All functions which are out of the scope of traffic mapping and forwarding (e.g. ONT discovery and provisioning-related functions, Dynamic Bandwidth Allocation mechanism, optical layer supervision, alarms and performance monitoring etc.) are assumed to be realized in traditional way, i.e. in line with recommendations defined in [2] and [3] . The physical layer and access network topology remains the same. Each ONT (being a termination of optical network) is installed in customer premise. ONT aggregates traffic incoming from different end devices (PCs, laptops, ToIP phones, servers, etc.) and encapsulates Ethernet frames originated from office LAN into GEM frames. Mapping to GEM Ports and T-CONTs is executed in FlowTable based on sophisticated rules provided by OpenFlowPLUS protocol. The upstream traffic is sent to OLT using GPON uplink interface. OLT takes a control over the entire PON tree and it is responsible for making the whole system functions working properly. In the scope of GEM-based forwarding OLT assigns unique set of GEM Port and T-CONTs (corresponding to timeslots of TDMA) to each ONT which is connected to the PON. The traffic received from ONTs is forwarded towards other network segments (e.g. towards aggregation network routers) based on the flow entries existing in OLT FlowTable. The downstream transmission is supposed to be realized in similar fashion, i.e. making use of FlowTables implemented in OLT and ONTs. The important difference as compared to upstream is that in downstream no T-CONTs are used since TDMA does not exists there. That is why traffic incoming "from the network" starting from OLT is encapsulated only in GEM-Ports as the only GTC layer-related traffic instances utilized for the purpose of downstream transmission.

Taking into account above mentioned assumptions an optimal approach seems to be adding OpenFlowPLUS controller as a functional module to the standard EMS (Element Management System) managing the system. Such solution would allow to manage the PON using single management entity. However it is important to stress that integration of GPON technology with OpenFlowPLUS protocol requires some efforts in the areas which are much wider than system management aspects. The implementations of OpenFlowPLUS-based OLT and ONT will differ from the traditional ones since OpenFlowPLUS introduces a different way of traffic forwarding. That is why a logical architecture of OLT and ONT is supposed to be modified in the context of invoking traffic forwarding functions. In other words OpenFlowPLUS logical components implemented in GPON devices have to be able to "communicate" with GPON-layer control plane.

As mentioned before the idea of OpenFlowPLUS is to provide GPON-related functions to the protocol in terms of traffic mapping and forwarding. Similarly to original Open Flow, OpenFlowPLUS is assumed to use Flow Table(s) which perform packet lookups, modification and forwarding. Each Flow Table contains multiple flow entries (see Figure 8). Each flow entry contains ([15] ):

· match fields - to match against packets; match fields include packet header fields (e.g. VLAN ID, MPLS label, IP destination address, TCP source port, etc.) and ingress port (optionally also metadata that pass information between tables can be used)

· priority - determines an order in which flow entry is matched against packets

· counters - which can be maintained for each port, table, flow, etc; counters are updated when packets are matched

· instructions - set of operations which are executed when a packet matches a flow entry

· timeouts - specify amount of time before flow is expired by the switch

· cookie - a field reserved for controller in order to modify or delete flows or to filer statistics; it is not used during packet processing

· flags - they impact the way flow entries are managed

Instructions define the ways of how single action is processed. Actions represent operations of packet modification or forwarding to the specified port. Actions are grouped by different action types, for instance pop action type (e.g. pop VLAN header action), set action type (e.g. set MPLS traffic class action), etc. Instructions executed during OpenFlowPLUS pipeline processing can either add appropriate actions to the current action set (a set of actions that are accumulated when the packet is processed by the tables and that are executed after exiting the processing pipeline by the packet), or force some actions to be applied immediately. OpenFlowPLUS defines new actions which are relevant to GPON technology. The considered functions are presented in Table 2.

OpenFlowPLUS introduces a brand new action type called gpon related to GPON-specific mapping methods. The considered action type provides two actions: Map to GEM Port action which represents an operation of mapping Ethernet frames to particular GEM Port instance and Map to T-CONT action which represents an operation of mapping GEM Ports to particular T-CONT instance. Additionally the new functionality for original OpenFlow output action is supposed to be supported: when a packet is destined to be forwarded to the GPON port, GTC framing is performed for the packet before exiting the interface. The aforementioned protocol improvements are the main GPON-related forwarding and mapping functions provided by OpenFlowPLUS.

4.3 Use case

In this section we present a possible application for SDN-based GPON concept which is proposed in the paper. The following assumptions are made for the considered use case:

· the solution is dedicated to business customers who reside in office buildings

· operator acts not only as a service provider but is responsible also for administration of in-building network

· in-building network is based on Optical LAN solution

· different service types can be offered (the considered traffic flows are listed in Table 3):

o Internet access,

o ToIP (telephony over IP),

o Metro Ethernet (corporate connections),

o cloud computing-based services,

o office LAN services

· access network architecture is based on OpenFlowPLUS GPON solution (see Figure 9)

Each office in the building is connected to the optical network via its dedicated ONT installed in customer premise. Copper cables terminated with RJ-45 sockets are deployed in office rooms. Each user device (PC, IP phone, application server, etc.) is connected to one of multiple Ethernet LAN ports which ONT is equipped with (see Figure 10). ONT aggregates the entire traffic incoming from user terminals (this traffic is in general assumed to contain no VLAN tags) and provides the functionality of L3 gateway. Public IPv4 addresses are assigned to ONT ([email protected]) and to some selected user devices: web-based application server - [email protected] and intelligent installation system controller - [email protected]. For other devices private addressing is used (IP@priv). ONT is supposed to act as an internal DHCP server for that purpose. Any kind of additional CPE (Customer Premise Equipment) acting as a BGW (Business Gateway) is not required in the considered network.

Thanks to applying OpenFlowPLUS, sophisticated mapping mies are supported in order to ensure effective traffic forwarding through GPON. As an example we show how match fields with corresponding instructions can be defined for flow entries within ONT Flow Table. To avoid complexity description of forwarding is limited to traffic flows transmitted in upstream direction (see Table 4 and Figure 10). The idea of traffic forwarding is as follows:

1. Traffic flows (packets) incoming from different end devices enter ONT Flow Table

2. ONT performs a table lookup. Packet match fields (which typically include various packets header fields) are extracted from the packet and then it is matched against the ONT Flow Table. Each flow entry in the table is uniquely identified by match fields and priority taken together. During matching operation only flow entry with the highest priority (from those which match the packet) can be selected.

3. For the selected flow entry instructions are executed. In particular packet modification actions are applied in the first step, e.g. Push VLAN header, Set VLAN ID, Set IPv4 ToS bits, etc.

4. Next GPON-specific actions are executed, i.e. Map to GEM Port and Map to T-CONT that correspond to the operation of mapping user traffic flows (packets) to GPON-related traffic entities

5. Finally output action is applied which terminates OpenFlowPLUS processing pipeline and invokes further packet processing based on the mechanisms defined for GPON technology (GTC framing, allocation to dedicated timeslots, etc.)

Based on the user traffic to GPON-specific instances mapping methods (using limited set of parameters like VLAN ID, pbit, UNI) which are currently supported in typical coimnercial implementations it would be very difficult or even impossible to follow the traffic forwarding model presented in considered use case. For instance, applying traditional approach it would be impossible to map traffic flows F#1 and F#3 to different GEM Ports if they originated from the same end-device. Moreover it can be expected that the traditional approach:

· would require additional CPE (some kind of L3 Business Gateway - BGW) if standard L2 aware GPON ONT is used

· would introduce VLANs or even additional L2 switches (in some cases) to customer network

· would attach most of end devices to particular physical ports on L2 switches, BGW, ONT

· would partition customer network into "service domains" (e.g. in the sense of VLANs), it may lead to the situation that not all services are available for single end device

All above mentioned aspects make the traditional approach more expensive (more devices), more complex (more devices and more VLANs) and less flexible (fixed connections in customer network, limited set of available services per end device) On the other hand the proposed OpenFlowPLUS-based GPON solution is very flexible and convenient from customer perspective. Moreover, since it is assumed to be a programmable system its configuration can be easily adapted to support immediately new services and business needs once they appear.

It is important to stress that considered scenario is only example case for traffic forwarding realized in the sense of OpenFlowPLUS protocol. Here, for the sake of simplicity, only one Flow Table is used as well as simplified instructions scheme is proposed. However, for real deployment more advanced mechanisms can be applied like pipeline processing based on multi Flow Table entities. Also much more complex and sophisticated actions can be defined for traffic flows. The example of forwarding considered in this section is limited only to upstream forwarding for ONT (towards OLT). Obviously, the complete forwarding model for the entire system is supposed to cover:

· upstream forwarding for ONT (towards OLT)

· downstream forwarding for ONT (towards customer network)

· downstream forwarding for OLT (towards ONTs)

· upstream forwarding for OLT (towards aggregation network)

Presented access network model supports also openness for TPOs (Third Party Operators) what is typically required by country-specific regulations. Each customer served by TPO connects a dedicated CPE (which he/she was given by the TPO) to the OpenFlowPLUS-based ONT. For such application ONT provides only a basic functionality, i.e. it is configured to work as a traditional L2 bridge (equipped with GPON uplink) that passes assigned VLAN(s) through the system up to the first TPO's switch or router (see "office #2" in Figure 9) interconnected to primary operator's network. It is clear that in such case most of advanced forwarding functions offered by OpenFlowPLUS would not be available for such customer. However, it is important to note that it is not a matter of any technology limitations. It is rather a decision of primary operator who would offer "exclusive" features only for its own customers. Nevertheless, such customer always can change the telco company which he/she is served by. In particular the customer can leave the TPO and join primary operator's customers base. In this way he/she would be able to make use of the full range of features offered by OpenFlowPLUS-based solution.

5 Conclusion

In the paper we presented a novel approach to deploy optical access networks addressed to B2B market segment where we defined a new role for telcos. The major advantage of our solution is its flexibility thanks to introduction of SDN paradigm to GPON-based networking. We believe our work can be considered as a conceptual framework for further analysis and solution development.

References

ReferencesReferences

[1] ITU-T Gigabit-capable Passive Optical Networks (GPON) : General characteristic, ITU-T G.984.1, 2008.

[2] ITU-T Gigabit-capable Passive Optical Networks (GPON) : Transmission convergence layer specification, ITU-T G.984.3, 2008.

[3] ITU-T Gigabit-capable Passive Optical Networks (GPON) : ONT management and control interface specification, ITU-T G.984.4, 2008.

[4] IEEE Carrier Sense Multiple Access With Collision Detection (CSMA/CD) Access Method and Physical Layer Specification, IEEE Standard 802.32008, 2008.

[5] IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks, IEEE Standard 802.1Q-2011, 2011.

[6] IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges, IEEE Standard 802.1D-2004, 2004.

[7] FTTH Council Europe, FTTH Handbook, Edition 5, 2012.

[8] Cisco Systems. (1999). White Paper, Gigabit Campus Network Design - Principles and Architecture [Online]. Available: http://www.cisco.com/warp/public/cc/so/neso/lnso/ cpso/gcnd_wp.pdf

[9] Brocade. Designing a Robust and Cost-Effective Campus Network [Online]. Available: http://www.brocade.com/downloads/documents/des ign-guides/robust-cost-effective-lan.pdf

[10] S. T. Karris, Networks Design and Management. 2nd ed. Orchard Publications, 2009.

[11] Motorola. (2012). White Paper, Creating Simple, Secure, Scalable Enterprise Networks using Passive Optical LAN [Online]. Available: http ://moto. arrisi. com/staticfiles/Video - Solutions/Solutions/Enterprise/Passive-OpticalLAN/_Documents/_Staticfiles/WP_POL_Creating Networks_365-095-20298-x. l.pdf

[12] Tellabs. (2011). How Enterprises Are Solving Evolving Network Challenges with Optical LAN [Online]. Available : http://www.tellabs.com/solutions/opticallan/tlab_so lve-net-challenges-with-optical-lan_an.pdf

[13] Zhone. FiberLAN Optical LAN Solution [Online]. Available: www.zhone.com/solutions/docs/zhone_fiberlan_sol utiompdf

[14] P.Parol and M.Pawlowski, "How to build a flexible and cost-effective high-speed access network based on FTTB+LAN architecture," in Computer Science and Information Systems (FedCSIS), 2012 Federated Conference on , vol., no., pp.655,662, 9-12 Sept. 2012

[15] The OpenFlow Switch Specification. [Online]. Available: https ://www. opennetworking, org/images/stories/do wnloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.3.pdf 1.3.3 .pdf

[16] N.McKeown, T.Anderson, H.Balakrishnan, G.Parulkar, L.Peterson, J.Rexford, S.Shenker, and J.Tumer, "OpenFlow: enabling innovation in campus networks". SIGCOMM Comput. Commun. Rev. 38, 2, pp. 69-74, March 2008

[17] Open Networking Foundation. (2012). White Paper, Software-Defined Networking: The New Norm for Networks [Online]. Available: https ://www. opennetworking, org/images/stories/do wnloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf

[18] P.Parol and M.Pawlowski, "Towards networks of the future: SDN paradigm introduction to PON networking for business applications" in Computer Science and Information Systems (FedCSIS), 2013 Federated Conference on , vol., no., pp.829,836, 8-11 Sept. 2013