Internet DRAFT - draft-weijing-lap-ops-user
draft-weijing-lap-ops-user
Weijing Chen
Internet Draft Keith Allen
Expiration Date: April 2003 SBC Communications, Inc.
October 2002
User Cases of Network Operation of Large Access Providers
draft-weijing-lap-ops-user-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document discusses the typical network operation user cases of
Large Access Providers (LAP). Since a LAP has hundreds location,
thousand node, millions subscriber, where the law of large number
affects bottom line of network operation, LAP has been always
striving to streamline all the possible network operation functions.
The user cases presented in this document are generic with respect
to the type of network technology and can be augmented with
technology-specific details. They are intended to be used for
baseline for other network operation streamlining requirements.
Table of Contents
1. Introduction.................................................3
2. Terminology..................................................3
3. User Cases of Network Infrastructure Operation...............5
3.1. NE Installation.............................................5
3.2. NE Software Download........................................5
Chen and Allen Expire April 2003 [Page 1]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
3.3. NE Synchronization..........................................6
3.4. NE Continuous Synchronization...............................7
3.5. Alarm Browsing and Clearing.................................7
3.6. NE, Plug-In, and Port Configuration.........................8
3.7. NE and Plug-In Remove.......................................9
3.8. NE, Plug-In, and Port Retrieval.............................9
3.9. NE, Plug-In, and Port Alarm................................11
3.10. NE, Plug-In, and Port Test.................................12
3.11. NE, Plug-In, and Port Performance and Usage................12
3.12. Trunk Link and Connection Configuration....................13
3.13. Trunk Link and Connection Remove...........................14
3.14. Trunk Link and Connection Retrieval........................14
3.15. Trunk Link and Connection Alarm............................15
3.16. Trunk Link and Connection Test.............................16
3.17. Trunk Link and Connection Performance and Usage............17
3.18. Routing and Signaling Configuration........................18
3.19. Routing and Signaling Remove...............................18
3.20. Routing and Signaling Retrieval............................19
3.21. Routing and Signaling Alarm................................20
3.22. Routing and Signaling Test.................................21
3.23. Routing and Signaling Performance and Usage................21
4. User Cases of Peer Provider Service Operation...............22
4.1. Provider Service Provision (Network-based).................22
4.2. Provider Service Remove (Network-based)....................23
4.3. Provider Service Retrieval (Network-based).................23
4.4. Provider Service Provision (Connection-based)..............24
4.5. Provider Service Remove (Connection-based).................25
4.6. Provider Service Retrieval (Connection-based)..............25
4.7. Provider Service Alarm.....................................26
4.8. Provider Service Test......................................27
4.9. Provider Service Performance and Usage.....................27
5. User Cases of Subscriber Service Operation..................28
5.1. Subscriber Service Provision (Network-based)...............28
5.2. Subscriber Service Remove (Network-based)..................29
5.3. Subscriber Service Retrieval (Network-based)...............29
5.4. Subscriber Service Provision (Connection-based)............30
5.5. Subscriber Service Remove (Connection-based)...............31
5.6. Subscriber Service Retrieval (Connection-based)............31
5.7. Subscriber Service Alarm...................................32
5.8. Subscriber Service Test....................................33
5.9. Subscriber Service Performance and Usage...................34
6. User Cases of Security Operation............................35
6.1. Management Communication Channel Security..................35
6.2. Operator and OSS Login.....................................35
6.3. Operator and OSS Group Administration......................35
7. Security Considerations.....................................36
8. References..................................................36
9. Authors' Addresses..........................................37
Chen and Allen Expire April 2003 [Page 2]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
1. Introduction
Large providers of broadband Internet access are faced with
difficult demands that need be alleviated by streamlining network
operation. This document discusses the typical network operation
user cases of Large Access Providers (LAP). Since a LAP has
hundreds location, thousand node, millions subscriber, where the law
of large number affects bottom line of network operation, LAP has
been always striving to streamline all the possible network
operation functions. The user cases presented in this document are
generic with respect to the type of network technology and can be
augmented with technology-specific details. They are intended to be
used for baseline for other network operation streamlining
requirements.
A LAP typical has one or few network management systems (NMSs)
deployed to manage its network. NMSs are located in network
operations centers, remote from the network elements (NEs) but
connected to them by a central office data communications network
(CODCN). While most NEs provide some local means of accessing the
device for management purposes (ôcraft interfaceö or "command line
interface"), this is usually used only during extraordinary
situations, as the cost and time required sending a technician to
the NE site is burdensome. Also it is time consuming and expensive
to train a technician to be proficient in many varieties of "craft
interface" or "command line interface". Thus, the NMS is a service
provider's primary access for managing network elements.
This does not mean that all network operation functions will be
performed by people sitting in front of a NMS terminal. To the
contrary, streamlining network operation functions requires the NMS
to be integrated with a service provider's Operation Support Systems
(OSSs). The NMS must provide electronic protocol interfaces to
accomplish this.
The user cases are described to center on network management system
(NMS). Each use case description indicates the actor(s) involved in
the use case. An actor is a user of the system and may be a human
or a machine. In addition to the behavior described in the use case
body, each use case also lists preconditions and post conditions.
Preconditions are statements that must hold true before the system
is expected to exhibit the behavior described in the use case. Post
conditions are statements that must hold true at the completion of
the use case.
2. Terminology
Chen and Allen Expire April 2003 [Page 3]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
LAP (Large and very large Access Provider)
An access provider who at least has: hundreds geographically
dispersed access service location, thousands access service node,
and millions access service subscriber.
CODCN (Central Office Data Communication Network)
An IP-based data communication network that links all the central
offices together
NMS (Network Management System)
A suite of complex software systems and hardware platforms that
is responsible for network management and operation.
OSS (Operation Support System)
A suite of complex software systems and hardware platforms that
is responsible for service management and operator, inventory
management and operation, work force management and operation.
Configuration vs. Provision
A service provider configures the network equipment before
provisions the provider and/or subscriber service on the network
equipment.
CLLI Code (Common Language Location Identifier)
A CLLI code is an 11-character standardized geographic identifier
that uniquely identifies the geographic location of places and
certain functional categories of equipment unique to the
telecommunications industry.
NE (Network Equipment)
A physical platform that performs network function, for example
router, switch
Plug-In
A physical hardware that must be plugged into NE to function
Port
A physical or logical connector on a network equipment or plug-in
Link
A physical fiber or copper that links two or more physical ports
Connection
A logical channel that spans over one or multiple physical links,
for example ATM VC, Frame Relay VC, MPLS LSP, Ethernet VLAN
Chen and Allen Expire April 2003 [Page 4]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
Peer Provider
A service provider who is providing additional connecting, or
enhanced, or advanced network service on top of access service
provided by LAP
Subscriber
A customer who subscribes to the access service from LAP
3. User Cases of Network Infrastructure Operation
3.1. NE Installation
Actor: Operator, NE
Pre-Conditions:
1. A new NE has been installed.
2. The NE is connected to OCN to which NMS is also connected.
3. The NE has been assigned an IP address through some local
means and the IP connectivity between NE and NMS has been
established.
Descriptions:
1. Operator navigates to the NE by entering its IP address.
2. Operator assigns the NE a unique name (which could be a CLLI
code).
3. The NMS then MUST automatically synchronize itself with the
current configuration of the NE. See User Case 3.3.
Post Conditions: The NMS is in sync with the NE and the NMS is now
managing the NE.
3.2. NE Software Download
Actor: Operator, NE
Pre-Conditions:
1. The NE is under the NMS management.
2. The operator has load new NE software from a distribution
medium onto the MS.
Descriptions:
1. The software download MUST be performed from the NMS GUI and
MUST NOT require sending a technician to the NE.
2. The software download MUST be performed without halting the
NE. It SHOULD be done without rebooting the NE and
interrupting services.
3. The operator SHOULD be able to download the software
immediately or schedule the download for a later time.
4. The NE and NMS MUST verify the download and notify the
operator of the success or failure of the download.
5. The operator SHOULD be able to activate the new software
once the success of it has been verified. The software SHOULD
be automatically activated if operator chooses so.
6. The NE and NMS MUST notify the operator of the success or
failure of activating the new software.
Chen and Allen Expire April 2003 [Page 5]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
7. If for some reason the new software need be reverted to the
previous version, the operator SHOULD be able to accomplish
this from the GUI without having to download the previous
version.
8. The download MUST be logged.
Post Conditions: The NE is running the new software or is reverted
to previous version.
3.3. NE Synchronization
Actor: NE
Pre-Conditions:
1. The NMS has just established or re-established connectivity
with the NE(s).
Descriptions:
1. The NE is the master of "hard" data about itself. The "hard"
data is read-only data that cannot be changed by the MS. This
includes, for example, the current alarm and operational state
of the resource entity (NE, plug-in, port, etc.), the hardware
installed in and software loaded on the NE, performance and
usage measurement, etc. The NMS is responsible for updating
itself to match the NE on this data.
2. The NMS is the master of "soft" data about the NE. The
"soft" data is writable data that is set by the MS. This
includes, for example, configurable parameters such as
administrative state of the resource entity (NE, plug-in, port,
etc.), whether or not they are assigned, links and connections
(circuit, VC, LSP, etc), VPNs, routing and signaling, etc. The
NMS is responsible for updating the NE to match the NMS on this
data.
3. If the NE is a new NE, the NMS MUST automatically
synchronize with it for the first time.
4. The NMS MUST automatically detects a condition that might
have caused it to lose connectivity with the NE. The NMS MUST
automatically synchronize with the NE it has been out of
connectivity with. This includes:
. The NMS has been down and is now active again.
. A NE has been down and is now active again.
. The CODCN between the NMS and NEs has been down and is now
active again.
5. Priority SHOULD be placed on re-establishing the ability to
synchronize the affected NEs over other management functions.
6. The volume of data update is very large in LAP network. The
bulk data synchronization MUST BE finished during the NMS
maintenance window.
7. The NMS GUI MUST be automatically updated with the new
synchronized data.
Post Conditions: The data in the NMS and the NE accurately reflects
the current state of each other's configuration.
Chen and Allen Expire April 2003 [Page 6]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
3.4. NE Continuous Synchronization
Actor: NE
Pre-Conditions:
1. The state of a NE changes in such a way that data in the NMS
may inaccurately reflect the state of the NE configuration.
Descriptions:
1. The NE MUST automatically notify the NMS changes to its
hardware, software, links and connections, routing and
signaling, and any other physical or logical resource entity
steward by the NE, especially changes due to technician
interaction with the NE through "craft interface" or "command
line interface".
2. The NE MUST support automatically notifications of
installation, remove, or change, of plug-in units.
3. The NMS MUST automatically maintains data synchronization
between itself and the NE. The operator SHOULD NOT be aware
exactly where the data physically resides or how the NMS
provides synchronization and consistency.
4. Changes are logged, including date time stamp of the change.
Items that MUST be logged include: changes to hardware and
software, protection switching events, etc.
5. The NMS MUST maintain the time source for the purposes of
providing timestamps. The NMS MUST enforces time-stamp
synchronization for the NE in its management jurisdiction. It
MUST maintain a single normalized time designation (GMT) for
all NE events and displays events with the local time. The
operator designates the local time zone. The NMS MUST
automatically adjusts for daylight savings time.
6. The NMS GUI MUST be automatically updated with the new
synchronized data.
Post Conditions: The data in the NMS accurately reflects the
current state of the NE configuration.
3.5. Alarm Browsing and Clearing
Actor: Operator, NE
Pre-Conditions:
1. The NE is under EMS management.
Descriptions:
1. The operator MUST be able to browse any active alarm and
history alarm in interactive and bulk method. The operator
MUST be able to force the NMS to re-synchronize its alarm state
with a NE.
2. The operator MUST be able to select any alarms in
interactive and bulk method and write them to a text file that
can be stored, transferred, etc.
3. The operator MUST be able to select any alarm in interactive
and bulk method and delete them.
4. The operator MUST be able to set a limit on the size of the
history alarm log. The oldest alarm records are dropped from
the log to make room for the new records.
Chen and Allen Expire April 2003 [Page 7]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
5. The network resource entity (NE, plug-in, port, link,
connection, service, etc.) may send a clearing alarm to clear a
previous sent alarm. The NMS MUST be able to correlate the
clearing alarm with the original alarm.
6. The operator may select an alarm and manually clear it. The
reason, note, operator's name MUST be logged.
7. The cleared alarm MUST be marked "cleared", removed from the
active alarm log, and moved to the history alarm log. The date
and time, reason of the alarm clearing MUST be logged.
8. Any "descendant" alarms correlated with the cleared alarm
MUST be also cleared in the same fashion.
9. The NMS GUI MUST be automatically updated with the new alarm
data.
Post Conditions: The alarm and any correlated descendants are
marked as cleared and moved from the active alarm log to the history
alarm log.
3.6. NE, Plug-In, and Port Configuration
Actor: Operator, NE
Pre-Conditions:
1. The NE is under the NMS management.
2. A new piece of plug-in may have just been installed in the
NE.
Description:
1. If a new piece of plug-in has just been installed, the NMS
MUST automatically detect the addition and retrieve all the
"hard" data from the NE about the new hardware. See user case
3.4 for more details.
2. The operator MUST be able to configure the NE with the
following data:
. NE name
. NE user label (e.g. CLLI code)
. NE equipment code and function code
. NE location
. NE administrative state (lock, unlock, defect)
. External time (wall-clock time)
. Network technology-specifc data
3. The operator MUST be able to configure the plug-in with the
following data:
. Plug-in name
. Plug-in user label
. Plug-in equipment code and function code
. Plug-in administrative state (lock, unlock, defect)
. Network technology-specifc data
4. If same type of plug-in had previously been installed in the
same slot, the NMS MUST automatically configures the new plug-
in the same way the old plug-in was configured. This is to
automate the handling defect repair case in which defect plug-
in is removed and new one installed.
Chen and Allen Expire April 2003 [Page 8]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
5. The operator MUST be able to configure the port with
following data:
. Port name
. Port user label
. Port administrative state (lock, unlock, defect)
. Network technology-specific data
6. Any configuration by the operator that violates an entity
relationship or cause an invalid state transition MUST not be
allowed.
7. Any configuration by operator MUST be logged. The log MUST
be retrieval in both interactive and bulk method.
8. The NMS GUI MUST be automatically updated with the new
configuration data.
Post Conditions: The NE is updated according to the configuration
made by the operator.
3.7. NE and Plug-In Remove
Actor: Operator, NE
Pre-Conditions:
1. The NE is under the NMS management.
2. A piece of hardware (NE, plug-in, etc.) has just been
removed.
Descriptions:
1. Upon the removal of a piece of hardware, the NMS MUST
automatically detect the removal. See user case 3.4 for more
details.
2. Any network trunk link or connection, provider or subscriber
service currently supported by the removed hardware is handled
as if the hardware failed. See user case 3.9 for more details.
3. The NMS MUST automatically stores the configuration of the
removed hardware so that if a same type of new hardware is
installed it can be automatically configured the same as the
old.
4. If hardware removal is permanent, operator MUST be able to
remove stored configuration from the NMS permanently.
5. The removal MUST be logged. The log MUST be retrieval in
both interactive and bulk method.
6. The NMS GUI MUST be automatically updated with hardware
removed.
Post Conditions: The NMS is in sync with the new state of the
network and the NE.
3.8. NE, Plug-In, and Port Retrieval
Actor: Operator, NE
Pre-Conditions:
1. The NE is under the NMS management.
Descriptions:
1. The operator MUST be able to retrieve the following data for
the NE:
. NE name
Chen and Allen Expire April 2003 [Page 9]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
. NE user label (e.g CLLI code)
. NE equipment code and function code
. NE vendor name
. NE serial number
. NE software version
. NE location
. NE administrative state (lock, unlock, defect)
. NE operational state (enabled, disabled)
. External time (wall-clock time)
. NE equipment hierarchy (bay, shelf, slot, plug-in, port,
etc.)
. Network technology-specific data
2. The operator MUST be able to retrieve the following data from
the NE:
. Any trunk link and connection supported by this NE
. Any routing and signaling context maintained by this NE
. Aggregated network-based provider and subscriber service
group supported by this NE
. Individual connection-based provider and subscriber
service supported by this NE
3. The operator MUST be able to retrieve the following data for
the plug-in:
. Plug-in name
. Plug-in user label
. Plug-in equipment code and function code
. Plug-in administrative state (lock, unlock, defect)
. Plug-in operational state (enabled, disabled)
. Plug-in equipment hierarchy (sub plug-in, port, etc.)
. Network technology-specific data
4. The operator MUST be able to retrieve the following data from
the plug-in:
. Any trunk link and connection supported by this plug-in
. Any routing and signaling context maintained by this plug-
in
. Any aggregated network-based provider and subscriber
service group supported by this plug-in
. Any individual connection-based provider and subscriber
service supported by this plug-in
5. The operator MUST be able to retrieve the following data for
the port:
. Port name
. Port user label
. Port administrative state (lock, unlock, defect)
. Port operational state (enabled, disabled)
. Network technology-specific data
6. The operator MUST be able to retrieve the following data from
the port:
. Any trunk link and connection supported by this port
. Any routing and signaling context maintained by this port
Chen and Allen Expire April 2003 [Page 10]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
. Any aggregated network-based provider and subscriber
service group supported by this port
. Any individual connection-based provider and subscriber
service supported by this port
7. The operator MUST be able to retrieve any data maintained by
NE, plug-in, and port in the both interactive and bulk method.
Post Conditions: The operator and OSS retrieve the data as they
desire.
3.9. NE, Plug-In, and Port Alarm
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NE is under the NMS management.
2. The NE, or plug-in, or port experience a notable event, i.e.
an alarm.
Descriptions:
1. The NMS MUST be able to receive an alarm regarding NE, plug-
in, and port from the NE reliably.
2. The operator MUST be able to define a default alarm severity
assignment profile to be used by the NE and NMS to assign alarm
severity (Critical, Major, Minor, Warning) to alarm conditions.
3. The operator MUST be able to define an alarm severity
assignment for a specific network resource entity (NE, plug-in,
port).
4. The operator MUST be able to set a length of time for a
specific network resource entity (NE, plug-in, port) during
which alarms on that entity will be suppressed.
5. The operator MUST be able to set "soak" period for the
various alarm conditions. A soak period defines how long an
alarm condition must persist before an alarm is declared.
6. New alarms MUST be added to the active alarm log. Duplicate
alarms SHOULD not be added to the alarm log. Instead, a count
of duplicates MUST be kept for each alarm, along with a record
of when the first and last occurrences were received.
7. If the communication channel between an NE and the NMS is
down, the NMS MUST re-synchronizes to the alarm state of the NE
after the communication channel is up again. The NMS MUST logs
and reports outstanding alarm and cleared alarms missed during
out of synchronization.
8. Alarms from the same NE MUST be correlated to identify any
cause and effect relationships between them. Therefore alarms
are organized into tree structures, where child alarms
represent conditions that are actually a result of the parent
alarm. Alarms at the roots of these trees are the actual alarm
conditions. Repairing the root-cause alarm will fixing its
descendent alarms.
9. The received alarm MUST contain the following data:
. Alarm unique ID
. Alarm severity
. Alarm type
Chen and Allen Expire April 2003 [Page 11]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
. Alarm description
. Alarm date and time
. Alarm source entity (smallest possible unit)
. Alarm ID of the root cause alarm to which this alarm may
have been correlated
. Network technology-specific data
10. The network resource entity (NE, plug-in, port) may clear a
previous sent alarm. See user case 3.5 for more details.
11. The NMS GUI MUST be automatically updated with the new alarm
data.
Post Conditions: The active alarm log and history alarm log are
updated accordingly.
3.10. NE, Plug-In, and Port Test
Actor: Operator, NE
Pre-Conditions:
1. The NE is under the NMS management.
Descriptions:
1. The operator MUST be able to invoke any network resource
entity (NE, plug-in, port) test capability from the NMS GUI.
2. The operator SHOULD be able to invoke multiple concurrent
tests on the same and different network resource entity (NE,
plug-in, port).
3. The operator SHOULD be able to schedule the test at a future
time.
4. The operator SHOULD be able to set source and sink points,
number of iterations, iteration interval, of continuity
(loopback) test, if network technology supports it.
5. The test result SHOULD be displayed and retrievable through
the NMS GUI.
Post Conditions: The test result is available for diagnosing.
3.11. NE, Plug-In, and Port Performance and Usage
Actor: Operator, NE
Pre-Conditions:
1. The NE is under the NMS management.
Descriptions:
1. The operator MUST be able to specify the following
performance and usage data collection parameters:
. Collection interval, typically 15 minutes
. Number of intervals to be collected into a single data
file, typically 96 intervals
. Lifetime of the data files in NE
. Network resource entities or types of entities (NE, plug-
in, port) from which data is to be collected
. Network technology-specific performance and usage data to
be collected
2. The operator MUST be able to set the threshold values for
the monitored data attributes. When the data attribute crosses
this threshold, a threshold crossing alarm MUST be generated.
Chen and Allen Expire April 2003 [Page 12]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
See User Case 3.9 for details on alarm processing. The
monitored data attributes for threshold crossing are the
following:
. NE, plug-in, port related table size
. NE, plug-in, port related buffer size
. Network technology-specific data
3. The operator MUST be able to browse, delete, and transfer
the performance and usage data files based on file names and
locations (e.g. URL).
4. Any data files whose lifetimes expire before they are
deleted by an operator SHOULD be automatically deleted by the
NE or the MS.
Post Conditions: Performance and usage data are collected and
stored in data files.
3.12. Trunk Link and Connection Configuration
Actor: Operator, NE
Pre-Conditions:
1. The NEs are under NMS management.
2. Links have been installed between NEs managed by the MS.
Descriptions:
1. The trunk link or connection discussed here is the point-to-
point network trunk link or connection, not the provider or
subscriber service connection.
2. The operator MUST be able to provision and configure the
port(s) that support the trunk link or connection. See User
Case 3.6 for more details.
3. The operator MUST be able to configure the trunk link and
connection with the following data:
. Supporting port(s)
. Link or connection name (e.g. time slot, DLCI VPI/VCI, LSP
label)
. Link or connection user label (e.g. CLCI code, VPI/VCI,
LSP label)
. Link or connection endpoints (A and Z point). The
endpoints are the ports of endpoint NEs where the link or
connection is terminated.
. Link or connection characteristics (e.g. DS3, OC3, LSP)
. Link or connection directionality (A to Z, Z to A, bi-
directional)
. Link or connection administrative state (lock, unlock,
defect)
. Link or connection maximum bandwidth
. Link or connection routing weight if applicable
. Network technology-specific data
4. The NMS MUST notify the operator and prevents the trunk link
or connection from being built if the two endpoint ports are
not compatible.
Chen and Allen Expire April 2003 [Page 13]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
5. The operator SHOULD be able to optionally constrain the
routing of the connection by identifying the links over which
the connection must be routed.
6. The NMS then attempts to setup the trunk link or connection
with the configuration parameter specified by the operator,
allocate resources in the NEs as necessary.
7. Any configuration by operator MUST be logged. The log MUST
be retrieval in both interactive and bulk method.
8. The NMS MUST store the link or connection data in its
database for later reference.
9. The NMS GUI MUST be automatically updated with new
configuration data.
Post Conditions: The trunk link or connection is setup and can
provide provider or subscriber services.
3.13. Trunk Link and Connection Remove
Actor: Operator, NE
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
Descriptions:
1. The trunk link or connection discussed here is the point-to-
point network trunk link or connection, not the provider or
subscriber service connection.
2. The operator MUST be able to select the trunk link or
connection based on name, or user label, or either one of
endpoints.
3. The NMS MUST notify the operator and prevents the selected
trunk link or connection from being removed if the trunk link
or connection is supporting active provider or subscriber
service.
4. The NMS then attempt to remove the selected trunk link or
connection from network, release the associated resources in
the NEs as necessary.
5. Removal MUST be logged. The log MUST be retrieval in both
interactive and bulk method.
6. The NMS MUST update the trunk link or connection data in its
database for later reference.
7. The NMS GUI MUST be automatically updated with the trunk
link or connection removed.
Post Conditions: The trunk link or connection is removed.
3.14. Trunk Link and Connection Retrieval
Actor: Operator, NE
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
Descriptions:
Chen and Allen Expire April 2003 [Page 14]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
1. The trunk link or connection discussed here is the point-to-
point network trunk link or connection, not the provider or
subscriber service connection
2. The operator MUST be able to retrieve the following data for
the trunk link or connection:
. Link or connection name (e.g. time slot, DLCI VPI/VCI, LSP
label)
. Link or connection user label (e.g. CLCI code, VPI/VCI,
LSP label)
. Link or connection endpoints (A and Z point). The
endpoints are the ports of endpoint NEs where the link or
connection is terminated.
. Link or connection characteristics (e.g. DS3, OC3, LSP)
. Link or connection directionality (A to Z, Z to A, bi-
directional)
. Link or connection administrative state (lock, unlock,
defect)
. Link or connection operational state (enabled, disabled)
. Link or connection maximum bandwidth
. Link or connection used bandwidth if applicable
. Link or connection available bandwidth if applicable
. Link or connection routing weight if applicable
. Network technology-specific data
3. The operator MUST be able to retrieve the following data from
the trunk link or connection:
. Any NE, plug-in, port supporting this link or connection
. Any routing and signaling context supporting this
connection
. Any routing and signaling context supported by this link
or connection
. Any aggregated network-based provider and subscriber
service group supported by this link or connection
. Any individual connection-based provider and subscriber
service supported by this link or connection
4. The operator MUST be able to retrieve any trunk link or
connection data in the both interactive and bulk method.
Post Conditions: The operator and OSS retrieve the data as they
desire.
3.15. Trunk Link and Connection Alarm
Actor: Operator, NE
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
3. The trunk links or connections experience a notable event,
i.e. an alarm.
Descriptions:
1. The trunk link or connection discussed here is the point-to-
point network trunk link or connection, not the provider or
subscriber service connection.
Chen and Allen Expire April 2003 [Page 15]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
2. The NMS MUST be able to receive an alarm regarding trunk
link, connection from the NE reliably.
3. The operator MUST be able to define a default alarm severity
assignment profile to be used by the NE and NMS to assign alarm
severity (Critical, Major, Minor, Warning) to alarm conditions.
4. The operator MUST be able to define an alarm severity
assignment for a specific network resource entity (link,
connection).
5. The operator MUST be able to set a length of time for a
specific network resource entity (link, connection) during
which alarms on that entity will be suppressed.
6. The operator MUST be able to set "soak" period for the
various alarm conditions. A soak period defines how long an
alarm condition must persist before an alarm is declared.
7. New alarms MUST be added to the active alarm log. Duplicate
alarms SHOULD not be added to the alarm log. Instead, a count
of duplicates MUST be kept for each alarm, along with a record
of when the first and last occurrences were received.
8. If the communication channel between an NE and the NMS is
down, the NMS MUST re-synchronizes to the alarm state of the NE
after the communication channel is up again. The NMS MUST logs
and reports outstanding alarm and cleared alarms missed during
out of synchronization.
9. Alarms from the same NE MUST be correlated to identify any
cause and effect relationships between them. Therefore alarms
are organized into tree structures, where child alarms
represent conditions that are actually a result of the parent
alarm. Alarms at the roots of these trees are the actual alarm
conditions. Repairing the root-cause alarm will fixing its
descendent alarms.
10. The received alarm MUST contain the following data:
. Alarm unique ID
. Alarm severity
. Alarm type
. Alarm description
. Alarm date and time
. Alarm source entity (smallest possible unit)
. Alarm ID of the root cause alarm to which this alarm may
have been correlated
. Network technology-specific data
11. The network resource entity (link, connection) may clear a
previous sent alarm. See user case 3.5 for more details.
12. The NMS GUI MUST be automatically updated with the new alarm
data.
Post Conditions: The active alarm log and history alarm log are
updated accordingly.
3.16. Trunk Link and Connection Test
Actor: Operator, NE
Pre-Conditions:
Chen and Allen Expire April 2003 [Page 16]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
Descriptions:
1. The trunk link or connection discussed here is the point-to-
point network trunk link or connection, not the provider or
subscriber service connection.
2. The operator MUST be able to invoke any network resource
entity (link, connection) test capability from the NMS GUI.
3. The operator SHOULD be able to invoke multiple concurrent
tests on the same and different network resource entity (link,
connection).
4. The operator SHOULD be able to schedule the test at a future
time.
5. The operator SHOULD be able to set source and sink points,
number of iterations, iteration interval, of continuity
(loopback) test, if network technology supports it.
6. The test result SHOULD be displayed and retrievable through
the NMS GUI.
Post Conditions: The test result is available for diagnosing.
3.17. Trunk Link and Connection Performance and Usage
Actor: Operator, NE
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
Descriptions:
1. The trunk link or connection discussed here is the point-to-
point network trunk link or connection, not the provider or
subscriber service connection.
2. The operator MUST be able to specify the following
performance and usage data collection parameters:
. Collection interval, typically 15 minutes
. Number of intervals to be collected into a single data
file, typically 96 intervals
. Lifetime of the data files in NE
. Network resource entities or types of entities (link,
connection) from which data is to be collected
. Network technology-specific performance and usage data to
be collected
3. The operator MUST be able to set the threshold values for the
monitored data attributes. When the data attribute crosses this
threshold, a threshold crossing alarm MUST be generated. See
User Case 3.9 for details on alarm processing. The monitored
data attributes for threshold crossing are the following:
. Link or connection QoS
. Link or connection table size
. Link or connection buffer size
. Network technology-specific data
Chen and Allen Expire April 2003 [Page 17]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
4. The operator MUST be able to browse, delete, and transfer
the performance and usage data files based on file names and
locations (e.g. URL).
5. Any data files whose lifetimes expire before they are
deleted by an operator SHOULD be automatically deleted by the
NE or the MS.
Post Conditions: Performance and usage data are collected and
stored in data files.
3.18. Routing and Signaling Configuration
Actor: Operator, NE
Pre-Conditions:
1. The NEs are under NMS management.
2. The trunk links or connections are under the NMS management.
Descriptions:
1. The operator MUST be able to provision and configure the
NE(s), plug-in(s), port(s) that support the routing and
signaling context. See User Case 3.6 for more details.
2. The operator MUST be able to configure the routing and
signaling context with the following data:
. Supporting NE(s), plug-in(s), port(s)
. Routing and signaling context name (e.g. Autonomous System
number)
. Routing and signaling context user label
. Routing and signaling areas or groups
. Routing and signaling timers
. Routing and signaling preferences and constrains
. Routing and signaling static routes
. Routing and signaling context administrative state (lock,
unlock, defect)
. Network technology-specific data
3. The NMS MUST notify the operator and prevents the routing
and signaling context from being configured if the
configuration violates the network resource entity relationship
or cause invalid state transition.
4. The NMS then attempts to configure the routing and signaling
context with the configuration parameter specified by the
operator, allocate resources in the NEs as necessary.
5. Any configuration by operator MUST be logged. The log MUST
be retrieval in both interactive and bulk method.
6. The NMS GUI MUST be automatically updated with new
configuration data.
Post Conditions: The routing and signaling context is configured
and can support provider or subscriber services.
3.19. Routing and Signaling Remove
Actor: Operator, NE
Pre-Conditions:
1. The NEs are under NMS management.
2. The trunk links or connections are under the NMS management.
Chen and Allen Expire April 2003 [Page 18]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
Descriptions:
1. The operator MUST be able to select the routing and
signaling context based on name, or user label.
2. The NMS MUST notify the operator and prevents the selected
routing and signaling context from being removed if the routing
and signaling context is supporting active provider or
subscriber service.
3. The NMS then attempt to remove the selected routing and
signaling context from network, release the associated
resources in the NEs as necessary.
4. Removal MUST be logged. The log MUST be retrieval in both
interactive and bulk method.
5. The NMS GUI MUST be automatically updated with the routing
and signaling context removed.
Post Conditions: The routing and signaling context is removed.
3.20. Routing and Signaling Retrieval
Actor: Operator, NE
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
Descriptions:
1. The operator MUST be able to retrieve the following data for
the routing and signaling context:
. Routing and signaling context name (e.g. Autonomous System
number)
. Routing and signaling context user label
. Routing and signaling areas or groups
. Routing and signaling timers
. Routing and signaling preferences and constrains
. Routing and signaling static routes
. Routing and signaling graphic topology
. Routing and signaling forwarding information base (FIB)
. Routing and signaling context administrative state (lock,
unlock, defect)
. Routing and signaling context operational state (enabled,
disabled)
. Network technology-specific data
2. The operation MUST be able to retrieve the following data
from the routing and signaling context:
. Any NE, plug-in, port supporting this routing and
signaling context
. Any trunk link or connection supporting this routing and
signaling context
. Any trunk connection supported by this routing and
signaling context
. Any aggregated network-based provider and subscriber
service group supported by this routing and signaling
context
Chen and Allen Expire April 2003 [Page 19]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
. Any individual connection-based provider and subscriber
service supported by this routing and signaling context
3. The operator MUST be able to retrieve any routing and
signaling data in the both interactive and bulk method.
Post Conditions: The operator retrieve the data as they desire.
3.21. Routing and Signaling Alarm
Actor: Operator, NE
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling context experience a notable
event, i.e. an alarm.
Descriptions:
1. The NMS MUST be able to receive an alarm regarding routing
and signaling context from the NE reliably.
2. The operator MUST be able to define a default alarm severity
assignment profile to be used by the NE and NMS to assign alarm
severity (Critical, Major, Minor, Warning) to alarm conditions.
3. The operator MUST be able to define an alarm severity
assignment for a specific network resource entity (routing and
signaling context).
4. The operator MUST be able to set a length of time for a
specific network resource entity (routing and signaling
context) during which alarms on that entity will be suppressed.
5. The operator MUST be able to set "soak" period for the
various alarm conditions. A soak period defines how long an
alarm condition must persist before an alarm is declared.
6. New alarms MUST be added to the active alarm log. Duplicate
alarms SHOULD not be added to the alarm log. Instead, a count
of duplicates MUST be kept for each alarm, along with a record
of when the first and last occurrences were received.
7. If the communication channel between an NE and the NMS is
down, the NMS MUST re-synchronizes to the alarm state of the NE
after the communication channel is up again. The NMS MUST logs
and reports outstanding alarm and cleared alarms missed during
out of synchronization.
8. Alarms from the same NE MUST be correlated to identify any
cause and effect relationships between them. Therefore alarms
are organized into tree structures, where child alarms
represent conditions that are actually a result of the parent
alarm. Alarms at the roots of these trees are the actual alarm
conditions. Repairing the root-cause alarm will fixing its
descendent alarms.
9. The received alarm MUST contain the following data:
. Alarm unique ID
. Alarm severity
. Alarm type
. Alarm description
. Alarm date and time
Chen and Allen Expire April 2003 [Page 20]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
. Alarm source entity (smallest possible unit)
. Alarm ID of the root cause alarm to which this alarm may
have been correlated
. Network technology-specific data
10. The network resource entity (routing and signaling context)
may clear a previous sent alarm. See user case 3.5 for more
details.
11. The NMS GUI MUST be automatically updated with the new alarm
data.
Post Conditions: The active alarm log and history alarm log are
updated accordingly.
3.22. Routing and Signaling Test
Actor: Operator, NE
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
Descriptions:
1. The operator MUST be able to invoke any network resource
entity (routing and signaling context) test capability from the
NMS GUI.
2. The operator SHOULD be able to invoke multiple concurrent
tests on the same and different network resource entity
(routing and signaling context).
3. The operator SHOULD be able to schedule the test at a future
time.
4. The operator SHOULD be able to set source and sink points,
number of iterations, iteration interval, of continuity
(loopback) test, if network technology supports it.
5. The test result SHOULD be displayed and retrievable through
the NMS GUI.
Post Conditions: The test result is available for diagnosing.
3.23. Routing and Signaling Performance and Usage
Actor: Operator, NE
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
Descriptions:
1. The operator MUST be able to specify the following
performance and usage data collection parameters:
. Collection interval, typically 15 minutes
. Number of intervals to be collected into a single data
file, typically 96 intervals
. Lifetime of the data files in NE
. Network resource entities or types of entities (routing
and signaling context) from which data is to be collected
. Network technology-specific performance and usage data to
be collected
Chen and Allen Expire April 2003 [Page 21]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
2. The operator MUST be able to set the threshold values for the
monitored data attributes. When the data attribute crosses this
threshold, a threshold crossing alarm MUST be generated. See
User Case 3.9 for details on alarm processing. The monitored
data attributes for threshold crossing are the following:
. Routing and signaling table size
. Routing and signaling buffer size
. Network technology-specific data
3. The operator MUST be able to browse, delete, and transfer
the performance and usage data files based on file names and
locations (e.g. URL).
4. Any data files whose lifetimes expire before they are
deleted by an operator SHOULD be automatically deleted by the
NE or the MS.
Post Conditions: Performance and usage data are collected and
stored in data files.
4. User Cases of Peer Provider Service Operation
4.1. Provider Service Provision (Network-based)
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
Descriptions:
1. The operator and OSS MUST be able to provision and configure
the access port(s) that support the provider service. See User
Case 3.6 for more details.
2. The operator and OSS MUST be able to provision and configure
the provider service with the following data:
. Supporting access port(s)
. Service name
. Service user label
. Service access address(es) (e.g. IP address)
. Service access control list
. Service administrative state (lock, unlock, defect)
. Network technology-specific data
3. The NMS MUST notify the operator and OSS and prevents the
provider service from being built if the configuration violates
the network resource entity relationship or cause invalid state
transition.
4. The NMS then attempts to setup the provider service with the
configuration parameter specified by the operator and OSS,
allocate resources (access address(es) and port(s)) in the NEs
as necessary.
5. Any configuration by operator and OSS MUST be logged. The
log MUST be retrieval in both interactive and bulk method.
Chen and Allen Expire April 2003 [Page 22]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
6. The NMS MUST store the provider service data in its database
for later reference.
7. The NMS GUI and protocol interface to the OSS MUST be
automatically updated with new configuration data.
Post Conditions: The provider service is provisioned.
4.2. Provider Service Remove (Network-based)
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
Descriptions:
1. The operator and OSS MUST be able to select the provider
service based on name, or user label, or access address.
2. The NMS MUST notify the operator and OSS and prevents the
selected provider service from being removed if the provider
service is supporting active subscriber service.
3. The NMS then attempt to remove the selected provider service
from network, release the associated resources (access address
(es) and port(s)) in the NEs as necessary.
4. Removal MUST be logged. The log MUST be retrieval in both
interactive and bulk method.
5. The NMS GUI and protocol interface to the OSS MUST be
automatically updated with the provider service removed.
Post Conditions: The provider service is removed.
4.3. Provider Service Retrieval (Network-based)
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
Descriptions:
1. The operator and OSS MUST be able to retrieve the following
data for the provider service:
. Service name
. Service user label
. Service access address(es) (e.g. IP address)
. Service access control list
. Service administrative state (lock, unlock, defect)
. Service operational state (enabled, disabled)
. Network technology-specific data
2. The operator and OSS MUST be able to retrieve the following
data from the provider service:
. Any access NE, plug-in, port supporting this provider
service
Chen and Allen Expire April 2003 [Page 23]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
. Any routing and signaling context supporting this provider
service
. Any aggregated network-based subscriber service group
supported by this provider service
. Any individual connection-based subscriber service
supported by this provider service
3. The operator and OSS MUST be able to retrieve any provider
service data in the both interactive and bulk method.
Post Conditions: The operator and OSS retrieve the data as they
desire.
4.4. Provider Service Provision (Connection-based)
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
Descriptions:
1. The operator and OSS MUST be able to provision and configure
the access port(s) that support the provider service. See User
Case 3.6 for more details.
2. The operator and OSS MUST be able to provision and configure
the point-to-point, or point-to-multipoint, or multipoint-to-
point, or multipoint-to-multipoint service connection(s) that
support the provider service with the following data:
. Supporting port(s)
. Connection name (e.g. time slot, DLCI VPI/VCI, LSP label)
. Connection user label (e.g. CLCI code, VPI/VCI, LSP label)
. Connection endpoints (A and Z point(s)). The endpoints are
the ports of endpoint NEs where the connection(s) are
terminated.
. Connection characteristics (e.g. DS3, OC3, LSP)
. Connection directionality (A to Z, Z to A, bi-directional)
. Connection administrative state (lock, unlock, defect)
. Connection maximum bandwidth
. Network technology-specific data
3. The operator and OSS MUST be able to provision and configure
the provider service with the following data
. Supporting connection(s)
. Service name
. Service user label
. Service administrative state (lock, unlock, defect)
. Network technology-specific data
4. The NMS MUST notify the operator and OSS and prevents the
provider service from being built if the configuration violates
the network resource entity relationship or cause invalid state
transition.
5. The NMS then attempts to setup the provider service with the
configuration parameter specified by the operator and OSS,
Chen and Allen Expire April 2003 [Page 24]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
allocate resources (connection(s), port(s)) in the NEs as
necessary.
6. Any configuration by operator and OSS MUST be logged. The
log MUST be retrieval in both interactive and bulk method.
7. The NMS MUST store the provider service data in its database
for later reference.
8. The NMS GUI and protocol interface to the OSS MUST be
automatically updated with new configuration data.
Post Conditions: The provider service is provisioned.
4.5. Provider Service Remove (Connection-based)
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
Descriptions:
1. The operator and OSS MUST be able to select the provider
service based on name, or user label.
2. The NMS MUST notify the operator and OSS and prevents the
selected provider service from being removed if the provider
service is supporting active subscriber service.
3. The NMS then attempt to remove the selected provider service
from network, release the associated resources (connection(s)
and port(s)) in the NEs as necessary.
4. Removal MUST be logged. The log MUST be retrieval in both
interactive and bulk method.
5. The NMS GUI and protocol interface to the OSS MUST be
automatically updated with the provider service removed.
Post Conditions: The provider service is removed.
4.6. Provider Service Retrieval (Connection-based)
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
Descriptions:
1. The operator and OSS MUST be able to retrieve the following
data for the provider service:
. Service name
. Service user label
. Service access address(es) (e.g. IP address)
. Service access control list
. Service administrative state (lock, unlock, defect)
. Service operational state (enabled, disabled)
. Network technology-specific data
Chen and Allen Expire April 2003 [Page 25]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
2. The operator and OSS MUST be able to retrieve the following
data from the provider service:
. Any access NE, plug-in, port supporting this provider
service
. Any trunk link and connection supporting this provider
service
. Any connection supporting this provider service
. Any routing and signaling context supporting this provider
service
. Any aggregated network-based subscriber service group
supported by this provider service
. Any individual connection-based subscriber service
supported by this provider service
3. The operator and OSS MUST be able to retrieve any provider
service data in the both interactive and bulk method.
Post Conditions: The operator and OSS retrieve the data as they
desire.
4.7. Provider Service Alarm
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
4. The provider service experiences a notable event, i.e. an
alarm.
Descriptions:
1. The NMS MUST be able to receive an alarm regarding provider
service from the NE reliably.
2. The operator and OSS MUST be able to define a default alarm
severity assignment profile to be used by the NE and NMS to
assign alarm severity (Critical, Major, Minor, Warning) to
alarm conditions.
3. The operator and OSS MUST be able to define an alarm
severity assignment for a specific network resource entity
(provider service).
4. The operator and OSS MUST be able to set a length of time
for a specific network resource entity (provider service)
during which alarms on that entity will be suppressed.
5. The operator and OSS MUST be able to set "soak" period for
the various alarm conditions. A soak period defines how long
an alarm condition must persist before an alarm is declared.
6. New alarms MUST be added to the active alarm log. Duplicate
alarms SHOULD not be added to the alarm log. Instead, a count
of duplicates MUST be kept for each alarm, along with a record
of when the first and last occurrences were received.
7. If the communication channel between an NE and the NMS is
down, the NMS MUST re-synchronizes to the alarm state of the NE
after the communication channel is up again. The NMS MUST logs
Chen and Allen Expire April 2003 [Page 26]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
and reports outstanding alarm and cleared alarms missed during
out of synchronization.
8. Alarms from the same NE MUST be correlated to identify any
cause and effect relationships between them. Therefore alarms
are organized into tree structures, where child alarms
represent conditions that are actually a result of the parent
alarm. Alarms at the roots of these trees are the actual alarm
conditions. Repairing the root-cause alarm will fixing its
descendent alarms.
9. The received alarm MUST contain the following data:
. Alarm unique ID
. Alarm severity
. Alarm type
. Alarm description
. Alarm date and time
. Alarm source entity (smallest possible unit)
. Alarm ID of the root cause alarm to which this alarm may
have been correlated
. Network technology-specific data
10. The network resource entity (provider service) may clear a
previous sent alarm. See user case 3.5 for more details.
11. The NMS GUI and the protocol interface to OSS MUST be
automatically updated with the new alarm data.
Post Conditions: The active alarm log and history alarm log are
updated accordingly.
4.8. Provider Service Test
Actor: Operator, NE
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
Descriptions:
1. The operator and MUST be able to invoke any network resource
entity (provider service) test capability from the NMS GUI.
2. The operator SHOULD be able to invoke multiple concurrent
tests on the same and different network resource entity
(provider service).
3. The operator SHOULD be able to schedule the test at a future
time.
4. The operator SHOULD be able to set source and sink points,
number of iterations, iteration interval, of continuity
(loopback) test, if network technology supports it.
5. The test result SHOULD be displayed and retrievable through
the NMS GUI.
Post Conditions: The test result is available for diagnosing.
4.9. Provider Service Performance and Usage
Actor: Operator, NE, OSS
Chen and Allen Expire April 2003 [Page 27]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
Descriptions:
1. The operator and OSS MUST be able to specify the following
performance and usage data collection parameters:
. Collection interval, typically 15 minutes
. Number of intervals to be collected into a single data
file, typically 96 intervals
. Lifetime of the data files in NE
. Network resource entities or types of entities (provider
service) from which data is to be collected
. Network technology-specific performance and usage data to
be collected
2. The operator and OSS MUST be able to set the threshold values
for the monitored data attributes. When the data attribute
crosses this threshold, a threshold crossing alarm MUST be
generated. See User Case 3.9 for details on alarm processing.
The monitored data attributes for threshold crossing are the
following:
. Provider service QoS data
. Network technology-specific data
3. The operator and OSS MUST be able to browse, delete, and
transfer the performance and usage data files based on file
names and locations (e.g. URL).
4. Any data files whose lifetimes expire before they are
deleted by an operator SHOULD be automatically deleted by the
NE or the MS.
Post Conditions: Performance and usage data are collected and
stored in data files.
5. User Cases of Subscriber Service Operation
5.1. Subscriber Service Provision (Network-based)
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
4. The provider services are under the NMS management.
Descriptions:
1. The operator and OSS MUST be able to provision and configure
the access port(s) that support the subscriber service. See
User Case 3.6 for more details.
2. The operator and OSS MUST be able to provision and configure
the subscriber service with the following data:
Chen and Allen Expire April 2003 [Page 28]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
. Supporting access port(s)
. Supporting provider service(s)
. Service name
. Service user label
. Service access address(es) (e.g. IP address)
. Service access control list
. Service administrative state (lock, unlock, defect)
. Network technology-specific data
3. The NMS MUST notify the operator and OSS and prevents the
subscriber service from being built if the configuration
violates the network resource entity relationship or cause
invalid state transition.
4. The NMS then attempts to setup the subscriber service with
the configuration parameter specified by the operator and OSS,
allocate resources (access address(es) and port(s)) in the NEs
as necessary.
5. Any configuration by operator and OSS MUST be logged. The
log MUST be retrieval in both interactive and bulk method.
6. The NMS MUST store the provider service data in its database
for later reference.
7. The NMS GUI and protocol interface to the OSS MUST be
automatically updated with new configuration data.
Post Conditions: The provider service is provisioned.
5.2. Subscriber Service Remove (Network-based)
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
4. The provider services are under the NMS management.
Descriptions:
1. The operator and OSS MUST be able to select the subscriber
service based on name, or user label, or access address.
2. The NMS then attempt to remove the selected subscriber
service from network, release the associated resources (access
address (es) and port(s)) in the NEs as necessary.
3. Removal MUST be logged. The log MUST be retrieval in both
interactive and bulk method.
4. The NMS GUI and protocol interface to the OSS MUST be
automatically updated with the subscriber service removed.
Post Conditions: The subscriber service is removed.
5.3. Subscriber Service Retrieval (Network-based)
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
Chen and Allen Expire April 2003 [Page 29]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
3. The routing and signaling contexts are under the NMS
management.
4. The provider services are under the NMS management.
Descriptions:
1. The operator and OSS MUST be able to retrieve the following
data for the subscriber service:
. Service name
. Service user label
. Service access address(es) (e.g. IP address)
. Service access control list
. Service administrative state (lock, unlock, defect)
. Service operational state (enabled, disabled)
. Network technology-specific data
2. The operator and OSS MUST be able to retrieve the following
data from the subscriber service:
. Any access NE, plug-in, port supporting this subscriber
service
. Any routing and signaling context supporting this
subscriber service
. Any provider service supporting this subscriber service
3. The operator and OSS MUST be able to retrieve any subscriber
service data in the both interactive and bulk method.
Post Conditions: The operator and OSS retrieve the data as they
desire.
5.4. Subscriber Service Provision (Connection-based)
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
4. The provider services are under the NMS management.
Descriptions:
1. The operator and OSS MUST be able to provision and configure
the access port(s) that support the subscriber service. See
User Case 3.6 for more details.
2. The operator and OSS MUST be able to provision and configure
the point-to-point, or point-to-multipoint, or multipoint-to-
point, or multipoint-to-multipoint service connection(s) that
support the subscriber service with the following data:
. Supporting port(s)
. Supporting provider service(s)
. Connection name (e.g. time slot, DLCI VPI/VCI, LSP label)
. Connection user label (e.g. CLCI code, VPI/VCI, LSP label)
. Connection endpoints (A and Z point(s)). The endpoints are
the ports of endpoint NEs where the connection(s) are
terminated.
. Connection characteristics (e.g. DS3, OC3, LSP)
. Connection directionality (A to Z, Z to A, bi-directional)
Chen and Allen Expire April 2003 [Page 30]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
. Connection administrative state (lock, unlock, defect)
. Connection maximum bandwidth
. Network technology-specific data
3. The operator and OSS MUST be able to provision and configure
the subscriber service with the following data
. Supporting connection(s)
. Service name
. Service user label
. Service administrative state (lock, unlock, defect)
. Network technology-specific data
4. The NMS MUST notify the operator and OSS and prevents the
subscriber service from being built if the configuration
violates the network resource entity relationship or cause
invalid state transition.
5. The NMS then attempts to setup the subscriber service with
the configuration parameter specified by the operator and OSS,
allocate resources (connection(s), port(s)) in the NEs as
necessary.
6. Any configuration by operator and OSS MUST be logged. The
log MUST be retrieval in both interactive and bulk method.
7. The NMS MUST store the subscriber service data in its
database for later reference.
8. The NMS GUI and protocol interface to the OSS MUST be
automatically updated with new configuration data.
Post Conditions: The subscriber service is provisioned.
5.5. Subscriber Service Remove (Connection-based)
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
4. The provider services are under the NMS management.
Descriptions:
1. The operator and OSS MUST be able to select the subscriber
service based on name, or user label.
2. The NMS then attempt to remove the selected subscriber
service from network, release the associated resources
(connection(s) and port(s)) in the NEs as necessary.
3. Removal MUST be logged. The log MUST be retrieval in both
interactive and bulk method.
4. The NMS GUI and protocol interface to the OSS MUST be
automatically updated with the subscriber service removed.
Post Conditions: The subscriber service is removed.
5.6. Subscriber Service Retrieval (Connection-based)
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under the NMS management.
Chen and Allen Expire April 2003 [Page 31]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
4. The provider services are under the NMS management.
Descriptions:
1. The operator and OSS MUST be able to retrieve the following
data for the subscriber service:
. Service name
. Service user label
. Service access address(es) (e.g. IP address)
. Service access control list
. Service administrative state (lock, unlock, defect)
. Service operational state (enabled, disabled)
. Network technology-specific data
2. The operator and OSS MUST be able to retrieve the following
data from the subscriber service:
. Any access NE, plug-in, port supporting this provider
service
. Any trunk link and connection supporting this provider
service
. Any connection supporting this provider service
. Any routing and signaling context supporting this provider
service
. Any aggregated network-based subscriber service group
supported by this provider service
. Any individual connection-based subscriber service
supported by this provider service
3. The operator and OSS MUST be able to retrieve any subscriber
service data in the both interactive and bulk method.
Post Conditions: The operator and OSS retrieve the data as they
desire.
5.7. Subscriber Service Alarm
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
4. The provider services are under the NMS management.
5. The subscriber service experiences a notable event, i.e. an
alarm.
Descriptions:
1. The NMS MUST be able to receive an alarm regarding
subscriber service from the NE reliably.
2. The operator and OSS MUST be able to define a default alarm
severity assignment profile to be used by the NE and NMS to
assign alarm severity (Critical, Major, Minor, Warning) to
alarm conditions.
Chen and Allen Expire April 2003 [Page 32]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
3. The operator and OSS MUST be able to define an alarm
severity assignment for a specific network resource entity
(subscriber service).
4. The operator and OSS MUST be able to set a length of time
for a specific network resource entity (subscriber service)
during which alarms on that entity will be suppressed.
5. The operator and OSS MUST be able to set "soak" period for
the various alarm conditions. A soak period defines how long
an alarm condition must persist before an alarm is declared.
6. New alarms MUST be added to the active alarm log. Duplicate
alarms SHOULD not be added to the alarm log. Instead, a count
of duplicates MUST be kept for each alarm, along with a record
of when the first and last occurrences were received.
7. If the communication channel between an NE and the NMS is
down, the NMS MUST re-synchronizes to the alarm state of the NE
after the communication channel is up again. The NMS MUST logs
and reports outstanding alarm and cleared alarms missed during
out of synchronization.
8. Alarms from the same NE MUST be correlated to identify any
cause and effect relationships between them. Therefore alarms
are organized into tree structures, where child alarms
represent conditions that are actually a result of the parent
alarm. Alarms at the roots of these trees are the actual alarm
conditions. Repairing the root-cause alarm will fixing its
descendent alarms.
9. The received alarm MUST contain the following data:
. Alarm unique ID
. Alarm severity
. Alarm type
. Alarm description
. Alarm date and time
. Alarm source entity (smallest possible unit)
. Alarm ID of the root cause alarm to which this alarm may
have been correlated
. Network technology-specific data
10. The network resource entity (subscriber service) may clear a
previous sent alarm. See user case 3.5 for more details.
11. The NMS GUI and the protocol interface to OSS MUST be
automatically updated with the new alarm data.
Post Conditions: The active alarm log and history alarm log are
updated accordingly.
5.8. Subscriber Service Test
Actor: Operator, NE
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
4. The provider services are under the NMS management.
Chen and Allen Expire April 2003 [Page 33]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
Descriptions:
1. The operator and MUST be able to invoke any network resource
entity (subscriber service) test capability from the NMS GUI.
2. The operator SHOULD be able to invoke multiple concurrent
tests on the same and different network resource entity
(subscriber service).
3. The operator SHOULD be able to schedule the test at a future
time.
4. The operator SHOULD be able to set source and sink points,
number of iterations, iteration interval, of continuity
(loopback) test, if network technology supports it.
5. The test result SHOULD be displayed and retrievable through
the NMS GUI.
Post Conditions: The test result is available for diagnosing.
5.9. Subscriber Service Performance and Usage
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under the NMS management.
2. The trunk links or connections are under the NMS management.
3. The routing and signaling contexts are under the NMS
management.
4. The provider services are under the NMS management.
Descriptions:
1. The operator and OSS MUST be able to specify the following
performance and usage data collection parameters:
. Collection interval, typically 15 minutes
. Number of intervals to be collected into a single data
file, typically 96 intervals
. Lifetime of the data files in NE
. Network resource entities or types of entities (subscriber
service) from which data is to be collected
. Network technology-specific performance and usage data to
be collected
2. The operator and OSS MUST be able to set the threshold values
for the monitored data attributes. When the data attribute
crosses this threshold, a threshold crossing alarm MUST be
generated. See User Case 3.9 for details on alarm processing.
The monitored data attributes for threshold crossing are the
following:
. Subscriber service QoS data
. Network technology-specific data
3. The operator and OSS MUST be able to browse, delete, and
transfer the performance and usage data files based on file
names and locations (e.g. URL).
4. Any data files whose lifetimes expire before they are
deleted by an operator SHOULD be automatically deleted by the
NE or the MS.
Post Conditions: Performance and usage data are collected and
stored in data files.
Chen and Allen Expire April 2003 [Page 34]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
6. User Cases of Security Operation
6.1. Management Communication Channel Security
Actor: Operator, NE, OSS
Pre-Conditions:
1. The NEs are under the NMS management.
Descriptions:
1. The management communication channel between the NMS and the
NE, the NMS and the OSS SHOULD be securable. The operator MUST
be able to enable or disable the security feature of the
communication channel.
2. The security feature of communication channel when enabled
SHOULD not adversely affect the NMS, NE, and OSS.
3. Both in-band (management traffic shared with user traffic)
and out-band (management traffic only) physical channel SHOULD
be provided for the management communication channel between
the NMS and the NE. The operator MUST be able to choose in-
band or out-band channel based on individual NE selection.
Post Conditions: Not applicable
6.2. Operator and OSS Login
Actor: Operator, OSS
Pre-Conditions:
1. The NEs are under the NMS management.
Descriptions:
1. Each operator and OSS MUST have unique login id and security
key (e.g. password) to authenticate himself to the NMS.
2. The NMS MUST allow the definition of NMS privileged
operators who are separate from the NMS system administrators,
with separate access capabilities. For example, the NMS
privileged operator is able to administer the NMS application
without need to access the system root.
3. The privileged operator MUST be able to create, browse,
update, or delete other operator and OSS login.
4. The security violation MUST be logged. Any security breach
SHOULD be traceable.
Post Conditions: Not applicable
6.3. Operator and OSS Group Administration
Actor: Operator, OSS
Pre-Conditions:
1. The NEs are under the NMS management.
Descriptions:
1. The privileged operator MUST be able to create, browse,
update, and delete access control profile for operator and OSS
group. When individual operator and OSS login are created,
they can belong to zero or more groups, giving the operator and
Chen and Allen Expire April 2003 [Page 35]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
OSS the same privileges as the sum of the groups to which he
belongs.
2. The access control profile MUST include restrictions based
on the following network resource entities:
. NE, plug-in, port
. Trunk link or connection
. Routing and signaling context
. Provider service
. Subscriber service
3. The access control profile MUST include restrictions based
the following operational activities:
. Network configuration (e.g. User Cases in Section 3)
. Provider service provision (e.g. User Cases in Section 4)
. Subscriber service provision (e.g. User Cases in Section
5)
. Alarm and test (e.g. User Cases 3.9, 3.10, 3.15, 3.16,
3.21, 3.22, 4.7, 4.8, 5.7, 5.8)
. Performance and usage (e.g. User Cases 3.11, 3.17, 3.23,
4.9, 5.9)
. Information retrieval (e.g. User Cases 3.8, 3.14, 3.20,
4.3, 5.3, 5.6, 4.6)
. Privileged capabilities (e.g. User Cases 6.1, 6.2, 6.3)
Post Conditions: Not applicable
7. Security Considerations
The security considerations of this document are detailed in Section
6.
8. References
[RFC2026] "The Internet Standards Process -- Revision 3", S.
Bradner, October, 1996.
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner, March, 1997.
Chen and Allen Expire April 2003 [Page 36]
Internet Draft draft-weijing-lap-ops-00.txt Oct. 2002
9. Authors' Addresses
Keith Allen
SBC Technology Resources, Inc.
9505 Arboretum Blvd.
Austin, Texas 78759
Phone: +1 512 372 5741
Email: kallen@tri.sbc.com
Weijing Chen
SBC Technology Resources, Inc.
9505 Arboretum Blvd.
Austin, Texas 78759
Phone: +1 512 372 5710
Email: wchen@tri.sbc.com
Chen and Allen Expire April 2003 [Page 37]
