1. NOBEL WP4 Meeting – Dec 1st, 2004
Control Plane modeling for ASTN: guidelines and experimental activities
NOBEL WP4 Meeting – Dec 1st, 2004

2. Outline Objective: CP operation relevant aspects: Reference standard:
Information Modeling (IM) definition related to Control Plane (CP) operation: CP_T & CP_C
Rigorous modeling and easy scalability
CP operation relevant aspects:
State of the control plane network elements
Routing and signaling information
Switched connectivity establishment (SPC and SC)
Reference standard:
ITU-T G.805: Generic functional architecture of transport networks
ITU-T M.3100: Generic Network Information Model
ITU-T G.8080: Architecture for the Automatic Switched Optical Network (ASON)
Steps:
Study of internal functional blocks for a generic CP network element (CPE)
Layering according to switching capability of transport network element
Definition of IM fragment related to CP operation
Testbed implementation for IM validation
The goal of this research activity is to define an Information Modeling related to Control Plane operation supporting the automatic mechanism of ASON. IM is an abstract representation of a network entity (in this case CP node) for management purpose.
The relevant aspect related to CP operation for management purpose and needed to be considered in CP IM are:
State of network composed by a set of control plane network elements (equipment configuration, alarms)
Control information flowing in CP related to routing and signaling (network topology, resource discovery and allocation)
Switched connectivity management on client network request resulting in TP node resource settings.
As the control plane network controls the underlying transport network,there are obviosly some dependencies between the resources of both networks. A connection configured in the CP finally uses transport resource of the transport plane. So we can distinguish CP(C) IM for CP node resouce and functionalities from CP(T) IM describing the TP resource as presented to the management plane through the CP.
ITU-T stands for the telecom standardization organization of the International Telecommunication Union.
ITU-T M.3000 recommendation series constitutes a management framework widespread adopted by the most important telecommunication vendors. In addition ITU-T introduces a new architecture called Automatic Switched Optical Network (ASON), defined in G.8080 recommendation, that should be considered as a starting point for our approach towards Control Plane modeling, taking into account G.805 functional layering approach adopted by M.3xxx Recommendations.
Steps that we are carrying out are the study of functional internal operation of CP network element in order to identify the constituting functional blocks and their interactions and a functional network layering according to switching capability. This permit to define dedicate IM fragment or extension to those already defined in order to extend the M.3100 IM for Generic Transport network.

3. Layering & Partitioning Concepts - G.805
= subnetwork
Layering view
(Client/Server Association)
Partitioning concept
(applied to a signle layer network)
Specific Layer
Network
Client
Server
Layer network
Sublayer
Sublayer
Sublayer
Modeling the Control Plane vision of the Transport Plane, by following ITU-T directives, implies the application of the G.805 formalism as G.8080 suggests. According with G.805, a transport network can be decomposed into a number of independent transport layer networks with a client/server association between adjacent layer networks. G.805 presents the layering concept as a fundamental of that information model. A layer network is defined by the complete set of access groups of the same type which may be associated for the purpose of transferring information. The information transferred is characteristic of the layer network and is termed characteristic information. The concept of layering helps manage the complexity created by the presence of different types of characteristic information in networks. A layered network is also called vertically structured.
Within a single layer, complexity is introduced by the presence of many different network nodes and the connections between them. In G.805 recommendation, in order to manage the complexity, the concept of partitioning is introduced. It uses the principle of recursion to tailor the amount of detail needed to be understood at any particular time according to the need of the viewer. Sub-networks are constructs that are confined to a layer network. Partitioning involves the division of layer networks into separate sub-networks interconnected by links and provides ability to flexibly partition a layer network into subnetworks due to management reasons that in turn can be further partitioned into smaller sub-networks. A partitioned layer is also called horizontally structured. The concepts of partitioning and layering are orthogonal.
We propose to adopt the recursive layering concept in which a layer can be in turn subdivided in two or more layers. TP layering is the starting point for determining the set of CP involved in subnetworks in which routing funcionaliy are provided. These CP, through a mapping between the TP name domain and the CP name domain, permit to obtain a suitable layering of the Control Plane as shown in the following figure.
Layer network that is recursively partitioned subnetworks

4. Subnetwork point (SNP) - G.8080
CP = Connection Point
TCP = Termination Connection Point
SNC = Sub Network Connection
SNP = Sub Network Point
SNPP = Sub Network Point Pool
CTP = Connection Termination Point
TTP = Trail Termination Point
TTP (M.3100)
TTP (M.3100)
TTP (M.3100)
TTP (M.3100)
TCP (G.805)
TCP (G.805)
TCP (G.805)
TCP (G.805)
Subnetwork
Subnetwork
SNP
SNP
SNP
SNP
SNC
SNC
SNP Link Connection
SNP Link Connection
SNC
SNC
Link Connection
Link Connection
CP (G.805)
CP (G.805)
CP (G.805)
CP (G.805)
CTP (M.3100)
CTP (M.3100)
CTP (M.3100)
CTP (M.3100)
For the purpose of managing simple native connections, the underlying transport plane resources are represented by a number of entities in the control plane. The first step for obtaining a compliant ITU-T CP modeling is determine the set of layers the CP should be subdivided. TP layering according to G.805 reflects how the data flow transport is articulated across the network starting from the source and arriving to destination. CP is focused on controlling this data flow through routing and signalling and therefore the CP layering should be bound to the dynamic switching capability of the transport network in order to take into account the switched connectivity.
Unfortunately the objects defined in G.805, were deployed taking in mind the transport capability of the network without any explicitly reference to the dynamic aspects of the transport like the routing. G.805 defined objects should be considered as a good starting point but more ad-hoc objects are needed for modeling in particular the routing functionality of the CP. This slide shows the relationship between the transport resources described in G.805, the entities that represent these resources for the purposes of network management (as described in Recommendation M.3100) and the view of the transport resources as seen by the control plane.
In G.8080, for the purpose of network control (i.e. for signalling purposes), the vision of transport resources is described in terms of relation among reference points that represent the end-point of connections called Subnetwork Point (SNP). The SNP is an abstraction that represents an actual or potential underlying CP or CTP or an actual or potential TCP or TTP. Several SNP’s (in different subnetwork partitions) may represent the same TCP or CP. UML diagram class of the SNP related objects is reported on the right.
The control processing handle information in terms of relationship among reference point SNP.
An SNP has two principal relationships with other SNPs: a static one, called SNP link connection, that is between two SNP’s in different subnetworks and a dynamic one, called subnetwork connection, that is between two (or more in the case of broadcast connections) subnetwork points at the boundary of the same subnetwork.
The G.8080 efforts for modeling the routing functionality consists in the introduction of the subnetwork point pool (SNPP) that is defined as a set of SNP that are grouped together for the purpose of routing. One use of this sub-structuring is to describe different degrees of route diversity. For example, all the SNPs in one subnetwork that have a relationship to a similar group on another subnetwork may be grouped into a single SNPP. This SNPP may be further sub-divided to represent diverse routes and further sub-divided to represent, for example, individual wavelengths. The association between SNPPs on different subnetworks is an SNPP link.
Trail
Trail

5. CP layering according to switching capability
CPE
CPE
Layer n+3
Layer n+2
Layer n
Layer n+1
Transport Plane Modeling
Layer m+1
Layer m
Control Plane Modeling
CPE
CCI
NNI
CPE
CPE
This slide represent an example of the application of the CP layering concept. The transport plane is composed by 4 elements. The information model of every NE is composed by 2 layers which only one provided with switching capability. The number of layer of the CP information model should reflects the number of layer of the transport plane provided with switching capability. In this case we have 2 layer in the CP as shown in the slide. Every CP layer should be considered as a container of 2 layer of the transport plane (we have applied the concept of sublayering expressed in ITU-T G.805 recommendation).
It is important to underline that we have a functional CPE layer for every switching layer present in a generic NE information model.

6. CPE layer-n functional components
Connection
Controller (CC)
Link Resource
Manager (LRM)
Routing
Controller (RC)
Termination &
Adaptation
Performer (TAP)
Discovery
Agent (DA)
RDB
Call Controller
LRM DB
Client NE
CCI
NNI
UNI Port
UNI protocol
Controller
NNI Protocol
NNI Port
UNI
This slide shows the functinal blocks for CP network element as reported by G.8080 with some of them introduced by ourself.
Link Resource Manager (G.8080)
The LRM conponents are responsible for the management of an SNPP link, this includes the allocation and release of link connection and providing topology and status information.
Routing controller (G.8080)
The role of the routing controller is to:
 respond to requests from connection controllers for path (route) information needed to set up connections. This information can vary from end-to-end (e.g., source routing) to next hop.
respond to requests for topology (SNPs and their abstractions) information for network management purposes.
Call Controller (G.8080)
The call controller role is to manage call request coming from client network and to trigger the connection controller in order to fullfil it.
Connection Controller (G.8080)
The connection controller is responsible for coordination among the Link Resource Manager, Routing Controller. This component services a single subnetwork and can communicate through the NNI Controller with both peer and subordinate Connection Controllers (subordinate CC belonged to adjacent CP layers) for the purpose of the management and supervision of connection set-ups, releases and the modification of connection parameters for existing connections. The request parameters comprise a pair of SNP that are in the scope of this controller. A Link connection (as an SNP pair) or a subnetwork connection are given as result of connection set-up.
Discovery Agent (DA) (G.8080)
 The federation of DAs operates in transport plane name space and provides for separation between that space and CP space. The role of the DA is to looking for CP-CP link established in the TP an than communicates them to the TAP functional block that in turn maps those connections into a set of SNP - SNP link connection. These relationships may be discovered (or confirmed against a network plan) using a number of different techniques for example use of a test signal or derived from a trail trace in the server layer.
Termination and Adaptation Performer (TAP) (G.8080)
 TAP provides a control plane view of the link connection, and hides any hardware and technology specific details of the adaptation and termination control. This is achieved by assigning an SNP for every CTP related to the IM of the TP and controlled by the CPE, and placing those SNP in the corresponding CP sublayer. In fact the role of the TAP is to map the IM objects of the TP, found by the DA and compliant with the M.3100, in objects of the CP IM compliant with G.8080 recommendation.
NNI Port (NP) (our proposal)  
Permits to manage the communication between a CC and a set of CC on different CPE. It supports a set of NNI Protocol Controller.
 NNI Protocol Controller (NPC) (our proposal)  
This entity permits the communication between two CC by implementing the NNI protocol.
UNIPort (UP) (our proposal) 
It permits to manage the communication between a Call controller and a set of end users. It supports a set of UNI Protocol Controller.
UNI Protocol Controller (UPC) (our proposal)
 This entity permits the communication between a Call controller and a specific end user by implementing the UNI protocol.
from G.8080 in black
from SOON (our proposal) in blue

7. Reference interfaces: Inter-NNI Intra-NNI
CPE
Layer n+1
Layer n
Layer n-1
UNI
Intra NNI
Inter NNI
Domain A
E-NNI
The CPE modeling described in the previous slide is meant for each layer network in a way that the overall CP operation is the result of interoperation between blocks belonging to different layers, phisical control network elements and domain.
In particular we differentiated I-NNI to take into account the layer interoperation:
Inter NNI: client-server relationship between layers belonging to the same CPE
Intra NNI: p2p relationship between layers beloging to different CPE in the same domain.
CPE
CPE

8. Work in progress
Extend the scope of the M.3100 Generic Information Model
M.3100 IM fragments:
Network fragment
Managed element fragment
Termination Point fragment
Transmission fragment
Cross connection fragment
Functional Area fragment
M.3100 extension to Termination Point fragment related to SNP objects relevant for control information management
M.3100 additional fragments in order to take into account the switched connection set-up, routing and signaling processing
M.3100 provides generally useful object classes that can be supplied to support the TMN architecture or in other words uniform mechanisms to support fault, configuration, performance, security and accouting management. After the CP introduction the management framework has to be extended in order to include the management of the automatic capability introduced by CP operation.
The M.3100 specification is organized into 6 “fragments” combined to form the Generic Information Model. At the moment thay are:
Network Fragment: defines the relationship between a managed network and its related trails, connections and management elements
Managed Element: defines the components and relationships contained in a single managed element. A generic Management Element contains Equipment (including Software) along with Trail Termination Point and Fabric
Termination Point: contains the types of terminations that a single piece of managed equipment may contain. Both trail and connection termination point are included in this fragment
Transmission Fragment: provides a functional (not-equipment oriented view) of communications through a network according to G.805. Two forms of transmission entities are defined: trails and connections. The relationship between these entities and references to their relative termination points are included in this fragment.
Cross connection Fragment: helps in managing cross connect fabric topologies
Functional Area Fragment: defines the classes of objects contained within a managed element to provide additional management services, such as Log, alarm management, event forwarding discriminator, etc etc.
In order to take into account the CP operation an additional fragments should be considered in order to manage the soft-permanent connection, the routing processing and the internal functional behavior of the controlled CP element.
Furthermore an extention to Termination Points fragment should be considered in order to include the SNP objects relevant for control needs.

9. The CP modeling experiment activity
Verification of the ITU-T G.8080 Control Plane Element modeling.
Valuation of the scalability of the CP multilayer modeling by comparing the results obtained with a transport plane equivalent simulation based on a CP single layer approach.
Development of a NE independent CCI communication protocol able, at the same time, to support the layer specific constrains.
Study of the client-server network interaction via UNI for the creation and maintenance of switched connections.
Study of the Control Plane INTRA and INTER layers communication via NNI for supporting the routing and signalling processing.
The experiment activity of the SOON Control Plane Modeling research area requires a testbed able to easily obtain the following goals:
Verify the ITU-T G.8080 Control Plane Element (CPE) modeling by implementing a CPE composed by the same functional blocks expressed in the recommendation itself in order to determine the exact role of each block inside the functional architecture (open issue in G.8080).
Valuate the scalability of the SOON CP multilayer modeling by comparing the results obtained with an transport plane equivalent simulation based on a CP single layer approach.
Design and develop a NE independent CCI communication protocol able, at the same time, to support the layer specific constrains.
Study the client-server network interaction via UNI for the creation and maintenance of switched connections.
Study the Control Plane INTRA and INTER layers communication via NNI for supporting the routing and signalling processing.

10. The SOON Simulated Testbed
In order to achieve the presented goals we need a testbed composed by:
a transport network with at least 2 layers provided with switching capability and more than 3 nodes per layer
a control plane compliant with the ITU-T G.8080 Recommendation
a set of data traffic generator device and a set of data traffic analyser
Solution:
Utilize a discrete-event network simulation tool that permits to easily implement the CP and provided with a large network element library for achieve a realistic implementation of a complex transport planes.
Tool adopted:
J-Sim* ( a Java-based freeware discrete-event simulator based on the Autonomous Component Architecture (ACA)
*project partially supported by:
NSF Next Generation Software program, DARPA/IPTO network modeling and simulation program, MURI/AFOSR, Cisco Systems, Inc., Ohio State University, and University of Illinois at Urbana-Champaign.
In order to achieve the presented goals we need a testbed composed by: a transport network with at least 2 layers provided with switching capability and more than 3 nodes per layer, a control plane compliant with the ITU-T G.8080 recommendation, a set of data traffic generator device and a set of data traffic analyser (traffic data generator/analyser can be considered as generic network clients for testbed purpose).
Create a testbed based on real device is an effort too big and a cost too high for a single research center. In addition the commercial device are often black box and doesn’t permit to easily interact with self-made software tool (for example CPE software running on a PC).
A reasonable solution is the utilization of a discrete-event network simulation tool able to easily implement the CP, provided with a large network element library for achieve a realistic implementation of a complex transport plane.
We decided to adopt J-Sim ( a Java-based freeware discrete-event simulator based on the Autonomous Component Architecture (ACA).
J-Sim project is partially supported by:
NSF Next Generation Software program
DARPA/IPTO network modeling and simulation program
MURI/AFOSR
Cisco Systems, Inc.
Ohio State University
University of Illinois at Urbana-Champaign.

11. Tesbed Screen shot taken by J-Sim Editor UNI NNI CCI Data
Every traffic generator (H1-4) and traffic receiver (H5-8) is connected via UNI to a different CPE that control the edge of the simulated transport network (in this case the edge layer is represented by the GE Router). All the CPE are connected via NNI with a network topology completely different from the transport plane one. The transport plane network is designed in order to permit the connection of every couple of traffic generator and traffic receiver using different paths, depending of the state of the switchers (in this case we have only two switcher state: BAR or CROSS). This permits to evaluate the CP capacity of providing switched connection with random duration (we can think for example of a service of FTP GRID in which a high bandwidth is required but only for a small amount of time).
UNI
NNI
CCI
Data
Bidirectional
Connection
Unidirectional
Screen shot taken
by J-Sim Editor

12. Testbed CPE internal structure
Numero a piacere di interfacce UNI e NNI settabili.
NNI Controller gestisce il flooding intelligente per gestire il o I protocolli dell NNI (Intra e inter) gestiti
LRM che gestisce una interfaccia CCI con protocollo NE independent
Screen shot taken
by J-Sim Editor

13. Experimental activities work in progress
Determine a complete CCI, UNI and NNI message sets for achieving a layer independent CPE architecture.
Increase the number of network nodes and the number of layers in the simulated testbed for verifying the scalability of the CP modeling proposed.
Introduce the SOON Service Plane in the testbed.
Create an hybrid testbed able to combine the simulated CP with real network device.
The next steps in this experimental research activity are:
Determine a complete CCI, UNI and NNI message sets for achieving a layer independent CPE architecture
Increase the number of network nodes and the number of layers in the simulated testbed for verifying the scalability of the CP modeling proposed. In particular we want to realize the lambda switching layer by providing J-Sim lambda switching and lambda ADDROP components.
Introduce the SOON Service Plane in the testbed in order to integrate the results obtained with the CP modeling with the architecture proposed for a generic Service Provider.
Create an hybrid testbed able to combine the simulated CP with real network device by utilizing socket communication between simulated CPE and a software tool that control a network element (for example a Juniper Router via Junoscript XML-based interface or a Marconi PMA 32 via Qx interface).

14. Thank You!

15. The SOON project Customer Service Plane Control Plane Transport Plane
SP activities:
Dedicated functional blocks definition
IN concept application
Separation of the Service Provider from Network Provider
Standard interface development
Control Plane
Transport Plane
NMI-T
NMI-A
CSI
UNI
CCI
Service Plane
Management
Plane X
ASTN
Customer
SO-ASTN
CP Modeling:
Vision of the TP through CP
Functional layering
Reference Point definition
CP network element modeling
Functional blocks definition
CCI standardization
UNI - NNI development
MP Modeling:
IM extension for CP management
NMI-A standartization
Testbed:
Pisa Metro/Core DWDM Ring
Acreo Stockholm testbed
J-Sim based Simulated testbed