Internet Standards

home *** CD-ROM | disk | FTP | other *** search

/ Internet Standards / CD2.mdf / ccitt / 1992 / g / g784.asc < prev next >

Wrap

Text File | 1993-08-15 | 70KB | 1,911 lines

C:\WINWORD\CCITTREC.DOT_______________ Recommendation G.784 Recommendation G.784 SYNCHRONOUS DIGITAL HIERARCHY (SDH) MANAGEMENT The CCITT, considering (a) that Recommendations G.707, G.708 and G.709 form a coherent set of specifications for the synchronous digital hierarchy (SDH) and the network node interface (NNI); (b) that Recommendation G.781 gives the structure of Recommendations on multiplexing equipment for the SDH; (c) that Recommendation G.782 describes the types and general charac- teristics of SDH multiplexing equipment; (d) that Recommendation G.783 specifies the characteristics of SDH mul- tiplexing equipment functional blocks; (e) that Recommendation G.958 specifies digital line systems based on SDH for use on optical fibre cables; (f) that it is expected that further Recommendations will be produced concerned with other SDH equipment types, e.g. digital cross-connects and radio systems; (g) that Recommendation M.30 defines the principles for a telecommuni- cationas management network (TMN); (h) that Recommendation G.773 defines the protocol suites for Q-inter- faces, recommends that the management of SDH equipment should be organized in accordance with the details contained within this Recommendation. 1 Introduction This Recommendation addresses management aspects of the synchro- nous digital hierarchy (SDH), including the control and monitoring func- tions relevant to SDH network elements (NE). The SDH management sub- network (SMS) architecture, SDH embedded control channel (ECC) func- tions, and SDH ECC protocols are specified. Detailed message sets are for further study. The management of SDH equipment should be seen as a subset of the telecommunications management network (TMN) described in Recommen- dation M.30, and reference is made to Recommendation G.773 for the spec- ification of protocol suites to be used at external (Q) management interfaces. 2 Abbreviations and definitions 2.1 Abbreviations ACSE Association control service element AITS Acknowledged information transfer service APDU Application protocol data unit ASE Application service element ASN.1 Abstract syntax notation one CC Connect confirm CLNP Connectionless network layer protocol CLNS Connectionless network layer service CMIP Common management information protocol CMISE Common management information service element CONP Connection oriented network-layer protocol CR Connection request CV Code violation DCC Data communications channel DCN Data communications network ECC Embedded control channel ES Errored second FLS Frame loss second FU Functional unit GNE Gateway network element IFU Interworking functional unit IP Interworking protocol IS Intermediate system ISO International for standardization organization LCN Local communications network MAF Management applications function MCF Message communications function MD Mediation device MF Mediation function MO Managed object MOC Managed object class NE Network element NEF Network element function NLR Network layer relay NNE Non-SDH network element NPDU Network protocol data unit NSAP Network service access point OAM&P Operations, administration, maintenance and provisioning OS Operations system OSF Operations system function OSI Open systems interconnection PDU Protocol data unit PJC Pointer justification count PPDU Presentation protocol data unit PSN Packet switched network ROSE Remote operations service element SAPI Service access point identifier SDH Synchronous digital hierarchy SMN SDH management network SMS SDH management sub-network SNDCF Sub-network dependent convergence function SPDU Session protocol data unit STM Synchronous transport module SVC Switched virtual circuit TEI Terminal end-point identifier TMN Telecommunications management network TPDU Transport protocol data unit TSAP Transport service access point UAS Unavailable second UAT UnAvailable time UI Unnumbered information UITS Unacknowledged information transfer service 2.2 Definitions 2.2.1 data communications channel (DCC) Within an STM-N signal there are two DCC channels, comprising bytes D1-D3, giving a 192 kbit/s channel, and bytes D4-D12, giving a 576 kbit/s channel. D1-D3 (DCCR) are accessible by all SDH NEs whereas D4- D12 (DCCM), not being part of the regenerator section overhead, are not accessible at regenerators. D1-D3 are allocated for SDH NE use. The D4- D12 channel can be used as a wide area, general purpose, communication channel to support TMN including non-SDH applications. This would include both communication between OSs and communication between an OS and a network element (including SDH network elements). The applica- tion of the D4-D12 channel requires study for general TMN applications and also for SDH network element management applications. 2.2.2 embedded control channel (ECC) An ECC provides a logical operations channel between SDH NEs, utilizing a data communications channel (DCC) as its physical layer. 2.2.3 SDH management network (SMN) An SDH management network is a subset of a TMN, responsible for managing SDH NEs. An SMN may be subdivided into a set of SDH man- agement sub-networks. 2.2.4 SDH management sub-network (SMS) An SDH management sub-network (SMS) consists of a set of separate SDH ECCs and associated intra-site data communication links which have been interconnected to form an operations data communications control net- work within any given SDH transport topology. An SMS represents an SDH specific local communication network (LCN) portion of a network opera- tor's overall operations data network or TMN. 2.2.5 management application function (MAF) An application process participating in system management. The management application function includes an agent (being managed) and/or manager. Each SDH network element (NE) and operations system or media- tion device (OS/MD) must support a management application function that includes at least an agent. A management application function is the origin and termination for all TMN messages. 2.2.6 manager Part of the MAF which is capable of issuing network management operations (i.e. retrieve alarm records, set thresholds) and receiving events (i.e. alarms, performance). SDH NEs may or may not include a manager while SDH OS/MDs will include at least one manager. 2.2.7 agent Part of the MAF which is capable of responding to network manage- ment operations issued by a manager and may perform operations on man- aged objects, issuing events on behalf of managed objects. The managed objects can reside within the entity or in another open system. Managed objects from other open systems are controlled by a distant agent via a local manager. All SDH NEs will support at least an agent. Some SDH NEs will provide managers and agents (being managed). Some NEs (e.g. regenera- tors) will only support an agent. 2.2.8 managed object (MO) The management view of a resource within the telecommunication environment that may be managed via the agent. Examples of SDH man- aged objects are: equipment, receive port, transmit port, power supply, plug- in card, virtual container, multiplex section, and regenerator section. 2.2.9 managed object class (MOC) An identified family of managed objects that share the same charac- teristics, e.g. ôequipmentö may share the same characteristics as ôplug-in cardö. 2.2.10 message communications function (MCF) The message communications function provides facilities for the transport of TMN messages to and from the MAF, as well as facilities for the transit of messages. The message communications function does not originate or terminate messages (in the sense of the upper protocol layers). 2.2.11 operations system function or mediation function (OSF/MF) A telecommunications management network (TMN) entity that pro- cesses management information to monitor and control the SDH network. In the SDH sub-portion of the TMN, no distinction is made between the opera- tions system function and the mediation function; this entity being a MAF containing at least a manager. 2.2.12 network element function (NEF) A function within an SDH entity that supports the SDH based net- work transport services, e.g. multiplexing, cross-connection, regeneration. The network element function is modelled by managed objects. 2.2.13 operations system or mediation device (OS/MD) A stand-alone physical entity that supports OSF/MFs but does not support NEFs. It contains a message communication function (MCF) and a MAF. 2.2.14 network element (NE) A stand-alone physical entity that supports at least NEFs and may also support OSF/MFs. It contains managed objects, a MCF and a MAF. 3 SDH management network 3.1 Management network organizational model The management of an SDH network uses a multi-tiered distributed management process. Each tier provides a pre-defined level of network management capabilities. The lower tier of this organizational model (see Figure3-1/G.784) includes the SDH NEs providing transport services. The management applications function (MAF) within the NEs communicates with, and provides management support to, peer NEs and mediation device(s) (MDs)/operations system(s) (OSs). The communication process is provided via the message communica- tion function (MCF) within each entity. The MAF at each entity can include agents only, managers only, or both agents and managers. Entities that include managers are capable of managing other entities. Each tier in the multi-tiered organizational model can provide addi- tional management functionality. However, the message structure should remain the same. A manager within an SDH NE may suppress alarms gener- ated by one or more of its managed NEs due to a common failure, and replace them by a new alarm message, directed to the OS/MD, identifying the source of the problem. The new alarm message format will be consistent with other alarm messages. FIGURE 3-1/G.784 FIGURE 3-2/G.784 The message format will be maintained as messages are elevated up the hierarchy, i.e., SDH NE to SDH NE messages will have the same structure as SDH NE to MD messages and SDH MD to OS messages. Figure 3-2a/G.784 illustrates examples of management communication using a Q-interface implemented in the MCF where logically independent communications are provided over a single physical interface: û between a manager in the OS and two different agents; one in the MD and one in NE2 (interface a); û between a manager in the MD and an agent in NE1; between a man- ager in the OS and an agent in NE2 (interface b). Figure 3-2b/G.784 illustrates examples of management communication using Q-interface protocols implemented in the MCF: û between a manager in the OS and an agent in the MD (interface c); û between a manager in the MD and an agent in NE1 (interface d); û between a manager in NE1 and an agent in NE2 (interface e). 3.2 Relationship between SMN, SMS and TMN The inter-relationship between the SMN, SMS and TMN is shown in Figure3-3/G.784. Figure 3-4/G.784 shows specific examples of SMN, SMSs and connectivities within the encompassing TMN. FIGURE 3-3/G.784 The following sub-sections describe the SMS in more detail, addressing: û access to the SMS; and û SMS architecture. 3.2.1 Access to the SMS Access to the SMS is always by means of an SDH NE functional block. The SDH NE may be connected to other parts of the TMN through the following sets of interfaces: 1) workstation (F); 2) mediation device (a Q-interface); 3) operations system (a Q-interface); 4) non-SDH NE or site related information (interface(s) for further study). FIGURE 3-4/G.784 The functionality required to be supported by the SDH NE will determine the type of Q-interface to be provided. For instance, the two main varieties of SDH NEs expected are the SDH NEs with mediation functions (MF) and ôregularö SDH NEs. An example of the SDH NE with MF is shown in Figure3-5/G.784. An example of a ôregularö SDH NE is shown in Figure3- 6/G.784. 3.2.2 SDH management sub-network architecture In Figure 3-4/G.784 a number of points should be noted concerning the architecture of the SMS: a) Multiple NEs at a single site Multiple, addressable SDH NEs may appear at a given site. For exam- ple, in Figure 3-4/G.784 NEe and NEg may be collocated at a sin- gle equipment site. b) SDH NEs and their communications functions The message communications function of an SDH NE terminates (in the sense of the lower protocol layers), routes or otherwise pro- cesses messages on the ECC, or connected via an external Q-inter- face. i) All NEs are required to terminate the ECC. In OSI terms, this means that each NE must be able to perform the functions of an end system. ii) NEs may also be required to route ECC messages between ports according to routing control information held in the NE. In OSI terms, this means that some NEs may be required to perform the functions of an intermediate system. iii) NEs may also be required to support Q- and F-interfaces. c) SDH inter-site communications The inter-site or inter-office communications link between SDH NEs will normally be formed from the SDH ECCs. d) SDH intra-site communications Within a particular site, SDH NEs may communicate via an intra-site ECC or via an LCN. Figure3-4/G.784 illustrates both instances of this interface. Note û A standardized LCN for communicating between collocated network elements has been proposed as an alternative to the use of an ECC. The LCN would potentially be used as a general site communications net- work serving both SDH and non-SDH NEs (NNEs). The LCN is part of the TMN and thus the specification of the LCN is beyond the scope of this Rec- ommendation. 3.3 SMS topology and reference models 3.3.1 ECC topology for the SDH management sub-network It is intended that this Recommendation should place no restriction on the physical transport topology to support the ECC. Thus it is expected that the supporting DCCs may be connected using string (bus), star, ring or mesh topologies. Each SDH management sub-network (SMS) must have at least one element which is connected to an OS/MD. This is called a gateway network element (GNE) and is illustrated in Figures3-5/G.784, 3-6/G.784 and 3-7/ G.784. The GNE should be able to perform an intermediate system network layer routing function for ECC messages destined for any end system in the SMS. Note û This is a specific instance of the general requirement that mes- sages passing between communicating sub-networks shall use the network layer relay. The communications function is illustrated in Figure 3-7/G.784. Mes- sages passing between OS/MD and any of the end systems in the sub-net- work are routed through the GNE and, in general, other intermediate systems. FIGURE 3-5/G/784 FIGURE 3-6/G.784 FIGURE 3-7/G.784 3.3.2 Message routing at SDH NE sites The means of generation and administration of routing control infor- mation amongst communicating sub-networks and within sub-networks is detailed in º6.2.3. 3.3.3 SMS reference models Reference models are particularly suited for test cases and for design verification and acceptance testing. The reference configurations in Figure3-8/G.784 and Figure3-9/G.784 are examples of test cases for SMS management. Examples of SMS connectivity are given in Figure3-10/ G.784. Other variations of Figure 3-9/G.784 are also of interest as reference configurations; for example, on routes where the operator chooses not to implement the multiplex section protection (MSP) function, the ECCs would be provided on at least two SDH lines, and optionally on any remain- ing SDH lines of a particular route. FIGURE 3-8/G.784 FIGURE 3-9/G.784 FIGURE 3-10/G.784 4 Information model An overview of object modelling and the objectives for the SDH spe- cific model are given in Annex D. Detailed specifications are for further study. Note û This section will contain the information required to specify the ASN.1 encoded manager-agent messages needed to support the manage- ment functions described in º5. 5 Management functions This section provides an overview of the minimum functions which are required to support inter-vendor/-network communications and single- ended maintenance of SDH NEs within an SMS, or between communicating peer NEs across a network interface (ºº5.1.1, 5.2.1, 5.3.1, 5.4.2). Single- ended maintenance is the ability to access remotely located NEs to perform maintenance functions. Other management functions have been identified (ºº 5.1.2, 5.1.3, 5.1.4, 5.1.5, 5.2.2, 5.2.3, 5.4.1, 5.4.3, 5.5) and will be specified in the latter stages of the 1988-1992 CCITT study period. It should be noted that the management functions have been catego- rized according to the classifications given in RecommendationM.30. Detailed specifications of the management functions, in terms of sup- port objects, attributes and message specification, are given in AnnexA. 5.1 General functions 5.1.1 Embedded control channel (ECC) management In order for SDH NEs to communicate they must manage the ECC. The ECC management functions defined below are examples of functions required to be supported with ECC messages: a) retrieval of network parameters to ensure compatible functioning, e.g., packet size, timeouts, quality of service, window size,etc.; b) establishment of message routing between DCC nodes; c) management of network addresses; d) retrieval of operational status of the DCC at a given node; and e) capability to enable/disable access to the DCC. 5.1.2 Security For further study. 5.1.3 Software For further study. 5.1.4 Remote login For further study. 5.1.5 Time-stamping The required accuracy and precise details of the time-stamping of events/reports is the subject of further study. (Maximum values in the range 1 to 30seconds have been mentioned for the permissible inaccuracy com- pared to real time.) 5.2 Fault (maintenance) management 5.2.1 Alarm surveillance Alarm surveillance is concerned with the detection and reporting of relevant events/conditions which occur in the network. In a network, events/ conditions detected within the equipment and within the incoming signal, as well as those external to the equipment, should be reportable. Alarms are indications that are automatically generated by an NE as a result of certain events/conditions. The user shall have the ability to define which events/ conditions generate autonomous alarm reports. The remaining events/condi- tions are reported on request. The following alarm-related functions shall be supported: û report autonomous alarms; û request all alarms; û report all alarms; û allow/inhibit alarm reporting over the ECC; û request status of allow/inhibit alarm reporting; û report status of allow/inhibit alarm reporting. A summary of alarm conditions is given in º 2 of Annex A. Detailed mes- sage sets are for further study. 5.2.2 Testing For further study. 5.2.3 External events For further study. 5.3 Performance management 5.3.1 Performance monitoring Note û Fixed window processing of the primitive performance infor- mation (15minutes and 1 day) is considered satisfactory for the purpose of network surveillance and of fault identification and sectionalization. This does not preclude the additional use of other window processing techniques for detailed performance or fault characterization where it is demonstrated that these provide significant additional information on the nature of errored events. If an alternative window processing technique is used, it should be capable of default to the fixed window method. 5.3.1.1 Performance data collection Performance data collection refers to the event count associated with each of the performance parameters indicated in RecommendationG.783. The parameters are derived from performance primitives associated with SDH frame formats defined in RecommendationsG.707, G.708 and G.709. Event counts are inhibited under certain failure or unavailable conditions as specified in º5.3.1.7. Parameter requirements specific to each digital signal are summarized in º 3 of Annex A. Detailed message sets are for further study. 5.3.1.2 Performance monitoring history Performance history data is useful to assess the recent performance of transport systems and sectionalize the trouble or degradation. This history can also enable performance assessment against long-term performance objectives. Limited historical data, in the form of event counts for each moni- tored parameter, shall be stored in NEs, or in mediation devices associated with NEs. Separate performance monitoring data shall be stored for individ- ual directions of transmission. A current 15-minute and current day register, a previous 15-minute and previous day register, and a certain number of recent 15-minute and day registers will be provided per monitored parameter, per direction (as detailed in º3 of AnnexA). The 15-minute and day registers shall function as follows: a) Current 15-minute register û contains the impairment count for the parameter during a 15-minute period. The current 15-minute regis- ter shall be reset to zero each 15 minutes after the data is trans- ferred to the previous 15-minute register. b) Current day register û contains the impairment count for the param- eter during a 1-day period. The current day register shall be reset to zero each day (e.g. at midnight) after the data is transferred to the previous day register. c) Previous 15-minute register û contains a 15-minute count for the parameter. At the end of each 15minutes the impairment count from the current 15-minute register is stored in the previous 15-minute register and the old data from the previous 15-minute register is transferred to the first recent register (if recent 15- minute registers are provided; if not, the old data is discarded). d) Previous day register û contains a 1-day count for the parameter. At the end of each day the impairment count from the current day reg- ister is stored in the previous day register and the old data from the previous day register is transferred to the most recent register (if recent day registers are provided; if not, the old data is discarded). e) Recent 15-minute registers û a group of n registers, each of which contains a 15-minute count, so that performance data for the n most recent 15 minutes (plus the previous 15 minutes) is stored (values of ônö are specified in º3 of AnnexA). At the end of each 15 minutes the count from the previous 15-minute register is stored in the first recent register. The values in each successive recent register are pushed down one register in the stack. The oldest 15 minutes at the bottom of the stack is discarded. f) Recent day registers û a group of m registers, each of which con- tains a 1-day count, so that performance data for the m most recent days (plus the previous day) is stored (values of ômö are specified in º3 of AnnexA). At the end of each day the count from the pre- vious day register is stored in the first recent register. The values in each successive recent register are pushed down one register in the stack. The oldest day at the bottom of the stack is discarded. The above registers shall be readable on demand, and routine (e.g. daily) retrieval of the previous plus recent data shall be possible without loss of data. The registers may be manually reset to zero at any time. The registers shall not be automatically reset when service is restored after failure. Note û The need to provide a limited number of registers which could pro- vide, on request, event history of a selectable parameter, time stamped on a 1-second basis is for further study. 5.3.1.3 Threshold setting and threshold crossing notifications Threshold crossing alarm messages signify performance degradations reaching and/or exceeding (i.e. >= function) preset thresholds, and as such, are an integral part of the performance monitoring process. Thresholds may be set in the NE to notify the OS before service is affected. The value of the threshold shall be settable over the minimum range given in TableA-6/ G.784. When the NE recognizes a threshold crossing for a given parameter, a threshold crossing notification should be generated. When a threshold is crossed, the NE shall continue counting to the end of the accumulation period, when the current count is stored and reset. No more than one thresh- old notification (per parameter, per direction of transmission) shall be sent during any accumulation period. Details of threshold setting functions are given in º 5.3.1.5. 5.3.1.4 Performance data reporting Data reporting is useful for initiating appropriate maintenance actions and also when following up trouble reports. That is, performance data stored in the NE may be collected and analysed. If marginal troubles are detected, appropriate maintenance actions can then be carried out. Also, routine data collection may be performed periodically to sup- port trend analysis to predict future failure/degrade conditions. To report performance data, the parameters (e.g. ES, SES), the direc- tion of transmission (i.e. near end, far end) and the accumulation period (e.g.current 15minutes, day) need to be specified. The reporting intervals are nominally 15minutes and a day. Performance data shall be reportable across the OS/NE interface in each of the following ways: a) on demand per port when requested by the OS; b) automatically upon the crossing of a performance monitoring threshold (e.g. 15-minute alert and current 15-minute register val- ues for all parameters); c) periodically for specific ports as required by the OS. The suppres- sion of reporting of zero counts is for further study. Note û The term ôportö means a single section, line or path termination, or monitoring point, in the NE. An OS can request an NE to report performance monitoring data on demand or periodically on selected ports. If the NE is unable to begin periodic reporting of data in response to the OS command, the NE should respond with an unable to comply message. For 24-hour data specifically, the OS may instruct the NE on when to begin measurement of the 24-hour period for the purpose of collecting data. The NE shall be able to begin the measurement at the start of any hour. The specific functions which should be supported at the OS/NE interface to support data collection and thresholding are: a) Request data û OS requests the NE to send data including parame- ters, direction of transmission and accumulation period; NE responds with a data report. b) Schedule data report û OS directs the NE to establish a schedule for the reporting of data including parameters, direction of transmis- sion, reporting interval, start of reports and number of reports; NE responds by sending the appropriate period data reports, or NE responds with an unable to comply message if not equipped to han- dle scheduling of data reports. c) Request data report schedule û OS directs the NE to send the cur- rent data reporting schedule; NE reports with the schedule includ- ing parameters, direction of transmission, reporting interval (i.e.15minutes, daily), time of next report, and remaining number of reports. d) Start/stop data û OS directs the NE to start or stop the reporting of data including reporting interval, parameters, direction of trans- mission; NE responds with verification that reporting will start/ stop. e) Data report û NE sends performance data to the OS including parameter, direction of transmission, type of threshold, threshold level and register value. It may be generated periodically by the NE (when periodic reporting is scheduled by OS), sent upon demand by the OS or by exception when a parameter threshold has been exceeded. f) Set attributes û OS directs the NE to assign designated attributes including parameter to be monitored, type of threshold (i.e.15minutes, daily), threshold value, data reporting mode (e.g.scheduled, start/stop), and start time of 24-hour period; NE responds with new attribute designations. g) Request attributes û OS requests the NE to send to the OS the cur- rent attributes; NE responds by sending the currently assigned attributes including parameter to be monitored, type of threshold, threshold value, whether data reports are enabled or inhibited, and start time of 24-hour period. It is permissible for the NE to code the set (or sets) of attributes so as to minimize message traffic, and also to use the code to signify operational status of the NE. How this latter function can be achieved in the context of standardized OS/NE messages is for further study. 5.3.1.5 Register and threshold setting functions 5.3.1.5.1 Initialization The NE shall allow the OS to initialize current storage registers. The specific function related to data initialization which should be supported at the OS/NE interface is: û Initialize data û OS directs the NE to reset storage registers for data, including type of registers (i.e. 15minutes, daily). 5.3.1.5.2 Capability for threshold setting The OS shall be able to retrieve and change the settings of the 15-minute and daily thresholds on a per port basis. Threshold crossing notifications shall have default thresholds, as well as locally and remotely settable non-default thresholds. When the OS requests that a threshold be changed, the NE shall respond with the new value to which the threshold has been set. If the OS requests a threshold value higher than allowed by a given NE implementa- tion, the NE shall set the threshold to the nearest lower threshold value which the NE implementation allows and report this change to the OS. The ability to inhibit threshold setting on a per port basis or on a per NE basis shall be supported. The OS shall be notified of such a condition when data is collected, and when attributes are requested. When threshold setting is re-enabled, threshold values shall be restored to the same ones in place just prior to the inhibit. 5.3.1.6 Accuracy and resolution All parameter counts should be actual, except when there is register overflow, in which case the registers hold at the maximum value until they are read and reset at the end of the accumulation period. 15-minute and daily time intervals shall be accurate to within plus or minus (to be decided; values in the range1 to 10seconds have been pro- posed). The start of 15-minute and daily counts shall be accurate to within plus or minus (to be decided; values in the range1 to 30seconds have been proposed). 5.3.1.7 Performance monitoring during unavailable and trouble conditions Performance parameter counts shall be inhibited during UnAvailable time (UAT) as given in TableA-7/G.784. Monitoring shall be correlated with UAT and trouble conditions, e.g. LOS, LOF and LOP, as well as AIS which is indicative of upstream trouble. 5.4 Configuration management 5.4.1 Provisioning For further study. 5.4.2 Status and control (protection switching) The general facility of protection switching is defined as the substitu- tion of a standby or back-up facility for a designated facility. The specific functions which allow the user to control the traffic on the protection line are: û operate/release manual protection switching; û operate/release force protection switching; û operate/release lockout; û request/set automatic protection switching (APS) parameters. 5.4.3 Installation functions For further study. 5.5 Security management For further study. 6 Protocol stack 6.1 Description The protocol stack shown in this section has been selected to satisfy requirements for the transfer of operations, administration, maintenance and provisioning (OAM&P) messages across the SDH data communications channels (DCC). It is in accordance with the current object oriented approach to the management of open systems. That is, the application layer includes the common management information service element (CMISE), and the remote operations service element (ROSE) and association control service element (ACSE) to support CMISE. The presentation, session and transport layers provide the connection oriented service required for support of ROSE and ACSE. The transport layer includes the additional protocol elements required to provide a Con- nection Mode service when operating over the connectionless network layer protocol (CLNP) (ISO 8473 [1]). Data link support is provided by LAPD as defined in RecommendationsQ.920[31] and Q.921[32]. Layer 1, the physical layer of the stack, represents the SDH DCC. 6.1.1 ECC protocol stack description The protocol stack given in Figure 6-1/G.784 is to be used for the communication of management messages over the SDH DCC. The specifi- cations of options and parameters required in order to guarantee interopera- tion are described in º6.2. The protocols for each layer, as outlined in the following sub-sec- tions, are to be used for management communications over the SDH ECC. The detailed specifications of these protocols are given in º6.2. FIGURE 6-1/G.784 6.1.1.1 Physical layer (layer 1) The SDH data communication channel (DCC) constitutes the physical layer. 6.1.1.2 Data link layer (layer 2) The data link protocol, LAPD (Recommendation Q.921) provides point-to-point connections between nodes of the underlying transmission network. 6.1.1.3 Network layer (layer 3) The network protocol ISO 8473, provides a datagram service suitable for the high speed, high quality underlying network. Convergence protocols have been defined in ISO8473/AD3 for the operation of ISO 8473 over both connection-oriented and connectionless data link sub-networks. 6.1.1.4 Transport layer (layer 4) The transport protocol ensures the accurate end-to-end delivery of information across the network. The protocol creates a transport connection from the underlying connectionless network service (ISO8073/AD2[7]) and provides for flow-control and error recovery on this connection. Trans- port class4 is selected to ensure reliable NPDU delivery over the connec- tionless mode network layer services. 6.1.1.5 Session layer (layer 5) The session protocol ensures that the communication systems are syn- chronized with respect to the dialogue under way between them and man- ages, on behalf of the presentation and application layers, the transport connections required. 6.1.1.6 Presentation layer (layer 6) The presentation protocol and the ASN.1 basic encoding rules act to ensure that application layer information can be understood by both of the communicating systemsûthe context of the information being transferred and the syntax of the encoding of information. 6.1.1.7 Application layer (layer 7) The following options of the application layer shall be utilized: i) CMISE The common management information service element (CMISE) of the ISO common management information protocol (CMIP) provides services for the manipulation of management information across the ECC. It has been selected by ISO as the carriage proto- col for network management protocols. CMISE is based on an object-oriented paradigm that represents network entities, and net- work management functions and information as objects with attributes and operations that can be performed on the objects. The CMISE services enable a network management system to: û create and delete the objects (CREATE/DELETE); û define and redefine values of object attributes, (SET and GET); û invoke operations on the objects (ACTION), and û to receive reports from the objects (EVENT REPORT). ii) ROSE The remote operations service element (ROSE) permits one sys- tem to invoke an operation on another system and to be informed of the results of that operation. In the context of the ECC protocol stack, the operations are defined to be CMISE services. iii) ACSE The association control service element (ACSE) provides services to initiate and terminate a connection (association), between two applications. This association is then used to convey the manage- ment messages corresponding to the CMISE services. 6.2 Protocol specifications This section specifies protocols for the SDH ECC. Protocol options, features, parameter values, etc., in addition to those specified in this Recommendation may be included in a conforming system provided they are not explicitly excluded by this Recommendation and they do not prevent interoperability with conforming systems that do not provide them. A control network topology is outlined in º 3.2.2. 6.2.1 Physical layer protocol specification The regenerator section DCC shall operate as a single 192 kbit/s mes- sage based channel using the section overhead bytesD1 toD3. The multi- plex section DCC shall operate as a single 576kbit/s message based channel using the section overhead bytesD4 toD12. 6.2.2 Data link layer protocol specification The data link layer shall provide point-to-point transfer, over the SDH DCC, of Network Service Data Units (NSDU) through a single logical channel between each pair of adjacent network nodes. The data link layer shall operate under the rules and procedures speci- fied in RecommendationQ.921[32] for the Unacknowledged Information Transfer service (UITS) specified in º6.2.2.1, and for Acknowledged Infor- mation Transfer service (AITS) specified in º6.2.2.2. Both services (UITS and AITS) shall be supported. AITS shall be the default mode of operation. A mapping between the connection-mode Data Link service primi- tives defined in ISO 8886 (RecommendationX.212) and RecommendationsQ.920/Q.921 primitives is defined in Table6-1/G.784. 6.2.2.1 Unacknowledged information transfer service (UITS) UITS shall follow the rules and procedures specified in Recommen- dation G.921 [32]. For the UITS, the sub-network dependent convergence function (SNDCF) provides a direct mapping onto the data link layer as specified in º8.4.4.1 of ISO8473/AD3[2]. For this application, mandatory and optional service and Protocol parameters shall have the values specified in Table6-2/G.784. 6.2.2.2 Acknowledged information transfer services (AITS) AITS shall follow the rules and procedures specified in Recommen- dation Q.921 [32]. For AITS, the SNDCF provides a mapping onto the data link layer as specified in º8.4.4.2 of ISO8473/AD3[2]. For this applica- tion, mandatory and optional service and protocol parameters shall have the values specified in Table6-3/G.784. In addition, the requirements specified in c) to f) of Table6-2/G.784 shall also be followed. 6.2.3 Network layer protocol description The connectionless mode network layer service provided to the trans- port layer is defined in ISO8348/AD1[3] and the protocol to provide this service shall conform to ISO8473[1]. Network protocol data units (NPDUs) are routed through intermediate systems to end systems using routing control information at each intermediate system. All NEs must be designed to function as an intermediate system, as an end system or both. An intermediate system is defined as having one or more ports to which a received NPDU may be forwarded, while an end system has none. The routing control information is used to select the underlying ser- vice needed to reach the next system in the route. It is recommended that the derivation and provisioning of this routing information should be supported in one of the following ways. a) manual administration; b) use of the end system to intermediate system routing exchange pro- tocol as defined in ISO 9542 [4] (i.e.can be used between an inter- mediate system and all end systems connected to it to establish the routing control at the intermediate system); c) intermediate system to intermediate system intra-domain routing exchange protocols are currently under study and may be used when available. They are expected to be backward compatible with the end system to intermediate system routing exchange pro- tocol referred to in b) above. Note û Until intermediate system to intermediate system intra-domain rout- ing exchange protocols are available, and if the manual administration of routing tables is too burdensome, then one of the schemes described in AnnexesB andC may be used. However, when selecting one of these schemes, network operators should take into account the possible backward compatibility implications of introducing intermediate system to intermedi- ate system intra- domain routing exchange protocols, once finalized. For this application, the full protocol subset of category 1 functions, as spec- ified in ISO 8473 [1], shall be supported. Category2 functions, as specified in ISO8473[1], may be supported. Category 3 functions, as specified in ISO8473[1], that are not required or prohibited in Table6-4/G.784, may also be supported. The service/protocol parameters shall have the values specified in Table6-4/G.784. 6.2.4 Transport layer protocol specification The required transport layer protocol shall be the connection-mode protocol as specified in ISO8073 [6], together with ISO8073/AD2[7] for class4 operation over CLNS. Transport protocol class4 (TP4) shall be the only supported transport protocol class over the SDH DCC. Transport layer attribute values are given in Table 6-5/G.784. 6.2.5 Session layer The session layer conforms to the service definition and protocol specification in Recommen-dationsX.215[19] and X.225[20] respectively. Support of version2 of the session protocol is mandatory. Two session layer functional units (FU) are required in this Recom- mendation: 1) Kernel, 2) Duplex. Restrictions applied to parameters and their values are specified in the fol- lowing sections. 6.2.5.1 Session protocol data units The following session protocol data units (SPDUs) associated with the Kernel and Duplex functional units shall be supported as detailed in Table6-6/G.784. 6.2.5.2 Transport expedited service The use of the transport expedited service is as stated in RecommendationX.225 [20]; if available, it must be used. When the trans- port expedited service is available, the prepare (PR) SPDU shall be sup- ported as in Recommen-dationX.225[20]. The prepare type parameter value in the PR SPDU, to indicate the arrival of an abort (AB) SPDU, is ABORT. 6.2.5.3 Parameters All mandatory parameters defined in RecommendationX.225 [20] for the SPDUs required by the Kernel and Duplex FUs are mandatory parame- ters for this Recommendation. 6.2.5.4 User data The maximum length of the session user data shall be 10 240 octets. This restriction implies that the overflow accept (OA) and connect data overflow (CDO) SPDUs are not required to be supported. Session selector (S-selector) parameter values shall have a maximum length of 16 octets. 6.2.5.5 Reuse Reuse of the transport connection is not required. The transport dis- connect parameter value (PV) field may be absent or set to ôtransport con- nection is releasedö in appropriate SPDUs. Furthermore, on receipt of a transport disconnect PV field indicating ôtransport connection is keptö, the transport connection can be released. 6.2.5.6 Segmentation The segmentation feature in the session layer is not required. Support for extended concatenation of SPDUs is not required. 6.2.5.7 Invalid SPDUs Upon receipt of an invalid SPDU, the session protocol machine shall take any action specified in ºA.4.3.2 of RecommendationX.225[20] with the exception of action ôdö (take no action). 6.2.6 Presentation layer It is mandatory that the presentation layer conform to the services and protocols specified in RecommendationsX.216[21] and X.226[22] respectively. One presentation layer functional unit (FU) is required in this Recommendation: Kernel. The presentation protocol shall be used in the normal mode. Restric- tions applied to parameters and their values are specified in the following sections. 6.2.6.1 Presentation protocol units The following presentation protocol units (PPDU) associated with the Kernel functional unit shall be supported, as detailed in Table6-7/G.784. 6.2.6.2 Parameters All mandatory parameters defined in Recommendation X.226 [22] for the above PPDUs are mandatory for this Recommendation. The presenta- tion context identifier value shall be encoded in no more than 2 octets. Also, the value(s) in the parameter presentation context definition list shall be consistent with the value(s) defined in the application-specific standards. Presentation-selector (P-selector) parameter values shall have a maximum length of 4octets. 6.2.6.3 Encoding rules for transfer syntax The encoding rules defined in RecommendationX.209 [23] shall be applied to derive the transfer syntax for the application protocol data units (APDUs). The ASN.1 OBJECT IDENTIFIER {joint-iso-ccittasn.1(1) basic- encoding(1)} shall be used as the value for the transfer syntax name. The maximum value of an ASN.1 basic encoding tag that needs to be han- dled for conformance to this Recommendation is 16383. This is the largest unsigned integer that can be represented in 14bits. Hence the identifier octets shall consist of an initial octet and up to two more octets, thus occu- pying a maximum of three octets. Also, the largest number of octets in the contents octets component of an ASN.1 data value encoding that needs to be handled for conformance to this Recommendation is 4294967295. This is the largest unsigned integer than can be represented in 32bits. Hence in the long form encoding, the length octets shall consist of an initial octet and up to four more octets, thus occupying a maximum of five octets. (Note that this restriction does not apply to indefinite length encodings.) 6.2.7 Application layer It is mandatory that the application layer conforms to the architecture for the application layer outlined in ISO9545[8]. Abstract syntax notation one (ASN.1) shall be used as the abstract syntax for specifying application protocols. 6.2.7.1 Supporting ASE It is mandatory that the association control service elements (ACSE) conform to the services and protocols specified in RecommendationsX.217[24] and X.227[25]. The ACSE shall establish, release and abort the associations required. The ACSE service shall operate in the normal mode. Network management transaction oriented applications shall use the common management information service element (CMISE). Services defined by CMISE that are applicable include: 1) the reporting of an event to an OS/MD; 2) the transfer of information between OSs/MDs and NEs; 3) the transfer of action requests and results between OSs/MDs and NEs. 6.2.7.2 Application protocol data units The following application protocol data units shall be supported, as detailed in Table 6-8/G.784. All mandatory parameters defined in RecommendationX.227 [25] for the above APDUs are mandatory for this Recommendation. 6.2.7.3 Abstract syntax name The ACSE abstract syntax name has the ASN.1 type OBJECT IDEN- TIFIER. The following value shall be used to identify the ACSE abstract- syntax-definition: { joint-iso-ccitt association-control(2) abstract-syntax(1) apdus(0) version(1) } 6.2.7.4 Common management information 6.2.7.4.1 Services The common management information service element (CMISE) shall be a mandatory service element. The CMISE service description is detailed in ISO9595[9], ISO9595/DAD1[10] and ISO9595/DAD2[11]. Multiple object selection, filter and multiple reply functional units as defined in ISO9595[9] are optional. Their use is application dependent. The negotiation during association establishment to use or not use the Func- tional Units shall be supported. Support of the extended service functional unit defined in ISO9595 [9] is not required for conformance to this Recommendation and negotiation shall be supported, at association establishment, for its non-use. 6.2.7.4.2 Protocol Implementations shall support those operations defined in ISO9596 [12], ISO9596/DAD1 [13] and ISO9596/DAD2[14] that are required by specific applications. All mandatory parameters defined in ISO9596[12], ISO9596/DAD1[13] and ISO9596/DAD2[14] for the required operations are mandatory parameters for this Recommendation. 6.2.7.5 Remote Operations Service Element (ROSE) Network management transaction-oriented applications shall use the following underlying service defined in RecommendationX.219[26]: û Remote Operations Service Element (ROSE). The protocol is speci- fied in RecommendationX.229[27]. The requirement specified above implies association class 3 in ROSE. 7 EEC Interworking 7.1 Introduction Within the TMN architecture (see Recommendation M.30 [29]), the SMS is a type of local communication network (LCN). Communications between an SMS and OS will take place (optionally) over one or more inter- vening wide-area data communications networks (DCN) and LCNs. There- fore, interworking is necessary between the SMS and either a DCN or another LCN. Interworking may also be necessary between a DCN and an LCN. This section will only specify the interworking between a SMS and DCN. The regenerator section and multiplex section DCCs will use the seven layer, OSI protocol stack specified in º6 and includes the connection- less-mode network protocol (CLNP) that is specified in ISO8473[1]. For the purpose of this Recommendation, the communications on the DCN between the OS and entry point(s) to the SMS will use an OSI protocol stack that includes the X.25[28] connection-mode network protocol (CONP) specified in ISO8208[15] with ISO IP (ISO8473[1]) as an option in the OS. The OSI architecture describes the view that interworking between sub-networks, such as the SMS and DCN, should take place within the net- work layer, with the transport and higher layers operating strictly on a peer- to-peer basis between end systems (SNE and OS). ISO7498[16] specifies that the network layer will provide the transparent data transfer between transport-entities, i.e. end systems, that is independent of the characteristics, other than quality of service, of different sub-networks. This is identified as the routing and relaying function in the network layer. ISO8648[17] speci- fies the OSI principles of interworking within sublayers of the network layer. 7.2 Interworking between the SMS and DCN Interworking between the SMS's CLNP and the DCN's CONP OSI protocol stacks shall be required. Interworking, at the lower layers, between the SMS's and the DCN's OSI protocol stacks shall be based upon ISODTR10172[18]. The ISO interworking PDTR defines an interworking functional unit (IFU) that will perform relaying and/or conversion of PDUs between networks. 7.3 Network layer relay overview The IFU, operating in the NLR mode, would function as a regular intermediate system and is the only OSI compliant method of interworking between end systems with different OSI network protocols. As specified in ISO7498[16] and ISO8648[17], interworking is a network layer function. ISO8473[1] specifies the CLNP and describes an SNDCF that specifies the rules for operating the CLNP over a X.25[28] packet switched network (PSN). The NLR could provide interworking between the SMN and the DCN if both the SMN and DCN operated the ISO8473[1] CLNP and utilized TPclass4 (TP4) connections. The top-level SMS SNE û DCN OS network service would then be connectionless, with the X.25[28] PSN providing an underlying CONP from the IFU to the OS via the DCN. The IFU would examine the destination address of network PDUs (NPDU) received from the SMN and then transfer those CLNP NPDUs (from the SMS) to an appropriate X.25[28] switched virtual circuit (SVC) on the DCN. 8 Operations interfaces 8.1 Q- interface For interconnection with the TMN, the SMS will communicate through a Q-interface having a protocol suite, B1, B2 or B3 as defined in RecommendationG.773[30]. The selection of which of the three protocol suites to adopt is a network provider's decision. 8.2 F-interface For further study. ANNEX A (to Recommendation G.784) Support object, attributes and messages1) A.1 ECC For further study. A.2 Alarms A.2.1 SDH alarm indications Table A-1/G.784 contains a summary of alarm indications required to be available for reporting, if enabled. This information is derived from the anomalies and defects tables in Recommendation G.783. A.3 Performance monitoring A.3.1 SDH data collection Required (R) primitives and parameters are given in Tables A-2/ G.784 and A-3/G.784 respectively. Other parameters are indicated as optional (O). A.3.2 SDH performance monitoring history SDH history requirements are given in Table A-4/G.784. A.3.3 SDH thresholding SDH thresholding requirements are given in Table A-5/G.784. The minimum range for SDH performance thresholds is specified in TableA-6/G.784. Except for bit error ratios (related to CV counts), these ranges are independent of the SDH signal, and for completeness are shown for both required and optional parameters. Parameter counts shall be inhibited under unavailable and alarm con- ditions as detailed in Table A-7/G.784. A.4 Protection switching control For further study A.5 Configuration For further study. A.6 Security For further study. A.7 Testing For further study. A.8 External events For further study. A.9 Software download For further study. A.10 Remote login For further study. A.11 Detailed network model For further study. ANNEX B (to Recommendation G.784) Network layer protocol procedures If it is felt that the administrative procedures for manually inputting routing information is burdensome or no routing information is available, another procedure may be used. This procedure, called broadcast routing, consists of the forwarding of the network protocol data units to all underlying services except the service from which it may have been received. The ISO IP protocol (ISO8473) [1], requires an error message be created when an NPDU is received with an unknown address. The error reporting flag may be set to inhibit error messages. However, this procedure inhibits all error messages and not just routing error messages. It may be utilized, with the loss of some maintenance functionality, at the discretion of the user. ANNEX C (to Recommendation G.784) A mechanism to eliminate routing control administration in the SMS A layer 2 multicast function and a media access (MA) sublayer are intro- duced to eliminate the need for intermediate system functionality at branch points in the SMS. Thus, any SMS, no matter how complex the topology, will consist of one intermediate system (the GNE) and a number of end sys- tems. C.1 Data link layer protocol description The main purpose of the data link layer is to provide a broadcast ser- vice with address filtering, to the network layer. It must achieve this using the underlying SDH DCC network, which is made up from a series of phys- ical point to point links. The data link layer is made up from two sublayers, one controlling logical links and one dealing with media access (see FigureC-1/G.784). FIGURE C-1/G.784 C.1.1 Logical link control (LLC) sublayer description Since the network layer assumes an underlying connectionless mode sub-network, ISO8802 class1 logical link control shall be used. This proto- col needs 3 octets at the start of the LLC PDU: These octets are carried in the media access sublayer information field. C.1.2 Media access sublayer description The description of the media access (MA) sublayer covers three areas, the general operation, the format of various fields and the bit oriented frame structure. The sublayer is based on a combination of the IEEE802.3MAC services plus part of the frame structure and the RecommendationQ.921 HDLC frame structure. The service this sublayer provides is to transfer LLC PDUs from one LLC sublayer entity to a peer LLC sublayer entity, by transporting the LLC PDUs across a physical sub-network, which is made up from SDH NEs con- nected by point to point SDH DCCs. The sublayer uses HDLC framing and the octets shown below are car- ried in the HDLC frame information field: The provision of the NE address is a local matter, but it shall be assigned to a NE prior to initialization. The operation of the sublayer is a combination of address filtering and frame relay. When an MA frame is received at an SDH NE, the following basic algorithm is applied. If the MA destination address (DA) of the received frame matches the MA address of the NE or it is a group address, the HDLC information field is passed to the logical link sublayer. If the MA destination address (DA) of the received frame does not match the MA address of the NE or it is a group address, the frame is sent out on all DCC physical ports, except the one it was received on. C.1.3 HDLC description The purpose of the HDLC frame is to provide a bit structure that can be transmitted to and received from the SDH DCC physical line. It also pro- vides for the removal of corrupted frames using the cyclic redundancy check. Since the frequency of errors on an optical line is so low, it is not effi- cient to perform retransmission of lost frames at this layer. The HDLC frame described in Recommendation Q.921, º 2 shall be used. However, the address (RecommendationQ.921, º2.3) and control (RecommendationQ.921, º2.4) fields shall not be used, because they are redundant. Present hardware will be able to operate with this partial use of HDLC. The fields shall be defined as follows: The HDLC information field length must be at least 529 octets (512+3+14); 512 octets for the NPDU, 3 octets for LLC 1 and 14 octets for the MA address. Two further options in the use of HDLC are outlined in the section entitled ôHDLC optionsö. C.2 Physical layer description The physical layer consists of a point to point connection, between SDH network elements, where it is terminated. The data link PDUs are car- ried in the octets (D1toD3 or D4toD12) of the SDH DCC, which form two clear channels. There is no physical layer signalling protocol associated with this layer. ANNEX D (to Recommendation G.784) Object model overview An information model provides a structured means of describing a portion of the real world that is of interest. Information models use a formal nota- tion and vocabulary for organizing, classifying, and abstracting items. Information is identified in terms of objects. Detailed characteristics of each object are described in terms of attributes and behaviour. Objects with simi- lar properties may be grouped into object classes. Additionally, associations between object instances may be described by relationships. A telecommunications information model provides a means of describing those items used to provide telecommunications services. Such an informa- tion model, applicable to all telecommunications networks, is essential for the consistent management of different types of telecommunications net- works. The SDH information model is a subset of the telecommunications network information model. The SDH information model will allow a manager to obtain the following from an agent regarding those entities for which it is responsible: a) object classes and instances (what the entities are); b) attributes and methods (what they know and how they behave); c) relationships (what they are related to and how they relate). Criteria for evaluating the SDH information model include: 1) Satisfactory management of the transport reference configurations, a subset of which is given in FigureD-1/G.784 below. Test cases are for further study. These test cases should minimally address the network-wide management of paths, as well as the management of equipment. 2) Unambiguous inter-vendor communications, when the reference configurations are provided by equipment from different vendors. 3) Unambiguous inter-operator communications when the reference configurations cross one or more inter-operator boundaries. 4) Ability to generate a unique mapping of the information model to the functional reference model described in RecommendationsG.782 and G.783. 5) Ability to manage the reference configurations in the context of a large network which has many network elements and crosses multi-operator boundaries. 6) Controlled mechanism for extending the information model within the procedures of CCITT. FIGURE D-1/G.784 References [1] ISO 8473 û Information processing systems û Data communications û Protocol for providing the connectionless-mode network service,1988. [2] ISO 8473/AD3 û Information processing systems û Data communica- tions û Protocol for providing the connectionless-mode network ser- vice û Addendum3: Provision of the underlying service assumed by ISO8473 over point-to-point sub-networks which provide the OSI data link service,1988. [3] ISO 8348/AD1 û Information processing systems û Data communica- tions û Network service definition û Addendum1: Connectionless- mode transmission, 1987. [4] ISO 9542 û Information processing systems û End system to intermedi- ate system routing exchange protocol for use in conjunction with ISO8473,1988. [5] ISO 8348/AD2 û Information processing systems û Data communica- tions-Network û service definition û Addendum2: Covering network layer addressing,1988. [6] ISO/IEC 8073 û Information processing systems û Open systems inter- connection û Connection oriented transport protocol specification,1988. [7] ISO/IEC 8073/AD2 û Information processing systems û Open systems interconnection û Connection oriented transport protocol specifica- tion û Addendum2: Operation of class4 over connectionless network service,1989. [8] ISO/IEC 9545 û Information processing systems û Open systems inter- connection û Application layer structure (ALS),1989. [9] ISO 9595 û Information processing systems û open systems interconnec- tion û Common management information service definition (CMIS),1990. [10] ISO 9595/DAD1 û Information processing systems û Open systems interconnection û Common management information service element definition (CMIS), CANCEL-GET. [11] ISO 9595/DAD2 û Information processing systems û Open systems interconnection û Common management information service defini- tion, REMOVE. [12] ISO 9596 û Information processing systems û Open systems intercon- nection û Common management information protocol specification (CMIP),1990. [13] ISO 9596/DAD1 û Information processing systems û Open systems interconnection û Common management information protocol speci- fication, CANCEL-GET. [14] ISO 9596/DAD2 û Information processing systems û Open systems interconnection û Common management information protocol speci- fication, REMOVE. [15] ISO 8208 û Information processing systems û X.25 packet level pro- tocol for data terminal equipment,1987. [16] ISO 7498 û Information processing systems û Open systems inter- connection û Basic Reference model,1984. [17] ISO 8648 û Information processing systems û Open systems intercon- nection û Internal organization of the Network Layer,1988. [18] ISO DTR 10172 û Information processing systems û Data communica- tion network transport protocol interworking specification. [19] CCITT Recommendation û Session service definition for open systems interconnection (OSI) for CCITT applications, Vol.VIII, Rec.X.215 (ISO 8326, 1987). [20] CCITT Recommendation û Session protocol specification for open sys- tems interconnection (OSI) for CCITT applications , Vol.VIII, Rec.X.225 (ISO 8327 û 8327/AD1 û 8327/AD3, 1988). [21] CCITT Recommendation û Presentation service definition for open sys- tems interconnection (OSI) for CCITT applications, Vol.VIII, Rec.X.216 (ISO 8822, 1987). [22] CCITT Recommendation û Presentation protocol definition for open systems interconnection (OSI) for CCITT applications, Vol.VIII, Rec.X.226 (ISO 8823, 1988). [23] CCITT Recommendation û Specification of basic encoding rules for abstract syntax notation one (ASN.1), Vol.VIII, Rec.X.209 (ISO 8825, 1987). [24] CCITT Recommendation û Association control service definition for open systems interconnection (OSI) for CCITT applications, Vol.VIII, Rec.X.217. [25] CCITT Recommendation û Association control protocol definition for open systems interconnection (OSI) for CCITT applications, Vol.VIII, Rec.X.227 (ISOIS8650,1988). [26] CCITT Recommendation û Remote operations: Model, notation and service definition, Vol.VIII, Rec.X.219 (ISO 9072-1,1988). [27] CCITT Recommendation û Remote operations: Protocol specifica- tion, Vol.VIII, Rec.X.229. [28] CCITT Recommendation û Interface between data terminal equipment (DTE) and data circuit terminating equipment (DCE) for terminating operating in the packet mode and connected to public data networks by dedicated circuit, Vol.VIII, Rec.X.25 (ISO8208,1984 and ISO7776,1986). [29] CCITT Recommendation û Principles for a telecommunications man- agement network (TMN), Vol.IV, Rec.M.30. [30] CCITT Recommendation û Protocol suites for Q-interfaces for manage- ment of transmission equipment, Vol.III, Rec.G.773. [31] CCITT Recommendation û ISDN User-network interface û Data link layer û General, Vol.VI, Rec.Q.920. [32] CCITT Recommendation û ISDN User-network interface û Data link layer û Specification, Vol.VI, Rec.Q.921. INTERNATIONAL TELECOMMUNICATION UNION CCITT G.784 THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE GENERAL ASPECTS OF DIGITAL TRANSMISSION SYSTEMS; TERMINAL EQUIPMENTS SYNCHRONOUS DIGITAL HIERARCHY (SDH) MAN- AGEMENT Recommendation G.784 Geneva, 1990 FOREWORD The CCITT (the International Telegraph and Telephone Consultative Committee) is a permanent organ of the International Telecommuni- cation Union (ITU). CCITT is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The Plenary Assembly of CCITT which meets every four years, establishes the topics for study and approves Recommendations pre- pared by its Study Groups. The approval of Recommendations by the members of CCITT between Plenary Assemblies is covered by the procedure laid down in CCITT Resolution No. 2 (Melbourne, 1988). Recommendation G.784 was prepared by Study Group XV and was approved under the Resolution No. 2 procedure on the 14 of December 1990. ___________________ CCITT NOTE In this Recommendation, the expression ôAdministrationö is used for conciseness to indicate both a telecommunication Administration and a recognized private operating agency. πITU1990 All rights reserved. No part of this publication may be reproduced or uti- lized in any form or by any means, electronic or mechanical, including pho- tocopying and microfilm, without permission in writing from the ITU.