Internet Draft Weijing Chen Expiration Date: June 2003 Keith Allen Category: Informational SBC Communications, Inc. December 2002 Use Cases of Network Operation of Large Access Providers draft-weijing-lap-ops-use-01.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 use cases of Large Access Providers (LAP). Since a LAP has hundreds of locations, thousands of nodes, millions of subscribers, where the law of large number affects the bottom line of network operation, a LAP has been always strives to streamline network operation functions. The use 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 the baseline for other network operation streamlining requirements. Table of Contents 1. Introduction.................................................3 2. Terminology..................................................4 3. Use Cases of General Operation...............................5 3.1. Browsing and Clearing of Alarm..............................5 3.2. Alarm of Network Resource Entity............................6 Chen and Allen Expire June 2003 [Page 1] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 3.3. Test of Network Resource Entity.............................7 3.4. Performance and Usage of Network Resource Entity............8 4. Use Cases of Network Infrastructure Operation................8 4.1. NE Installation.............................................8 4.2. NE Software Download........................................9 4.3. NE Synchronization..........................................9 4.4. NE Continuous Synchronization..............................10 4.5. NE, Plug-In, and Port Configuration........................11 4.6. NE and Plug-In Removal.....................................12 4.7. NE, Plug-In, and Port Retrieval............................12 4.8. NE, Plug-In, and Port Alarm................................14 4.9. NE, Plug-In, and Port Test.................................14 4.10. NE, Plug-In, and Port Performance and Usage................14 4.11. Link Configuration.........................................14 4.12. Link Removal...............................................15 4.13. Link Retrieval.............................................16 4.14. Link Alarm.................................................16 4.15. Link Test..................................................17 4.16. Link Performance and Usage.................................17 4.17. Routing and Signaling Configuration........................17 4.18. Routing and Signaling Removal..............................18 4.19. Routing and Signaling Retrieval............................18 4.20. Routing and Signaling Alarm................................19 4.21. Routing and Signaling Test.................................19 4.22. Routing and Signaling Performance and Usage................19 5. Use Cases of Peer Provider Service Operation................20 5.1. Provider Service Provision (Network-based).................20 5.2. Provider Service Removal (Network-based)...................20 5.3. Provider Service Retrieval (Network-based).................21 5.4. Provider Service Provision (Connection-based)..............21 5.5. Provider Service Removal (Connection-based)................22 5.6. Provider Service Retrieval (Connection-based)..............23 5.7. Provider Service Alarm.....................................23 5.8. Provider Service Test......................................23 5.9. Provider Service Performance and Usage.....................24 6. Use Cases of Subscriber Service Operation...................24 6.1. Subscriber Service Provision (Network-based)...............24 6.2. Subscriber Service Removal (Network-based).................25 6.3. Subscriber Service Retrieval (Network-based)...............25 6.4. Subscriber Service Provision (Connection-based)............25 6.5. Subscriber Service Removal (Connection-based)..............26 6.6. Subscriber Service Retrieval (Connection-based)............27 6.7. Subscriber Service Alarm...................................27 6.8. Subscriber Service Test....................................28 6.9. Subscriber Service Performance and Usage...................28 7. Use Cases of Security Operation.............................28 7.1. Management Communication Channel Security..................28 7.2. Operator and OSS Login.....................................28 7.3. Operator and OSS Group Administration......................29 8. Security Considerations.....................................29 Chen and Allen Expire June 2003 [Page 2] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 9. References..................................................30 10. Authors' Addresses..........................................30 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 use cases of Large Access Providers (LAP). Since a LAP has hundreds of locations, thousands of nodes, millions of subscribers, where and the law of large number affects the bottom line of network operation, a LAP has been always strives to streamline network operation functions. The use 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 the baseline for other network operation streamlining requirements. A LAP typically has one or a 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 use cases described here are centered 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. Chen and Allen Expire June 2003 [Page 3] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 2. Terminology 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 of geographically dispersed access service locations, thousands of access service nodes, and millions of access service subscribers. 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 operation, inventory management, and work force management. 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 a router, or a switch Plug-In A physical hardware unit that must be plugged into NE to function Port A physical or logical connector on an NE or plug-in Link A facility between two ports that is capable of transmitting information, can be physical or logical Physical Link A link between two physical ports that is created with a physical medium, such as an optical fiber or coaxial cable Logical Link Chen and Allen Expire June 2003 [Page 4] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 A link between two logical ports that relies upon an underlying connection Connection A logical channel that spans over one or multiple physical links, for example an ATM VC, Frame Relay VC, MPLS LSP, or Ethernet VLAN Peer Provider A service provider who is providing additional connecting, or enhanced, or advanced network service on top of access service provided by a LAP Subscriber A customer who subscribes to the access service from a LAP Administrative State When the administrative state of a network resource entity is "unlocked" by the operator, the entity is allowed to perform its normal functions. When the administrative state of a network resource entity is "locked" by the operator, the entity is not allowed to perform its normal functions. When the administrative state of a network resource entity is set to "defective" by the operator, the entity is out of service. Operational State When the operational state of a network resource entity is in the enabled state, the entity is operational. When the operational state of a network resource entity is in the disabled state, the entity is incapable of performing its normal function. 3. Use Cases of General Operation 3.1. Browsing and Clearing of Alarm Actor: Operator, NE Pre-Conditions: 1. The NE is under EMS management. Descriptions: 1. The operator MUST be able to browse any active alarms and cleared alarms (history alarm) in interactive and bulk methods. 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 methods 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 methods 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 June 2003 [Page 5] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 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, and the 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, the 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.2. Alarm of Network Resource Entity Actor: Operator, NE, OSS Pre-Conditions: 1. The NE is under the NMS management. 2. The network resource entity (e.g. NE, plug-in, port, link, routing and signaling instance, connection, or service) experience a notable event, i.e. an alarm. Descriptions: 1. The NMS MUST be able to receive an alarm regarding a network resource entity (e.g. NE, plug-in, port, link, routing and signaling instance, connection, or service) 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 the NMS, and 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 (e.g. NE, plug-in, port, link, routing and signaling instance, connection, or service). 4. The operator MUST be able to set a length of time for a specific network resource entity (e.g. NE, plug-in, port, link, routing and signaling instance, connection, or service) during which alarms on that entity will be suppressed. 5. The operator MUST be able to set a "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 Chen and Allen Expire June 2003 [Page 6] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 after the communication channel is up again. The NMS MUST logs and reports outstanding alarms and cleared alarms missed during an out of synchronization period. 8. Alarms from the same NE MUST be correlated to identify any cause and effect relationships between them. Therefore alarms are organized into a tree structure, 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 (e.g. NE, plug-in, port, link, routing and signaling instance, connection, or service) SHOULD send the alarms on the following cases: . Reset of network resource entity . Administrative state change of network resource entity . Operational state change of network resource entity . Network technology-specific cases 11. The network resource entity (e.g. NE, plug-in, port, link, routing and signaling instance, connection, or service) may clear a previously sent alarm. See Use Case 3.1 for more details. 12. The NMS GUI and the protocol interface to the OSS MUST be automatically updated with the new alarm data. Post Conditions: The active alarm log and the history alarm log are updated accordingly. 3.3. Test of Network Resource Entity 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 the source and sink points, the number of iterations, and the iteration interval, Chen and Allen Expire June 2003 [Page 7] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 of continuity (loopback) test, if the 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.4. Performance and Usage of Network Resource Entity 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 (e.g. NE, plug-in, port, link, routing and signaling instance, connection, or service) 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. See Use Case 3.2 for details on alarm processing. The monitored data attributes for threshold crossing are the following: . 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. Use Cases of Network Infrastructure Operation 4.1. NE Installation Actor: Operator, NE Pre-Conditions: 1. A new NE has been installed. 2. The NE is connected to CODCN 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: Chen and Allen Expire June 2003 [Page 8] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 1. The operator navigates to a GUI screen for adding new NEs to the NMS. 2. The operator enters the IP address assigned to the new NE, and any necessary security key (e.g. user name, password). 3. The operator assigns to the new NE a unique name (which could be a CLLI code). 4. The NMS then MUST automatically synchronize itself with the current configuration of the NE. See Use Case 4.3. Post Conditions: The NMS is in sync with the NE and the NMS is now managing the NE. 4.2. NE Software Download Actor: Operator, NE Pre-Conditions: 1. The NE is under the NMS management. 2. The operator has loaded new NE software from a distribution medium onto the NMS. 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 operator SHOULD be able to identify a set of NEs to target for the software download. 5. The NMS MUST verify that the software to be downloaded to the NE, or the plug-in, is compatible with the current hardware version of the NE or the plug-in. 6. The NE and NMS MUST verify the download and notify the operator of the success or failure of the download. 7. The operator SHOULD be able to activate the new software once the success of downloading has been verified. The software SHOULD be automatically activated if the operator chooses so. 8. The NE and the NMS MUST notify the operator of the success or failure of activating the new software. 9. 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. 10. The download MUST be logged. Post Conditions: The NE is running the new software or is reverted to previous version. 4.3. NE Synchronization Actor: NE Pre-Conditions: 1. The NMS has just established or re-established connectivity with the NE(s). Chen and Allen Expire June 2003 [Page 9] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 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 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 the NE's configuration. 4.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 of changes to its hardware, software, links and connections, routing and signaling, and any other physical or logical resource entity stewarded by the NE, especially changes due to technician interaction with the NE through the "craft interface" or "command line interface". 2. The NE MUST support automatically notifications of installations, removals, or changes, of plug-in units. 3. The NMS MUST automatically maintains data synchronization between itself and the NE. The operator SHOULD NOT have to be Chen and Allen Expire June 2003 [Page 10] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 aware of 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. 4.5. 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. Descriptions: 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 Use Case 4.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 (locked, unlocked, defective) . External time (wall-clock time) . Network technology-specific 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 (locked, unlocked, defective) . Network technology-specific data 4. If the 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 of defect repair case in which a defective plug-in is removed and a new one is installed. Chen and Allen Expire June 2003 [Page 11] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 5. The operator MUST be able to configure the port with the following data: . Port name . Port user label . Port administrative state (locked, unlocked, defective) . Network technology-specific data 6. Any configuration by the operator that violates any network resource entity relationship or causes an invalid state transition MUST not be allowed. 7. Any configuration by the operator MUST be logged. The log MUST be retrievable using both interactive and bulk methods. 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. 4.6. NE and Plug-In Removal 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 Use Case 4.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 Use Case 4.8 for more details. 3. The NMS MUST automatically stores the configuration of the removed hardware so that if a new hardware of the same type is installed it can be automatically configured the same way as the old. 4. If hardware removal is permanent, operator MUST be able to remove the stored configuration from the NMS permanently. 5. The removal MUST be logged. The log MUST be retrievable using both interactive and bulk methods. 6. The NMS GUI MUST be automatically updated with the hardware removed. Post Conditions: The NMS is in sync with the new state of the network and the NE. 4.7. 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 June 2003 [Page 12] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 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 (locked, unlocked, defective) . 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 links supported by this NE . Any routing and signaling instances maintained by this NE . Any aggregated groups of network-based provider or subscriber services supported by this NE . Any individual connection-based provider or subscriber services 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 (locked, unlocked, defective) . 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 links supported by this plug-in . Any routing and signaling instances maintained by this plug-in . Any aggregated groups of network-based provider or subscriber services supported by this plug-in . Any individual connection-based provider or subscriber services 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 (locked, unlocked, defective) . Port operational state (enabled, disabled) . Network technology-specific data 6. The operator MUST be able to retrieve the following data from the port: . Any links supported by this port . Any routing and signaling instances maintained by this port Chen and Allen Expire June 2003 [Page 13] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 . Any aggregated groups of network-based provider or subscriber services supported by this port . Any individual connection-based provider or subscriber services supported by this port 7. The operator MUST be able to retrieve any data maintained by NE, plug-in, or port using both interactive and bulk methods. Post Conditions: The operator and OSS retrieve the data as they desire. 4.8. NE, Plug-In, and Port Alarm Actor: Operator, NE, OSS Pre-Conditions: 1. The NE is under the NMS management. 2. The NE, plug-in, or port experience a notable event, i.e. an alarm. Descriptions: 1. See Use Case 3.2 for details. Post Conditions: The active alarm log and the history alarm log are updated accordingly. 4.9. NE, Plug-In, and Port Test Actor: Operator, NE Pre-Conditions: 1. The NE is under the NMS management. Descriptions: 1. See Use Case 3.3 for details. Post Conditions: The test result is available for diagnosing. 4.10. NE, Plug-In, and Port Performance and Usage Actor: Operator, NE Pre-Conditions: 1. The NE is under the NMS management. Descriptions: 1. See Use Case 3.4 for details. Post Conditions: Performance and usage data are collected and stored in data files. 4.11. Link Configuration Actor: Operator, NE Pre-Conditions: 1. The NEs are under NMS management. 2. The physical links have been installed between NEs managed by the NMS. Descriptions: 1. The link discussed here is a point-to-point network trunk link, not a provider or subscriber service connection. 2. The operator MUST be able to provision and configure the port(s) that support the link. See Use Case 4.5 for more details. Chen and Allen Expire June 2003 [Page 14] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 3. The operator MUST be able to configure the link with the following data: . Supporting port(s) . Link name (e.g. time slot, DLCI VPI/VCI, LSP label) . Link user label (e.g. CLCI code, VPI/VCI, LSP label) . Link endpoints (upstream and downstream point). The endpoints are the ports of endpoint NEs where the link is terminated. . Link characteristics (e.g. DS3, OC3, LSP) . Link directionality (upstream to downstream, downstream to upstream, bi-directional) . Link administrative state (locked, unlocked, defective) . Link maximum bandwidth . Link routing weight if applicable . Network technology-specific data 4. The NMS MUST notify the operator and prevents the link from being built if the two endpoint ports are not compatible. 5. The operator SHOULD be able to optionally constrain the routing of a logical link by identifying the underlying links over which the logical link must be routed. 6. The NMS then attempts to setup the link with the configuration parameter specified by the operator, and to allocate resources in the NEs as necessary. 7. Any configuration by the operator MUST be logged. The log MUST be retrievable using both interactive and bulk methods. 8. The NMS MUST store the link data in its database for later reference. 9. The NMS GUI MUST be automatically updated with new configuration data. Post Conditions: The link is established and available for provider or subscriber services. 4.12. Link Removal Actor: Operator, NE Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. The link discussed here is a point-to-point network trunk link, not a provider or subscriber service connection. 2. The operator MUST be able to select the link based on name, or user label, or either one of endpoints. 3. The NMS MUST notify the operator and prevents the selected link from being removed if the link is supporting active provider or subscriber service. 4. The NMS then attempt to remove the selected link from network, and to release the associated resources in the NEs as appropriate. 5. The removal MUST be logged. The log MUST be retrievable by both interactive and bulk methods. Chen and Allen Expire June 2003 [Page 15] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 6. The NMS MUST update the link data in its database for later reference. 7. The NMS GUI MUST be automatically updated with the link removed. Post Conditions: The link is removed. 4.13. Link Retrieval Actor: Operator, NE Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. The link discussed here is a point-to-point network trunk link, not a provider or subscriber service connection 2. The operator MUST be able to retrieve the following data for the link: . Link name (e.g. time slot, DLCI, VPI/VCI, LSP label) . Link user label (e.g. CLCI code, VPI/VCI, LSP label) . Link endpoints (upstream and downstream point). The endpoints are the ports of endpoint NEs where the link is terminated. . Link characteristics (e.g. DS3, OC3, LSP) . Link directionality (upstream to downstream, downstream to upstream, bi-directional) . Link administrative state (locked, unlocked, defective) . Link operational state (enabled, disabled) . Link maximum bandwidth . Link used bandwidth if applicable . Link available bandwidth if applicable . Link routing weight if applicable . Network technology-specific data 3. The operator MUST be able to retrieve the following data from the link: . Any NEs, plug-ins, or ports supporting this link . Any routing and signaling instances supporting this link . Any routing and signaling instances supported by this link . Any aggregated groups of network-based provider or subscriber services supported by this link . Any individual connection-based provider or subscriber services supported by this link 4. The operator MUST be able to retrieve any trunk link or connection data using both interactive and bulk methods. Post Conditions: The operator and OSS retrieve the data as they desire. 4.14. Link Alarm Actor: Operator, NE Pre-Conditions: 1. The NEs are under the NMS management. 2. The links experience a notable event, i.e. an alarm. Descriptions: Chen and Allen Expire June 2003 [Page 16] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 1. The link discussed here is a point-to-point network trunk link, not a provider or subscriber service connection. 2. See Use Case 3.2 for details. Post Conditions: The active alarm log and history alarm log are updated accordingly. 4.15. Link Test Actor: Operator, NE Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. The link discussed here is a point-to-point network trunk link, not a provider or subscriber service connection. 2. See Use Case 3.3 for details. Post Conditions: The test result is available for diagnosing. 4.16. Link Performance and Usage Actor: Operator, NE Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. The link discussed here is a point-to-point network trunk link, not a provider or subscriber service connection. 2. See Use Case 3.4 for details. Post Conditions: Performance and usage data are collected and stored in data files. 4.17. Routing and Signaling Configuration Actor: Operator, NE Pre-Conditions: 1. The NEs are under NMS management. Descriptions: 1. The operator MUST be able to provision and configure the NE(s), plug-in(s), and port(s) that support the routing and signaling instance. See Use Case 4.5 for more details. 2. The operator MUST be able to configure the routing and signaling instance with the following data: . Supporting NE(s), plug-in(s), port(s) . Routing and signaling instance name (e.g. Autonomous System number) . Routing and signaling instance 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 instance administrative state (locked, unlocked, defective) . Network technology-specific data 3. The NMS MUST notify the operator and prevents the routing and signaling instance from being configured if the Chen and Allen Expire June 2003 [Page 17] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 configuration violates any network resource entity relationship or causes an invalid state transition. 4. The NMS then attempts to configure the routing and signaling instance with the configuration parameter specified by the operator, and to allocate resources in the NEs as necessary. 5. Any configuration by the operator MUST be logged. The log MUST be retrievable using both interactive and bulk methods. 6. The NMS GUI MUST be automatically updated with new configuration data. Post Conditions: The routing and signaling instance is configured and can support provider or subscriber services. 4.18. Routing and Signaling Removal Actor: Operator, NE Pre-Conditions: 1. The NEs are under NMS management. Descriptions: 1. The operator MUST be able to select the routing and signaling instance based on name, or user label. 2. The NMS MUST notify the operator and prevents the selected routing and signaling instance from being removed if the routing and signaling instance is supporting active provider or subscriber services. 3. The NMS then attempt to remove the selected routing and signaling instance from network, and to release the associated resources in the NEs as appropriate. 4. The removal MUST be logged. The log MUST be retrievable using both interactive and bulk methods. 5. The NMS GUI MUST be automatically updated with the routing and signaling instance removed. Post Conditions: The routing and signaling instance is removed. 4.19. Routing and Signaling Retrieval Actor: Operator, NE Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. The operator MUST be able to retrieve the following data for the routing and signaling instance: . Routing and signaling instance name (e.g. Autonomous System number) . Routing and signaling instance 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 instance administrative state (locked, unlocked, defective) Chen and Allen Expire June 2003 [Page 18] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 . Routing and signaling instance operational state (enabled, disabled) . Network technology-specific data 2. The operation MUST be able to retrieve the following data from the routing and signaling instance: . Any NEs, plug-ins, or ports supporting this routing and signaling instance . Any links supporting this routing and signaling instance . Any logical links supported by this routing and signaling instance . Any aggregated groups of network-based provider or subscriber services supported by this routing and signaling instance . Any individual connection-based provider or subscriber services supported by this routing and signaling instance 3. The operator MUST be able to retrieve any routing and signaling data using both interactive and bulk methods. Post Conditions: The operator retrieve the data as they desire. 4.20. Routing and Signaling Alarm Actor: Operator, NE Pre-Conditions: 1. The NEs are under the NMS management. 2. The links are under the NMS management. 3. The routing and signaling instance experience a notable event, i.e. an alarm. Descriptions: 1. See Use Case 3.2 for details. Post Conditions: The active alarm log and history alarm log are updated accordingly. 4.21. Routing and Signaling Test Actor: Operator, NE Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. See Use Case 3.3 for details. Post Conditions: The test result is available for diagnosing. 4.22. Routing and Signaling Performance and Usage Actor: Operator, NE Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. See Use Case 3.4 for details. Post Conditions: Performance and usage data are collected and stored in data files. Chen and Allen Expire June 2003 [Page 19] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 5. Use Cases of Peer Provider Service Operation 5.1. Provider Service Provision (Network-based) Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under NMS management. Descriptions: 1. The operator and the OSS MUST be able to provision and configure the access port(s) that support the provider service. See Use Case 4.5 for more details. 2. The operator and the 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 (locked, unlocked, defective) . Network technology-specific data 3. The NMS MUST notify the operator and the OSS, and prevents the provider service from being built if the configuration violates any network resource entity relationship or causes an invalid state transition. 4. The NMS then attempts to setup the provider service with the configuration parameter specified by the operator and the OSS, and to allocate resources (access address(es) and port(s)) in the NEs as necessary. 5. Any configuration by the operator and the OSS MUST be logged. The log MUST be retrievable using both interactive and bulk methods. 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. Provider Service Removal (Network-based) Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under NMS management. Descriptions: 1. The operator and the 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 the 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, and to release the associated resources (access address (es) and port(s)) in the NEs as appropriate. Chen and Allen Expire June 2003 [Page 20] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 4. The removal MUST be logged. The log MUST be retrievable using both interactive and bulk methods. 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. 5.3. Provider Service Retrieval (Network-based) Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. The operator and the 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 (locked, unlocked, defective) . Service operational state (enabled, disabled) . Network technology-specific data 2. The operator and the OSS MUST be able to retrieve the following data from the provider service: . Any access NEs, plug-ins, or ports supporting this provider service . Any routing and signaling instances supporting this provider service . Any aggregated groups of network-based subscriber services supported by this provider service . Any individual connection-based subscriber services supported by this provider service 3. The operator and the OSS MUST be able to retrieve any provider service data using both interactive and bulk methods. Post Conditions: The operator and OSS retrieve the data as they desire. 5.4. Provider Service Provision (Connection-based) Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under NMS management. Descriptions: 1. The operator and the OSS MUST be able to provision and configure the access port(s) that support the provider service. See Use Case 4.5 for more details. 2. The operator and the 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) Chen and Allen Expire June 2003 [Page 21] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 . Connection user label (e.g. CLCI code, VPI/VCI, LSP label) . Connection endpoints (upstream and downstream 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 (upstream to downstream, downstream to upstream, bi-directional) . Connection administrative state (locked, unlocked, defective) . Connection maximum bandwidth . Network technology-specific data 3. The operator and the 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 (locked, unlocked, defective) . Network technology-specific data 4. The NMS MUST notify the operator and the OSS, and prevents the provider service from being built if the configuration violates any network resource entity relationship or causes an invalid state transition. 5. The NMS then attempts to setup the provider service with the configuration parameter specified by the operator and the OSS, and to allocate resources (connection(s), port(s)) in the NEs as necessary. 6. Any configuration by the operator and the OSS MUST be logged. The log MUST be retrievable using both interactive and bulk methods. 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. 5.5. Provider Service Removal (Connection-based) Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under NMS management. Descriptions: 1. The operator and the OSS MUST be able to select the provider service based on name, or user label. 2. The NMS MUST notify the operator and the 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, and to release the associated resources (connection(s) and port(s)) in the NEs as appropriate. 4. The removal MUST be logged. The log MUST be retrievable by both interactive and bulk methods. Chen and Allen Expire June 2003 [Page 22] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 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. 5.6. Provider Service Retrieval (Connection-based) Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. The operator and the 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 (locked, unlocked, defective) . Service operational state (enabled, disabled) . Network technology-specific data 2. The operator and the OSS MUST be able to retrieve the following data from the provider service: . Any access NEs, plug-ins, or ports supporting this provider service . Any links supporting this provider service . Any connections supporting this provider service . Any routing and signaling instances supporting this provider service . Any aggregated groups of network-based subscriber services supported by this provider service . Any individual connection-based subscriber services supported by this provider service 3. The operator and the OSS MUST be able to retrieve any provider service data using both interactive and bulk methods. Post Conditions: The operator and OSS retrieve the data as they desire. 5.7. Provider Service Alarm Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under the NMS management. 2. The provider service experiences a notable event, i.e. an alarm. Descriptions: 1. See Use Case 3.2 for details. Post Conditions: The active alarm log and history alarm log are updated accordingly. 5.8. Provider Service Test Actor: Operator, NE Pre-Conditions: 1. The NEs are under the NMS management. Chen and Allen Expire June 2003 [Page 23] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 Descriptions: 1. See Use Case 3.3 for details. Post Conditions: The test result is available for diagnosing. 5.9. Provider Service Performance and Usage Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. See Use Case 3.4 for details. Post Conditions: Performance and usage data are collected and stored in data files. 6. Use Cases of Subscriber Service Operation 6.1. Subscriber Service Provision (Network-based) Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under NMS management. Descriptions: 1. The operator and the OSS MUST be able to provision and configure the access port(s) that support the subscriber service. See Use Case 4.5 for more details. 2. The operator and the OSS MUST be able to provision and configure the subscriber service with the following data: . 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 (locked, unlocked, defective) . Network technology-specific data 3. The NMS MUST notify the operator and the OSS, and prevents the subscriber service from being built if the configuration violates any network resource entity relationship or causes an invalid state transition. 4. The NMS then attempts to setup the subscriber service with the configuration parameter specified by the operator and the OSS, and to allocate resources (access address(es) and port(s)) in the NEs as necessary. 5. Any configuration by the operator and the OSS MUST be logged. The log MUST be retrievable using both interactive and bulk methods. 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. Chen and Allen Expire June 2003 [Page 24] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 6.2. Subscriber Service Removal (Network-based) Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under NMS management. Descriptions: 1. The operator and the 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, and to release the associated resources (access address (es) and port(s)) in the NEs as appropriate. 3. The removal MUST be logged. The log MUST be retrievable by both interactive and bulk methods. 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. 6.3. Subscriber Service Retrieval (Network-based) Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. The operator and the 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 (locked, unlocked, defective) . Service operational state (enabled, disabled) . Network technology-specific data 2. The operator and the OSS MUST be able to retrieve the following data from the subscriber service: . Any access NEs, plug-ins, or ports supporting this subscriber service . Any routing and signaling instances supporting this subscriber service . Any provider services supporting this subscriber service 3. The operator and the OSS MUST be able to retrieve any subscriber service data using both interactive and bulk methods. Post Conditions: The operator and the OSS retrieve the data as they desire. 6.4. Subscriber Service Provision (Connection-based) Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under NMS management. Descriptions: Chen and Allen Expire June 2003 [Page 25] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 1. The operator and the OSS MUST be able to provision and configure the access port(s) that support the subscriber service. See Use Case 4.5 for more details. 2. The operator and the 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 (upstream and downstream 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 (upstream to downstream, downstream to upstream, bi-directional) . Connection administrative state (locked, unlocked, defective) . Connection maximum bandwidth . Network technology-specific data 3. The operator and the 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 (locked, unlocked, defective) . Network technology-specific data 4. The NMS MUST notify the operator and the OSS, and prevents the subscriber service from being built if the configuration violates any network resource entity relationship or causes an invalid state transition. 5. The NMS then attempts to setup the subscriber service with the configuration parameter specified by the operator and the OSS, and to allocate resources (connection(s), port(s)) in the NEs as necessary. 6. Any configuration by the operator and the OSS MUST be logged. The log MUST be retrievable using both interactive and bulk methods. 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. 6.5. Subscriber Service Removal (Connection-based) Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under NMS management. Chen and Allen Expire June 2003 [Page 26] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 Descriptions: 1. The operator and the 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, and to release the associated resources (connection(s) and port(s)) in the NEs as appropriate. 3. The removal MUST be logged. The log MUST be retrievable using both interactive and bulk methods. 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. 6.6. Subscriber Service Retrieval (Connection-based) Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. The operator and the 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 (locked, unlocked, defective) . Service operational state (enabled, disabled) . Network technology-specific data 2. The operator and the OSS MUST be able to retrieve the following data from the subscriber service: . Any access NEs, plug-ins, or ports supporting this subscriber service . Any links supporting this subscriber service . Any connections supporting this subscriber service . Any routing and signaling instances supporting this subscriber service . Any provider services supporting this subscriber service 3. The operator and the OSS MUST be able to retrieve any subscriber service data using both interactive and bulk methods. Post Conditions: The operator and the OSS retrieve the data as they desire. 6.7. Subscriber Service Alarm Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under the NMS management. 2. The subscriber service experiences a notable event, i.e. an alarm. Descriptions: 1. See Use Case 3.2 for details. Chen and Allen Expire June 2003 [Page 27] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 Post Conditions: The active alarm log and history alarm log are updated accordingly. 6.8. Subscriber Service Test Actor: Operator, NE Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. See Use Case 3.3 for details. Post Conditions: The test result is available for diagnosing. 6.9. Subscriber Service Performance and Usage Actor: Operator, NE, OSS Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: 1. See Use Case 3.4 for details. Post Conditions: Performance and usage data are collected and stored in data files. 7. Use Cases of Security Operation 7.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 usage and performance of the NMS, the NE, and the OSS. 3. Both in-band (management traffic shared with user traffic) and out-band (management traffic only) physical channels SHOULD be provided for the management communication channel between the NMS and the NE. The operator MUST be able to choose the in-band or the out-band channel based on individual NE selection. Post Conditions: Not applicable 7.2. Operator and OSS Login Actor: Operator, OSS Pre-Conditions: 1. The NEs are under the NMS management. Descriptions: Chen and Allen Expire June 2003 [Page 28] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 1. Each operator and the 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 a 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 7.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 a group of the operator and the OSS. When individual operator and OSS login are created, they can belong to zero or more groups, giving the operator and the 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 instance . Provider service . Subscriber service 3. The access control profile MUST include restrictions based on the following operational activities: . Network configuration (e.g. Use Cases in Section 3) . Provider service provision (e.g. Use Cases in Section 5) . Subscriber service provision (e.g. Use Cases in Section 6) . Alarm and test (e.g. Use Cases 4.8, 4.9, 4.14, 4.15, 4.20, 4.21, 5.7, 5.8, 6.7, 6.8) . Performance and usage (e.g. Use Cases 4.10, 4.16, 4.22, 5.9, 6.9) . Information retrieval (e.g. Use Cases 4.7, 4.13, 4.19, 5.3, 6.3, 6.6, 5.6) . Privileged capabilities (e.g. Use Cases 7.1, 7.2, 7.3) Post Conditions: Not applicable 8. Security Considerations Chen and Allen Expire June 2003 [Page 29] Internet Draft draft-weijing-lap-ops-use-01.txt Dec. 2002 The security considerations of this document are detailed in Section 7. 9. 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. 10. 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 June 2003 [Page 30]