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]