sodales - europa

Grant Agreement No.: 318600

SODALES

SOftware-Defined Access using Low-Energy Subsystems

Funding Scheme: Small or medium-scale focused research project STREP - CP-FP-INFSO Activity: ICT-8-1.1 - Future Networks

D3.1 Control Plane Service Requirements

Due date of the Deliverable: Month 9 Actual submission date: 19 September 2013

Start date of project: November 1st 2012 Duration: 36 months Project Manager: Carlos Bock | i2CAT

Version: 1.0

Author List: André Domingos Brízido (PTI), Eduard Escalona (i2CAT), Victor Marques (PTI), Jordi Ferrer Riera (i2CAT), Tiago Miguel Mendes (PTI), Carlos Bock (i2CAT), Vitor Mirones

(PTI)

Project co-funded by the European Commission in the 7th Framework Programme (2007-2013)

Dissemination Level PU Public PP Restricted to other programme participants (including the Commission Services) RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)

Ref. Ares(2013)3089840 - 20/09/2013

Deliverable D3.1

Project SODALES Doc Control Plane Service

Requirements Date 31/08/2013

of 36

Abstract This deliverable D3.1 provides the requirements to design the SODALES control plane from the operator’s perspective. These include overall requirements, Network Element specific requirements and requirements for the Signalling Communication Network. Also specified are the management protocols that will be supported.

The document also presents a description of the state-of-the-art of network management and control with focus on the most relevant aspects for the SODALES project. These include Open Access and Software Defined Networking.

Deliverable D3.1



of 36

Table of Contents 1 Introduction ........................................................................................................................... 5 2 State of the Art and available technologies ............................................................................ 7

2.1 Traditional Management .................................................................................................. 7 2.1.1 Management approaches ............................................................................................. 7 2.1.2 Signalling Communication Network ............................................................................ 11 2.1.3 Integral Vendor NMS .................................................................................................. 12 2.1.4 Northbound interfaces for OSS and BSS.................................................................... 12

2.2 Open Access ................................................................................................................. 13 2.3 Software Defined Networking......................................................................................... 15

2.3.1 Network as a Service ................................................................................................. 17 2.3.2 OpenNaaS ................................................................................................................. 18

3 Unified Control & Management Requirements ..................................................................... 20 3.1 Overview ....................................................................................................................... 20 3.2 Overall Requirements .................................................................................................... 21 3.3 Network Element Requirements .................................................................................... 25

3.3.1 Configuration Requirements ....................................................................................... 26 3.3.2 Security Requirements ............................................................................................... 26 3.3.3 Fault Management Requirements .............................................................................. 26 3.3.4 Performance Requirements........................................................................................ 26 3.3.5 Virtualization considerations ....................................................................................... 27

3.4 Management Interfaces ................................................................................................. 27 3.4.1 REST Web Services................................................................................................... 28 3.4.2 SNMP ........................................................................................................................ 28 3.4.3 XML based configuration ............................................................................................ 29 3.4.4 OpenFlow ................................................................................................................... 29

3.5 Signalling Communication Network (SCN) ..................................................................... 29 3.5.1 Out-of-band management .......................................................................................... 29 3.5.2 In-band management ................................................................................................. 30

4 Initial roadmap for the SODALES management and control plane ...................................... 33 5 Conclusions ......................................................................................................................... 34 6 Acronyms ............................................................................................................................ 35 7 References .......................................................................................................................... 36

Deliverable D3.1



of 36

List of Figures Figure 1: Basic SODALES architecture and service vision ........................................................... 6 Figure 2: Centralized approach example ...................................................................................... 9 Figure 3: Weakly distributed approach ....................................................................................... 10 Figure 4: Strongly distributed management approaches ............................................................. 10 Figure 5: Cooperative management approach ............................................................................ 11 Figure 6: The open network model and typical open access value chain [FORZA] ..................... 15 Figure 7: SDN Architecture layers [ONF-SDN] ........................................................................... 16 Figure 8: Layered OpenNaaS architecture [OPENNAAS] ........................................................... 18 Figure 9: SODALES Unified Control and Management Plane .................................................... 20 Figure 10: Out-of-band management: Logical view .................................................................... 30 Figure 11: SODALES in-band signalling with dedicated VLAN per NE ....................................... 31 Figure 12: SODALES in-band signalling with dedicated VLAN and routed CO ........................... 31 Figure 13: SODALES in-band signalling with shared VLAN ........................................................ 32 Figure 14: SODALES in-band signalling with shared VLAN and routed CO................................ 32 Figure 15: WP3 Gantt diagram ................................................................................................... 33

Deliverable D3.1



of 36

1 Introduction

The control and management (C&M) functions of the SODALES architecture create the basis for allowing the network providers to dynamically interact with the SODALES system and configure its operational parameters, as well as to offer tailored infrastructure slices to service providers. In addition, appropriate C&M functionality will enable the implementation of processes that are required for the operation, administration, and maintenance (OAM) of network services deployed on top of the central office (CO), active remote node (ARN), and customer premises equipment (CPE) systems, as well as monitoring and troubleshooting.

The SODALES system approach is targeted towards an integrated platform based on SDN (software defined networking) principles. It offers critical abstraction and virtualization functionalities, so that the physical infrastructure can be partitioned and each virtual slice managed by individual service providers.

The key requirements for the SODALES Control and Management Plane are therefore described as follows:

• Support for isolation and virtualization – one of the main objectives for SODALES is to allow multiple service providers to share the same physical network with the guarantee of isolation between virtualized resources. The network management system must provide internal mechanisms in order to abstract the physical resources and enable the uniform management and operation of all the physical resources.

• Support of monitoring and recovery – the network element (NE) must support the detection and reporting of alarms, and must provide mechanisms to protect against data plane failures.

• Support of security mechanisms – the management system must be able to operate the NEs in a secure manner. This can be achieved through the use of a private signalling communication network (SCN), which can be either in-band or out-of-band. Also encryption and authentication mechanisms can be used depending on the protocol used for communication.

The generic SODALES architecture is depicted in Figure 1. From the physical point of view, the presence of an ARN located at an intermediate location between the CO and the end-users is one of the key structural innovations inherent to the SODALES network. The introduction of the novel ARN architectural possibility into the access network pushes the network intelligence ever closer to the end-user, making it easier to enforce the requirements of the SODALES control plane in a more immediate and directed manner.

Deliverable D3.1



of 36

Figure 1: Basic SODALES architecture and service vision

In this deliverable D3.1 the requirements for the SODALES control and management plane are elaborated and specified.

The document is organized as follows:

Chapter 2 offers an analysis on the state-of-the-art of network management and control, and includes a description of the most commonly used management solutions (traditional management), as well providing an overview of open access (OA) and software defined networking (SDN) – two of the key defining aspects of the SODALES architecture.

Chapter 3 specifies the overall requirements for the unified control and management of the SODALES network, the NE-specific requirements, and the requirements for the signalling communication network (SCN). Particularly important aspects considered in this section are the support of isolation and virtualization, the support of monitoring and recovery, and the support of security. Also in this chapter the management protocols that will be supported in the SODALES architecture are specified.

Chapter 4 provides some concluding remarks to summarise the results described in this deliverable.

Deliverable D3.1



of 36

2 State of the Art and available technologies

An efficient control and management functionality is essential for the operation, administration, maintenance, and provisioning (OAMP) procedures in any phase of a network lifecycle. The set of functions that a management system supports over network resources, such as planning, deployment, configuration or monitoring, can be implemented following different architectures and levels of automation involving less or more complex software systems.

This section presents the most commonly used management solutions, from the traditional point of view. It also provides an overview of the different state-of-the-art technologies related and relevant for SODALES, i.e. open access, software defined networking and network as a service (NaaS).

2.1 Traditional Management

The lifecycle of network service operations involves many variables all of which need to be controlled at the same time. Traditional management was performed mainly with manual intervention; however it has been evolving to become a more strategic and intrinsic aspect of network design, when it is considered as an integral part of the overall solution. Different management approaches have been used depending on the context (situation) and requirements of the network operators.

Traditional management approaches, according to [MARTFLAT] may be classified into four different category archetypes:

• Centralized

• Weakly distributed hierarchical

• Strongly distributed hierarchical

• Cooperative paradigms

To each of these approaches, another important dimension now also needs to be applied: the Open Access (OA) concept, in which the roles of network and service providers are separated and the network provider offers tools and/or interfaces to partition its network into a number of self-contained and virtualized smaller networks, able to be managed by different service providers.

2.1.1 Management approaches

2.1.1.1 Centralized Approaches

Centralized management assumes the existence of a single system that controls the whole network of elements, each of them running a local management agent. The centralized manager coordinates a potentially very large number of agents. This centralized manager, typically known as the NMS (Network Management System), monitors and administers one or more networks, composed of (NEs) Network Elements, which are known as the managed entities.

Among the responsibilities or functions of a NMS, it is common to find:

Deliverable D3.1



of 36

• Network discovery (discovering the NEs) - In order to perform any operation on the NEs, the NMS must maintain a database with information about the managed devices such as the location, version, and available resources. This database is populated by reading a NE‘s characteristics (the discovery process).

• Configuration of each NE and service configuration (often involving more than one NE) – the purpose of the network is to transport services (flows of information between two endpoints). To provision a particular service, the NMS determines the resources needed by the service, computes a configuration sequence and applies it to the NEs.

• Fault Management – The NMS monitors the NEs and receives alerts/alarms. With the information gathered, it is possible to identify possible problems and provide tools for resolving them by combining this information with that of the discovery database.

• User and machine-to-machine (M2M) interfaces – The NMS provides an integrated view of the network to the user, abstracting the low level aspects of the NEs. It can also provide Northbound Interfaces to interact with other platforms (e.g. operations support services (OSSs) and business support services (BSSs)).

• Virtualization – Virtualization is the concept of partitioning the same physical infrastructure into several virtual slices managed by different service providers. The network belongs to a single operator, but each service provider sees only the virtual resources that were agreed with them. The NMS offers control of the virtual networks to the service providers and must guarantee the isolation of these virtual environments.

The network management performed by the NMS follows the FCAPS model (Fault, Configuration, Accounting, Performance, and Security).

The communication between the NMS and the NEs uses one or more protocols. It may be done through the use of telnet with CLI (Command Line Interface), using parsers; through the use of SNMP (the most common and standardized approach, but rather slow and inefficient), or, more recently, through the use of XML messages over a transfer protocol (e.g. HTTP). This last option is suitable for M2M communications, and allows for large data transfers in a single operation (for example, where the limiting case is where the entire NE database is coded and sent in a XML envelope).

As mentioned before, the majority of current IP telecommunication networks are managed by SNMP (Simple Network Management Protocol) that refers to a set of standards to the networks management, including a protocol, the Management Information Base (MIB) structure and the set of data objects.

SNMPv1, the first version of the protocol, was adopted as a management standard for TCP/IP-based networks and became the most popular. Remote Network MONitoring (RMON), a supplement of SNMP, was defined to extend SNPM capabilities, in particular to allow SNMP to manage LANs (Local Area Networks).

SNMPv2 RFC 1448 was created to address specific problems found on the first version of the protocol and afterwards, SNMPv3 RFC3410 was also defined to bring authentication, and to improve remote configuration and security features.

A Command Line Interface (CLI) is a means of interacting directly with the NEs through text commands. Graphical Users Interfaces (GUIs) are generally more intuitive and have an easier learning curve, but a CLI allows the creation of scripts that allow the automation of certain tasks. It is also possible for a CLI to be used by a machine (such as the NMS) to configure a device remotely by telnet or SSH, since typically it has a well-defined and structured syntax (which makes possible the creation of parsers). There is no standard syntax for the commands of a CLI,

Deliverable D3.1



of 36

but many vendors choose to implement CLIs similar to those from Unix-like operating systems, or to those from Cisco Systems’ equipment.

The use of XML messages for configuration of the NEs is growing more common due to its well-structured and self-documenting nature, and the ability to add new features without losing compatibility. The structure of a XML document is defined by a schema [W3SCHEMA]. Schemas are usually proprietary, but there have been some standardization attempts regarding the transport protocol and the message formats, such as the Network Configuration Protocol (NETCONF) RFC 6241 [RFC6241], the Simple Object Access Protocol (SOAP) [SOAP] or the Representational State Transfer (REST) [REST] .

Figure 2: Centralized approach example

The centralized approaches to network management present some disadvantages, namely:

The NMS manager is a single point of failure; however, this may be overcome with the introduction of appropriate redundancy.

The manager is the only “intelligent” entity and is singly the only responsible unit for analysing the data received from the NEs, and using that data in the best way to improve overall network performance.

Scalability may also become an issue, since every network configuration operation is dependant of the NMS.

The main advantage of the centralized approaches is that such architecture allows the operator to gain an integral view of the network, its resources, its utilization and the general status of the services and physical infrastructure.

2.1.1.2 Distributed Approaches

The distributed management approaches introduce the concept of a management hierarchy, in a way similar to that found in human organizations. With these approaches, the Central Manager (NMS) delegates part of the management load among Agent Managers, each responsible for a part of the network. The Agent Managers typically do not exchange information between themselves, but rather with the Central Manager, this single entity having sole responsibility for the coordination of the whole network management.

This distributed model is mostly used by the OSI-SM (OSI System Management) that uses CMIP (Common Management Information Service) as the management protocol. This model is the basis of the TMN (Telecommunication Management Network), a telecommunication management

NMS

NENE

NE

NENENE

Deliverable D3.1



of 36

framework, defined by the ITU-T (International Telecommunication Union) in ITU-T M.30000 recommendation series. Being defined by the ITU means that most of the traditional (incumbent) telecommunication operators are using and have adopted it. More recently, even system providers that have been born on the Internet market are now introducing management solutions that use this concept (e.g. for the management of Wi-Fi hotspots).

One agent manager may control several agents, whether they are located at several different items of equipment, or they are more or less independent pieces located on a single unit of equipment.

This approach is classified as a weakly distributed management approach and on IP networks, CORBA (Common Object Request Broker Architecture) is being used as the basis to create collaborative processes that enable and define communications between the NEs and the Agent Managers.

Figure 3: Weakly distributed approach

Other approaches define a tighter and more intense cooperation between the different Agent Managers. These approaches are known as Strongly Distributed approaches.

Figure 4: Strongly distributed management approaches

AgentManagerNE

NMS

NE

NENENE

AgentManager

NE NE

NENENE

AgentManager

NE

NE

NE

NE

NE

AgentManagerNE

NMS

NE

NENENE

AgentManager

NE NE

NENENE

AgentManager

NE

NE

NE

NE

NE

Delegation

Delegation

Delegation

Deliverable D3.1



of 36

Weakly distributed approaches have the advantage of lowering the processing needs of the NMS, but basically they suffer from the same constraints as the fully centralized model. The NMS is still a single point of failure, but the Agent Manager now acts as a “mini”-NMS, responsible for a part of the network.

On strongly distributed approaches there is a well-described relation between the Agent Managers, making them able to delegate decisions. However, the NMS is still the single full intelligent entity. The NMS has the main function of coordination of all the delegation tasks, but the distribution of the communication is now mostly performed by the Agent Managers.

2.1.1.3 Cooperative Approaches

In cooperative approaches, as the name indicates, the main characteristic is that the Agent Managers cooperate between themselves, but there is also cooperation between an Agent Manager and a NE belonging to another Agent Manager area. These entities act as both managers and agents, and work together in a collaborative way to fulfil the required management tasks.

Figure 5: Cooperative management approach

Although cooperative approaches tend to make the management process more flexible, they do pose some drawbacks:

• It is complex to implement since it requires and imposes a high degree of intelligence on the agents.

• It therefore tends to be less secure. • The provider may also lose full contemporaneous understanding of the network conditions

and available resources.

2.1.2 Signalling Communication Network

The control plane communications rely on the existing of a highly reliable and robust signalling communication network (SCN) to transport signalling and control messages between network elements. The SCN can be deployed in-band or out-of-band for the management message exchange.

AgentManagerNE NE

NENENE

AgentManager

NE NE

NENENE

AgentManager

NE

NE

NE

NE

NECooperation

AgentManager

NE NE

NE

NE

Cooperation

Cooperation

Cooperation Cooperation

Deliverable D3.1



of 36

2.1.2.1 In-band management

In-band management uses the service network interfaces to access and manage the NE; however it is usually separate from the core network being segmented out by VLANs. To make this possible, a part of the service configuration has to be performed in advance, and this means that the risk of losing access to network equipment due to a wrong configuration increases drastically. On the other hand, this type of management access saves infrastructure resources, since there is no need to have two separated networks for the service Data and Control/Management Planes.

2.1.2.2 Out-of-band management

Out-of-band management involves the existence of a dedicated management network in an overlay infrastructure of the service network. Out-of-band management has the advantage that it is therefore physically isolated from the actual managed network, and the management process may therefore be performed from the starting point where no configurations (besides management interface) exist. Out-of-band management may include tools to remotely power-off and power-on the NE or part of it, and still be able to have some access to it. The management interface may include independent powering and CPU. Often, this type of management includes the remote access to the equipment console ports.

Some disadvantages of out-of-band management are that it requires independent configuration and fault management to ensure that the management channel is alive, and usually a remote management card needs to have additional power supply.

2.1.3 Integral Vendor NMS

In the early years of NMS systems deployment, the tendency was that the system vendor and the NMS vendors were separated entities, both using a common protocol, SNMP. The NMS vendors were integrating the vendors’ new products as they were coming to the market. However, soon the system vendors saw advantages in implementing their own NMS platforms. They could enjoy a shorter time to market, and also enable proprietary functions, extending the capabilities of the rather simplistic SNMP approach. In terms of the network providers, this resulted in the existence of multiple NMS systems, typically one for each system vendor. This lead to a high degree of complexity for services provision, especially when taking into account the fact that many different platforms from different system providers need be used. At this point, it became clear that the service providers needed platforms that could give an integrated and merged view of the network and network elements, allowing a single centralized point for the provision and operation of the networks, the OSS/BSS platforms.

2.1.4 Northbound interfaces for OSS and BSS

The standardization of the interfaces between NMS and OSS/BSS was soon understood by both telecom operators and system vendors as possessing great advantage, and having enormous potential, especially when dealing with large networks. In this sense, the TM Forum (http://www.tmforum.org/), founded by 8 companies (Operators and Vendors) in 1988 and initially called “OSI/Network Management Forum” (due to the providers’ network reality at that time), was created with the mission of "accelerating the availability of interoperability of network management products". In fact, the Multi-Technology Network Management (MTNM) interface, one of the first defined by the TM Forum, was proposed for the provisioning of SONET/SDH infrastructures.

http://www.tmforum.org/

Deliverable D3.1



of 36

MTNM definition was undertaken with the goal of taking advantage of CORBA (Common Object Request Broker Architecture). At that time, CORBA was being promoted by the IT industry as a standard (defined by the Object Management Group - OMG) to enable separate pieces of software, written in different languages and running on different platforms to interwork as a single application or set of services. However, subsequent network and IT evolution brought about XML-based architectures that became much more deployed than the CORBA solutions. This fact promoted the development of a MTNM profile based on XML, called the Multi-Technology Operations System Interface (MTOSI). MTOSI was defined as an all-in-one monolithic interface.

The “Internet revolution” brought new technologies to the IT panorama, such as Java, that, supported essentially by Sun Microsystems with the OSS through the Java OSS/J initiative, started the JAVA API’s for OSS integration standardization process. Opposed to the MTOSI approach, OSS/J opted for an open approach, allowing multiple standalone interfaces to be defined. These interfaces shared a common interface model based on parts of the Information Framework (SID). XML aspects also impacted the OSS/J approach, such that OSS/J defined a XML profile and thus allowed the implementation of OSS/J interfaces without the need of a Java environment.

The TM Forum decided to integrate in one single framework, the NGOSS (New Generation Operations Systems and Software), now called Frameworkx, with several (four) of its frameworks now listed as follows:

• Application Framework or Telecom Application Map (TAM)

• Business Process Framework or enhanced Telecom Operations Map (eTOM)

• Information Framework or Shared Information/Data (SID) model

• Integration Frameworks, developed in the TM Forum Integration Program (TIP)

The objectives of Frameworkx are: (1) the separation of Business Process from Component Implementation; (2) Loosely Coupled Distributed System; (3) Shared Information Model; (4) Common Communications Infrastructure; and (5) Contract defined interfaces.

Thus, the Frameworkx, has joined the Application Framework (TAM), the Business Process Framework (eTOM) and the Information Framework (SID) as all the tools to provide a common design language for the Telecommunications Management design. The Frameworkx is a model driven engineering framework to which all interfaces should migrate. However, this migration process could not be done in one single step. As such, it was subsequently decided under the TM Forum that all new interfaces should be derived from Frameworkx, while interfaces derived from OSS/J and MTOSI should go through an intermediate step, defined directly from the new version of the Information Framework.

2.2 Open Access

One of the key aspects to the SODALES solution is that it is based on the Open Access paradigm, which therefore affects the way networks and services are managed. An Open Access network refers to a horizontally layered network architecture in telecommunications, and the business model that decouples the physical access to the network resources from the actual provisioning and delivery of services on top of these network resources. In an Open Access network, thus, the owner of the physical infrastructure does not supply services for the network,

Deliverable D3.1



of 36

but separated retail service providers must provide the services. The basic idea behind the Open Access model is to promote the highest degree of competition in order to maximise the freedom of choice for end-users, and to avoid a monopoly situation [BATT].

The traditional telecom model is based on vertical integration, in which one entity delivers the service, operates the network, and owns the network infrastructure. Originally, the available services were mainly limited to telephony, radio, and television; such that these justified dedicated infrastructures, each optimised to transmit the information carried by a specific signal, and with their inherently different traffic patterns. However, technology has evolved dramatically since, such that today the number and quantity of available services is booming: from well-established ones such as telephony (mobile or fixed), web access, emailing, or television, to rapidly growing ones such as video conferencing, video, and music streaming and sharing, online gaming, e-health, or even 3D TV. Ideally, there is now no reason today, why telecommunication services should be delivered by a network infrastructure that is optimised to the type of end-user termination rather than the services being delivered [FORZA].

The open network model, in which services are provided on a fair and non-discriminatory basis to the network users, is enabled by conceptually separating the roles of the service provider and the network and communication operator. Due to the different technical and economic natures of the different parts of the network, different roles and actors can be identified. A fibre access network broadly consists of a passive infrastructure, and active equipment. The passive segment is typically characterised by high CAPEX, low OPEX, low economies of scale, and is highly local, hard to duplicate and inherently subject to regulation. The active equipment is traditionally characterised by high OPEX, economies of scale, and is subject to limited regulation. These factors justify a further role separation between a network owner, which owns and maintains the passive infrastructure; and the communications operator, which operates the active equipment [FORZA].

SODALES architecture, depicted in Figure 1, is a converged architecture, lying between purely passive and active solutions. One of the key challenges of SODALES is to enable the network providers to create isolated infrastructure slices that can be later on leased to service providers. These service providers are responsible for the operation of the active equipment, while the network providers are responsible for maintaining, and partitioning the infrastructure and guaranteeing the access to it. Therefore, SODALES is aiming at offering the best of both passive and active open access solutions.

Open access promotes role separation. However, from an infrastructure management point of view, the main issue includes who should own, operate and maintain an operator neutral access network. A key issue to get the open access concept accepted as commercially viable network architecture is the establishment of a trusted actor that owns, maintains and supervises a well-designed set of access rules to a common shared infrastructure creating a market place for use and a wide spectrum of service providers [OPENNET]. Besides from the business and regulation issues, SODALES control and management plane must provide the different actors the tools to maintain and manage the infrastructure, as well as must guarantee that there are no interferences between different service providers.

Deliverable D3.1



of 36

Figure 6: The open network model and typical open access value chain [FORZA]

Figure 6 illustrates the value chain associated to the Open Access model. The end users typically purchase services directly from the service providers. The operator receives revenue from the service provider and pays a connection fee to the network owner for the network access.

2.3 Software Defined Networking

Nowadays, management is based mainly on software systems allowing different levels of automation of the different management processes. In this sense, Software Defined Networking (SDN) has swiftly become an important aspect of the strategy to address the network management requirements as identified by the commercial players in this market. From a functional perspective, SDN can be considered as the physical separation of the network control plane from the forwarding plane, where a control plane controls several devices [ONF-SDN]. The Open Networking Foundation (ONF) [ONF], a user-driven organization dedicated to the promotion and adoption of SDN through open standards development, describes SDN as an emerging architecture that is dynamic, manageable, cost-effective, and adaptable, making it ideal for the high-bandwidth, dynamic nature of today’s applications. This architecture decouples the network control and forwarding functions enabling the network control to become directly programmable and the underlying infrastructure to be abstracted for applications and network services. ONF declares that SDN architecture is:

• Directly programmable: network control is directly programmable because it is

decoupled from forwarding functions.

• Agile: abstracting control from forwarding lets administrators dynamically adjust network-

wide traffic flow to meet changing needs.

• Centrally managed: network intelligence is (logically) centralized in software-based SDN

controllers that maintain a global view of the network, which appears to applications and

policy engines as a single, logical switch.

Deliverable D3.1



of 36

• Programmatically configured: SDN lets network managers configure, manage, secure,

and optimize network resources very quickly via dynamic, automated SDN programs,

which they can produce themselves because the programs do not depend on proprietary

software systems.

• Open standards-based and vendor-neutral: when implemented through open

standards, SDN simplifies network design and operation because instructions are

provided by SDN controllers instead of multiple, vendor-specific devices and protocols.

The figure below depicts the different SDN layers as proposed by the Open Networking Foundation.

Figure 7: SDN Architecture layers [ONF-SDN]

The motivation behind the separation is twofold. Mainly, the decoupling allows for the control plane to be implemented using a different distribution model than the data plane; and second, it allows the control plane development and runtime environment to be on a different platform than the traditional low-powered management CPUs found on hardware switches and routers. There is a lot of momentum currently in the research community regarding SDN. For example, several applications are listed as potential beneficiaries of the SDN functionalities (e.g. Infrastructure as a Service (IaaS), or intra-Data Centre network management).

The same ONF is also promoting the OpenFlow standard [OPENFLOW] as the communication protocol to access, manage, and configure the data plane from the control plane. Although at its outset, SDN tended to use OpenFlow, which lead to the misunderstanding that OpenFlow is equivalent to be SDN, there is actually no requirement for the use of OpenFlow within an SDN environment.

Deliverable D3.1



of 36

OpenFlow was initially defined as an open standard that enables researchers to run experimental protocols over the campus networks we use every day. OpenFlow is added as a feature to commercial Ethernet switches, routers and wireless access points – and provides a standardized hook to allow researchers to run experiments, without requiring vendors to expose the internal workings of their network devices. OpenFlow is currently being implemented by major vendors, with OpenFlow-enabled switches commercially available.

In a classical router or switch, the fast packet forwarding (data path) and the high-level routing decisions (control path) occur on the same device. An OpenFlow switch separates these two functions, following SDN architectural requirements. The data path portion still resides on the Switch, while high-level routing decisions are moved to a separate controller, typically deployed into a typically standard server or a Virtual Machine (VM). The communication is performed through the OpenFlow protocol, which supports three message types: controller-to-switch, asynchronous, and symmetric, each with multiple sub-types.

The SDN concept can be applied to network management problems considering that network configuration consists in processing events in domains such as time, history, user or traffic flows. Therefore, novel management systems could benefit from applying SDN architectures in a similar way that OpenFlow currently allows controlling flows. In fact, the control and management system for SODALES aims at applying such principles. On the one hand, SODALES will provide the network owner with the different required tools to create, manage, and monitor infrastructure slices and will study the most suitable protocol to enable an SDN architecture (e.g. OpenFlow). This implies that the system must hold a centralized view of the whole infrastructure and the different events happening there by means of accessing the different resources. On the other hand, the system will allow the different service providers to control and operate the corresponding infrastructure slice, decoupling the data plane and the control plane.

2.3.1 Network as a Service

Network service delivery and management models remain an area of on-going evolution, and are additionally being continually revised in tandem with the constantly evolving needs of the R&E community. The network as a service concept represents an interesting service model from which SODALES can benefit. Network as a service is a business model for delivering network services virtually over any network on a pay-per-use basis. It is not a new concept. However, its development has been hindered by some of the same concerns that have affected also other cloud computing services, such as high availability or service level agreements. In essence, network becomes a utility, paid for just like any other utility (e.g. water, electricity or heat).

In this context, NaaS can be adopted as a new management and provisioning model, which needs to be evaluated in the context of the Network Management Architecture (NMA) principles, latest network management standards, and the trends in Next-Generation Operations Support System (NG-OSS).

NaaS capabilities are of particular relevance for the value they can provide to virtualization services, as they can extend the IaaS model from data centres into access and transport networks.

NaaS may therefore enable the evolution of network management and operations to increase flexibility in operations and potentially reduce OPEX in the short/mid-term, and as such is of particular interest to SODALES.

Deliverable D3.1



of 36

2.3.2 OpenNaaS

The NaaS model has been brought forward with the OpenNaaS framework [OPENNAAS] for easy prototyping and proofcasing of NaaS concepts. OpenNaaS is an open-source framework, developed under the FP7 MANTYCHORE project [MANTYCHORE], which provides tools for managing the different resources present in any network infrastructure. The software platform was created in order to offer a neutral tool to the different stakeholders comprising an OA network. It allows them to contribute and benefit from a common NaaS software-oriented stack for both applications and services. OpenNaaS is currently being developed by an open community under the LGPLv3 license. It is based on a lightweight, abstracted, operational model, which is decoupled from actual vendors’ specific details, and is flexible enough to accommodate different designs and orientations. In fact, the OpenNaaS framework provides tools to implement the logic of an SDN-like control and management plane on top of the lightweight abstracted model.

Figure 8 depicts the OpenNaaS architecture, which can be structured into three different horizontal layers or components. The platform layer contains the reusable building blocks, which are common to all the extensions, and controls the access to the different infrastructure resources. The resource layer contains the different resource abstractions. A resource represents a manageable unit inside the NaaS concept. Each resource holds a list of capabilities, which comprise the list of different actions that can be performed over each resource. Finally, the upper layer, where the network intelligence resides, provides integration with the north-bound middleware or even user applications.

Figure 8: Layered OpenNaaS architecture [OPENNAAS]

Deliverable D3.1



of 36

Based on the architecture picture, if any user or developer of the community wants to extend the platform through third-party extensions, the only requirement is to define and create a new resource, with the list of capabilities associated to it. Immediately, the resource will inherit all the functionalities provided by the OpenNaaS platform (e.g. persistence, CLI, or even queuing).

Once presented the relevant state-of-the-art and the related technologies to the project, the next chapter will introduce the SODALES control and management plane requirements identified for the design and implementation process of the framework.

Deliverable D3.1



of 36

3 Unified Control & Management Requirements

This section contains the description of the different requirements of the SODALES unified Control and Management framework. This control and management component will allow the SODALES network operator to control all the network devices and at the same time offer to the different service providers OAM control over their connections, so they can manage them efficiently and guarantee the delivery of critical services. The functional requirements that constrain the specification of the technical functionalities to be supported by the control and management platform have to be identified prior to the design of its modules.

3.1 Overview

The control and management in SODALES implements the required operation functions that allow network providers to configure the network, and to offer tailored infrastructure slices to service providers. In addition, it also enables the OAM of the network services to be deployed on top of the CO and the ARN. CPE devices are also under the umbrella of the control and management plane. They will be controlled and configured through its traditional management interface, although these devices will not be sliced.

SODALES control and management must support a set of features for the provisioning of the network services enabled by the ARN, such as support for isolation and virtualisation, monitoring and recovery, support for heterogeneity, on-demand provisioning, scalability, dynamic reconfigure-ability or support for AAI (Authentication, Authorization Infrastructure) mechanisms.

Figure 9: SODALES Unified Control and Management Plane

Deliverable D3.1



of 36

The system is based on an integrated platform that offers abstraction and virtualization functionalities, so that the physical infrastructure can be partitioned, and each virtual slice managed by individual service providers. Figure 9 represents a high level view of the control and management architecture for the SODALES system, which lies on top of the physical equipment. The system will need to setup a signalling channel and establish a signalling communication network (SCN) to forward signalling messages for configuration, control and management of the network devices.

The approach for the unified control and management can be seen as a centralized SDN-based approach, where all the intelligence resides within the control and management plane. Moreover, it is worth mentioning that the communication between the different components of the SODALES architecture (CO, ARN, and CPE) and the control plane is not restricted to OpenFlow; the control and management plane to be implemented can adopt any protocol suitable for the communication with the actual devices. Several protocols, from simple REST/SOAP Web Services to SNMP may be used to communicate the control plane, where the management and control logic resides, to the data plane. Those protocols are included later on the network elements requirements.

3.2 Overall Requirements

The following table contains a basic classification of the requirements that will be supported by the SODALES control and management plane. It also contains the basic description of each of the identified requirements.

Requirement ID

Title Type Priority Description

CMP-REQ-001

Resource abstraction mechanisms and associated data models

Functional Essential

The network management system must provide internal mechanisms in order to abstract the physical resources and thus enable the uniform management and operation of all the physical resources considered within the SODALES environment. Abstraction is the requirement that will enable the management platform to uniformly handle the different resources (CPE, CO, ARN).

In fact, the management platform needs to provide mechanisms to create abstract descriptions of physical resources, by using a set of attributes, characteristics and functionalities while hiding unnecessary characteristics of the resources themselves. These descriptions will be produced according to the data models created within SODALES. They will also be used as the basis for virtual resources deployment.

CMP-REQ-002

On-demand slice-provisioning

Functional Essential One of the key objectives of SODALES is to explore and implement virtualization mechanisms to support multi-tenancy for

Deliverable D3.1



of 36

capabilities (Virtualization)

service providers, and guarantee isolation between virtualized resources. On-demand slice-provisioning requirement responds to the necessity of the network owner (i.e. infrastructure or network provider) to create isolated slices as a function of the demands of the different service providers, who will be operating them.

Thus, this requirement is twofold. On the one hand, the management system must be able to virtualize (partition) each physical resource and create virtual representations of each partition that behave as a physical resource by themselves. Isolation between virtual resources built on top of the same physical resource must be guaranteed. Virtualization of the resources will be realized over the abstracted resources, so all the resources belonging to the same type will have the same abstracted data model. On the other hand, the on-demand slice-provisioning requirement implies that the management system must be capable of creating virtual infrastructures in an on-demand basis to serve the service providers’ requests. These virtual infrastructures are composed of different virtual resources. Thus, the management system must be capable of composing different resources, once they are virtualized, and offer them as a virtual infrastructure to the service provider, who will be controlling it and offering services to the retail consumers.

CMP-REQ-003

Resource discovery and registration


The unified management and control plane must support resource discovery and registration in order to discover new physical resources and include their abstracted models into the system, so the management and operation functionalities are enabled. Discovery and registration represents the first logical step for the management plane, so the system itself is aware of the different resources that are under its control.

Different discovery and registration models will be analysed in order to find which one fits better for the SODALES scenario (e.g. automated/manual, online/offline)

CMP-REQ-004

Security Management

Functional Essential In multi-tenant environments, security management becomes one of the key

Deliverable D3.1



of 36

(AAI) objectives to guarantee isolation and privacy to each tenant.

The management system must be able to operate the physical resources (CPE, ARN, CO) in a secure manner; as well as provide specific access control mechanisms. Each Service Provider must be able to access only the control, management, and monitoring functionalities related to its own virtual slice of the network, without interfering in the operation of the rest of provisioned slices. Thus, the presence of other slices must be completely hidden.

This requirement leads to the need of specific Authentication and Authorization mechanisms to guarantee that: (i) only the authorized traffic can access specific physical resources allocated to virtual slices; and (ii) that only authorized users access the different operation functionalities of the virtualized resources.

CMP-REQ-005

Operation of the heterogeneous physical resources


The management system is deployed on top of heterogeneous resources (i.e. CO, ARN, CPE). Once the tailored slices are provisioned on top of these resources, the management and control platform needs to support different functionalities to enable the operation of the resources.

For each resource, a set of operations will be enabled through different interfaces in order to ensure correct operation of the resource by each service provider.

CMP-REQ-006

Resource monitoring Functional Essential

Equally to CMP-REQ-005, once the tailored slices are provisioned and being operated by each service provider, the management system must provide tools in order to monitor the status of the different resources.

The service providers will monitor the different resources in order to provision the services and act in case any network service is affected.

Monitoring features include both alarms notification as well as event management.

CMP-REQ-007

Remote access to offered functionalities

Functional Essential One of the key requirements for the Unified Management and Control system is the remote access to the different functionalities offered. The access must be

Deliverable D3.1



of 36

provided through well-known protocols.

It is not necessary that all the functionalities are offered by the same interface, so the system may have different interfaces, grouped by the type of functionality they offer or grouped by the type of user (network provider or service provider) that will be using the given interface.

Each device under the control and management plane (i.e. CO, ARN, and CPE) may have different management interfaces. The SODALES control and management plane offers remote access to these interfaces, but it may group them in order to simplify the service provisioning process. For example, all the configuration interfaces of the three devices may be grouped into one single endpoint at the control and management plane level.

CMP-REQ-008

Scalability, and Robustness

Non-functional

Nice-to-have

Scalability refers to the ability of the management system to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth. For the SODALES management and control plane, scalability can be defined as the ability of the system to handle a growing amount of physical resources and different users (network owners, service providers), as well as the ability to be adapted to this growth if required.

On the other hand, robustness is the ability of the system to cope with errors during execution.

Although these are not essential requirements for the management plane, it is worth to declare them as nice-to-have, so they will be included from the beginning within the SODALES development process. Robustness can be ensured through complete software testing techniques.

CMP-REQ-009 Portability Non-

functional Essential

Portability is becoming an essential requirement for the SODALES management plane. Since it is located within a multi-tenant environment, where each tenant may use a different type of computer (different operating systems, different platforms), the management platform must support being able to be

Deliverable D3.1



of 36

deployed over all these different platforms.

CMP-REQ-010

Usability, and Operability

Non-functional

Nice-to-have

Similar to CMP-REQ-090, a multi-tenant environment may imply that not all the users of the management system are necessarily located within the same user group. Thus, the management system should be usable and operable by any of the targeted users.

In principle, the management platform addresses the network providers and the service providers. Thus, at least, the specific characteristics of these types of users should be considered when designing and implementing the unified SODALES control and management platform.

However, this is not an essential requirement for the system.

CMP-REQ-011

Resource failure management Functional Essential

The management platform must ensure features to enable failure management. Failure can happen in different places, with the actions to be taken differing in each case. Failures considered may happen at: a) physical resource level; b) virtual resource level; or c) system level.

For the two first ones, the management platform must inform the corresponding tenant through the monitoring features, who will then be responsible to take the corresponding decision.

For the final instance, the management platform should include mechanisms to avoid the possibility that any failure at the system level blocks the management and control of the network.

Table 1: Control and management plane requirements

3.3 Network Element Requirements

The management of the SODALES network elements also imposes a set of requirements on the actual devices, covering aspects such as configuration, security, fault management or performance. The most relevant of these requirements are now described below. Additionally, some considerations related to the physical layer constraints that must be taken into account when performing virtualization of the NE are added at the end of the section.

Deliverable D3.1



of 36

3.3.1 Configuration Requirements

The network element must support the configuration management defined in the section 8 of the standard ITU-T G.7710 [G.7710], which includes the functions for controlling, identifying, collecting data from and provide data to NEs. Besides, the network element must support traffic management and QoS for virtualized services.

3.3.2 Security Requirements

There are no specific requirements regarding the security of the Management and Control Plane, since the Network Elements will be controlled by a single NMS through a private Signalling and Communication Network. Nevertheless the NE should support the security mechanisms provided by the protocol chosen for communication between the NMS and the NE. For example, SNMP Version 3 provides authentication and encryption mechanisms. TLS and SSH can be used to secure XML based configuration protocols and user/password authentication should be supported on the local terminals (CLI and Web Interface).

3.3.3 Fault Management Requirements

The OAM functionalities defined in ITU-T Y.1731 [Y-.1731] together with continuity check and connectivity verification must be supported for Ethernet connections.

The Network Element must be able to notify the NMS of events or alarms. The key alarm types are:

• OAM generated alarms

o Remote defect indication

o Loss of continuity

• General equipment alarms, such as Power Loss

• Interface alarms

o Link down, etc…

The key information that must be reported is:

• The time of the event/alarm condition

• Identification of the alarm condition

• Identification of the entity responsible for the event

The events may be reported to the NMS via SNMP Version 2 Trap or Inform or via NETCONF Event Notifications defined in RFC 5277 [RFC5277].

3.3.4 Performance Requirements

The NE must support the performance management applications and functions defined in section 10 of the ITU-T G.7710 standard [G.7710].

Deliverable D3.1



of 36

The NE must be able to deliver traffic counters which may include the measurement of total bytes, total packets, packet loss and others.

A history of counter values must be maintained.

The set of performance parameters defined in the Remote Network Monitoring (RMON) Management Information Base (MIB) RFC 2819 [RFC2819] or the Remote Network Monitoring Management Information Base Version 2 RFC 4502 [RFC4502] can be used.

3.3.5 Virtualization considerations

In order to create completely isolated slices of the infrastructure, the NE must ensure certain parameters related to the optical layer physical constraints. The physical impairments in passive optical networks are introduced both by the NE and the optical cables connecting the different NEs. The source of penalty from passive optical devices is due to inherent insertion loss and crosstalk; whereas the source of penalty from fibre optic cables is due to both linear and non-linear impairments.

Specifically linear impairments are effects such as:

• Noise introduced due to the amplified spontaneous emission (ASE), noise generated by

optical amplifiers used to compensate fibre and node losses

• Chromatic dispersion and polarization mode dispersion (PMD)

• Intra- and inter-band crosstalk is generated by unwanted leakage of optical signals when

transmitted through optical fibres, switches and other optical components

• Spectral clipping due to filter narrowing effects introduced when cascading a number of

optical filters

Non-linear effects are the ones following:

• Self-Phase Modulation (SPM)

• Cross-Phase Modulation (XPM)

• Four Wave Mixing (FWM)

The NE manages these physical impairments when it is operated by a single service provider. However, within the SODALES environment, considering role separation and that the infrastructure will be sliced to several service providers, the management and control plane needs to take into account the impairments during the slice planning phase. Specific considerations require to be implemented to ensure the NE will operate properly even managed by different actors.

3.4 Management Interfaces

Apart from a Graphical User Interface (GUI), the unified control and management plane should support remote connections for management purposes, mainly through IPv4 and/or IPv6; and it also needs to support at least one of the following management protocols:

Deliverable D3.1



of 36

• Web Services (REST/SOAP)

• RPC (XML-based)

• SNMP

From the functional point of view, Web Services are becoming the most preferred option in order to implement the SODALES Control and Management Plane interface, which will offer the different functionalities of the platform.

In addition, in order to enable the configuration of network elements, they must have IPv4 and/or IPv6 connectivity for management purposes, and must support at least one of the following management protocols:

• SNMP – Simple Network Management Protocol

• XML based configuration

• OpenFlow

A local terminal such as a Command Line Interface (CLI) (through serial port, USB or local Ethernet port) or Web based configuration interfaces may also be supported mainly for debugging purposes.

3.4.1 REST Web Services

Representational State Transfer (REST) is an architectural style that specifies constraints to be applied to a web service. RESTful web services use the HTTP protocol to perform requests from a web service over a collection of resources. A Restful request comprises a base URI, the MIME type of the supported web service and a set of operations supported by the web service using HTTP methods (e.g., POST, GET, PUT or DELETE). The benefits of this method are its scalability, the freedom for the definition of simple resources over which we want to operate, and the simplicity for creating new clients for the developed web services.

3.4.2 SNMP

The SNMP protocol is one of the most used protocols between the NMS and the Network Elements. It is standardized by the IETF. The most relevant RFCs are:

• RFC 1157 - A Simple Network Management Protocol (SNMP) [RFC1157]

• RFC 3416 - Introduction to version 2 of the Internet-standard Network Management

Framework [RFC3416]

• RFC 3414 - User-based Security Model (USM) for version 3 of the Simple Network

Management Protocol (SNMPv3) [RFC3414]]

If SNMP is implemented, at least version 2 must be supported. Version 3 is optional; however if it is supported, it should include both authentication and encryption, and notifications via Traps and Inform Requests.

Deliverable D3.1



of 36

3.4.3 XML based configuration

The use of XML (Extensible Markup Language) based configuration allows the functionality of the management protocol to closely mirror the native functionality of the Network Element. The structured and self-documenting nature of the XML language also makes the development of client applications easier, reducing implementation costs.

Different XML enabled protocols may be used for different cases such as the Network Configuration Protocol (NETCONF) RFC 6241 [RFC6241] or the Simple Object Access Protocol (SOAP) [SOAP].

If security is desired, the Transport Layer Security (TLS) defined in RFC 5246 [RFC5246] or Secure Shell (SSH) RFC 4251 [RFC4251] may also be used.

3.4.4 OpenFlow

The OpenFlow [OPENFLOW] standard defines an interface between the control and forwarding layers of the SDN architecture standardized by the Open Network Foundation as described in section 2.3.

OpenFlow provides network administrators a set of tools that allows them to control programmable networks. OpenFlow specification defines two principal elements, the controller and the switching device. Communication between these two elements is performed through the OpenFlow protocol. The message exchange between the controller (control plane) and the switch (data plane) is performed over a secure channel.

The protocol defines three types of messages:

• Controller-to-switch

• Asynchronous

• Synchronous

The relevant description of the whole protocol is provided into the OpenFlow specification [OPENFLOW].

3.5 Signalling Communication Network (SCN)

In the SODALES architecture, the management and control messages will rely on the existence of a highly reliable and robust signalling communications network (SCN) to transport these messages between network elements. In SODALES, the preferred method to transport the SCN is in-band along with data traffic, but it could also be alternatively carried out-of-band through a separate network. However, for completeness, we consider both these two cases in detail.

3.5.1 Out-of-band management

Out-of-band management involves the use of a dedicated management channel for device configuration and maintenance. The dedicated management channel requires a separate infrastructure. In principle, this option will not be implemented, although it could be supported in

Deliverable D3.1



of 36

SODALES. Typically, out-of-band management is done through network connection, although a management card is usually a physically separated network connector.

For the SODALES architecture, out-of-band management can be performed either through the Internet or through dedicated network connections. In any case, each one of the different devices considered must have enabled this specific connection, used for management purposes. The figure below contains a logical view of the out-of-band management scheme that could be implemented for SODALES in the case that this approach were to be eventually selected.

Figure 10: Out-of-band management: Logical view

3.5.2 In-band management

Since out-of-band management requires a separate and dedicated physical infrastructure, in-band signalling is currently the preferred technical solution for the SODALES architecture.

For the in-band SCN implementation two options exist:

• In-band signalling with a dedicated VLAN for each Network Element.

• In-band signalling with shared VLAN.

The management VLANs can either be transported over a separate wavelength or mixed with the data traffic. However, the use of a separate wavelength would greatly exceed the bandwidth requirements for the management messages, e.g. typically, a channel of 1 Mb/s will be sufficient, such that it can easily be mixed with data traffic with a minimal impact (as long as policing is applied, i.e. control traffic is prioritized).

3.5.2.1 In-band signalling with dedicated VLAN

For the in-band signalling with dedicated VLAN scenario, each CO, ARN and CPE must be assigned with a VLAN with the advantages of simplifying the hardware requirements and providing isolation. However it is not scalable for large networks as it could exhaust the pool of available VLANs, e.g. see Figure 11.

Deliverable D3.1



of 36

Figure 11: SODALES in-band signalling with dedicated VLAN per NE

If the CO has routing capabilities, only the ARN and CPE would require dedicated VLANs. Each CO would then be responsible for a LAN with multiple ARN and CPEs and the management VLANs could be reused between sites, e.g. see Figure 12.

Figure 12: SODALES in-band signalling with dedicated VLAN and routed CO

CO

ARN

CPE

ARN

NMS

CO

CPE

VLAN B

VLAN C

VLAN A

VLAN D

VLAN E

VLAN F

CPE

ARN CO

CPE

VLAN B

VLAN C

VLAN A

CPE

ARN CO

CPE

VLAN B

VLAN C

VLAN A

NMS

IP Network

Deliverable D3.1



of 36

3.5.2.2 In-band signalling with shared VLAN

The use of a single management VLAN for signalling is depicted in Figure 13. This alternative is also not suitable for very large networks due to the great number of nodes in the same broadcast domain. As in the previous section 3.5.2.1, this limitation can be overcome if the CO is embedded with routing capabilities (Figure 14). In this scenario only one VLAN will be required to manage the entire network since it can then be reused across sites.

Figure 13: SODALES in-band signalling with shared VLAN

Figure 14: SODALES in-band signalling with shared VLAN and routed CO

CO

ARN

CPE

ARN NMS

CO

CPE

VLAN A

CPE

ARN CO

CPE

CPE

ARN CO

CPE VLAN A

NMS

IP Network VLAN A

Deliverable D3.1



of 36

4 Initial roadmap for the SODALES management and control

plane

The management and control plane will be designed in the following task T3.3. Figure below contains the overall Gantt diagram for the work package three.

Figure 15: WP3 Gantt diagram

General design of the control and management plane, including specification of the different elements (i.e. CO, ARN, and CPE) and its interfaces is the next logical step in the roadmap. At the same time, OAM parameters specification for the end-to-end service provisioning will be defined within task T3.2. Finally, at M12 the implementation will start. The initial classification of the overall requirements has been included in this document and will be used as the starting point, jointly with the outcome of task 3.3, to create the final roadmap of the implementation.

Before starting the implementation within task T3.4, the software development plan (SDP) for the SODALES control and management plane will be created. The SDP comprehends a software-related document where all the required functionalities and tasks to be developed are included. The SDP also contains the timing plan for the whole development task, as well as the validation and testing processes.

Deliverable D3.1



of 36

5 Conclusions

In this deliverable we have specified the requirements for the SODALES Management and Control plane. It has been designed to consist of a centralized management platform responsible for the abstraction of the Network Elements (CO, ARN and CPE) capabilities, and for the construction of virtual slices upon request from service providers. In order for this to be possible the network elements must be configured to support proper QoS and traffic management mechanisms.

The architecture of SODALES has been envisaged to follow SDN principles, but will not be constrained to any protocol for the communication between the management platform and the Network Elements. That said, a XML-based protocol over HTTP is the preferred choice for the SODALES network, for the associated development convenience.

The management platform will need to setup a signalling channel and establish a signalling communication network (SCN) to forward signalling messages for configuration, control and management of the network devices. From the alternatives presented in this document, in-band signalling with a shared VLAN is the best option, since it does not require a separate infrastructure. Security of the control and management plane is guaranteed in this case, because only the network provider has access to this part of the network. Any interaction of the service provider with the network devices will be made through the management platform, which provides the proper authentication authorization mechanisms.

Finally, the SODALES management system will also be designed to provide the appropriate tools for monitoring the status of the different resources. The relevant fault management and performance monitoring requirements have also specified in this document.

This deliverable is part of the work package WP3 whose main goal is to implement a Control and Management plane for the SODALES project. Also part of this work package are the forthcoming deliverables D3.2, which will define the OAM parameters for E2E service delivery and D3.1 which will provide the complete description of the SODALES control and management plane, featuring network segmentation, open access and multi-vendor functionalities.

Deliverable D3.1



of 36

6 Acronyms

ARN Active Remote Node BSS Business Support System CAPEX Capital Expenditures CLI Command Line Interface CMIP Common Management Information Service Protocol CO Central Office CORBA Common Object Request Broker Architecture CPE Customer Premises Equipment FCAPS Fault, Configuration, Accounting, Performance, and Security FWM GUI

Four Wave Mixing Graphical User Interface

IaaS Infrastructure as a Service LAN Local Area Network MIB Management Information Base MTNM Multi-Technology Network Management MTOSI Multi-Technology Operations System Interface NaaS Network as a Service NE Network Element NG-OSS Next-Generation Operations Support System NMA Network Management Architecture NMS Network Management System OAMP Operation, Administration, Maintenance and Provisioning OMG Object Management Group ONF Open Network Foundation OPEX Operational Expenditures OSS Operation Support System RMON Remote Network MONitoring SCN Signalling Communication Network SDN Software Defined Networking SDP Software Development Plan SID Shared Information/Data SNMP Simple Network Management Protocol SOAP SPM

Simple Object Access Protocol Self-Phase Modulation

TAM Telecom Application Map TLS Transport Layer Security TMN Telecommunication Management Network VM Virtual Machine XML XPM

eXtensible Markup Language Cross-Phase Modulation

Deliverable D3.1



of 36

7 References

[BATT] Battiti et al., “Global Growth of Open Access Networks: from WarChalking and Connection Sharing, to Sustainable Business”, MASH ’03, New York, NY, USA: ACM, 2003, pp19.28.

[FORZA] M. Forzati, C.P. Larsen, C. Mattsson, “Open Access Networks, the Swedish Experience”, Proceedings of the International Conference on Transparent Optical Networks (ICTON) 2010. Munich, Germany. We.A4.5.

[G.7710] Recommendation G.7710/Y.1701, Common equipment management function requirements, ITU-T, Feb. 2012

[MANTYCHORE] Mantychore: IP Networks as a Service, Deliverable D1.1 – Project Presentation, http://www.mantychore.eu/wp-content/files/MFP7%20D1%20r4.pdf

[MARTFLAT] Martin-Flatin, J.-P., S. Znaty, and J.-P. Hubaux, A Survey of Distributed Enterprise Network and Systems Management Paradigms. J. Netw. Syst. Manage., 1999. 7(1): p. 9-26.

[ONF] https://www.opennetworking.org [ONF-SDN] Open Networking Foundation. White Paper. Software-Defined Networking: The New

Norm for Networks. April 13. 2012. Available online: https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf

[OPENFLOW] http://www.openflow.org [OPENNAAS] http://www.opennaas.org [OPENNET] D.Liberal, O.Lundström, T.Rautiainen, P.Samlin, M.Setterberg, SwedenOpen.net?,

Technical Report from a Communication Systems Design course project, KTH/IMIT, May 2003

[REST] R. Fielding, Architectural Styles and the Design of Network-based Software Architectures, 2000. Available online: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

[RFC1157] J. Case, M. Fedor, M. Schoffstall, J. Davin, Simple Network Management Protocol (SNMP), RFC 1157, May 1990

[RFC2819] S. Waldbusser, Remote Network Monitoring Management Information Base, IETF RFC 2819, May 2000

[RFC3414] U. Blumenthal, B. Wijnen, User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), IETF RFC 3414, December 2002

[RFC3416] R. Presuhn, J. Case, K. McCloghrie, M. Rose, S. Waldbusser, ersion 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP), IETF RFC 3416, December 2012

[RFC4251] T. Ylonen, C. Lonvick, Ed., The Secure Shell (SSH) Protocol Architecture, IETF RFC 4251, January 2006

[RFC4502] S. Waldbusser, Remote Network Monitoring Management Information Base Version 2, IETF, RFC 4502, May 2006

[RFC5246] T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246, August 2008

[RFC5277] S. Chisholm, H. Trevino, NETCONF Event Notifications, IETF RFC 5277, July 2008 [RFC6241] R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed., Network

Configuration Protocol (NETCONF), IETF RFC 6241, June 2011 [SOAP] [http://www.w3.org/TR/soap/ [Y.1731] Recommendation Y.1731, OAM functions and mechanisms for Ethernet based

networks, ITU-T, July 2011 [W3SCHEMA] http://www.w3.org/XML/Schema

sodales - europa

Documents