490 likes | 646 Views
Management of Hybrid Packet and Circuit Switched Networks Work ongoing in ITU-T SG-4 27 March 2000 IETF TMN BOF Mark Klerer Working Group Chair, ITU-T SG 4 WP 5 Tel: +1 973 292 5710 Fax: +1 973 292 4161 Email: klerer@nortelnetworks.com. Topics. Problem Statement What is TMN The Q.25 Framework
E N D
Management of Hybrid Packet and Circuit Switched NetworksWork ongoing in ITU-T SG-4 27 March 2000IETF TMN BOFMark KlererWorking Group Chair, ITU-T SG 4 WP 5Tel: +1 973 292 5710Fax: +1 973 292 4161Email: klerer@nortelnetworks.com
Topics • Problem Statement • What is TMN • The Q.25 Framework • One Common Simplified Methodology • Multiparadigm Support In TMN • Common Semantics and Processes in TMN • Event Services in TMN • Work within SG-4 on TMN • Proposal for Joint Work
Problem Statement • New telecom networks are emerging and existing networks are evolving to use packet switched technologies as networks backbone and/or service infrastructure. These networks build on the heritage of the traditional PSTN and the traditional Internet. In order to be able to support the services the users are demanding it must be possible to manage these new networks in a manner that allows: • Easy configuration of network elements, networks and services • The ability to support different types of Service Level Agreements • The ability for service providers to measure and bill service usage • Monitor the network to assure performance guarantees are met • Provision for network robustness in the event of faults and the isolation of faults • The ability for multiple service providers to cooperate in end-to-end service and network management • The ability for service providers to deploy multi-vendor solutions • The ability for new vendors to work into a known deployed operations infrastructure
What is TMN • A functional architecture for: • Identification of levels of abstraction of management activity • Separation of technology, networking, service and business concerns • Identification of management tasks that need to be performed • Identification of information and activities that need to exist between functional entities • A set of common information models and processes • Information models for network elements, networks and services • Models and procedures for common management tasks, e.g. alarm reporting, performance monitoring, call detail recording, . . . • A set of protocols for communicating between NEs and Oss, and OSs and OSs • Large selection of lower layer protocols • Original upper layers use OSI protocols (CMIP and FTAM) • Upper layer architecture evolving to address CORBA, EDI, SNMP, ...
TMN Relationship to Telecommunications Networks WorkStation WS WS WS . TMN OS Survelliance OS Provisioning OS Traffic Mgmt WS Data Communications Network TMN Interfaces Switching System Switching System Switching System Transmission Systems Transmission Systems Telecommunications Network
OSF OSF OSF OSF NEF TMN Layered Architecture (M.3010) • Enterprise view • Goal setting, finance, budgeting • Product & human resource planning Business Management • q • Contacts with customers & svc providers • Service orders, complaints, & billing • Quality of service Service Management • q Network Management • Network support of all services • End-to-end network view of all NEs & links q • • View of NE subset, individually or • collectively as a subnetwork • Mediation Element Management • q Network Elements • Network resource functionality
Elements of a TMN Interface • Architectural definition of communicating TMN entities: roles and relationships • Operation, Administration, Maintenance, and Provisioning (OAM&P) requirements to be supported by communications • Application information models for support of OAM&P requirements • Resource information models defining abstractions of telecommunications network resources to be managed • Protocols to transport the application and resource information between TMN entities Managed System Managing System TMN Interface
TMN Physical Architecture (M.3010) TMN Operations System (OS) G F WS Q / X / F Data Communications Network (DCN) X WS - Workstation Q / F Mediation Device (MD) Q Q Q Data Communications Network (DCN) Q Q Network Element (NE) Network Element (NE) Q Adaptor (QA) Q Adaptor (QA)
Integrated Management of Telecom and IP-based Networks • In June 1998, SG 13 modified its work plan to emphasize IP and SG 16 requested SG 4 support of its work on the management of multimedia terminals, systems, and protocols. • In response, SG 4 agreed to define the Integrated Management of IP-based and Telecom Networks. • In September, ITU-T’s Telecommunication Standardization Advisory Group (TSAG) • Assigned SG 13 as the lead SG for IP Aspects • Requested each SG to determine how to support IP-based networks • Established procedures for collaboration between the ITU-T and the IETF • In October, SG 15 modified its TMN work plan to support interworking with IP-optimized transport equipment. • In December 1998, ITU-T IP Workshop supported TMN as basis for Integrated Management of IP and Telecom Networks • In March 1999, SG 4 modified its work plan to support IP, including the creation of a unified management framework to support its role as lead ITU-T SG for TMN • January 2000 SG-4 agrees to work jointly with ETSI TC-TMN, TIPHON and T1M1 on management of hybrid packet/circuit switched based networks
Q 25/4 Proposal on Integrated Management of Hybrid Circuit Switched and Packet/IP Networks • Objectives • Enable flow-through of management information in support of business processes, both within OSs within a single administration and between administrations. Flow-through of information between administrations may be subject to firewalling and may, therefore, not be available for all functions; (i.e. the business processes determine what may flow through and what will require interactions between staff or be blocked). • Enable one-touch end-to-end service management in a Hybrid Circuit/Packet (HCP) environment, by supporting an integrated view of packet and circuit switched network resources, applications and services. • Enable end-to-end network management in an HCP environment, including transparent fault isolation across packet and circuit switching technologies and performance parameter allocation for impairments that occur due to the multiple technologies. • Allow identical functionality of network elements, networks and services to be managed by the same processes regardless of whether the functionality is used with circuit or packet technology.
Framework Document Outline • Descriptions of • Networking Environment • Services Environment • Application Services • TMN Considerations • TMN Management Architectures for HCPN • IP Based Management Architectures • Information Models and Specification Methodology • Protocol Architectures and Interworking
TMN Methodology for Requirements and Modelling • Objective: Common working methods for all groups working on specifications of TMN based on Requirement, Analysis and Design methodology (M.3020) • Requirements to be understandable to OAM experts and provide sufficient detail to drive modelling • Model details to be traceable to requirement details • Information to be defined independent of deployment technology • Approved Methodology will use: • For Requirements and Analysis: • UML notations including Use Case, Class Structure, Sequence, Collaboration, Activity, and Implementation Diagrams; State Charts • For Design: • Use tools appropriate for that paradigm. E.g. IDL for CORBA; GDMO for CMIP, SMI for SNMP, ...
It’s a Multi-paradigm World • New technologies are evolving continuously and particular technologies may be more appropriate in particular environments. It is therfore proposed to accommodate multiple model paradigms within TMN. Two types of paradigms are defined: • General purpose paradigms • Models and protocols that supply the full set of management functionality required in a distributed environment (.e.g. scalability, data search capabilities, event services) • Currently: CMIP and CORBA2.3 with additional services • Special purpose paradigms: • Models and protocols designed to satisfy some specific management application. Special purpose paradigms will exist because for their particular application they may offer a performance advantage or economic benefit. • Currently: EDI, SNMP
Requirements for General Purpose Paradigms. • Scalability (106 - 107 objects) • Compatibility with existing models • Support multiple managers • Support for query capabilities • Support for data modification capabilities • Support operations for set valued attributes • Support multiple object access • Selective access of attributes • Support operations on multiple objects • Support of autonomous notifications • Well defined notifications • Support for modeling of the containment relationship • Support of unique names • Support of creation and deletion semantics
CMIS Capabilities (Q.811, Q.812) • Data manipulation functions • Get • Set: Replace, Set to Default, Add to list, Delete from list • Object Life Cycle • Create • Delete • Object Methods • Action • Notification Service • Event Report • Support Capabilities • Simultaneous operation on multiple objects • Conditional operation based on filtering • Retrieval based on filtering • Cross object synchronization
Preserving Semantics and Processes in a Multi-paradigm World • Common semantics (at the individual parameter level) for all common parameters (e.g. be able to perform a one-to-one mapping of state information between two objects/entities). • Allow the management application for the same management function to operate identically in both the circuit-switched and packet-switched environment.
Telecommunications Management Services • Alarm Surveillance - Q.821 • Performance Management - Q.822 • Traffic Management - Q.823 • ISDN Service Profile Management - Q.824 • Call Detail Recording - Q.825 • Routing Management - Q.826
Alarm Reporting Services • Initiate Alarm Reporting • Configure Alarm Filters • Suspend/Resume Alarm Reporting • Terminate Alarm Reporting • Create (Alarm) Logs • Configure Log Filters • Log Alarm Reports • Suspend/Resume Logging of Events • Retrieve Alarm Records • Configuration of Summary Alarms • Alarm Severity Assignment • Inhibiting/Allowing of Audible/Visual Indicators • Resting of Audible/Visual Indicators
Alarm Reporting Service - Event Specific Information • Probable Cause • Specific Problems • Perceived Severity • Backed-up Status • Back-up Object • Trend Indication • Threshold Information • Notification Identifier • Correlated Notifications • State Change Definition • Monitored Attributes • Proposed Repair Actions • Additional Text • Additional Information
Q.822 Performance Monitoring • Approach • Identify events that are of interest in determining performance characteristics • Define a time interval over which these events are to be observed • Record the number of occurrences of these events in a current data object • Threshold these event, if required, to generate an alarm • At the end of the time interval, if required, move data into a history data object
Management of HCSP Networks Possible Realizations Option 4 SMS NMS Payload EMS Ckt Layer EMS Pkt Layer EMS iwNE pNE pNE pNE cNE cNE cNE
Possible IP Management Areas • Management of IP network resources • Routers, bridges, hubs, LANs, and hosts, such as servers and workstations • Supports management of IP-based TMN DCNs • FCAPS for IP networks including • H.323-based management • Topology management • Policy management • SLA management • IP usage management • FCAPS for mixed networks including • End-to-end connection management • Integrated accounting management • Interlayer management (ala G.805 layers)
ITU-T SG 4 Question Responsibilities • Q.2/4 – M.1400 extensions (C) • Q.6/4 – None • Q.8/9/4 (aka MQ/4) – M.23IP perf. objectives, allocations and limits (P) • Q.10/4 & 11/4 – IP test procedures and test equipment (F,P) • Q.12/4 – None • Q.13/4 – M.3013, Investigate extensions to architecture (All) • Q.14/4 – “SMI responsibility” (some relationship to Q.19/4) • Q.15/4 – M.3100 (F,C,P), M.3200 (All), M.3400 (All), M.3108- and M.3208-series leased circuits (All) • Q.17/4 – M.3320 (All), M.332x-series (specific parts of FCAPS), SLA Requirements (P) • Q.18/4 – Generic CL Network Models (FCAP), Adapt to G.cls • Q.19/4 – Q.81x-series, IP related management protocol
ITU-T SG 4 Question Responsibilities • Q.20/4 – Q.825 [CDR](A), Q.823 (tfc. mgt), Q.821 (alarm), Q.822 (perf), Q.824 (?), Policy managemnt • Q.21/4 – IP access network (NAS and RAS) • Q.23/4 – IP NML • Q.24/4 – Mobile-IP, Intelligent Networks • Q.25/4 – Framework and Tracking Work Plan of SG-4 Projects and other SG IP related Management Projects
Proposal for a Common Group for Joint Expert Meetings on HCSP Management • To allow work on management of HCSP networks to proceed most rapidly and assure that common semantics can be preserved it is proposed that the network, service and business management level work be done jointly. This work needs to be cognizant of the capabilities provided by the network elements. • The network element work will in all likelihood be done within the network element groups but should use common semantics and be driven by overall management capabilities required at the network, service and business layer. • Initial stake-holder groups identified: ITU-T, ETSI, TIPHON, T1M1 and IETF
Next Scheduled Meeting 23 - 24 May Meeting: Contributions expected by 10 May 2000 Venue: ETSI Building in Sophia Antipolis, France (Nearest Airport: Nice) Mailing List For Joint Meetings: jointnm@etsi.fr To subscribe sent e-mail to: listserv@list.etsi.fr with body of text subscribe jointnm
Want More Information ? • Selected TMN Standards and Comprehensive Presentation on SG-4 Work is available via FTP at • anonymous@137.118.21.16/itu_to_ietf/SG4
Management of HCSP Networks Possible Realizations Option 1 SMS NMS Inf. EMS IP EMS iwNE pNE pNE pNE cNE cNE cNE
Management of HCSP Networks Possible Realizations Option 2 SMS NMS Inf. EMS IP EMS Semantic Mediator iwNE pNE pNE pNE cNE cNE cNE
Management of HCSP Networks Possible Realizations Option 3 SMS Integrated NMS Inf. NMS IP NMS Inf. EMS IP EMS iwNE pNE pNE pNE cNE cNE cNE