All rights reserved © 2005, Alcatel TMF MTNM & MTOSI M. Canali, A. Mazzini WP4 NOBEL Meeting -...

All rights reserved © 2005, Alcatel

TMF MTNM & MTOSI

M. Canali, A. Mazzini WP4 NOBEL Meeting - Munich, June 13th –15th 2005

All rights reserved © 2005, Alcatel2

What is TMF

The TeleManagement Forum, founded in ‘88, is a non profit independent and global organization which focus is automating operational management and business processes of communications industry.

More than 340 company membership comprises service providers, computing and network equipment suppliers, software solution suppliers and customers of communications services.

The TMF objective is to define practical, market based, solutions for OSS integration.

MTNM and MTOSI are TMF standards


MTNM


What is MTNM (1)

Multi-Technology Network Management (formerly named SSIM, i.e. SDH-SONET InfoModel), is an Information Model for Transport Networks.

Main parties involved in the MTNM definition: NORTEL, FUJITSU, SIEMENS, ECI, LUCENT, ALCATEL,

TELCORDIA, CIENA, ACTERNA, TELLABS, CRAMER AT&T, DT, BT, VERIZON

Very pragmatic approach focus on IDL MTNM specifications are in use at more than 30

companies, and MTNM is regarded as the de facto standard for EMS/NMS integration.


What is MTNM (2)

MTNM 2.0 has been released in July 2001 Some months later the 2.1 was released MTNM 3.0 has been released in October 2003 Work in progress for MTNM 3.5 – expected for end 05

Participation and interest are still strong - increasing for some subjects Ciena has replaced AT&T as chair Nortel has maintained IDL editor Alcatel is editor of the Ethernet IDL Active contributors are:

Ciena, Cramer, Fujitsu, Lucent, Nortel, Siemens, Telcordia AT&T, BT Exact, T-Systems, Verizon

Alcatel is major contributor, for Connection Domain, for ASON and Ethernet management


What is MTNM (3)Document suite

TMF 513: Business Agreement TMF 608: Information Agreement the MTNM UML model is implementation independent as it will

allow implementation in “any” interface technology MTNM is currently in the process of development of an XML

implementation of the interface to be provided as an alternative to the IDL

UML reflects the essential decisions made related to purpose, e.g. UML includes the PTP and CTP encapsulations

TMF 814: Solution Set TMF 814A: Implementation Statement Supporting Documents


Where MTNM could be placed


Sub-Network LayerRegional Manager

Network LayerIntegration Level

Subnetwork Mng

Vendor X

MTNM with “network profile”

Element MngVendor X

Element Mng

Vendor Y

Subnetwork MngVendor Y

Multi-technology

E.g. a national network integrator canmanage more regional ntw integrators.

Where MTNM could be placedMulti-Vendor Integration at Network layer (1)

Network MngVendor X


Here a Subnetwork Connection is defined within a subnetwork.It is possible to upload the network topology.

MTNM i/f provides a “flat” view, i.e. NO partitioning. In other words, subnetworks cannot be nested, and 1 NE belongs to only 1 subnetwork.ASON management carries the FULL partitioning view.

Example of supported operations:- get all Ports (of a Subnetwork)- get all Topological Links (of a SN)- Create Subnetwok Connection (into a SN)- get the Route of Subnetwork Connection

TopologicalLink

Subnetwork Connection

TopologicalLink

Port

Port

Where MTNM could be placed Multi-Vendor Integration at Network layer (2)

the Cross Connections form theSubnetwork Connection


Network MngVendor X

Element LayerSub-Network Layer

Subnetwork MngVendor X

MTNM with “element profile”

E.g. a regional network integrator canmanage more element managers.

Where MTNM could be placed Multi-Vendor Integration at Subnetwork layer (1)

Element MngVendor X

Element Mng

Vendor Y

Multi-technology


Port

Port

Here a Subnetwork Connection is a cross connection inside the NE, i.e. the subnetwork is the NE matrix.

So the NEs are seen as isolated subnetworks, no view of Topological Links/Physical Connections.

In the ASON context, the singleton subnetwork is the Routing Node

Example of supported operations:- get all Ports (of an NE = Subnetwork)- Create Subnetwok Connection (into an NE = Subnetwork)

Where MTNM could be placedMulti-Vendor Integration at Subnetwork layer (2)

Subnetwork Connection


Basic Concepts of MTNM


Basic Concepts of MTNM interface Multi-technology main features

MTNM 2.1 supports: SDH / SONET almost all standard features DWDM pre G.709 ATM simplified

MTNM 3.0 supports also: SDH TCM, POM, Virtual Concatenation DWDM G.709 Common features ASAP, TCA Profile, Multiple Backup

Routes, SNC Modification

MTNM 3.5 will also support: ASON/GMPLS Control Plane Management Ethernet Connectionless Transport (S-VLAN based)


Basic Concepts of MTNM interfaceMajor aspects

CORBA based, but moving towards XML over JMS Multi-vendor integration White box (but allowing opaque view for ASON management) Based on ITU-T G.805 architecture (well proven, recursive) One model for more management layers, focus on network

view One model for more technologies

(many challenges, but these were mainly terminology rather than essence)

One model for both Data Plane and Control Plane(work in progress, V3.5)

One model for both connection oriented and connectionless technologies (Eth-VLAN, MPLS)(work in progress, >V3.5)

Efficiency: Less Objects = Coarse Grain + Encapsulation Expandability, Vendor Additions: Limited sub-classing, Soft

attributes


Basic Concepts of MTNM interfaceMajor aspects (2)

So, the MTNM key differentiators are the Focus on network management, end-to-end connectivity Multi-technology Proven and practical Built with continuity, on the legacy of several management

models

Future considerations and challenges Connectionless modelling – maintain the consistency Service/network split – to be carefully defined


Basic Concepts of MTNM interface Facades and 2nd class objects (1)

Few CORBA objects (first class objects): EMSMgr (EMS is the Agent OS - could be EML or SNML) ManagedElementMgr, EquipmentInventoryMgr, MaintenanceMgr MultiLayerSubnetworkMgr (i.e. where the SNCs are defined) PerformanceManagementMgr ProtectionMgr (SDH/SONET: SNCP, Linear and Ring MSP)

which manage the objects representing network functions: EMS Managed Element Termination Point (e.g. the port, CTP, TTP) Performance Monitoring Point Protection Group Multi-layer Subnetwork Topological Link Subnetwork Connection+ ASAP, etc.



EMSMgr

MultiLayerSubnetworkMgrManagedElementMgr

2nd classobject

Interface

EMS

managedElement multiLayerSubnetwork

topologicalLink

terminationPoint subnetworkConnection



Common

getUserLabel ()setUserLabel ()

<<Interface>>

ManagedElementMgr

getAllManagedElements ()getContainingSubnetwork ()getPTPs ()getTP ()getManagedElement ()getContainedTPs ()getContainingTPs ()setTerminationMode ()getActiveAlarms ()setTransmissionParameter ()opname()setOwner()

<<Interface>>EMS

nameversiontype

getTopLevelSubnetworks ()getTopLevelTopologicalLinks ()getEMSActiveAlarms ()getMultiLayerSubnetworkMgr ()getManagedElementMgr ()

<<Interface>>

MultiLayerSubnetworkMgr

getManagedElements ()getMultiLayerSubnetwork ()getTopologicalLinks ()getEdgePoints ()getAssociatedTP ()getSubnetworkConnections ()getSubnetworkConnectionsWithTpList ()getRoute ()getSNC ()createSNC ()activateSNC ()createAndActivateSNC ()deactivateSNC ()deleteSNC ()deactivateAndDeleteSNC ()setSNCTransmissionParameter ()checkValidSNC ()

<<Interface>>


name userLabel nativeEMSNameowner locationversionproductNamecommunicationStateemsInSyncStatesupportedRatesadditionalInfo

CTP<<Struct>>

PTP<<Struct>>

<<Naming>>

TopologicalLinknameuserLabelaEndPTPzEndPTP

<<Struct>>

+delimits

<<Termination>>

ManagedElement<<Struct>>

<<Naming>>

EMS<<Interface>

<<Naming>>

MultiLayerSubnetworknameuserLabelsubnetworkType : Topology

<<Struct>>

+Connects

<<Naming>>

SubnetworkConnection<<Struct>>

<<Naming>>

RouteworkingRouteprotectRoute

<<Struct>> +implements

TerminationPoint<<Struct>>

2

0..1

+delimits

2

0..1

<<Termination>>

+Passes Through

Basic Concepts of MTNM interface Object attributes and relationships

name userLabel nativeEMSNameowner ingressTrafficDescriptoregressTrafficDescriptortypeconnectionStatetpMappingModedirectiontransmissionParamstpProtectionAssociationedgePointadditionalInfo

nameuserLabelnativeEMSNameownersncStatedirectionratestaticProtectionLevelsncTypeaEndzEndrerouteAllowednetworkRoutedadditionalInfo


Basic Concepts of MTNM interface: Network ViewSDH & WDM scenario (1)

NE 5NE 2 NE 3

OTS

Phy

NE 4

OMS

OTS

Phy

NE 6

DSR

OS

Phy

VC4

MS

RS

DSR

OS

Phy

NE 1

VC4

MS

RS

DSR

OS

Phy

OS

Phy

OCH

OMS

OTS

Phy

DSR

OCH

OMS

OTS

Phy

NE1–NE2 and NE5-NE6 are IrDI (UNI) top-topological links.


Basic Concepts of MTNM interface: Network ViewSDH & WDM scenario (2)

NE 4 NE 3 NE 2 NE 5

OTS

Phy

OMS

OTS

Phy

NE 6

VC4

MS

RS

DSR

OCH

OS

Phy

NE 1

VC4

MS

RS

DSR

OCH

OS

Phy

OS

Phy

OMS

OTS

Phy

OCH

OMS

OTS

Phy

OCH

OS

Phy

NE1–NE2 and NE5-NE6 are IaDI (NNI) top-topological links


Basic Concepts of MTNM interface: Connection Model Connection Types (1)

A1 Z1

ST_SIMPLE(unidirectional) ST_SIMPLE

(bidirectional)

A1 Z1

ST_ADD_DROP_A[unidirectional]

A2

Z1

A1

Z2

A1

Z1

ST_ADD_DROP_Z[unidirectional]



A1

A2 Z2

Z1

ST_DOUBLE_ADD_DROP[unidirectional]

ST_DOUBLE_ADD_DROP[bidirectional]

Z2

Z1A1

A2

ST_ADD_DROP_A[bidirectional]

A2

Z1

A1



A2

A1

Z1

ST_INTERCONNECT[unidirectional]

A2

A1

Z1

ST_INTERCONNECT[bidirectional]

Z2

Z1

ST_DOUBLE_INTERCONNECT[bidirectional]

A1

A2



Z2

Z1

ST_OPEN_ADD_DROP[unidirectional]

A1

A2Z2

Z1

ST_OPEN_ADD_DROP[bidirectional]

A1

A2


Basic Concepts of MTNM interface: Connection Model Broadcast

MTNM does not explicitly model the broadcast SNC, rather allows the creation of more independent SNCs, all sharing the same source point

SNC a

SNC c

SNC b

SNC d


Basic Concepts of MTNM interface: Connection Model Levels of Connection Protection

The StaticProtectionLevel values are defined as follows:

PREEMPTIBLE: May have resources taken to recover another SNC.

UNPROTECTED: An SNC that will fail if any resource in its route fails.

PARTIALLY_PROTECTED: Protection exists but has at least one shared node, shared link or shared link and node.

FULLY_PROTECTED: An SNC that will not fail if any single managed resource along its route fails (excluding the originating and terminating nodes for the SNC); for example, an SNC that is diversely routed at any layer.

HIGHLY_PROTECTED: A higher level of protection than is possible by simple diverse path routing. A highly protected subnetwork should each be able to experience a single failure without affecting traffic. No shared facilities and NEs excluding originating and terminating NEs. Typically this is achieved in a SONET/SDH environment using dual ring interworking, where the proper use of links enhances survivability over that offered by simple diverse path routing. Highly Protected is used when the NMS wishes to request the highest available protection level from the EMS. If a level greater than simple diverse routing is available, it must be provided. If this can be done in multiple ways and is not further specified by the NMS, the choice of highly protected SNC is made by the EMS.

The StaticProtectionLevel does not have any bearing on the externally visible shape and traffic flows of the SNC.


ASON/GMPLS in MTNM


Work in progress: ASON/GMPLSIntroduction

MTNM 3.5 is introducing the management of Control Plane: Switched Connections Soft Permanent Connections Multi-layer Routing Area, SNPP Link (TE-Link) Routing Hierarchy UNI, I-NNI, intra carrier E-NNI

(inter Carrier E-NNI for versions > 3.5) Call and Connection Separation Multi-layer approach, at least for Ethernet over

VCAT


Control Plane Network,or Top Level Routing Area

Call (either of SC or SPC type)

Edge PTP,UNI interface

MEME

Control Plane Network Connectionor Network Call Segment (OIF)

UNI Call Segment

(OIF)

UNI Call Segment

(OIF)

SNPP Link

Work in progress: ASON/GMPLSThe Call


MEME

MEME

MEME

edge PTPInter or Intra

E-NNI interface

Routing Area Connection or Connection Segment,

supporting a Call Segment,(OIF)


supporting a Call Segment, (OIF)


supporting a Call Segment,(OIF)

E-NNI Call

Segment (OIF)

SNPP Link

E-NNI Call

Segment (OIF)

Edge PTP,Dumb interface

Control Plane Network,or Top Level Routing Area

Work in progress: ASON/GMPLSThe Control Plane Network Connection

Edge PTP,UNI interface

Control Plane Network Connection (supporting a Call of SPC or SC type)


ME

ME

ME

ME

E-NNI interface

MEME

ME

ME

MEME

MLSN 2 MLSN 1Routing Area 1

(level 0) Routing Area 1.2

(level 1)

EMS Domain 2EMS Domain 1

Routing Area 1.1(level 1)

Work in progress: ASON/GMPLSHierarchy of ML Routing Areas, reference scenario

SNC within level 1

SNC within level 0


ME

Routing Area 1 (level 0)

ME

ME

ME

MEME

Routing Node(level 2)


E-NNISNPP Link (level 1)

UNISNPP Link (level 0)

I-NNISNPP Link (level 2)

1

1

0

1

1

2 2

2

22

2

22

02

2

Work in progress: ASON/GMPLSControl Plane Topology


ME


ME

ME

ME

MEME





1

1

0

1

1

2 2

2

22

2

22

02

22

2

2

22 2

10

22

2

2

2

2

11

0

0

122



ME


ME

ME

ME

MEME





1

1

0

1

1

2 2

2

22

2

22

02

2

10

11

0

0

1





EMS Domain 2EMS Domain 1


E-NNI interface


MLSN 1

E-NNI interface

Work in progress: ASON/GMPLSCall&Connection Separation: VCAT Scheme


MTOSI


Origins and Objectives of MTOSI

Multi-Technology Operations Systems Interface (MTOSI)

Started as MTNM subteam mid 2003

Objective: Extend MTNM model for OS-OS interfaces

Based on MTNM 513 (BA), 608 (IM) and 814 (IDL)

XML / Web Services integration interface

Uses NGOSS and SOA design principles

Mtosi: A rare tropical fish found only in

Tanzania


MTOSI Status and Roadmap

Release 1 recently submitted for TM Forum member evaluation

Release 2 work has startedTwo multi-company demonstrations at May 2005

TMW, i.e., Lucent-Siemens-Telcordia and Cramer-Nortel

Catalyst project planned for the TMW in Dallas (November 2005)

Liaison with OSS/J and ETSI


MTOSI Initial Focus

OS to OS interface which covers the NMS/EMS interface as a special case

Release Version 1.0 designed for: Inventory Retrieval from NMS/EMS Inventory Synchronization Active Alarm Retrieval Inventory and Alarm Notification


MTOSI Release 2.0 (Tentative Scope)

Extend XML coverage to entire MTNM scopeService ActivationPerformance ManagementFault Service Enhancements (OSS/J alignment)Inventory Service EnhancementsOSS/J Convergence Collaboration


MTOSI 1.0 Deliverables

Major Deliverables

TMF 517 (Business Agreement) Extensions to TMF 608 (MTNM Information Agreement) TMF 854 (XML Solution Set) SD2-1 of TMF 854 (Implementation Statement) RN306 (Release Notes)


MTOSI 1.0 Deliverables

MTOSI Guidelines MTOSI Implementation

Statement MTOSI XML Implementation

User Guide Versioning and Extensibility Attribute Extensibility MTOSI Object Naming Communication Styles Inventory Layout Description

Using JMS as an MTOSI Transport

Transport Independent Example of MTOSI

MTOSI Example Using JMS MTOSI Notification Service MTOSI AVC and SC Notifications MTOSI IA-SS Mapping

Supporting Documents


MTOSI Release 1.0 Participants

Telcordia Lucent Nortel

TTI Siemens Cramer

Toborg Technology Strategies British Telecom Verizon

AT&T Fujitsu Alcatel

Deutsche Telekom Level 3 Sprint

QinetiQ Sheer Networks Ciena

Wipro ECI TM Forum


MTOSI Model


MTOSI Model = MTNM Model but…

Management Domain

OS

Managed Element

Topological Link

manages0..n 1..n

0..n

1 has subordinate

manages

0..n

0..n

1..n

1..n

Subnetwork

manages

manages

1..n

TMD

1..n

0..n

0..n

offers


MTOSI Model = MTNM Model but…

Management Domain

Topological Link

0..n

Managed Element

0..n

SNC

0..n

TP Pool

0..n

0..n

Subnetwork

PTP

0..n

CTP

0..n

Equipment

0..n

0..n

0..nEquipment

HolderPGP

0..n

EPGP

0..n

0..n


Operations System object (OS)

The OS object is used to represent an operations system. An OS instance can be used to represent an EMS. In the context of the MTOSI, there are top-level OSs which are

attached to the CCV and subordinate OS which are known to a given top-level OS but not attached to the CCV

The OS has the following distinguishing characteristics in addition to the common attributes: software version – the software version of the OS. product – the product name for the OS. vendor – the name of the OS supplier. service state – the attribute shall indicate the current administrative

state of the OS, intended as the MTOSI application running on it. The administrative states that shall be supported are In Service, Out of Service and Out of Service for Maintenance. (Optional).

subordinateOS – a Boolean saying if it is a subordinate OS or not.


Managed Domain object (MD)

The Management Domain (MD) object is used to represent a portion of a network.

A top-level OS may manage part or all of one or more MDs.

Operations Comments

getAllTopLevelSubnetworks This operation returns the subnetworks contained by the MD to which the operation is directed.

getAllTopLevelSubnetworkNames This operation returns the subnetwork names for the subnetworks contained by the MD to which the operation is directed.

getAllTopLevelTopologicalLinks This operation returns the TLs between the subnetworks contained by the MD to which the operation is directed.

getAllTopLevelTopologicalLinkNames

This operation returns the names of the TLs between the subnetworks contained by the MD to which the operation is directed.getAllManagedElements This operation returns all the MEs in the MD to which the operation is directed.

getAllManagedElementNames This operation returns all the names of all the MEs in the MD to which the operation is directed.


MTOSISupporting Mechanisms


Communication StylesHigh Level Architecture


Communication StylesDetailed Communication Architecture

Requirement: MTOSI needs to be transport independent Solution: MTOSI has defined an abstract interface that is transport

technology agnostic and the encapsulation of the mappings to different transport in generic modules called bindings.


Communication Stylesfrom Abstract to Concrete Interface


Communication StylesRPC vs. MSG styles

RPC

MSG


Communication StylesMessage Exchange Patterns


MTOSI 1.0 Transport = MSG with JMS

What Is the JMS API? The Java Message Service is a Java API that allows

applications to create, send, receive, and read messages. Designed by Sun and several partner companies, the JMS API defines a common set of interfaces and associated semantics that allow programs written in the Java programming language to communicate with other messaging implementations.


MTOSI JMS TransportArchitecture


MTOSI JMS TransportMessaging Domains

Point-to-Point Messaging Domain Each message has only one consumer. A sender and a receiver of a message have no timing

dependencies. The receiver can fetch the message whether or not it was

running when the client sent the message. The receiver acknowledges the successful processing of a

message.


MTOSI JMS TransportMessaging Domains

Publish/Subscribe Messaging Domain Each message can have multiple consumers. Publishers and subscribers have a timing dependency. A client that subscribes to a

topic can consume only messages published after the client has created a subscription, and the subscriber must continue to be active in order for it to consume messages.

The JMS API relaxes this timing dependency to some extent by allowing subscribers to create durable subscriptions, which receive messages sent while the subscribers are not active.


Versioning and Extensibility

An interface consists of a set of operations, which in turn consist of a set of messages. E.g., getTP operation in the managedElementMgr interface has: getTP, the request message getTPResponse the response message

All interface messages are XML instance documents with associated XSDs (XML Schema Definition) for validation.

A message processor processes an XML instance. In Client-Server architectures both Client and Server or Sender and Receiver in a Request/Response business activity will be processing an XML instance. For this reason Backward and Forward compatibility is defined in relation to the processor role in which a sender or a receiver is acting.



Backward compatibility The message processor works correctly when receiving an old

version of a message.

Forward compatibility The message processor works correctly when receiving a new

version of a message.

Interfaces versions are fully compatible if the versions are both backward and forward compatible.



Major update is a change for which no meaningful communication between

Sender and Receiver is possible with respect to the change, where the Sender and Receiver are using different versions.

A message processor will not be able to natively process a message after a major update.

After a major update the service will loose its backward compatibility (by definition).

Minor update is a change after which it is still possible for a processor to

natively process a message. After a minor change the service will still be backward

compatible.



For MTOSI Phase 1, versioning is defined on an interface set as a whole, not on individual operations, interfaces nor messages. MTOSI as a whole will have a notion of release version. Nevertheless MTOSI should not prevent an OS supplier to implement a finer grain versioning based for example on the Interfaces, operations or even objects.

Given the distributed and symmetrical nature of the MTOSI OSS, an MTOSI release is considered compatible if and only if it is forward and backward compatible.

A new version of an MTOSI release may be compatible or incompatible with a previous release .

Even when the structure of the contained interfaces does not change, a change in semantics, (i.e., how messages are processed), may cause a new release to be backward incompatible with earlier release.Only the addition of new optional elements or optional structures in the XSD is both forward and backward

compatible


Attribute Extensibility

An extensibility level is assigned to each object (and pseudo object) attribute, each notification parameter and the parameters of some operations.

The "extensibility level" refers to the value set of an attribute and not the syntax of an attribute.

It is intended that all attribute extensions (by the vendor or MTOSI team) be backward compatible within an MTOSI major version.

The following extensibility levels are defined: Open Closed Qualifiable Extendable Overlap


Notification ServiceThe information model

Is the result of: The attempt to re-use as much as possible the MTNM model The adoption of a model that naturally matches with a Web

service implementation style such as the WS-Notification

Key objectives are: The definition of an abstract specification that is independent

from the particular transport middleware used at deployment time.

Interoperability between Notification Producers and Notification Consumers in a deployment environment.


Notification Service (MTOSI)

Logical View Class Diagram

Date post:	11-Jan-2016
Category:	Documents
Upload:	gerald-waters
View:	212 times
Download:	0 times