Transcript tmnsnmp-bof-00mar

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: [email protected]
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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
2
2
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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
3
3
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, ...
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
4
4
TMN Relationship to Telecommunications Networks
WorkStation
WS
.
WS
WS
TMN
OS
Survelliance
OS
Provisioning
OS
Traffic Mgmt
WS
Data Communications Network
TMN Interfaces
Switching Transmission
System
Systems
Switching
System
Transmission
Systems
Switching
System
Telecommunications Network
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
5
5
TMN Layered Architecture (M.3010)
OSF
Business
Management
• Enterprise view
• Goal setting, finance, budgeting
• Product & human resource planning
Service
Management
• Contacts with customers & svc providers
• Service orders, complaints, & billing
• Quality of service
Network
Management
• Network support of all services
• End-to-end network view of all NEs & links
Element
Management
• View of NE subset, individually or
collectively as a subnetwork
• Mediation
Network
Elements
• Network resource functionality
•
q
OSF
•
q
OSF
q
•
OSF
q
•
NEF
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
6
6
Elements of a TMN Interface
Managed
System
Managing
System
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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
7
7
TMN Physical Architecture (M.3010)
TMN
Operations
System
(OS)
F
Q/X/F
WS
G
Data Communications Network
(DCN)
X
WS - Workstation
Q/F
Mediation
Device
(MD)
Q
Q
Q
Data Communications Network
(DCN)
Q
Network
Element
(NE)
Q
Network
Element
(NE)
Q Adaptor
(QA)
Q Adaptor
(QA)
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
8
8
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 ITUT 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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
9
9
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.
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
10
10
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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
11
11
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, ...
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
12
12
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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
13
13
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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
14
14
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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
15
15
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.
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
16
16
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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
17
17
The Q.821 Alarm Surveillance Model
Managed
Object
(e.g., TTP)
Notification
Event
Forwarding
Discriminator
Agent
LOG
Alarm Reports, to a
Manager (e.g., OS)
ALARM
ALARM
RECORD
RECORD
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
18
18
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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
19
19
Event Report Management Function (X.734)
The Event Reporting Function provides services and management support
objects to provide the following capabilities:
1. Allow specification the destination(s) and backup destination(s) to
which event reports are to be sent.
2. Allow the specification of filtering criteria that determine which
notifications to transmit as event reports.
3. Allow the initiation and termination of event reporting to a particular
destination.
4. Allow temporary suspension and resumption of event reporting
services.
5. Allow for scheduling of event reporting activity.
6. Allow retrieval of event reporting characteristics.
7. Allow the specification of whether or not events are to be sent in
confirmed mode.
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
20
20
Event Reporting Model
Notifications
Managed
Objects
Event
Preprocessing
Event
Reporting
Discriminator
Event
Reports
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
Potential
Event
Reports
Discriminator
Construct
Event
Report
Controls
M. Klerer -
21
21
Event Forwarding Discriminator Behaviour
The Event Forwarding Discriminator (EFD) contains a destination, and optionally,
a backup destination list and active destination attribute. When the EFD forwards
event reports it forwards these event reports to the destination indicated in the
destination sttribute or to the destination indciated in the active destination
attribute when this attribute is present. The backup destination list is a prioritized
list of backup destinations that are used if the primary or higher priority
destination becomes unreachable.
The optional mode attribute in the EFD determines whether the event report will
be sent in the confirmed or unconfirmed mode.
The scheduling characteristics of the EFD are determinjed by the Scheduling
Package that has been instantiated. At most one scheduling package may be
instantiated. If a scheduling package is instatntiated the availability status
package must also be instantiated.
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
22
22
Event Forwarding Discriminator Behaviour
The types of events that will be forwarded are determined by the logical
expression contained in the discriminator construct.
Event forwarding to a particular destination is initiated by creating an EFD
and terminated by deleting an EFD.
Suspension and resumption of event reporting is accomplished by
manipulating the administrative state attribute of the EFD. When the
administrative state is Locked, event reporting is suspended; changing to
the Unlocked state resumes event reporting.
Whether or not the EFD is currently on- or off-duty is indicated by its
availability status. In the absence of scheduling capability the EFD is
always on duty and this attribute is not present.
To allow monitoring of the history of event reporting of a particular system,
the EFD emits notifications when it is created, modified and deleted. The
first event processed by an EFD is its own creation notification; the last its
own deletion notification.
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
23
23
The Log Control Function (X.735)
The Log Control Function provides services and management support
objects to provide the following capabilities:
1. Allow the specification of filtering criteria that determine what
information is to be logged.
2. Allow the initiation and termination of logging to a particular log.
3. Allow temporary suspension and resumption of logging activity
4. Allow for scheduling of logging activity.
5. Allow retrieval of logging characteristics.
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
24
24
Log Control Model
Notifications
Managed
Objects
Applications
Event
Preprocessing
Event
Data
Event Discriminator
Construct
Log
Event
Event
Records Record
Requests
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
Event Report
Collector
Event
Data
Event
Log
Controls
Event
Reports
M. Klerer -
25
25
Log Behaviour
The Log is a support object that provides the capability of recording local
and incoming events. For each event or event report to be logged, a log
record is created and stored in the log.
The log, as defined in ISO, is a logical entity. A log may, therefore, be of
infinite size and may be implemented on multiple and heterogeneous
devices.
Logs that are of finite size will eventually become full. Two kinds of
behavior may be experienced when the log-full condition occurs: the log
may wrap, i.e. earliest received records are deleted, or the log may halt, i.e.
the most recent events are discarded.
To allert managers that a log-full condition is approaching, a Capacity
Alarm Threshold notification is available and may be used to generate
alarms. This threshold is set-valued. The threshold and associated
notification is mandatory for a log that displays "halt" behavior.
The log records within a particular log contain record ids. These ids are
assigned ascending in numerical sequence and can be used for retrieving
all records since the last read.
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
26
26
Log Behaviour; Contd.
The kind of information that will be logged is determined by the logical expression
contained in the discriminator construct.
Logging to a particular log is initiated by creating a log and terminated by deleting
the log. Alternatively, logging can also be terminated when the stop time arrives.
Suspension and resumption of logging is accomplished by manipulating the
administrative state attribute of the log. When the administrative state is Locked,
logging is suspended; changing to the Unlocked state resumes logging. Log
records can be retrieved eben when the log is in the Locked state.
Whether or not the log is currently on- or off-duty is indicated by its availability
status.
To allow monitoring of the history of the log of a particular system, the log emits
notifications when it is created, modified, deleted or when its optional capacity
threshold is exceeded.
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
27
27
The Event Log Record
event Log Record MANAGED OBJECT CLASS
ATTRIBUTES
Record Id
Logging time
Managed object class
Managed object instance
Event type
R/W
R
R
R
R
R
OPERATIONS
None
NOTIFICATIONS
None
CONDITIONAL PACKAGES
Event Time Package
Notification Identifier Package
Correlated Notifications Package
Additional Text Package
Additional Information Package
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
28
28
Log Record and Event Log Record Behavior
A log record cannot be created by a direct management operation. Instead
log records are created as a side effect of an event report or a local event.
Log records contain record ids that are unique within the log and are
assigned in numericaly ascending order.
All log records are time stamped when logged.
Event log records contain optional event time, notificationidentifier,
correlated notifications, additional text and additional information
attributes. These attributes are present in the event record whenever they
are contained as parameters in the incoming event report or when
available in the local system for local events.
Event log records cannot be modified by management action, but it can be
deleted. Until deleted event log records constitute an unmodified record of
what has occurred.
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
29
29
Event Reporting and Logging Model
Managed
Object
Log
Preprocessing
Event
Log
Applications
Discriminator
Construct
Event
Event
Records Record
Requests
Event
Data
Event
Log
Controls
Event
Data
Event Report
Collector
Event
Reports
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
Event
Preprocessing
Event
Reporting
Discriminator
Event
Reports
Potential
Event
Reports
Discriminator
Construct
Event
Report
Controls
M. Klerer -
30
30
Alarm Reporting Function (X.733)
The Alarm Reporting Function provides the user with the ability to
transmit and clear alarms. Alarms are events that indicate a
change in the networking or systems environment that is of
concern to management. The alarms allow for the indication of the
severity of the situation and provide parameters that facilitate
event correlation.
Five alarm types have been defined:
-
Communications alarm
Quality of service alarm
Processing alarm
Equipment alarm
Environmental alarm
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
31
31
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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
32
32
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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
33
33
Q.822 Performance Monitoring Hierarchy
Top
(X.721)
Scanner
(X.738)
Treshold
Data
(Q.822)
Current
Data
(Q.822)
History
Data
(Q.822)
Technology
Specific
Technology
History Data
Specific
History Data
Technology
Specific
Current Data
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
34
34
Model of the Performance Data Collection
Managed Object being observed
Current Data or its subclasses
Current Data or its subclasses
scannerId
Current Data or its subclasses
scannerId
granularityPeriod
scannerId
granularityPeriod
suspectFlag
granularityPeriod
suspectFlag
various
PM attributes
suspectFlag
.
various PM attributes
. PM
. attributes
various
. . .
.
. shown
not all attributes
.
not all attributes shown
not all attributes shown
.
.
.
not all attributes shown
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
35
35
Thresholding Applied to a Single Managed Object
Managed Object Being Observed
Log
logId
DiscriminatorConstruct
A la r m R
ecord
Alarm
A l a r m Record
R ec o r d
reco rd Id
recordId
r e c o r d Id
e v e n t T i m e.
eventTime
e v e n t T i m e.
.
.
.
.
n o t all
a l l a t t r i b u t e s shown
sh o w n
not
n o t a attributes
ll a t t r i b u t e s s h o w n
.
.
not all attributes shown
Quality of Service
Notification
Event Forwardind Discriminator
discriminatorConsdtruct
destinationAddress
beginTime
endTime
administrativeState
.
.
Current Data or its suclasses
scannerId
granularityPeriod
suspectFlag
thresholdDataInstance
various PM Attributes
.
.
.
not all attributes shown
Threshold Data
thresholdDataId
thresholdAttributeList
not all attributes shown
.
.
.
not all attributes shown
M-Event Report of
Threshold Crossing
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
36
36
Thresholding Applied to a Group of Managed Objects
Threshold Data
thresholdDataId
thresholdAttributeList
Managed Object Being Observed
Managed Object Being Observed
Current
c u r r e n t D Data
a ta I d or its suclasses
Managed Object Being Observed
c u r r e n tD
a ta I dor its suclasses
Current
Data
s ugranularityPeriod
s p ectF la g
Current Data or its suclasses
g r a n u la r it y P e r i o d
suspectFlag
thresholdDataInstance
scannerIdl
granularityPeriod
variousPmnAttributes
.
thresholdDataInstance
.
suspectFlag
.
variousPmnAttributes
.
thresholdDataInstance
.
.
various PM Attributes
n oForwarding
t a ll a t t r ib u t eDiscriminator
s show n
Event
.
.
.
not all attributesdiscriminatorConstruct
shown
n o t a ll a t t r ib u t e s s h o w n
destinationAddress
not all attributes shown
n o t a ll a t t r ib u t e s s h o w beginTime
n
endTime
not all attributes shown
administrativeState
.
.
.
Quality Of Service
Notification
not all attributes shown
M-Event Report of
Threshold Crossing
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
37
37
Performance Monitoring History Data
Managed Object Being Observed
currentDataId
Current Data or its suclasses
suspectFlag
scannerId
granularityPeriod
suspectFlag
discriminatorConstruct
various PM Attributes
.
.
not all attributes shown
.
.
History Data or its
History
Data or its
suclasses
History
Data or its
suclasses
suclasses
historyDataId
historyDataId
historyDataId
.various PM Attributes
.various PM Attributes
.various PM Attributes
.
. .
. .
.
not all attributes shown
not all attributes shown
not all attributes shown
not all attributes shown
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
38
38
Management of HCSP Networks Possible Realizations
Option 4
SMS
NMS
Payload EMS
Ckt Layer EMS
Pkt Layer EMS
cNE
cNE
cNE
iwNE
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
pNE
pNE
pNE
M. Klerer -
39
39
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)
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
40
40
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.3208series 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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
41
41
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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
42
42
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
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
43
43
Scheduled Meetings
Host
Date
TIPHON
March 14, 2000
ETSI TC-TMN
May 23-24, 2000
T1M1
August 9-11, 2000
ITU-T Q25/4
15-19 January 2001
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
44
44
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:
[email protected]
To subscribe sent e-mail to:
[email protected] with body of text
subscribe jointnm
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
45
45
Want More Information ?
• Selected TMN Standards and Comprehensive
Presentation on SG-4 Work is available via FTP at
— [email protected]/itu_to_ietf/SG4
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
M. Klerer -
46
46
Management of HCSP Networks Possible Realizations
Option 1
SMS
NMS
Inf. EMS
IP EMS
cNE
cNE
cNE
iwNE
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
pNE
pNE
pNE
M. Klerer -
47
47
Management of HCSP Networks Possible Realizations
Option 2
SMS
NMS
Inf. EMS
Semantic
Mediator
cNE
cNE
cNE
iwNE
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
pNE
IP EMS
pNE
pNE
M. Klerer -
48
48
Management of HCSP Networks Possible Realizations
Option 3
SMS
Integrated NMS
Inf. NMS
IP NMS
Inf. EMS
IP EMS
cNE
cNE
cNE
iwNE
IETF TMN BOF, Adelaide, Aus. - 27 March 2000
pNE
pNE
pNE
M. Klerer -
49
49