March 2006WP41 NOBEL Technical Audit WP4 Objectives & Achievements Brussels, March 08, 2006 Work Package 4 Network Management and Control/Protocols Monika.

March 2006WP4 1

NOBEL Technical AuditWP4 Objectives & Achievements

Brussels, March 08, 2006

Work Package 4

Network Management and Control/Protocols

Monika Jaeger, T-Systems

March 2006WP4 2

Nobel Objectives

• To define requirements, architecture and solutions for core-metro IP-over-optical networks for broadband end-to-end services

• To study advanced network functionalities such as multi-layer traffic engineering and multi-layer resilience

• To make techno- and socio-economic analysis of core and metro case-studies

• To find packet/burst switching techniques and technologies

• To discover innovative solutions for the three network planes: management, control and data (transmission)

• To define multi-service/multi-layer node architectures and to prototype the implementation of some selected node functionalities

• To assess existing technologies, components and sub-systems

• To integrate some test beds where to validate the project results

WP4

March 2006WP4 3

WP4 Objectives

Overall WP4 goal:

NOBEL short, mid, long-term network scenarios from WP1…

… analyze and propose simplified strategies and collaboration of Network Management and Control

Nobel Network Scenario WP4

• To analyze and propose solutions to lower the Network Management and Control complexity in core and metro networks

• To develop management and control strategies/functions for the evolutionary NOBEL network scenarios and architectures

• To investigate a comprehensive set of practical management and control aspects, leading to more simplified and efficient solutions (to be communicated towards standardization)

• To design and perform ASON/GMPLS and management prototype implementations with experimental evaluations, in complement to the conceptual studies

March 2006WP4 4

Activity Summary

• A4.1 - Network Management (NM) and Control/Protocol (CP) requirements and functional scope

• A4.2 - Performance, fault management, fault localization, and QoS monitoring requirements and solutions

• A4.3 - Inter-domain, multilayer NM , CP, and Service Management aspects

• A4.4 - Standardization approaches, especially centralized vs. distributed implementation of NM and CP functions

• A4.5 - NM and CP prototype function and design specification, implementation and test

March 2006WP4 5

WP4 Partners

Contributing partners

• Alcatel CIT

• T-Systems (WP4 coordinator)

• Telecom Italia Lab

• Siemens

• Telefónica

• Marconi Comm. S.p.A.

• (Marconi ONDATA)

• Scuola Sup. S. Anna

Planned total Manpower for 2004 and 2005: 352 MM

• Telenor

• Lucent Nederland BV

• TeliaSonera

• CTTC• Alcatel Italia

• ACREO

• France Télécom• Ericsson

March 2006WP4 6

CoreArea

AggregationArea

AggregationArea

Access • Business

Customers• Mass production • DSL public• FTTx

IP/Optical Network Introduction M

ulti-

Tec

hnol

ogy/

Ser

vice

A

cces

s A

rea

Multi-T

echnology/Service

Access A

rea

Core• High throughput at very

low cost in backbone area

• Optical technology• Scalability, open for

growth

Aggregation • Efficient aggregation

of multiple data streams in metro/regio area

• Support of different services

Network Areas

IP

Trans-port

March 2006WP4 7

WP4 Overall ViewReference Points and Domains

CP = Control PlaneMP = Management PlaneTP = Transport planeUNI = User Network InterfaceE-NNI = External Network Network InterfaceNMI-A = Network Management Interface, MP-CPNMI-T = Network Management Interface, MP-TPCCI = Connection Controller InterfaceUPI = User-Provider Interface PPI = Provider-Provider Interface

UPI

Client (User) - A Network Provider - A Network Provider - B

TP TP TP TP

UNI-C

NMI-A

Intra-carrier E-NNICCINMI-T

CPUNI

CP

PPI

CP

MP

MP

Inter-carrier E-NNI

Switched Connection Service– Voice/packet oriented management model– Transport oriented (SDH/OTH) management model– Hybrid management model

= SubNetwork

March 2006WP4 8

Core and Metro Networks

• Multilayer infrastructure …– Circuit and packet based

switching technologies

– Aggregation and grooming

• … with independent network management

– Service configuration

– Fault management

– Protection and Restoration…

• … some layers have control plane

– IP/MPLS deployed

– ASON/GMPLS?

– Ethernet?

IP

GigE

SDH

WDM

Management

Management

Management

Management

State of the Art

March 2006WP4 9

ASON controls point-to-point connectivity for L1/L2-services, over single and multiple domains

Resilience of L1 and L2 services Offers support for flexible VPN

services Ethernet services based on GFP,

LCAS ASON as server layer of IP creates

(IP topology), redirects (resilience) and modifies (bandwidth) dynamically links between IP/MPLS/GMPLS routers

ASON/GMPLS Control Plane Benefits

OpEx ReductionCapEx Reduction Automatic discovery mechanisms Automatic provisioning, TE and

resilience Alarm correlations and reductions Offloaded and simplified

management Simplified automated inter-working

with other administrative domains

Less backup capacity with restoration and shared mesh protection (up to 30 %)

Reduced over-provisioning with resource efficiency due to dynamic resource assignment

Enhanced traffic engineering capabilities

Efficient aggregation and grooming

Simplified integration of new equipment

Interoperability at control plane level between different vendor implementations at UNI and NNI interfaces

Increased scalability for IP Simplified Inter-working with MPLS

and Ethernet

New services (ASON specific) Simpler Network Integration

March 2006WP4 10

Control Plane Issues in WP4Multi-Service/Layer/Domain Scenarios

Multi-vendor/-technology functional architectures and generic modelingconcepts for multi-domain ASON/GMPLS networks, managed by TMF-MTNM:

Main objectives:• Identify architecture and control suited for specific service scenario

– No single network architecture and control scenario fits all services and business models

• Identify simplified control and management solutions• Resolve general interoperability issues raised by NOBEL scenarios

(provided in WP1)• Fine tune protocols as well enable converge toward real exploitation

perspectives• Verify concepts through implementation and test

March 2006WP4 11

Control Plane Issues in WP4 Scope and Results

Detailed objectives:

• Horizontal integration: Inter-domain collaborative mechanisms– Cooperation between MPLS-GMPLS and migration scenarios– Compatibility issues between ASON and GMPLS concepts and paradigms– Propose enhancements to an IP-based (end-to-end) signaling protocol – Inter-carrier interworking at E-NNI

• Vertical integration: Intra-domain cooperation between different data planes– Multilayer networks and common control plane, including TE– Unified Traffic Engineering in GMPLS networks– Layer 2 LSP and GMPLS for Ethernet– Path Computation Element (PCE), and its applications, for (G)MPLS

• Operational aspects for the GMPLS stack of protocols– Control Plane dimensioning and performance analysis– Restoration in multilayer and multi-domain networks

March 2006WP4 12

Control Plane Issues in WP4NG-SDH, GFP, VCAT, LCAS

• The integration of NG-SDH into the control plane could provide benefits regarding:

– Non-disruptive bandwidth modification

– Increase the resilience of the network

• To accomplish this, control plane should be properly enhanced:

– Support of multi-layer calls.

– Call and connection separation and support of calls composed of multiple connections.

– Bandwidth modifications

– End-to-end path diversity

March 2006WP4 13

Control Plane Issues in WP4NG-SDH, GFP, VCAT, LCAS

• Support of multi-layer calls:– All the connections at the server layer should be created before the connection

at client layer. This sequence allows also the correct coordination between the control plane and the SDH VCAT/LCAS procedures

• Call and connection separation:– Two approaches from ITU-T and IETF, whose differences are more in the form

than in the substance.

– ITU-T: a new object (CALL_ID) in two forms (Globally unique, operator specific)

– IETF: use of unused fields in already existing objects

• Bandwidth modifications– Modify bandwidth of existing calls (Ethernet)

– Add new connections to existing calls (SDH)

• End-to-end path diversity– In the scope of the work of the PCE Wg

March 2006WP4 14

Information modelling Objectives and approach

Based on requirements for (automating) the CP - MP interaction• Considering and harmonizing existing functional architectures and models:

– ITU-T, e.g. G.8080, G.805, G.7718, M.3100, and TMF (MTNM 608),and previous IST projects LION, WINMAN

– IETF GMPLS, and MPLS/GMPLS MIBs

To develop an information model for CP – MP collaboration, that enables and supports:

– End-to-end service establishment and management– Efficient, flexible, and adaptive management and control mechanisms– Multilayer, multi-technology, multi-domain networks– Innovative Policy-based management framework

• Focusing first on a model of managed entities representing the CP itself, its components, and capabilities, and how CP components are related

To derive a policy information model for enabling policy-based management and configuration of the CP itself and for improving the TP operational management via the CP

Work in progress – work to continue in NOBEL 2

March 2006WP4 15

Relationship of Information Modelling Standards and IST Projects Results

ITU-T

TMF

IETF

Winman

NEL view

use case approach

info modeland use cases

NL view

infomodel

modeling approach, info modeland architectureNEL view

Sta

ndar

disa

tion

NOBEL approach +integration of

existing resultsFocus of IM work

NMI-A

CP

MP

. . .

. . .

March 2006WP4 16

CP Node and CP Elementexample configuration (not IM as such)

March 2006WP4 17

Routing Controllers in CP Element and CP domain

March 2006WP4 18

Information modelling – Further work (NOBEL 2)

• Continue the requirements analysis and design phases with review of relevant sources to assess, update, and improve the current model

• Open issues and areas not jet covered by the model:– E.g., management capabilities related to TE, resilience, and path computation,

VPN, accounting, and SLA assurance

• To derive a policy information model to enable policy-based management and configuration of CP mechanisms and the TP via management of the CP

– The role and relationship of the management information model and the policy information model must be carefully considered

– To investigate and extend existing policy information models(E.g. IETF PCIM/PCIMe, QPIM)

• Contribute to standardisation

March 2006WP4 19

Implementation Activities in WP4 Objectives and Realization

A4.5 - NM and CP prototype function and design specification, implementation and test

Objectives: Implementation of selected features specified in WP4 Integration into prototypes and emulators Lab experiments, function verification and performance measurements Overall conclusions and recommendations derived from experiment results Integration into testbeds for field trials and interoperability tests in WP8

Realization: Eight partners implement new features in prototypes and emulators partly reused

from internal or other EU projects Focused on UNI (8x), E-NNI (3x) , hybrid performance monitoring (1x), XMP-based

multi-protocol frameworks (1x) Delivery to four testbeds in Spain, Sweden and Italy

March 2006WP4 20

Achievements

SDH/OTH Prototypes UNI implementations (x4)

– Optical node, OTH and SDH

E-NNI implementations (x3)– Optical node, OTH and SDH

Optical peformance monitoring implementation

– OTH

Protocol controller implementation– Based on an XLM parser/formatter

Emulators & Simulators GMPLS UNI implementation for an

ASON/GMPLS simulator (x2)

E-NNI implementation on a simulator

CCI, UNI and NNI implementation on a simulator

Planning & SpecificationSelection of implementation features: (GMPLS) UNI, E-NNi, XML protocol controller,

optical performance monitoring

Concept and design specification for the prototype, emulators and simulators

Test specification

March 2006WP4 21

Developed Prototypes

Functions Platform Remarks

Alcatel CIT GMPLS UNI, end-to-end IP/MPLS - SDH emulator -

CTTC GMPLS UNI/E-NNI, Advanced hybrid optical performance monitoring system

Distributed GMPLS, 3 OADMS, 3 DWDM links + emulated links + IP traffic generator + GMPLS emulator

WP8 test-bedUNI/E-NNI results in [D18]

Marconi SpA OIF UNI 2.0OIF E-NNI 1.0

IP-SDH emulator -

Lucent GMPLS Control Plane Enhanced GMPLS emulator eGem

WP8 testbed

Sant’Anna UNI/NNI simulatedXML-based Multi-Protocol Framework (XMPF) implementation

Simulator based on J-SIM -

Siemens OIF UNI 1.0R2 (optional 2.0) 2 SDH XC + IP-SDH emulator

Part of TILAB testbed

Telefonica I&D OIF UNI 1.0R2 IP-SDH emulator WP8 testbed final results in [D25]

TILAB OIF UNI 1.0R2OIF E-NNI, signalling 1.0,routing OIF2002.023.09

6 photonic XCs WP8 testbed

March 2006WP4 22

WP4 Deliverables and Publications (Y2)

• D18 “Conclusions on NM and CP functional scope and standardization approaches; NM and ASON prototype functional scope”(March 2005)

• D25 “Solutions for inter-domain and multi-layer NM & CP and Service Management concepts; NM and ASON prototype functional and design specification and test plan” (September 2005)

• D33 “Conclusions on Network Management and Control solutions supporting broadband services for all” (February 2006)

March 2006WP4 23

WP4 Deliverables and Publications II (Y2)

• Guillaume Juillot, Martin Nathansen, Cyril Margaria, and Andreas Iselt; "Emulation in GMPLS-controlled Optical Transport Networks"; ONDM2005, Milano, Italy, February 2005.

• G. Juillot, C. Margaria, M. Nathansen, A. Iselt; "Emulation of GMPLS controlled Networks"; NOC2005, London, England, July 2005.

• M. Vigoureux, B. Berde, L. Andersson, T. Cinkler, L. Levrau, M. Ondata, D. Colle, J. Fernandez-Palacios, M. Jäger; “Multilayer traffic engineering for GMPLS-enabled networks”; IEEE Communications Magazine, ISSN 0163-6804/05, Vol. 43, Nr. 7, July 2005, pp. 44-50.

• B. Berde, M. Canali, P. Castoldi, M. Jäger, L. Levrau, H. Lønsethagen, A. M. Mazzini, M. Nathansen, J. Gonzales Ordàs; "Network Management and Control for Intelligent and Agile Optical Networks"; ONDM2005, Milano, Italy, February 2005.

March 2006WP4 24

WP4 Deliverables and Publications III (Y2)

• C. Pinart, A. Amrani, G. Junyent; “Design and experimental implementation of a hybrid optical performance monitoring system for in-service SLA guarantee”; 9th IFIP/IEEE International Symposium on Integrated Network Management (IM 2005), Nice, France, May 16-19 2005.

• C. Pinart, R. Martínez, G. Junyent; “Experimental implementation of dynamic in-service performance monitoring for lambda services”; 31st European Conference on Optical Communications (ECOC 2005), Glasgow, UK, September 25-29 2005.

• L. Valcarenghi, L. Foschini, F. Paolucci, F. Cugini, P. Castoldi; "Topology Discovery Services for Monitoring the Global Grid"; IEEE Communication magazine special issue on "Optical Control Plane for Grid Networks: Opportunities, Challenges and the Vision", to appear, March 2006.

March 2006WP4 25

WP4 Highlights and Self AssessmentReached Objectives Year 2

• Definition of requirements, key characteristics, architectures and solutions of multi-service/layer/domain network management and control

• Analysis of functional architectures; recommendations on generic modelling concepts and key features of ASON/GMPLS

• Network service requirements, w.f.o. Layer 1, 2, 3 VPNs; Control and management scenarios of storage, broadcaster and grid applications as users of VPN services; CP enabled solutions for VPN services

• Control plane issues for TE in multilayer/multi-technology networks• Inter-carrier interworking scenarios; identification of functional requirements

related to different business models• ASON-GMPLS convergence issues and required harmonization actions• MPLS-GMPLS interworking, MPLS-GMPLS migration scenarios• Information Modeling requirements with focus on the interaction of the

control plane and management plane• Implementation of key functions of network management and control and

performance of selected tests, in cooperation with WP8

March 2006WP4 26

WP1/WP4 Common Activities

• VPN service scenarios and solutions• Service Supportive Networks

March 2006WP4 27

VPN Reference Model

Shared or dedicated resources• Transport plane

– Physical port based (dedicated)

– Logical port based (dedicated)

– Node based (dedicated)– Connection based (shared)– Closed User Group

(shared)

• Control plane– One CP instance per VPN

(dedicated)– One global CP instance

with optional resource partitioning (shared)

UNI

Customer 2 Customer 1

UNI

Customer 2

UNI

Customer 1

is connected to

can connect to

has visibility

March 2006WP4 28

VPN – general investigations

L1/ L2/ L3 VPNs that are based on advanced control plane functions, and its related management framework

Investigate types of L1 VPNs and related UNI/ NNI functionalities

Study inter-domain issues (intra-/inter-carrier) in L2/L3 VPNs

Capture management requirements for novel VPN services

Propose a potentially homogeneous solution to (control plane-based) Layer 1, 2, and 3 VPNs, and their management issues with reference to the NOBEL scenarios

Specify CE/PE management functions at customer and provider side: definitions, functionality, architectures, Information Model

Identify VPN implementation issues

March 2006WP4 29

State of the art

• L3 VPNs– Mature technology– Available for several years

• L2 VPNs– Many commercial offerings– Most specs ready for publication

• L1 VPNs– No (known) provider offering them– No (full) support from vendors– Timeframe for availability: Q2-2007

• IETF– L2 and L3 VPN working groups– RFC3809 “Generic Requirements for Provider Provisioned Virtual Private Networks”– L1 VPNs not (yet) in CCAMP charter

• ITU-T– Study Group 13, Question 2– Published standards

• Y.1311: Network Based VPNs - Generic Architecture and Service Requirements• Y.1312: L1 VPN generic requirements and architectures• Y.1313: L1 VPN service and network architectures

– Work in progress• Y.vpn-decomp: Generic VPN Functional Decomposition • Y.vpn-qos: QoS support for VPN services – Framework and Characteristics

• OIF– No support for VPNs in UNI 1.0 or UNI 2.0– Planned for an unspecified future release

March 2006WP4 30

Multiple services VPNs

LxVPN LxVPN

L1VPN

ProviderNetwork

service 1 (e.g. Video) service 2 (e.g. SAN traffic)

x={1,2,3} LxVPN LxVPN

L1VPN

ProviderNetwork

LxVPN LxVPN

L1VPN

ProviderNetwork

x={1,2,3}

service 1 (e.g. Video) service 2 (e.g. SAN traffic)

March 2006WP4 31

VPN Service ScenariosJoint WP1-WP4 work

• VPNs for broadcasters– Contribution and distribution network for standard TV, high definition TV etc.– Study of L1-VPNs and L2-VPN implementation options

• VPNs for storage applications– Remote vaulting and backup– Synchronous and asynchronous disk mirroring– Storage on demand needs flexible resource, high sensibility to latency, packet

loss and BER

• VPNs for GRIDs– Studies impact of overlay networks in VPNs– Virtualization of network, complements processing and storage virtualization– Very high bandwidth needs, flexibility

March 2006WP4 32

Interaction between customer and network provider: Interfaces

Management Plane

Use

r m

etw

ork

Business Plane/Service Plane

Management Plane

Use

r N

etw

ork

Business Plane/Service Plane

Management Plane

Use

r N

etw

ork

Business Plane/Service PlaneWeb

Interface

a) Advanced reservation (I) b) Advanced reservation (II)

c) Dial In

missing CP:means only, no functionality visible for the user

March 2006WP4 33

L1 – L2 VPN ComparisonFirst results

L1VPN L2VPN

Flexibility Flexible solutions can be realized, the time to configure is relatively long

Very flexible, existing management systems allow outstanding flexibility

Ease of configuration, changes

Quite hard to configure since it is more linked to physical access

Easy to configure, changes can be made remotely if no physical limitation is touched

Bandwidth, granularity Nice for high bandwidth requirements, coarse granularity

Bandwidth is available in the Gbit/s range with very fine granularity

Maturity of solutions No of-the-shelf technology available today

Technology available, adaptation for VPN functionality required

Cost Relatively low cost Relatively high cost since complex nodes are utilized

• Resource sharing and business process outsourcing enabled by extended VPN services is added value to customer• But, VPNs with broad customer control may reduce “vertical range of manufacture”

March 2006WP4 34

Service Supportive Networks Motivations & Objective

Motivations It is not possible to transparently trigger all network services defined in NOBEL

using the UNI (e.g. set-up of advanced network services such as VPNs) is done via the Management Plane

Applications have practically no mean to shape connectivity according to their needs via UNI

Even if an evolution of the UNI can be conceived, this evolution should be tailored in different flavors depending on the type of controlled transport network (UNI is technology-dependent)

Objective Introduction of automatic operation in the NOBEL network for triggering network

services. Define service invocation mechanisms that allow service invocation by

applications envisioning short and medium/long term scenarios. Define interfaces for the short term scenario (on request) and long term scenario

(on-demand)

March 2006WP4 35

Application to Network interaction

CCI

CP

Client (User) Network #1 Provider/Carrier Domain

CCI

SE

TP

CP

CCI

TP

CP

CCI

SE

TP

CP

TN

MP

SE

NNI NNI

MP

coreprocess

mgmtprocess

CNAEP

Client (User) Network #2

CCI

CP

MP

coreprocess

CN AEP

USI-CUSI

mgmtprocess

UPI

TP TP

UNI UNI

UPI

USIUSI-C

CCI

CP

Client (User) Network #1 Provider/Carrier Domain

CCI

SE

TP

CP

CCI

TP

CP

CCI

SE

TP

CP

TN

MP

SE

NNI NNI

MP

coreprocess

mgmtprocess

CNAEP

Client (User) Network #2

CCI

CP

MP

coreprocess

CN AEP

USI-CUSI

mgmtprocess

UPI

TP TP

UNI UNI

UPI

USIUSI-C

Application End Point (AEP) includes management process & core process On-request: User to provider Interface (UPI), interface between AEP and client MP On-demand: User to service interface (USI), interface between AEP and Service Elements Service Element (SE): entity capable of triggering CP solicited by AEP via USI

March 2006WP4 36

UPI/USI requirements & Open Issues

UPI main requirements• Shall support machine-based interaction as an evolution from existing human-based interaction

• Shall support control of connectivity from the management platform of the customer application

USI main requirements• Shall enable end-user functions or AEPs to access services provided by different administrative

network domains and regardless of the access network technology

• Shall support both executive or informative services on an administrative domain

• Shall support the transparency of applications across multiple domains

• Shall allow on-demand interactive services with real time constraints

• Shall support session-based services (e.g., high-definition video-telephony) and non-session-based services (e.g.,e-Business transactions) as well

Open Issues• Mapping of abstract service request to transport technology specific network services.• The engineering of a “percolation” mechanism of a service invocation message coming from an

application into a resource request understandable by an ASON/GMPLS metro networks

March 2006WP4 37

Long-term scenario (2)

CCI

TP

CP

CCI

TP

CP

CCI

TP

CP

ASTN

UPIMP

UNI-T

MP

CP

TP

Provider/CarrierDomain A

Provider/CarrierDomain B

NNI-T

E-NNI

I-NNI I-NNI

MP

SE SESESEUSI

applicationlogic

Host

CE

Client Network

UNI

ASTN

CCI

TP

CP

CCI

TP

CP

CCI

TP

CP

ASTN

UPIMP

UNI-T

MP

CP

TP

Provider/CarrierDomain A

Provider/CarrierDomain B

NNI-T

E-NNI

I-NNI I-NNI

MP

SE SESESEUSI

applicationlogic

Host

CE

Client Network

UNI

ASTN User-controlled service provisioning provided by dedicated Service Entities (SE)s through USI (distributed approach), e.g. on-demand VPN Transparent service provisioning based on signaling protocol among SEs

March 2006WP4 38

Service Supportive Networks Approach

First objective of Service TF:finalize the short/medium term scenario, i.e. demonstrate an enhancement of NOBEL architecture supporting a service interface beyond the UNI.

Primary focus on application services that are strictly related to and dependent on network services (e.g. storage applications).

What features supported by UPI for network service set-up (Sant’Anna, Telenor, .…

What are the UPI limitations that make us call for the long term approach outlined below (Sant’Anna, Telenor, ....

March 2006WP4 39

Potential Follow Up Activities in NOBEL II

Second objective of Service TF (not expected to complete in NOBEL I)finalize the long-term scenario, i.e. build a flexible and future proof service oriented NOBEL network architecture supporting application/user services.In NOBEL II Sant’Anna will also contribute to WP1, possibly split work between WP1 and WP4 and collaboration with Signaling TF and VPN TF: Focus on automatic/intelligent (i.e. application-network cooperative)

set-up of network services based on a request of an application/user service (Sant’Anna, ……

Define functionalities, message exchange, architecture of the SEs in view of the previous point, i.e. try to shape the so-called “service plane” (Sant’Anna, ….

Define supported primitives over the USI to achieve the goal (Sant’Anna, …..