1 / 66

TMF MTNM & MTOSI

TMF MTNM & MTOSI. M. Canali, A. Mazzini WP4 NOBEL Meeting - Munich, June 13th –15th 2005. What is TMF.

kessie-shaffer
Download Presentation

TMF MTNM & MTOSI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TMF MTNM & MTOSI M. Canali, A. Mazzini WP4 NOBEL Meeting - Munich, June 13th –15th 2005

  2. 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

  3. MTNM

  4. 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.

  5. 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

  6. 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

  7. Where MTNM could be placed

  8. Where MTNM could be placedMulti-Vendor Integration at Network layer (1) Network Mng Vendor X Network Layer Integration Level E.g. a national network integrator can manage more regional ntw integrators. MTNM with “network profile” Sub-Network Layer Regional Manager Subnetwork Mng Subnetwork Mng Vendor X Vendor Y Element Mng Element Mng Vendor X Vendor Y Multi-technology

  9. Where MTNM could be placed Multi-Vendor Integration at Network layer (2) Subnetwork Connection Port Topological Link MESH profile Port the Cross Connections form the Subnetwork Connection 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 Topological Link 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.

  10. Where MTNM could be placed Multi-Vendor Integration at Subnetwork layer (1) Network Mng Vendor X E.g. a regional network integrator can manage more element managers. Subnetwork Mng Vendor X MTNM with “element profile” Sub-Network Layer Element Layer Element Mng Element Mng Vendor X Vendor Y Multi-technology

  11. Where MTNM could be placedMulti-Vendor Integration at Subnetwork layer (2) Subnetwork Connection Port SINGLETON profile Example of supported operations: - get all Ports (of an NE = Subnetwork) - Create Subnetwok Connection (into an NE = Subnetwork) 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

  12. Basic Concepts of MTNM

  13. Basic Concepts of MTNM interfaceMulti-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)

  14. 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

  15. 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

  16. Basic Concepts of MTNM interfaceFacades 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.

  17. Basic Concepts of MTNM interfaceFacades and 2nd class objects (2) EMSMgr 2nd class object EMS Interface ManagedElementMgr MultiLayerSubnetworkMgr managedElement multiLayerSubnetwork topologicalLink terminationPoint subnetworkConnection

  18. <<Interface>> <<Interface>> <<Interface>> EMS MultiLayerSubnetworkMgr ManagedElementMgr name version getManagedElements () getAllManagedElements () type getMultiLayerSubnetwork () getContainingSubnetwork () getTopologicalLinks () getPTPs () getTopLevelSubnetworks () getEdgePoints () getTP () getTopLevelTopologicalLinks () getAssociatedTP () getManagedElement () getEMSActiveAlarms () getSubnetworkConnections () getContainedTPs () getMultiLayerSubnetworkMgr () getSubnetworkConnectionsWithTpList () getContainingTPs () getManagedElementMgr () getRoute () setTerminationMode () getSNC () getActiveAlarms () createSNC () setTransmissionParameter () activateSNC () opname() createAndActivateSNC () setOwner() deactivateSNC () deleteSNC () deactivateAndDeleteSNC () setSNCTransmissionParameter () checkValidSNC () Basic Concepts of MTNM interfaceFacades and 2nd class objects (3) <<Interface>> Common getUserLabel () setUserLabel ()

  19. Basic Concepts of MTNM interfaceObject attributes and relationships <<Struct>> <<Interface> <<Struct>> ManagedElement EMS MultiLayerSubnetwork name userLabel nativeEMSName owner location version productName communicationState emsInSyncState supportedRates additionalInfo name <<Naming>> userLabel <<Naming>> subnetworkType : Topology <<Naming>> <<Naming>> +Connects <<Struct>> TopologicalLink <<Struct>> +delimits PTP name <<Struct>> <<Struct>> userLabel SubnetworkConnection TerminationPoint <<Termination>> aEndPTP name userLabel nativeEMSName owner sncState direction rate staticProtectionLevel sncType aEnd zEnd rerouteAllowed networkRouted additionalInfo name userLabel nativeEMSName owner ingressTrafficDescriptor egressTrafficDescriptor type connectionState tpMappingMode direction transmissionParams tpProtectionAssociation edgePoint additionalInfo zEndPTP <<Naming>> <<Struct>> CTP +implements <<Struct>> Route workingRoute protectRoute +Passes Through +delimits 2 2 <<Termination>> 0..1 0..1

  20. Basic Concepts of MTNM interface: Network ViewSDH & WDM scenario (1) VC4 VC4 MS MS RS RS DSR DSR DSR DSR OCH OCH OS OS OS OMS OMS OS OMS OTS OTS OTS OTS Phy Phy Phy Phy Phy Phy Phy Phy NE 1 NE 2 NE 3 NE 4 NE 5 NE 6 NE1–NE2 and NE5-NE6 are IrDI (UNI) top-topological links.

  21. Basic Concepts of MTNM interface: Network ViewSDH & WDM scenario (2) VC4 VC4 MS MS RS RS DSR DSR OCH OCH OCH OCH OS OS OS OS OMS OMS OMS OTS OTS OTS OTS Phy Phy Phy Phy Phy Phy Phy Phy NE 1 NE 2 NE 3 NE 4 NE 5 NE 6 NE1–NE2 and NE5-NE6 are IaDI (NNI) top-topological links

  22. Z1 A1 Z2 ST_ADD_DROP_Z [unidirectional] A1 Z1 A2 ST_ADD_DROP_A [unidirectional] Basic Concepts of MTNM interface: Connection ModelConnection Types (1)

  23. A1 A1 Z1 A1 Z1 Z1 A2 Z2 A2 A2 Z2 ST_ADD_DROP_A ST_DOUBLE_ADD_DROP ST_DOUBLE_ADD_DROP [bidirectional] [unidirectional] [bidirectional] Basic Concepts of MTNM interface: Connection ModelConnection Types (2) Drop and Continue in one node

  24. A1 Z1 A2 Z2 ST_DOUBLE_INTERCONNECT [bidirectional] Basic Concepts of MTNM interface:Connection ModelConnection Types (3)

  25. Basic Concepts of MTNM interface: Connection ModelConnection Types (4) open SNCP

  26. Basic Concepts of MTNM interface: Connection ModelBroadcast • 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 b SNC d SNC c

  27. Basic Concepts of MTNM interface: Connection ModelLevels 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.

  28. ASON/GMPLS in MTNM

  29. 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

  30. ME ME Work in progress: ASON/GMPLSThe Call Call (either of SC or SPC type) UNI Call Segment (OIF) UNI Call Segment (OIF) Control Plane Network Connection or Network Call Segment (OIF) Edge PTP, UNI interface SNPP Link Control Plane Network, or Top Level Routing Area

  31. ME ME ME ME ME ME Work in progress: ASON/GMPLSThe Control Plane Network Connection Control Plane Network Connection (supporting a Call of SPC or SC type) Routing Area Connection or Connection Segment, supporting a Call Segment, (OIF) Routing Area Connection or Connection Segment, supporting a Call Segment, (OIF) Routing Area Connection or Connection Segment, supporting a Call Segment, (OIF) E-NNI Call Segment (OIF) E-NNI Call Segment (OIF) Edge PTP, Dumb interface Edge PTP, UNI interface SNPP Link edge PTP Inter or Intra E-NNI interface Control Plane Network, or Top Level Routing Area

  32. ME ME ME ME ME ME ME ME ME ME Work in progress: ASON/GMPLSHierarchy of ML Routing Areas, reference scenario Routing Area 1.1 (level 1) Routing Area 1 (level 0) Routing Area 1.2 (level 1) MLSN 1 MLSN 2 EMS Domain 1 EMS Domain 2 E-NNI interface SNC within level 1 SNC within level 0

  33. 0 1 1 1 1 2 2 2 2 2 2 2 2 0 2 2 ME ME ME ME ME ME Work in progress: ASON/GMPLSControl Plane Topology Routing Area 1.1 (level 1) Routing Node (level 2) Routing Area 1 (level 0) UNI SNPP Link (level 0) I-NNI SNPP Link (level 2) E-NNI SNPP Link (level 1)

  34. 0 1 0 0 1 2 2 2 2 1 1 0 1 1 2 2 2 2 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 0 2 2 ME ME ME ME ME ME Work in progress: ASON/GMPLSControl Plane Topology Routing Area 1.1 (level 1) Routing Node (level 2) Routing Area 1 (level 0) E-NNI SNPP Link (level 1) UNI SNPP Link (level 0)

  35. 2 2 2 0 0 1 0 1 2 2 0 1 2 1 0 1 1 2 1 2 2 2 1 ME ME ME ME ME ME Work in progress: ASON/GMPLSControl Plane Topology Routing Area 1.1 (level 1) Routing Node (level 2) Routing Area 1 (level 0) E-NNI SNPP Link (level 1) UNI SNPP Link (level 0)

  36. Work in progress: ASON/GMPLSCall&Connection Separation: VCAT Scheme Routing Area 1.1 (level 1) Routing Area 1 (level 0) Routing Area 1.2 (level 1) Routing Area 1.3 (level 1) MLSN 1 EMS Domain 1 EMS Domain 2 E-NNI interface E-NNI interface

  37. MTOSI

  38. 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

  39. MTOSI Status and Roadmap • Release 1 recently submitted for TM Forum member evaluation • Release 2 work has started • Two 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

  40. 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

  41. MTOSI Release 2.0 (Tentative Scope) • Extend XML coverage to entire MTNM scope • Service Activation • Performance Management • Fault Service Enhancements (OSS/J alignment) • Inventory Service Enhancements • OSS/J Convergence Collaboration

  42. 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)

  43. 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 MTOSI 1.0 Deliverables • Supporting Documents

  44. MTOSI Release 1.0 Participants

  45. MTOSI Model

  46. MTOSI Model = MTNM Model but… 1 has subordinate Management Domain OS 0..n 1..n manages 0..n 1..n 1..n 1..n 1..n manages offers Managed Element 0..n 0..n TMD manages Topological Link 0..n manages Subnetwork 0..n

  47. 0..n 0..n 0..n 0..n 0..n SNC TP Pool PGP Equipment Holder PTP 0..n 0..n 0..n EPGP 0..n CTP Equipment MTOSI Model = MTNM Model but… Management Domain 0..n Topological Link 0..n 0..n Subnetwork Managed Element 0..n

  48. 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.

  49. 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. 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.

  50. MTOSISupporting Mechanisms

More Related