ITU-T Q 940-1988 ISDN User-Network Interface Protocol for Management - General Aspects - Digital Subscriber Signalling System No 1 (DSS 1) Network Layer User-Network Management (St.pdf

1、CCITT FASCICLE VI.33 88 4862573 0507084 b SECTION 2 USER-NETWORK MANAGEMENT Recommendation Q.940 ISDN USER-NETWORK INTERFACE PROTOCOL FOR MANAGEMENT - GENERAL ASPECTS 1 General This Recommendation is one of a proposed series of Recommendations describing the management model, service elements and pr

2、otocol to be provided at the ISDN user-network interface. These Recommendations also specify the management functions required to support the ISDN subscriber installation. This Recommendation describes the Management Architecture and provides a general overview of the management services and functio

3、ns. Other Recommendations in this series will specify the System Management Service Elements and Protocol and the procedures associated with management functions. The management functions provided at the user-network interface have, as an objective, full alignment with the network management functio

4、ns being addressed by the Telecommunications Management Network (TMN) and the Management Framework for Open System Interconnection (OSI). While the TMN defines management functions from a network perspective, this Recommendation describes the management functions from the subscriber perspective and

5、provides for remote user management functions. 1.1 Scope This series of Recommendations will provide for a common approach for management communications to support procedures used by a remote maintenance centre, internal or external to the network and those initiated locally. These Recommendations d

6、eal with the specification of the following items: a) b) c) d) e) f) the specification of a Management Architecture and identification of communications paths; the specification of management functionality to be provided at the ISDN user-network interface; the specification of an information exchang

7、e protocol for the exchange of management information between two peer system management application entities (SMAE); the specification of primitives between the Management Application process (user) and the SMAE (Le., the primitives at the systems management service interface (SMSI); the specificat

8、ion of service primitives between the SMAE service element and the next lower layer service elements (Le., primitives at the presentation layer service access point (PSAP); the specification of a convergence function that may be required to permit the direct access of the SMAE service elements to se

9、rvices provided by layer 3 e., the primitives at the network layer service access point (NSAP). 1.2 Field of application The protocols and procedures described in these Recommendations provide the means to support management functions at the ISDN user-network interface. Management activities that ma

10、nage network services, operations such as network resource configuration, routing information and maintenance activities shall be 425 Fascicle VI.11 - Rec. Q.940 Y 7 - - Previous page is blank CCITT FASCICLE VI.33 88 m 4862593 0507085 8 m! supported by the functions and protocols defined in these Re

11、commendations. In particular these management functions should be able to support specific requirements such as those defined in the 1.60-Series of Recommenda- tions (Subscriber Access and Installation Maintenance). These protocols make it possible to control loopbacks and diagnostic tests, initiate

12、 and terminate event reporting and to exchange management information across the ISDN user-network interface, i.e., between equipment connected to the S/T reference points. The physical layer signals in the digital transmission section which are used to control maintenance functions are outside the

13、scope of this Recommendation. The protocols can be used on the D Channel of both the basic and primary rate interface structures and across both reference points S and T. The higher layer protocols can also be used on other ISDN channels and services. The protocols and procedures described in these

14、Recommendations take into account that interactions with the TMN will occur. It is, therefore, desirable that the services and protocols to be used to support access management are aligned, wherever possible, with those to be defined for the TMN and OS1 management. 2 Categories of management informa

15、tion exchange Management information exchanges may be categorized into the following three categories: a) b) Event notification: information transfer initiated by one system reporting instantaneously the occur- rence of an event (e.g., a fault occurrence) to another system. Data transfer: informatio

16、n exchange initiated by one system in order to get management-related information from another system. These exchanges follow the “request followed by response” paradigm. Control information: information exchanges which are of an executive nature, where one system requests that an action be performe

17、d by another system (e.g., for test access and downloading of parameters). c) 3 Management functions Management functions may be classified in accordance with fields of application. The following major functions have been identified: a) Fault management - Maintenance functions - Fault tracing - Spon

18、taneous error reporting - Error threshold alarm reporting - Continuous monitoring - Diagnostic testing - Resource (re)initialization - Confidence testing - Resource identification - Trouble isolation. b) Configuration management - Routing changes - Data base changes - Equipment identification - Netw

19、ork/equipment reconfiguration. - Reporting of billing data. c) Accounting management d) Performance management - - Performance monitoring - Applying controls. Collecting and reporting of traffic data e) Security management. f - 426 Fascicle VI.ll - Rec. 4.940 *-I _? CCITT FASCICLE VI-LL 88 48b259L 0

20、50708b T = 4 Management reference models 4.1 Communications path model Figure /Q.940 shows the entities which may contain System Management Entities (SME) which may require capability to communicate. System Management Entities may be located in, the local exchanges, subscriber installations, remote

21、management centres or network management centres. The management functions supported by the various systems may differ depending on system requirements and may vary between different networks. However, the communications facilities provided by the systems management entities should be as common as p

22、ossible. The scope of this Recommendation covers those functions and protocols that have immediate impact on the user-network interface. The system management entities may be in a TE, NT2 or management service provider. Although communication between any two management entities may be possible in th

23、e model, it does not imply that information held at a particular management entity is available to all other management entities. Security mechanisms may be used to restrict access to the information. . - Optional communication paths in the network FIGURE 1/Q.940 Management communication model Fasci

24、cle VI.ll - Rec. 4.940 ri - -, 427 CCITT FASCICLE VI.33 88 4862573 0507087 3 D Figure 1/Q.940 shows that three types of management communications can be accommodated: a) TE (or Remote Management Centre) - TE (1 -2); b) TE - Network Management Function (1 - 3); c) TE - Network Management Function - T

25、E (1 - 3 -2): Types a) and b) are direct peer communication. In type c), the TE requests the Network Management Entity to act as an agent which then, on behalf of the requesting TE, communicates with another TE. 4.1.1 Secure access to management and maintenance functions To facilitate maintenance pr

26、ocedures and fault sectionalization, maintenance entities located in different management domains may communicate. However, since management and maintenance information is of critical importance to system integrity, access to management functions and information is subject to prior authorization and

27、 security restrictions upon access. The security restrictions are normally enforced by the recipient of the management information but may be enforced by the originator independently of any security imposed by the recipient. The security measures may include requirements for peer-entity authenticati

28、on. The use of adequate security mechanisms is especially important in the case of a network since many users may be affected by unauthorized access. Whenever system management communication crosses an S or T reference point, the requirement for access authorization must be presumed. Note - This doe

29、s not preclude implicit actions on layer management parameters as specified within the relevant signalling protocols, e.g., Recommendations 4.921 and 4.93 1. These actions are, however, beyond the scope of this Recommendation. 4.2 System management entity Figure 2/Q.940 shows the internal structure

30、of the SME. 4.2.1 System management application entity (SMAE) The SMAE is an application layer entity that supports system management functions. The SMAE is responsible for communication with peer systems. The function of the SMAE is to provide the communications necessary to make a system managemen

31、t accessible to another SMAP. It is not necessary for the SMAE to be provided if only local system management is required. 4.2.2 system management application process (SMAP) An SMAP is an application process of a system performing management functions. The SMAP controls the SMAE, and includes the Ma

32、nagement Information Base (MIB) and may include one or more managers providing various functionalities. 4.2.3 management information base (MIB) The MIB is the repository of all information relevant to the operation of a system. Both the SMAP and Layer Management Entities (LME) have access to the MIB

33、. 4.2.4 layer management entity (LME) The LME is that part of a Layer Entity which manages resources and parameters residing in its layer protocol entity. 4.2.5 protocol entity (PE) The PE is that part of a layer entity which is dedicated to peer-to-peer communications. A layer PE provides services

34、to the next upper layer and uses services of the next lower layer. 428 Fascicle VI.11 - Rec. 4.940 - - 7 CCITT FASCICLE VI-LL 88 986259L 0507088 3 m System Management Application Process (SMAPI Management Information Base (MIB) System management service interface (SMSI) -.-.-.-.-.-.-.-.-.-.- -.-.-.-

35、.-. T“ M-type primitive System management MIP LM E application entity (SMAE) ii ii ii i 4 II il II ii ii * 4b LME L6 PE -4; LM E L5 PE +-i-, LME L4 PE II 4 ii II ii i LM E L3 PE i 4.- i +:- LM E L2 PE Il 4; LME LI PE II P-type primitive Note - See 8 4.2.5. N-type primitive Layer management Tl107451-

36、88 service interface (LMSII LI Layer 1, etc. MIP Management information protocol LME Layer management entity PE Protocol entity FIGURE 2/Q.940 System management entity model It should be noted that this model presently permits communication between peer management processes either by attaching to a

37、Presentation Layer Access Point (PSAP) or by attaching directly to the Network Layer Service Access Point (NSAP). A convergence function may be provided as an alternative to the full seven layer OS1 Reference Model (as specified in Recommendation X.200) to accommodate simple terminals that may be us

38、ed in the ISDN environment. If provided, the functions will be kept to a minimum, i.e., the OS1 layer services lost by elimination of layers 4-6 will not be recovered by the convergence function. Therefore, the use of all seven layers is to be preferred. This has the consequence that “convergence fu

39、nctions“ may need to be specified. Fascicle VI.ll - Rec. 4.940 429 , CCITT FASCICLE VI.33 88 m 4862593 0507089 5 m 4.2.6 Management information protocol (MIP) The Management Information Protocol provides the support for information exchange between peer SMAEs. 4.3 Managed objects: a hierarchical obj

40、ect model 4.3.1 Definitions 4.3.1.1 managed object A managed object is a collection of data objects and telecommunications or information processing resources that may be managed by means of the management protocol specified in this Recommendation. 4.3.1.2 A data object is an object that is the dire

41、ct recipient of an action or generator of an event report. 4.3.2 Hierarchical object model The maintenance functions are described as asymmetric functions using symmetrical communications paths. A maintenance activity is always started by an Invoker who is asking an Executor to manipulate event repo

42、rts or data objects. These can be classified as belonging to individual managed objects. Each elementary operation that will have to access or refer to data objects will identify these by specifying first the managed object to which they belong and then identifying them within the managed object. A

43、hierarchical object model is defined that allows access to any individual data object in a simple way. When a given managed object may be duplicated, an instance identifier will help to resolve the ambiguity. As an example, the model for user-network ISDN access interface is represented by the hiera

44、rchical tree of Figure 3/Q.940. /.C.-.- /? ?. 1 ISDN interface . -. 7? . .i ( . Bn D Signalling circuit mode packet mode packet mode (packet mode) LI L2 L3 LI L2 L3 LI L2 L3 LI T1108820-87 FIGURE 3/Q.940 Example hierarchical object tree The parameters and event reports pertaining to a particular man

45、aged object can then be defined implicitly within the managed object. Some managed objects may be empty when no data object is identified within them. In this case they are only present as an indication of a hierarchical level. It has to be noted that the ISDN user-network access interface model onl

46、y contains managed objects that belong to the network access functions, i.e., that are involved in the provision of the required bearer service (signalling and lower layer protocols on the bearer channels). The protocols that are not involved in the provision of the bearer service are excluded from

47、this model as they belong to the application part. Note - The identity of an object at the executing end may not be known to the Invoker when it requests a maintenance action at the remote end of a connection. In this case the Executor will be able to identify the object by the context of the connec

48、tion path used to convey the maintenance request. Fascicle VI.ll - Rec. 4.940 - 430 - r- 7 CCITT FASCICLE VI-II 88 m 4862593 0507090 I m As an example, remote maintenance may be required on an existing B Channel connection. The channel identity is only locally significant at each end. The maintenanc

49、e request must be transmitted over the signalling connection that is used to control the B Channel associated with the existing call. The identity of the B Channel will be implied by the signalling connection used to convey the maintenance request. 5 Management structure and activities This section considers the specific structure and activities of management in terms of system management, layer management and protocol processing for management purposes. 5.1 System management This section introduces the concept of system management, its boundaries and other structures an