============================================================ Question 1/VII - Standardization of the technical characteristics of user classes of service, international data transmission services and optional user facilities in public data networks (PDNs) and ISDNs and the categories of access for DTEs to such services (Amalgamation of Questions 1/VII and 2/VII studied in 1985-88) considering (a) that Recommendations X.1, X.2, X.4 and X.10 define the requirements of international data transmission services; (b) that PDNs and ISDNs are used to provide data transmission services; (c) that harmonization of supplementary services provided by the different types of network is important; (d) that studies are continuing into the interworking between different types of service (e.g., packet-switched and circuit-switched); (e) that a possible reorganization of Recommendations X.1 and X.10 is desirable in order to clarify the requirements; (f) that Study Group I is responsible for the definition and operational aspects of public data transmission services; (g) that Study Group III is responsible for tariff aspects of public data transmission services; (h) that Study Group XVIII is responsible for ISDN, What additional user classes of service, categories of access, services, DTE services and facilities, if any, should be standardized? Note 1 - The possible definition of DTE services and the applicability of the various optional user facilities for classes of service 8-13 in the case of switched connection to a PAD should be studied. Note 2 - Other matters relevant to Recommendations X.1, X.2, X.4 and X.10 should be considered. Note 3 - The deletion of unnecessary requirements should be considered. Note 4 - Liaison with Study Groups I, III and XVIII as appropriate should be undertaken. ============================================================ Question 2/VII - Call progress signals (continuation of Question 3/VII studied in 1985-88) considering (a) that public data transmission services are provided by PDNs and ISDNs with the various categories of access defined in Recommendation X.10; (b) that Recommendations X.1, X.2, X.4, X.10, X.21, X.25, X.28, X.29, X.30, X.31, X.32, X.75, X.96 and X.301 define all the requirements for the implementation of the international public data transmission services, What call progress signals for PDNs should be added to, or deleted from Recommendation X.96? Note - Any necessary clarification of call control signals should be considered. ============================================================ Question 3/VII - Technical characteristics of connectionless services in public networks (continuation of Question 4/VII studied in 1985-88) considering (a) that Recommendation X.327 defines the general arrangements for interworking between Packet Switched Public Data Networks (PSPDNs) and private data networks for the provision of data transmission services; (b) that ISO has developed OSI Connectionless Network Service; (c) that certain applications (e.g. point-of-sale, telemetry) do not utilize some typical features of connection-orientated services such as network provided sequence control, error recovery, or protection against loss or duplication of data; (d) that certain applications may need network-provided multicast services; (e) that there exists a "fast select" facility in Recommendation X.25 which is an essential facility; (f) that there may exist a need for internationally standardizing the network services to support applications of the types defined above; (g) that Study Group I is responsible for the definition and operational aspects of data transmission services, What additions to existing Recommendations or new Recommendations are required to specify the service(s) and interface(s) related to the above considerations? Question 4/VII - Network performance and Quality of Service in Data Communications Networks (continuation of Question 29/VII, studied in 1985-88) considering - that administrations and users each have an interest in ensuring that a good "Quality of Service" is provided on data communications networks; - that good "Quality of Service" is, in part, a consequence of good "network performance" in data communications networks; - that standard definitions for performance parameters are necessary for consistent evaluation of network performance; - that performance objectives and limits are necessary to ensure good network performance; - that for evaluating network performance, it is useful to define the conditions under which such objectives and limits should be measured; - that for comparing the network performance of several networks, it is useful to describe the conditions under which the performance descriptions apply; - that users' perceptions of network performance depend on how they interface with a service; - that users' needs for network performance depend on their applications; - that Recommendation X.140 defines general quality of service parameters; - that Recommendations X.130 and X.131 define network performance parameters and objectives for Circuit Switched Public Data Networks (CSPDNs); - that Recommendations X.134, X.135, X.136 and X.137 define network performance parameters and limits for Packet Switched Public Data Networks (PSPDNs); - that Study Group II is involved in the study of broad aspects of Quality of Service; the following topics should be studied: 1. Performance measurement How should the data communications network performance parameters in Recommendations X.130, X.131, X.135, X.136 and X.137 be measured? To assure consistency and compatibility of results: -how should statistically sound measurement programmes be designed? -what are the factors that influence the measured values (e.g., what is the meaning of the "busy hour" for data communications networks)? -what information should be included when reporting network performance? 2. Objectives and limits What objectives and limits should be assigned to the data communications network performance parameters in Recommendations X.130, X.131, X.135, X.136 and X.137? To assure a good network performance and Quality of Service: -to supplement the worst-case limits and to provide further guidance to network providers and users, what objectives should be established in Recommendations X.135, X.136 and X.137? -with regard to improvements in technology, how should the objectives and limits in Recommendations X.130, X.131, X.135, X.136 and X.137 be adjusted for the 1992-1996 time period? -what are the different Quality of Service needs for different data communications applications and what are the levels of network performance that support those needs? 3. Parameter relationships In order that users understand the relationships among the performance of their communications services, what are the relationships: -between the X.140 quality of service parameters for data networks and other general quality of service parameters and performance description frameworks for communications networks? -between the X.140 quality of service parameters and the PSPDN and CSPDN parameters defined in Recommendations X.130, X.131, X.135, X.136 and X.137? -between the X.140 quality of service parameters and the network performance parameters developed for ISDN, X.28 and X.32? -between throughput class as described in other Recommendations (e.g., X.25, X.75, etc.) and throughput parameters as defined in Recommendation X.135? What network performance parameters, objectives and limits should be recommended for the following interworking arrangements: -PSPDN/ISDN, - CSPDN/ISDN, - X.28 access to PSDNs, - X.32 access to PSPDNs? 4. Performance with Open Systems Interconnection (OSI) Systems -What is the quality of layer 1 bearer services required to ensure satisfactory PSPDN performance? -What is the relationship between signalled quality of service parameters and actual performance received? -What relationships exist between OSI layer service performance parameters and network performance? -How can the performance parameters defined in the various OSI layer service definition standards be interrelated? 5. How should the CSPDN performance parameters be clarified? -What are the allocation boundaries and what are the specific reference events that should be used in defining and allocating CSPDN performance? -What network performance parameters should be recommended for CSPDNs for the following areas? i) speed of service; ii) accuracy and dependability; iii) service availability; -What objectives and limits should be assigned to the CSPDN performance parameters and how do these values depend on different data communications applications? 6. Coordination with other Study Groups 6.1 The network performance models and parameters identified for data communications networks bear a close relationship with many of the models and network performance parameters appropriate for ISDNs. The studies of network performance in data communications networks should therefore be carefully coordinated with the studies in ISDN (Study Group XVIII). 6.2 The network performance models and parameters identified for PSPDNs are generally applicable to advanced packet technologies such as fast packet switching, frame relaying, and broadband ISDN. Close liaison should be maintained with those responsible for standardizing the advanced packet technologies (Study Group XVIII). 6.3 The quality of service parameters defined for data networks in X.140 are closely related to the general quality of service parameters being developed in Study Group II. Close liaison with that work should be maintained. 6.4 Close liaison should be maintained with those responsible for standardizing data communications network monitoring and maintenance (Study Group IV). Question 5/VII - Testing and verification of data communication protocols (continuation of Question 47/VII studied in 1985-88) considering (a) that Recommendation X.290 defines the general framework and methodology for the testing and verification of implementations of the X- and T-Series of the OSI protocol Recommendations; (b) that there is a need to develop standardized test suites for protocol Recommendations as a means to increase the probability of interworking; (c) that the area of ISDN is of greater importance for administrations; (d) that there is a need to continue collaborative work with ISO on conformance testing, and maintain alignment with ISO, if necessary, by appropriate means; (e) that the rules for cooperation between lower and upper testers during testing will be necessary, 1. What steps should be taken to achieve the standardization of test suites for OSI protocol Recommendations and the alignment of the conformance sections of these Recommendations with the methodology? 2. Which means are the most appropriate to manage and maintain in an efficient way CCITT manuals containing conformance test suites, given the specifics of these documents? 3. What is the need for testing and the applicability of Recommendation X.290 in the area of ISDN? (To be studied in liaison with Study Group XVIII.) 4. Which Test Management Protocol should be specified? ============================================================ Question 6/VII - Further study on Recommendations for DTE/DCE interfaces for circuit switched service (X.20, X.20bis, X.21, X.21bis, X.22) and study on access to the CSPDN through telephone networks (continuation of Question 6/VII studied in 1985-88) considering - that categories of access for data transmission services and facilities will be modified or enhanced; - that interworking between networks is requested; - that access to CSPDN through telephone networks is requested; - that the provision of the OSI-NS is requested; - that for purposes of conformance testing a more formal protocol description is required; it is necessary to study the following: - refinement of the DTE/DCE interface Recommendation for circuit switched service following their implementation in public data networks; - the enhancement/alignment of the DTE/DCE interface Recommendation for circuit switched service of the OSI model; - the separation of the network service functions between call control phase and data transfer phase; - implication of the provision of a V.25bis serial automatic dialling function on X.20bis and X.21bis DTEs; - the enhancement catering for reservation circuit switched service; - the protocol aspects of management functions; - further work on Annex 1 for access to a CSPDN through telephone networks; - the specification of the protocol using an FDT. ANNEX 1 (to Question 6/VII) Recommendation X.33 PROCEDURES AND ARRANGEMENTS FOR DATA TERMINAL 1.2 This Recommendation------------------------------------------ 3. Timing problem----------------------------------------------- 3.2.2.2 Operation in PSTN DTE side 3.3.1.2 Operation in IWU------------------------------------ 4.2.2 Circuit 106 (ready for sending) control 5.2.3 If the IWU--------------------------------------------- 7.2.2 In order to use existing X.21---------------------------------- 9. Modem type selection APPENDIX 1 (to Recommendation X.33) TABLE I-1/X.33 Examples of possible V-series interfaces ============================================================ Question 7/VII - Further study of DTE/DCE interfaces for terminals operating in the packet-mode (continuation of Question 7/VII studied in 1985-88) considering (a) that Recommendation X.25 specifies the DTE/DCE interface for terminals operating in the packet mode and connected to a public data network by dedicated circuits; (b) that Recommendation X.10 specifies the different methods of accessing a packet-switched data transmission service; (c) that Recommendation X.32, in addition to Recommendation X.25, defines the DTE/DCE interface for terminals operating in the packet mode and accessing a Packet-Switched Public Data Network through the Public Switched Telephone Network or a Circuit-Switched Public Data Network, or an Integrated Services Digital Network; (d) that Recommendation X.31 (support of packet mode terminals in an ISDN) includes the use of the X.25 protocol for packet mode operation through the ISDN; (e) that ISO/IEC JTC 1/SC 6 has developed standards at link and packet layers which are compatible with Recommendation X.25; (f) that networks and DTEs conforming to Recommendation X.25 have been in operation for several years, and that their number is increasing; (g) that Recommendation X.25 provides the Network Service defined by ISO and CCITT (Recommendation X.213); (h) that Recommendation X.223 describes the use of X.25 to provide the OSI connection mode network service, 1. What enhancements and additions to Recommendation X.25 should be defined, keeping in mind points e), f), g), and h) above? Aspects to be covered include: 1.1 Inclusion of procedures for additional user facilities defined (or which may be defined) in Recommendation X.2. In particular, direct call for packet mode terminals is for further study in X.2. 1.2 Consideration of the inclusion of an asynchronous mode of delimitation for X.25 and X.32, as an alternative to the current synchronous mode. This study should be conducted in liaison with Study Group XVII. 1.3 Consideration of the accommodation of throughput classes higher than those presently defined in X.25, that would be needed for access to PSPDNs or other applications of the X.25 Packet Layer Protocol. 2. What additions and changes to Recommendation X.32 should be required? In particular, the security aspects of X.32 should be further investigated, in relation with work on security and authentication undertaken in CCITT and ISO. 3. What enhancements to existing Recommendations (e.g. X.25, X.32) are needed to define the DTE/DCE interface at reference point R on the ISDN for a terminal in the packet mode accessing a packet switched data transmission service? This study should be based on the input from Questions 30 and 31/VII and carried in cooperation with Question 30/VII during the study period 1989-1992. Alignment should be aimed between the various ways of accessing a packet switched data transmission service (i.e. through PSTN, CSPDN or the ISDN). 4. What additions and changes to Recommendation X.223 should be required? In particular, this study should be based on the input from Question 27/VII on the enhancements of the OSI Network Service. Close cooperation with ISO/IEC JTC 1/SC6 on this point is required. 5. A potential addition to X.223 is attached as Annex 1 to this Question. Close cooperation with ISO/IEC JTC 1/SC6 and with Questions 30 and 31/VII on the provision of the OSI network service by packet mode terminal equipment connected to an ISDN for CCITT applications is required, to ensure compatibility with Recommendation X.223. 6. The feasibility of producing a standard set of procedures to test the conformances at a DTE with Recommendation X.25 should be studied with the view toward creating a Recommendation. This work should be conducted in close cooperation with ISO/IEC JTC 1/SC6. 7. The feasibility of producing a Recommendation describing X.25 data terminal equipment procedures for CCITT applications should be studied. This work should be conducted in close cooperation with other CCITT Study Groups and with ISO/IEC JTC 1/SC6. 8. What additional protocol or protocol elements, if any, are necessary in packet switched public data networks (PSPDNs) to support the addressing aspects of the OSI network service? In particular, it is for further study (see Question 27/VII) how to derive an address by which PSPDNs route from an OSI NSAP address. Work is to be done, based on input from and in cooperation with Question 27/VII, on the definition of any additional protocols or protocol elements to be used by the DTE and either supported by or carried transparently by PSPDNs for the above derivation. ============================================================ Question 8/VII - Study of DTE-DCE interface procedures for dissimilar terminal interworking (Continuation of Question 8/VII studied in 1985- 1988) considering (a) that administrations recognize the interest that some users would have in interworking between different terminals; (b) that the technical feasibility and economics of such interworking must be established before a user requirement can be determined, What are the interface requirements for data communications between dissimilar DTEs? 1. Study should include the following points relating to enhancement and extension of Recommendations X.3, X.28 and X.29: 1.1 PAD-to-PAD. Realizing that work has progressed over the last study period in this area, what additional procedures are needed (or enhancement to the existing ones) in Recommendation X.28 to fully accomplish this interworking? 1.2 Definition of the function of character 0/10 (FE). Recommendation V.3 provides for character 0/10 to be used as Line Feed (LF) or New Line (NL). The need for a new parameter which allows for this alternative use should be studied. Study should include the characters to be echoed. 1.3 Establishment of the access information path by the PAD in response to an incoming call or direct call from the remote DTE. The following item remains identified as open and should be considered: -automatic speed and code detection by the PAD if speed and code are not specified by facilities in the incoming call packet. 1.4 Establishment of the access information path for a start-stop mode DTE to a PAD via a PSTN. The following points should be considered: -speed and parity detection; -use of NUI; -disconnecting the access information path after call clear. 1.5 What happens to an incoming call when the interface is not in the PAD waiting state? 1.6 Various timers have been identified in the operation of the PAD (as found in the appendix to Recommendation X.20). Further definition and values for those timers currently undefined needs to be studied. In addition, this should include the definition of a time-out for the waiting for command state (state 10) so that the characters are received from the DTE. 1.7 Are there any mechanisms to increase PAD command handling efficiency? Study should include the concept and support of an operator sending more than one PAD command continuously (e.g. the PAD command and the selection PAD command continuously). In addition, functions such as type-ahead and overlap should be considered. 1.8 Expansion and enhancements to Recommendation X.25 have taken place during the last study period. What additional procedures (and/or parameters) should be added to the PAD Recommendations to take advantage and support the changes to Recommendation X.25? 1.9 While work has been done in adding access rates at higher speeds to the PAD, additional higher speeds may be necessary. 1.10 Recommendation X.2 provides for a variety of facilities: -call redirection notification; -call redirection and deflection; -local charging prevention; -fast select; -direct call; -hunt group; -on-line facility registration; -flow control parameter negotiation; -throughput class negotiation. Since additional facilities may enhance the PAD service, what new procedures (and/or parameters) need to be added to the PAD Recommendations to support them? 1.11 What new PAD procedures need to be defined in the PAD Recommendations to support permanent virtual circuits? 1.12 What support can the PAD give for escape sequences as used by the start-stop mode DTE (such as those conforming to ISO 2022), and how can the PAD be prevented from sending or echoing the undesired escape sequences? 1.13 Should the PAD send DC1 (XON) if the value of parameter 5 is changed from 1 to 0 when the interface is in XOFF state? 1.14 What new PAD procedures need to be defined to enable more flexibility in the page wait function when used in conjunction with manual page control? Study should include having control of the page wait service signal being independent from the control of the other PAD service signals. 1.15 Which link protective protocol needs to be supported to provide an error protected access to the PAD? (This is especially required for DTEs operating automatically and in applications such as file transfer via the PAD.) The possibility of implementing the protocol either in the PAD or in the PAD modem or similarly, within the start-stop mode DTE or the DTE modem, should be studied. Existing CCITT Recommendations (e.g. using a LAP-based protocol such as LAPB or LAPD) should be considered to improve quality and the wide-spread use of these protocols. Close liaison is necessary with the work on error-control modems in Study Group XVII. See also annexes to this Question. 2. Study should include the following points relating to the provision of the Packet Assembly/Disassembly (PAD) facility for Group 3 facsimile terminals: 2.1 What new parameters in the existing PAD Recommendations and/or new Recommendations are needed to enable this service? 2.2 What new procedures are needed to transfer the control information and document data defined in Recommendation T.30 between a PAD providing this service and a packet mode DTE or another PAD? 2.3 What new parameters and/or Recommendations are needed to provide access to this service? 3. Depending upon the conformation of service requirements, study should include the following points relating to the provision of the Packet Assembly/Disassembly (PAD) facility for other non-packet mode DTE: 3.1 What procedures are required for interworking between dissimilar terminals utilizing other procedures for data interchange? Study should include DTEs operating as follows: -basic control procedure; -under an ISDN; -asynchronous as well as synchronous (not covered by Recommendation X.21) block mode. Alternatives such as mapping from a terminal specific protocol to CCITT Recommendations should also be considered. What new parameters and/or Recommendations are needed to enable this service? ANNEX 1 (to Question 8/VII) SOURCE: COM VII-R 17, ANNEX 5, APPENDIX 6, ATTACHMENT 1, OCTOBER 1986 TITLE: LINK PROTECTIVE PROTOCOLS UNDER CONSIDERATION The protocol described in Delayed Contribution D.10 has the advantage that it allows ordinary asynchronous character oriented operation without any special precaution. There is not even a need to switch from character mode operation to block mode operation, therefore, neither is there for a switching procedure between the two. This allows the design of a block mode PAD including the normal asynchronous operation or, what is the same, the inclusion of the block mode operation in the X.28 PAD as an extension (see also Delayed Contribution D.9). For this characteristic to be achieved it is necessary to process in the PAD the control characters and character strings used by the block mode protocol in the "control state" (see D.10, 3.1.2). These characters and strings are given here once more as follows: STX 0/2 DLE STX 1/0, 0/2 ENQ 0/5 DLE ENQ 1/0, 0/5 EOT 0/4 DLE EOT 1/0, 0/4 ACK 0 1/0, 3/0 ACK 1 1/0, 3/1 ACK 0/6 NAK 1/5 WACK 1/0, 3/11 The only character of the above which is used in the X.28 PAD is DLE. It can be used to escape from the data transfer state. Two possibilities exist to overcome this problem: 1) As the character to escape from the data transfer state can be defined by parameter 1, another character could be used as default. 2) As DLE is used in the "control state" of the block mode link layer protocol only in conjunction with other control characters (i.e. ENQ, EOT and STX), it could also be processed only in this sequence and used as escape signal when appearing in any other combination. This then would not interfere with the X.28 PAD (see also X.28, 4.9.1., pt. d)). To allow maximum compatibility, the options left open in the block mode protocol (parameter settings) should be controlled by non-blocked command strings, i.e., the same way as for the X.28 PAD. These options and parameters still are to be defined. Summary To sum up, the following characteristics can be assigned to the protocol described in Delayed Contribution D.10 (of the Geneva meeting 1985): -compatibility with the X.28 PAD through the possibility of character mode and block mode operation; -error detection and correction; -simplicity of implementation; -asynchronous transmission; -octet orientation; -full duplex operation and half duplex operation possible; -transparent transmission possible; -split speed transmission possible; -flow control. ANNEX 2 (to Question 8/VII) SOURCE: ISO/IEC JTC1/SC6 N 4842 TITLE: PROGRESSION OF WORK ON START/STOP FRAMING MODE TRANSMISSION OPERATION OF HDLC PROTOCOLS - - - - - - - - - - - - - - - - - The attached documents have been distributed to SC6 Member Bodies for ballot as Proposed Draft Addenda to ISO 3309, 4335, 7809, and 8885 to add an optional capability for use of HDLC protocols in Start/Stop transmission environments. SC6 welcomes comments on the technical content of these addenda. SC6 is particularly interested in the suitability of the proposed mechanism for use in various applications. For example, suggestions have been made that the mechanism be enhanced to work in transmission environments which convey only seven data bits (and possibly a parity bit) between start and stop bits. Comments related to other special requirements are encouraged. The next meeting at which these matters will be considered is the ISO/IEC JTC1/SC6/WG1 meeting in Copenhagen, Denmark, 19-23 September 1988. Attachments: Proposed Draft Addenda to ISO 3309, 4335, 7809, and 8885 ============================================================ Question 9/VII - Principles of maintenance in user-network interfaces for public data networks (continuation of Question 25/VII studied in 1985- 1988) considering (a) that public data networks utilizing Recommendations X.20, X.20bis, X.21, X.21bis, X.22, X.25 and X.32 are being implemented; (b) that Recommendations X.30 and X.31 define the Terminal Adaptor (TA) functions to adapt circuit switched and packet switched X-Series DTE/DCE interfaces to ISDN; (c) that Recommendation X.150 defines the principles of maintenance testing using DTE and DCE test loops and details of maintenance testing using DTE and DCE test loops are described in the individual DTE/DCE interface Recommendations; (d) that Recommendation G.704 defines the maintenance mechanisms for digital networks, I.600-Series Recommendations define ISDN subscriber access and installation maintenance, and that Q.940-Series Recommendations define ISDN user-network management interface; (e) that the maintenance of public data networks are under the responsibility of administrations and operating agencies, and that maintenance principles must be harmonized in order to: -provide, as far as possible, the same maintenance of customer services, -define maintenance principles on international sections between two public networks; it is necessary to study the following: 1. What principles for fault locating and maintenance testing for PDN DTE/DCE interfaces and TA defined by X.30 and X.31 are required in addition to the existing ones? 2. What features must be harmonized to result in common management services for subscribers? 3. What differentiation would be appropriate between each layer management and system management at layer 7? 4. How can OSI management be used? 5. What management objects for PDN need to be defined based on common management from work specified by Question 24/VII. 6. What other management aspects (e.g. accounting, configuration and security control) in addition to maintenance should be studied? Note 1 - Close cooperation with the relevant Questions in this Study Group (OSI reference model and higher layer protocols) on OSI management is expected. Note 2 - Close cooperation with Study Groups regarding TA in ISDN is to be established. Note 3 - Close cooperation with Study Groups on telecommunication management is to be established. ============================================================ Question 10/VII - General technical principles for interworking between public networks or between public networks and other networks for the provision of data services (continuation of part of Question 10/VII studied in 1985-1988) considering (a) that the provision of data services may require several networks to interwork; (b) the framework of X-Series Recommendations related to interworking given in Recommendation X.300; (c) that the CCITT studies several types of networks for the provision of data services; (d) that consequently many interworking scenarios have been and continuously will be identified for the purpose of interworking; (e) that general principles are needed to study these scenarios and that Recommendation X.300 already defines such principles; (f) that Recommendation X.305 specifies how different networks relate to the provision of the OSI NS end-to-end; What further additions to existing Recommendations X.300 and X.305, or new Recommendations, if any, are required to define general principles for interworking for the provision of data services? This study should include: -possible enhancements or new descriptions of existing or new interworking scenarios and the abstract/functional requirements resulting from these scenarios; -general principles on service indications and compatibility checking, based on the work done during the 1985-1988 study period (see Annex 1); -resulting from above points, general guidelines for detailed descriptions of interworking cases; -further alignment of the representation of network elements in Recommendation X.300 and for example X.31 and X.122 (e.g. PH/AU/IWF). Question 11/VII - Arrangements generic to different interworking (circuit and packet modes) between public networks or between public networks and other networks, for the provision of data services (continuation of part of Question 10/VII studied in 1985-1988) Considering (a) that the provision of data services may require several networks to interwork; (b) the framework of X-Series Recommendations related to interworking given in Recommendation X.300; (c) that X.300 defines general principles for interworking for the provision of data services and provides for a structure for interworking scenarios; (d) that X.301 defines general principles for call control within and between subnetworks, independent of the protocol-type that is used; (e) that there is a continuous need to identify further details or aspects for such call control that new types of subnetworks are emerging, What further additions to existing Recommendations X.301, X.180 and X.181, or new Recommendations are needed, if any, to define general principles for call control between and within subnetworks for the provision of data transmission services? This study should include: -new emerging aspects of call control (e.g. addressing, optional user facilities,...); -between the I.250-Series and X.301 alignment, where needed. ============================================================ Question 12/VII - Management aspects of interworking between public networks, and between public networks and other networks, when involved in the provision of data services (amalgamation of Question 23/VII, Question 26/VII and part of Question 10/VII) Considering (a) that the provision of data services may require several networks to interwork; (b) the framework of X-Series Recommendations related to interworking given in Recommendation X.300; (c) that Recommendations X.300-Series define general principles for interworking between public networks, or between public networks and other networks for the provision of data services; (d) that Recommendation X.370 defines interworking of management information; (e) that Recommendations X.50, X.50bis, X.51, X.52, X.53, X.54, X.60, X.61, X.70, X.71, X.75, X.81 and X.82 define detailed interworking interfaces of public networks; (f) that the I.600-Series Recommendations define maintenance in ISDN; (g) that Recommendations X.200-Series define OSI reference model, service definitions and protocols; (h) that Recommendations M.30 and G.771 define a telecommunication management network; (i) that the maintenance of public networks are under the responsibility of administrations and operating agencies, and that maintenance principles must be harmonized in order to: -provide, as far as possible, the same maintenance of customer services, -define maintenance principles on international sections between two public networks it is necessary to study the following: 1. What should be the maintenance and operation principles of an international section? 2. What would be the requirements for OSI management from a public network point of view? 3. What differentiation would be appropriate between each layer management and system management at layer 7? 4. What management objects for public networks need to be defined based on common management from work specified by Question 24/VII? 5. What management features specific to public networks are needed in addition to common OSI management? 6. What kind of interworking between public network exchanges and a management center? 7. What relation to telecommunication management networks should be achieved? 8. What other management aspects (e.g. accounting and configuration control) in addition to maintenance should be studied? 9. What enhancements to existing Recommendations X.302 and X.370, or new Recommendations are needed, if any, to cover points above? Note 1 - Close cooperation with the relevant Questions in this Study Group (OSI reference model and higher layer protocols) on OSI management is expected. Note 2 - Close cooperation with other Study Groups on ISDN maintenance and telecommunication management network is to be established. ============================================================ Question 13/VII - Interworking between public data networks (circuit switched and packet switched) and ISDNs, and between ISDNs, for the provision of data services (amalgamation of Questions 13/VII and 14/VII studied in 1985-1988) Considering (a) that the provision of data services may require several networks to interwork; (b) the framework of X-Series Recommendations related to interworking given in Recommendation X.300; (c) that administrations are currently operating Circuit Switched and Packet Switched Public Data Networks (CSPDNs and PSPDNs); (d) that administrations are planning operation of Integrated Services Digital Networks (ISDNs); (e) that CSPDNs, PSPDNs and ISDNs will coexist and each provide data transmission services; (f) that interworking between DTEs connected to each of these networks is considered essential for the provision of data transmission services; (g) that Recommendation X.300 defines general principles for interworking between public networks, and between public networks and other networks for the provision of data transmission services; (h) that Recommendation X.320 defines general arrangements for interworking between ISDNs for the provision of data transmission services; (i) that Recommendation X.321 defines general arrangements for interworking between CSPDN and ISDN for the provision of data transmission services; (j) that Recommendation X.325 defines general arrangements for interworking between PSPDN and ISDN for the provision of data transmission services; (k) that Recommendation X.81 defines interworking between an ISDN circuit-switched and a CSPDN; (l) that Recommendation X.30 defines support of X.21 and X.21bis based DTEs on an ISDN; (m) that Recommendation X.31 defines the method of supporting X.25 based DTEs on an ISDN, 1. What additional Recommendations, if any, are necessary to enhance interworking between public data networks CSPDN, PSPDN and ISDN or between ISDNs for the provision of data transmission services? 2. What additions or modifications to existing Recommendations are necessary? Note - It is necessary to work these interworking issues in close cooperation with other groups, particularly the ISDN related groups in Study Groups XI, XVII and XVIII. ============================================================ Question 14/VII - Interworking between public data networks and the telex networks (continuation of Question 19/VII studied in 1985-88) Considering (a) that administrations are currently operating PDNs and the telex network; (b) that Study Group VII has the responsibility for studying the definitions and procedures for interworking between PSPDNs and the telex network; (c) that Recommendation F.73 gives the operational and service principles for communication between terminals on the telex network and data terminal equipment on a packet switched public data network, 1. What new Recommendation(s), and additions or modifications to existing Recommendation(s) are necessary to enable PSDNs to interwork with the telex network for interworking involving both communication and transmission capability? Draft Recommendation X.340 which gives the principles for this type of interworking should be the basis for further study on the subject, and is reproduced in Annex 1. The following topics have been identified: a) satisfying the service requirements described in Recommendation F.73; b) compatibility with the technical requirements for the telex network described in draft Recommendation U.203; c) use of alternative forms of conveying telex numbers in accordance with X.121; d) the method of break handling may be optional and enhanced to cover counterwriting; e) permit use of command and service signals; f) the need for explicit X.29 protocol identifier; g) network options for packet forwarding criteria; h) possible translation of WRW to ENQ and inhibiting IWF Answerback prior to connection phase; i) other mechanisms to indicate that the IWF is no longer able to accept additional characters; j) determination of an X.3 parameter profile and identification of which parameters should be changeable. 2. Is there a need for PSPDN to telex interworking involving communication capability? If so, what new Recommendation(s), and additions or modifications to existing Recommendation(s) are necessary? 3. Is there a need for CSPDN to telex interworking? If so, what new Recommendation(s), and additions or modifications to existing Recommendation(s) are necessary? 4. The following liaisons should be maintained in this study: a) general principles and arrangements for interworking between PDNs and between PDNs and other public networks are being studied in Study Group VII; b) procedures to be used on the telex network are being studied in Study Group IX; c) service principles for interworking are being studied in Study Group I. ANNEX 1 (to Question 14/VII) ============================================================ Question 15/VII - Arrangements for interworking between networks other than ISDNs and Telex, for the provision of data services (amalgamations of Questions 15/VII, 16/VII, 17/VII and 18/VII studied in 1985-88) Considering (a) that the provision of data services may require several networks to interwork; (b) the framework of X-Series Recommendations related to interworking given in Recommendation X.300; (c) that X.300-Series Recommendations define general principles and arrangements for interworking between public networks or between public networks and other networks for the provision of data services; (d) that X.60 and X.70-Series Recommendations define detailed internetwork signalling; (e) that X.80-Series Recommendations define detailed interworking functions, 1. What enhancements should be made to Recommendations: X.322, X.324, X.326, X.327 X.350, X.351, X.352 X.82 2. What new Recommendation(s), if any, are necessary to describe arrangements for interworking between networks of different types, other than ISDNs and Telex, including CSPDN, PSPDN, CCSN, private networks and mobile systems. ANNEX 1 (to Question 15/VII) Further details on the study of interworking between public data networks (PDNs) and public mobile systems Considering (a) that administrations are currently operating PDNs (like circuit switched and packet switched PDNs); (b) that there is a need to define the specific requirements for interworking between PDNs and Public Mobile Systems; (c) that Recommendation X.300 defines general principles and arrangements for interworking between PDNs and between PDNs and other public networks for the provision of data transmission services; (d) that Recommendation X.324 considers the general arrangements for interworking between PSPDNs and public mobile systems for the provision of data transmission services; (e) that procedures for interworking between PDNs and the Maritime Satellite Service are defined in Recommendations X.350, X.351, X.352, and X.353; (f) that Recommendation X.32 specifies the procedures for DTEs operating in the packet mode and accessing a PSPDN through a public switched network; (g) that the mobility of the terminals connected to the Public Mobile System may require specific functions within the PDNs (e.g. registration of location, registration of desired facilities, transfer of charging data between PDNs, etc.); (h) that Recommendation X.213 specifies the OSI Network Service and that the interworking between PDNs and Public Mobile Systems should enable the provision to users of the OSI Network Service; (i) that Recommendation E.212 contains an international identification plan for land mobile stations; (j) that Recommendation Q.1001 contains a comprehensive list of definitions related to public land mobile networks (PLMNs), What Recommendations, if any, are necessary to enable interworking between PDNs and Public Mobile Systems? What additions or modifications to existing Recommendations are necessary? Note 1 - The following liaisons should be maintained in this study: a) the general principles and arrangements for interworking between PDNs and between PDNs and other public networks are being studied under Question 10/VII; b) operational requirements, including routing numbering and identification plans for public land mobile systems as studied by Study Group II for interworking with the PSTN; c) interworking between public land mobile systems and Signalling System No.7 is studied by Study Group XI; d) the study of DTEs accessing a PDN through a public switched network is carried out under the relevant DTE interface Question 16/VII; e) for interworking between Public Mobile Systems transfer of registration and charging data could be required. The applicability of using the Common Channel Signalling System for this purpose will be studied by Study Group XI. Note 2 - The study should cover some possible specific requirements related to the mobility of the terminals connected to the Public Mobile System: -call diversion to a number in the PDN; -rerouting of calls when the mobile station roams between various Public Mobile Systems; -hand-over of calls when the mobile station moves from one base station area to another within a Public Mobile System; -procedures for obtaining routing information from the Public Mobile System prior to setting up the call (interrogation procedures). Note 3 - The study should cover the possible specific requirements related to new mobile satellite services such as Aeronautical and Land mobile satellite services. ANNEX 2 (to Question 15/VII) Further details on the study of interworking between Public Data Networks (PDNs) and private data networks Considering (a) that administrations are currently operating PDNs such as PSPDNs and CSPDNs; (b) that different interworking conditions may exist between private networks and PDNs; (c) that Recommendation X.25 defines the user interface to packet switched PDNs and Recommendations X.21/X.21bis specify the user interface to circuit switched PDNs. In this respect, it should be noted that the suitability of such user interfaces for interworking with private networks has already been considered by Study Group VII and will still be taken into account; (d) that PDNs operate a Network Address Extension mechanism which could be applied in private networks connected to a PDN; (e) that Recommendation X.300 defines general principles and arrangements for interworking between public networks, and between public networks and other networks for the provision of data transmission services; and that these principles may apply in the case of interworking between PDNs and private networks; (f) that Recommendation X.213 specifies the OSI Network Service and that interworking between Private Networks and PDNs should enable the provision to users of the OSI Network Service; (g) that Recommendation X.327 defines the general arrangements for interworking between packet-switched public data networks (PDNs) and private data networks for the provision of data transmission services, 1. What Recommendations, if any, are necessary to enable interworking between PDNs and private networks? 2. What additions or modifications to existing Recommendations are necessary for interworking between PDNs and private networks? Note 1 - When studying this Question close liaison should be maintained with Groups studying specific user interfaces to PDNs. Note 2 - Different interworking conditions may exist between PDNs and private networks. Study items identified in relation with such conditions are documented in the annex. Attachment (to Annex 2 of Question 15/VII) There is a need for general arrangements and principles of interworking between private data networks and different types of public networks. Different interworking conditions that may exist between private networks and public networks are described in the appendix. Taking into account that Recommendation X.300 already gives some guidance on this kind of interworking, further study should consider in particular the following aspects. 1. Bearing in mind the different interworking conditions with specific arrangements, in addition to those provided for a simple DTE, are required in the case the DTE is a private network equipment. 2. When considering a connection between a PDN or ISDN and a private network equipment, what differences have to be considered between the two types of networks (security, maintenance, ...)? Guidance from other CCITT Groups would be of interest on this subject. 3. Which layers of the OSI Reference Model are involved in such a connection between a PDN or ISDN and a private network equipment? 4. It is recognized that private networks, including several different terminals and types of terminals will be connected to the public data networks or ISDNs. In those private networks, the different terminals may belong to different groups internally in the private networks and may also have a need to communicate into different CUGs in the public data network or ISDN. This study should take into account the specific complete addressing requirements for uniquely identifying a specific DTE as are defined in Recommendations X.121 (International numbering plan for PDNs) and I.320 (Numbering and addressing principles in ISDN). Note - Study Group VII already considered the suitability of DTE/DCE interfaces such as X.25 and X.21 for interworking with private networks. These considerations should be taken into account. Appendix (to the Attachment to Annex 2 of Question 15/VII) This appendix describes the different interworking conditions that may exist between private networks and public data networks or ISDNs, for the purpose of studying the technical aspects of this interworking. Note - ISDN in this attachment is considered only for the provision of data transmission services. 1. "Private PBX" type of interworking In this case, the private equipment is linked by ONE CONNECTION TO ONE PUBLIC DATA NETWORK OR ISDN IN ONE COUNTRY as illustrated in Figure 1. FIGURE 1 "Private PBX" type of interworking Note 1 - In the case the private equipment is having a second connection to the same PDN or ISDN, e.g. for security or reliability, it may be of interest to consider it also as a "Private PBX". Note 2 - In a multi-services environment, the same PBX equipment may be simultaneously connected to several dedicated public networks (e.g. telephone, data, ...). In this case, such a PBX can be logically considered as different "private PBXs", each one connected to one dedicated public network. 2. "National private network" type of interworking In this case, the private equipment is linked by SEVERAL CONNECTIONS TO ONE OR SEVERAL NETWORKS IN ONE COUNTRY, as illustrated in Figure 2. FIGURE 2 "National private network" type of interworking Note - It may be interesting to distinguish in that category of private equipment interworking, those which are connected to only one PDN or ISDN. 3. "International private network" type of interworking In this case, the private equipment is linked by SEVERAL CONNECTIONS TO SEVERAL NATIONAL PUBLIC DATA NETWORKS IN SEVERAL COUNTRIES, as illustrated in Figure 3. FIGURE 3 "International private network" type of interworking Note - In this case, it may be useful to recognize the different national parts of the international private network. ============================================================ Question 16/VII - Packet mode signalling between public networks providing data transmission services (continuation of Question 22/VII studied in 1985-88) Considering (a) that Recommendation X.75 already specifies the packet mode signalling system between public networks providing data transmission services; (b) that Recommendation X.75 applies to all links between packet switched public data networks (PSPDNs) in different countries as well as links between PSPDNs and ISDNs, and between ISDNs, as defined in Recommendations X.31 and the X.300-Series; (c) that Recommendation X.75 may also apply to national links for interworking scenarios given in (b) above, within the same country; (d) that Recommendation X.75 is considered for interworking between an ISDN offering X.31 based packet mode services and another ISDN offering additional packet mode services in the future, as defined in the ISDN services framework Recommendation I.122; (e) that Recommendation X.75 is being used between a very large number of networks around the world, and that it has reached a level of maturity; (f) that Recommendation X.75 includes the protocol elements necessary to support the network layer service for interworking situations; (g) that there is a need for bearer rates higher than 64 kbps, higher throughput and reliability for X.75 links between networks, the following points should be studied: 1. What additions or modifications to Recommendation X.75 are needed to enhance the interworking arrangements for scenarios covered in (b), (c) and (d) above? 2. What additions or modifications to other packet mode interworking Recommendations, such as X.323, X.180 and X.181, are needed to enhance the interworking arrangements? 3. What additional Recommendations or enhancements to existing Recommendations are required for operations, administrations and maintenance (OA&M) signalling over X.75 for interworking arrangements given above, in liaison with Question 12/VII? 4. What additional Recommendations or enhancements to existing Recommendations are needed to support packet mode interworking arrangements between new types of interworking arrangements, if any? Specific points to be covered may include, among others: 1. Points for further study in Recommendation X.75. 2. Enhancements to improve reliability and throughput performance of X.75 links with higher than 64 kbit/s signalling rates. 3. Enhancements to multi-link procedures, in close cooperation with ISO and X.25. 4. Additional link layer and/or packet layer signalling for X.75 link maintenance. 5. Additional signalling over M.75 links for OA&M aspects of virtual calls and permanent virtual circuits, including: -maintenance; -billing and accounting; -provisioning; -monitoring; -testing. 6. Additional signalling over M.75 links to support those X.2 user facilities currently limited to one network, in interworking scenarios mentioned above. In particular, X.75 utility signalling for internetwork call redirection and deflection. 7. Enhancements for the provision of international permanent virtual circuits. 8. Enhancements to the procedure and the format for NUI utility signalling. 9. The need for and definition of traffic class utility. 10. Alternative ways of network identification for the purpose of X.75 utility signalling. 11. Alignment of Recommendation X.75 with Recommendation X.25 where appropriate. 12. Enhancements to QOS signalling over X.75. 13. Enhancements to addressing and routing aspects of X.75. ============================================================ Question 17/VII - Arrangements for CSPDNs interworking and associated internetwork signalling (new Question derived from Question 21/VII studied in 1985-88) Considering (a) that the provision of data services may require several networks to interwork; (b) that framework of X-Series Recommendations related to interworking is given in Recommendation X.300; (c) that common channel signalling for data applications is specified in Recommendation X.61 and that decentralized signalling for anisochronous and synchronous data networks is specified in Recommendations X.70 and X.71 respectively; (d) that requirements of interworking of signalling in accordance with Recommendations X.61, X.70 and X.71 are specified in Recommendation X.80; (e) that studies are continuing on the implementation of user facilities and network utilities and on the interworking between different signalling systems; (f) that it is desirable to coordinate the specification of additions to Recommendations X.61, X.70 and X.71 resulting from any new common requirements for inter-exchange signalling for the circuit switched service, 1. What additions, if any, are required to Recommendations X.70 and X.71? 2. What additions, if any, are required to Recommendation X.80? 3. What guidelines need to be defined for specification of additions, if any, to Recommendation X.61 resulting from common requirements? Note - For this study, collaboration with Study Groups IX and XI should be made, as necessary. ============================================================ Question 18/VII - Message handling systems (continuation of Question 33/VII studied in 1985-1988) Considering (a) that the X.400-Series of Recommendations standardizes the structure and operation of message handling systems; (b) that the CCITT has supported the establishment of public messaging services by creating the F.400-Series of Recommendations; (c) that administrations and other organizations have implemented, and continue to implement systems based upon the X.400-Series Recommendations; (d) the need to constrain changes to and thus stabilize the X.400Series Recommendations, especially the P1 and P2 protocols; (e) the need to continue collaborating with the ISO MOTIS group; (f) that conformance tests have been developed for the 1984 X.400Series Recommendations; (g) the need to update the tests to reflect the 1988 X.400Series Recommendations; (h) that administrations plan to implement MHS-PDS intercommunication based upon the X.400- and F.400Series Recommendations, and the resulting need to continue collaborating with Study Group I and the UPU; (i) that there is a growing demand for the electronic interchange of business transaction documents (hereafter referred to as EDI), especially in a store-and-forward mode; (j) that various trade and standards organizations have developed national and international format standards for numerous business transactions; (k) that X.400-based message handling is suited to provide secure store- and-forward transfer for a wide variety of content types; (l) the need for collaboration between communication standards bodies such as the CCITT and the various organizations concerned with EDI to facilitate widespread adoption of the X.400Series Recommendations for EDI; (m) the need to transfer files (e.g., word processing files, spreadsheets, and source and object code for computer programs) in a store-and- forward manner; (n) the possible need for CCITT to standardize other message handling applications; (o) the growing requirement to support electronic bulletin boards and non-real-time computer conferencing by means of message exchange; (p) the need for F.400 and Telematic services to intercommunicate; (q) that Recommendation T.330 specifies a Telematic interworking facility for the Teletex service, 1. What steps should be taken to maintain the 1988 X.400-Series Recommendations? 2. What minor enhancements are required to the P1 and P2 protocols? 3. What other enhancements are required to the remainder of the X.400Series Recommendations? 4. How best can X.400-based message handling be put to use to facilitate widespread support for EDI? 5. What new content types, body part types, or both, if any, need be defined to support EDI? 6. What new Recommendations, if any, should be written to specify X.400 support for EDI? 7. How best can X.400-based message handling be put to use to facilitate store-and-forward file transfer? 8. What new content types, body part types, or both, if any, need be defined to support store-and-forward file transfer? 9. What new Recommendations, if any, should be written to specify X.400 support for file transfer? 10. How can X.400-based message handling best support such other applications as may be found to require standardization by CCITT? 11. What new techniques, services, and protocols based upon X.400 need be developed to support electronic bulletin boards and message-based computer conferencing? 12. What new Recommendations, if any, need be written to specify X.400 support for electronic bulletin boards and message-based computer conferencing? 13. What new access units, if any, need be specified to support X.400 interworking with Telematic services? 14. What steps should be taken to maintain and enhance the MHS-PDS intercommunication capability? 15. How, if at all, must the MHS-PDS intercommunication capability be extended to support new applications? 16. What additional support for voice messaging (including voice in interpersonal messaging, integrated voice and data messaging, voice message system interworking, and voice messaging via ISDN) is required? 17. What additional support for the use of symmetric encryption techniques in the provision of secure messaging is required? 18. What extensions are required to the security services and security elements defined in the X.400-Series Recommendations in order to support a wider range of secure message handling communication and applications, e.g., interpersonal messaging involving remote users and users accessing MHS through access units? ============================================================ Question 19/VII - Framework for support of distributed applications (new Question) Considering (a) that CCITT has standardized a number of distributed applications, for example, message handling systems and directory systems; (b) that further distributed applications are likely to be standardized; (c) that in the course of standardizing message handling systems and directory systems, there has been a need to develop mechanisms and techniques that are likely to be of general utility, including ASN.1, ROS, security abstract service definition conventions, etc.; (d) that mechanisms and techniques likely to be of general utility are best provided in a way that is common to many distributed applications, rather than each distributed application providing its own specific, different solution; (e) that ISO/IEC are defining standards for open distributed processing, security and distributed office architecture; (f) that CCITT and ISO/IEC have standardized and are standardizing sets of formal description techniques; (g) that CCITT has developed Recommendation X.407 that describes abstract services, notations and conventions; (h) that the study of this Question is intended to be a collaborative effort with ISO/IEC; (i) that close liaison is necessary with the new Questions on OSI reference model and application layer structure, 1.Architectural framework 1.1 What general purpose architectural framework can be defined for the design and support of distributed applications? 1.2 What structuring principles (e.g. object oriented parodigms) and general properties need to be defined, examined and applied to the definition and development of this framework? 1.3 What notational, descriptive and specification-related tools and techniques need to be used and/or developed to define and support this framework? 1.4 How does the OSI reference model relate to this new framework; what impact does this framework have on that model? 2.Security framework 2.1 What security framework(s) and security model(s) can be used and/or defined for distributed applications and data communications in general? 2.2 What security mechanisms (e.g. access control, authentication, notarization, digital signatures, etc.) and security management principles and techniques can be used and/or developed to define and support this framework? 3. What tools, mechanisms and protocols of general use can be utilized and/or developed to support distributed (and secure) applications? 4. What changes or enhancements, if any, should be made to ROS (X.219, X.229) to define and support this framework? 5. What changes or enhancements, if any, should be made to RTS (X.218, X.228)? 6. What changes or enhancements, if any, should be made to ASN.1 (X.208, X.209) to define and support this framework? 7. What changes or enhancements should be made to X.407 to define and support this framework? ============================================================ Question 20/VII - Directory systems (continuation of Question 35/VII studied in 1985-88) Considering (a) that directory systems are standardized in the X.500-Series of Recommendations; (b) that many administrations* are planning to provide directory system services based on the X.500 Recommendations; (c) that close collaboration with ISO/IEC JTC/1/SC 21/WG 4 is required to advance the standardization of directory systems; (d) that test methods and notation have been developed to provide for conformance testing for X.400 message handling systems and which may also be applicable to other application protocols; (e) that close liaison with Study Group I is required to coordinate the directory service requirements with the technical solution, 1. What steps should be taken to maintain the X.500 Recommendations? 2. What enhancements should be made to the directory system specification, e.g. to support replication and update of distributed directory information? 3. What changes to the X.500 Recommendations and/or what new Recommendations are required to document the enhancements to the directory? 4. What conformance test suites are required to enable tests for conformance to the X.500 Recommendations? 5. What additional system support is required from the directory to support potential users of the directory? 6. What changes, if any, are required to the directory authentication framework standardized in Recommendation X.500 to satisfy the requirements of applications which make use of the directory for authentication? Note - This study should be carried out in close coordination with other Question(s) dealing with security in general. ============================================================ Question 21/VII - Numbering plan for public data networks (continuation of Question 31/VII studied in 1985-88) Considering (a) that the International Numbering Plan for Public Data Networks is standardized in Recommendation X.121 and is implemented on a large number of Data Networks; (b) that the numbering plan interworking schemes between X.121 and E.164 before time "T" are standardized in Recommendations X.122 and E.166; (c) that the CCITT Study Groups involved in development of Numbering Plans all recognize that a single Recommendation (or joint Recommendation(s)) is desirable to standardize numbering plan interworking schemes for Public Networks; (d) that enhancements to X.121 and related numbering interworking Recommendations may be required as a result of: - further development of the ISDN numbering plan, E.164; - the studies on broadband communications on Public Networks; -further development of public aeronautical and land mobile satellite systems; -harmonization in the use of terms and drawing conventions (e.g., AU, PH and IWF) among Recommendations; (e) that additions may be necessary in Recommendation X.121 to ensure no saturation of the numbering plan; (f) that additions may be required in Recommendation X.122 to include other numbering plan interworking cases, What modifications to Recommendations X.121 and X.122 are required and what additional Recommendations are needed to further address standardization of Numbering Plan and numbering plan interworking schemes? 2. Short-term interworking via intermediary network(s) (This is not an exhaustive list) (Only significant examples are described) (Specific routing cases should be referred to the respective routing principles e.g., X.11y, currently being studied under Question 22/VII) 2.1 PSPDN - ISDN - PSPDN 2.2 CSPDN - ISDN - CSPDN 2.3 ISDN - PSPDN -ISDN 2.4 ISDN - CSPDN - ISDN 2.5 ISDN - PSPDN - PSTN 2.6 ISDN - ISDN - PSPDN TABLE 2 Numbering interworking between network services (long-term) Note - The number above indicates corresponding section number below. [TO BE SUPPLIED] -use of NI (Numbering Identifier) -relatively simple for multiple PDN-ISDN interworking -routing principle would become more important ============================================================ Question 22/VII - Routing principles for public data networks (continuation of Question 32/VII studied in 1985-88) Considering (a) that Recommendation X.110 specifies the international routing principles and routing plan for public data networks (PDNs); (b) that Recommendation X.353 specifies the routing principles for interconnecting public maritime mobile satellite data transmission systems with public data networks; (c) that PDNs are expanding rapidly on a world-wide basis; (d) that interconnection of PDNs with other public networks is envisaged or has been effected and the following cases of international interworking will be required: - between public networks of the same type through PDNs, - between a PSPDN and a CSPDN, - between a PDN of any type and a PSTN, - between a PDN of any type and an ISDN, - between a PDN of any type and the Telex network, - between a PDN of any type and a public mobile satellite system, - between a PDN of any type and a public land mobile system; (e) that Recommendation X.122 specifies the short term numbering plan interworking between PSDNs and ISDNs or PSTNs; (f) that long term numbering plan interworking between PDNs and networks of different types is required; the following points should be studied: 1. What additional routing principles, routing plans or routing algorithms should be specified internationally in Recommendations X.110, X.353 or in possible new Recommendations, particularly, for the cases of interworking between two public networks, including dissimilar networks? Note - Possible routing principles for interworking between public networks are given in Annex 1 in the form of text for a draft Recommendation as a basis for further study. 2. What routing strategy should be specified for the case where a network receives information on "network congestion" or "network failure" of the adjacent networks? 3. What routing information other than DCC/DNIC should be transferred to the adjacent network, possibly by use of new network utility fields in PSPDNs or new additional signals in CSPDNs. Possibilities to be studied include: a) location of cross-over points to be used; b) ISDN bearer service requested, (e.g., packet or circuit mode); c) type of circuit switched IWF to be used (e.g., based on T.70 or X.25); d) type of terminal interface (e.g., digital on an ISDN, or analogue on a PSTN or integrated ISDN/PSTN). 4. What routing algorithms should be specified so as to respond to users' requirements related to "Quality of Service" (QOS), such as transfer delay, for the case where interface/network protocols and signalling systems provide methods for such user requirements and the principles for defining and allocating QOS parameters are agreed to. ANNEX 1 (to Question 22/VII) Draft Recommendation X.11y Routing principles applicable to public data networks for the establishment of data calls between networks of different types The CCITT, considering (a) that Recommendation X.1 defines the international user classes of service in public data networks (PDNs) and ISDN; (b) that Recommendation X.2 defines the international user services and facilities in PDN and ISDN; (c) that Recommendation X.10 defines the different categories of access of data terminal equipments (DTEs) to the different data transmission services provided by PDNs and ISDN; (d) that Recommendations X.20, X.20bis, X.21, X.21bis, X.25, X.32, X.28 and X.29 specify the detailed procedures applicable to different types of DTE/DCE interfaces on PDNs; (e) that Recommendations X.30 and X.31 specify the support of X.21, X.21bis and X.25 terminals on ISDNs; (f) that Recommendations X.61, X.70, X.71 and X.75 specify the detailed procedures applicable to call control between two PDNs of the same type; (g) that Recommendation X.300 specifies the general principles for interworking between PDNs and between PDNs and other networks; (h) that Recommendation X.121 specifies the international numbering plan for PDNs; (i) that Recommendations I.330 and I.331 (E.164) respectively specify ISDN numbering and addressing principles and the numbering plan for the ISDN era; (j) that Recommendation X.122 specifies the methods to be used for numbering plan interworking; (k) that Recommendation X.110 already specifies the international routing principles and routing plan for PDNs; (l) that Recommendation X.353 already specifies the routing principles for interconnecting the maritime satellite data transmission system with PDNs; (m) that Recommendation E.172 specifies call routing in the ISDN era; (n) the need that DTEs can communicate through different types of networks; (o) the need for routing principles for the establishment of data calls between public networks of different types; (unanimously) declares the view that the routing principles applicable to public data networks for the establishment of data calls between networks of different types be in accordance with principles specified in this Recommendation. CONTENTS 1. Introduction 2. Definition of the interworking routing problem 2.1 Context 2.2 Call route elements 2.3 Routing process 3.General routing principles for the establishment of data calls between different types of networks 3.1 Interworking routing plan 3.2 Location, selection and number of cross-over points 4.Specific routing principles for different interworking conditions 4.1Routing principles for interworking at the network layer between CSPDN and PSPDN 4.2Routing principles for switched access through a PSTN or CSPDN to a PSPDN by a packet-mode DTE 4.3Routing principles for interworking at the network layer between CCSN and PSPDN 4.4Routing principles for interworking via a non-OSI adapter between PSTN and PSPDN 4.5Routing principles for interworking at the network layer between PSPDN and private networks 4.6Routing principles for interworking between ISDN and PDNs 4.6.2Routing principles for interworking between CSPDN and ISDN where a circuit switched bearer is requested 4.6.3Routing principles for interworking between PSPDN and ISDN where a packet switched bearer is requested 4.6.3.1 Terminal with ISDN virtual circuit bearer service 4.6.3.2Terminal with ISDN transparent circuit switched service (for further study) 4.6.4Routing principles for interworking between a PSPDN and an ISDN where a circuit switched bearer is requested 4.6.5Routing principles for interworking between a CSPDN and an ISDN that supports the packet switched virtual call scenario 4.7Routing principles for interworking between two ISDNs for the provision of data transmission services 1. Introduction 1.1 In Recommendation X.300 it is recognized that there may be a demand to interconnect different types of public networks; such as, public data networks (PDNs) and integrated services digital networks (ISDNs) in order for a DTE or one type of network to communicate with a DTE on another type of network. 1.2 Recommendation X.300 includes within its scope the definition of the principles and detailed arrangements for the interworking of different networks in order to provide a data transmission service. 1.3 Implicit in the scope of Recommendation X.300, is the requirement that a network of one type be able to effectively route calls to the interfaces at which interworking with other types of networks takes place, to allow the establishment of network - connections between network-service users (within the end-systems) on different types of networks. 1.4 The scope of this Recommendation is to define the general and specific routing principles applicable to public data networks for the establishment of network connections between DTEs on different types of networks. Note - The viewpoint taken in this Recommendation is that of the public data network (PDN). Routing principles internal to other types of network e.g., ISDN, are not included in the scope. 1.4.1 This Recommendation applies to the routing of calls which cross international boundaries. Its application to calls within a single country is a national matter. 1.4.2 Interworking involving more than two networks is included in the scope of this Recommendation. 1.5 Recommendation X.110 applies to the routing of calls within a public data network of a single type, even in the case where this network interworks with a network of another type for the establishment of calls requiring such interworking. Thus Recommendation X.11y is intended to cover the specific routing principles applying to the interworking, and does not supersede Recommendation X.110. Note - Changes to Recommendation X.110 itself may be required to reflect internal PDN routing requirements arising from interworking. 2. Definition of the interworking routing problem 2.1 Context This Recommendation addresses the general problem of defining how networks should determine the route to be taken by a data call in a public network when both the calling and called DTEs are not connected to the same type of network, or when a network of a different type from those to which the calling and called DTEs are connected is used as a transit network. Note 1 - An interworking function specific to the type of interworking may be required between two different types of networks. In certain cases; e.g., port access, this interworking or access function may not be directly involved in establishment of end-to-end network connections. Note 2 - A call path may be either a circuit switched bearer or a logical channel on a packet bearer, depending on the type of network and/or bearer service requested. 2.2 Call route elements 2.2.1 Figure 1-2/X.11y illustrates five typical call routes involving international interworking. Other possibilities exist, however, these examples serve to indicate the typical elements which make up the route of call involving interworking. 2.2.2 Examples a), b), and c) depict interworking from a network of one type to that of a second type. Examples d) and e), depict interworking where two networks of one type are connected via a transit route through a network of a second type. 2.3 Routing process 2.3.1 For the routing of a call, the following types of information may need to be considered at each node in all the networks involved: a) numbering plan of called DTE; b) called DTE address; c) numbering plan of calling DTE; d) calling DTE address; e) incoming route; f) type of bearer requested by calling party; g) type of bearer requested by called party; h) service requests (e.g., supplementary services in ISDN, and user facilities/utilities in PDN). Examples are RPOA selection, and Quality of Service indication; i) information on prior routing history of call; e.g., number of satellite hops, networks already transited. Note - All the above information elements may not be available in all types of networks, nor at all cross-over points between different types of networks. 2.3.2 The above information is used as an input to a routing decision process, which for the purposes of interworking, must in general determine the following: a) in the calling and transit networks, the type of network of the called DTE; b) in the calling and transit networks the location of the cross- over points, and the routes to take to these points; c) in the calling and transit networks, the appropriate type of interworking units to be applied. These determinations are to be made within the constraints imposed by customer service requests, avoidance of looping, and barring of non- permitted calls. 3.General routing principles for the establishment of data calls between different types of networks 3.1 Interworking routing plan 3.1.1 The international routing of calls involving the connection of networks of different types will be in accordance with an interworking routing plan which is the responsibility of the administrations concerned, and is subject to bilateral agreement. 3.1.2 The interworking routing plan will identify the agreed points of interconnection of the different networks, and the location of required interworking functions (IWFs). 3.2 Location, selection and number of cross-over points 3.2.1 The location at which interworking between two different types of networks takes place, is termed the cross-over point. An interworking function may be required at this point between the two networks. 3.2.2 The following principles, which govern the selection of a cross- over point with respect to call origination, are for further study: Principle 1 The originating network normally routes the call to an IWF in the originating country; Principle 2 Where an originating country has no IWF within its boundaries, it can choose a route to access an IWF within the destination country. Principle 3 The originating country may choose to route a call to access an IWF on the international boundary between the source and a transit or destination country, or between a transit and another transit or destination country. 3.2.3 A cross-over point may be located within the national segment of a route, or at an international boundary. 3.2.4 The preferred location, with respect to the boundary, of an interworking unit between any two given types of networks interworking across an international boundary is a function of the types of networks, and is specified for each case, in section 4 of this Recommendation. 3.2.5 Where interworking between two types of networks takes place at the network layer as defined in Recommendation X.300, the selection of the cross- over point will be made by the Administrations concerned, according to the routing plan and not by the users. 3.2.6 Where interworking between two types of networks takes place by port access, as defined in Recommendation X.300 the user may be required to select the cross-over point. 3.2.7 The number of cross-over points through which a call is routed should be as low as possible; in most cases one. However, where it is necessary to transit a network of one type when interworking between networks of another type, two cross-over points are allowed. Note - Given, that except in the case of PSPDNs, there is no signalling information available on the route history of a call, it is for further study how the number of cross-over points can be controlled. 4. Specific routing principles for different interworking conditions This section defines the specific routing principles applicable to different interworking conditions, involving the interworking of different types of networks, where these networks interwork to provide a data transmission service. Table 4-1/X.11y summarizes the different interworking conditions considered, and indicates for each case whether or not the specific routing principles are presently covered or are for further study in this or other XSeries Recommendations (X.110, X.353). Where covered by this Recommendation, a reference to the pertinent sections is given. 4.1Routing principles for interworking at the network layer between CSPDN and PSPDN Section 8.2 of Recommendation X.300 presents three variations of this interworking case: a) where interworking takes place across an international boundary, and only one PSPDN and one CSPDN are involved (Figure 81/X.300); b) where a transit PSPDN is involved, and interworking takes place internally in a country (Figure 82/X.300); c) where a transit PSPDN is involved internationally, with interworking at an international boundary (Figure 83/X.300). Note - The case where the transit network is a CSPDN is also allowed by exception. 4.1.1 In all three cases, the determination of the type of called network and that this type is in fact different from the calling network can be made from the DNIC of the called network. 4.1.1.1 The responsibilities for determining that interworking is involved can lie with either the originating network, transit networks, or both. The assignment of these responsibilities is through bilateral agreement. 4.1.2 Where interworking takes place across an international boundary, the Interworking Unit shall normally be located in the same country as the CSPDN; however, the administrations involved may agree exceptionally to placement of the IWU in the country where the PSPDN is located. 4.1.3 An originating or transit network which, for a given call, is not able to determine that interworking is involved should route the call per Recommendation X.110. 4.1.4 A network which receives a call and determines that interworking is involved can: a) immediately route the call to cross-over point, e.g., a cross- over point connected to the originating node, or node at which the call is received; b) route the call through the network to a remote cross-over point; or c) route the call to a transit network of the same type, where the choice of transit network is consistent with the need for this call to eventually arrive at a cross-over point. 4.1.5 Since the specific type of interworking function required may depend on the type of terminal on the CSPDN, there is a need for further study to determine how an IWF appropriate to the type of CSPDN terminal can be chosen. 4.2Routing principles for switched access through a PSTN or CSPDN to a PSPDN by a packet-mode DTE Section 8.3 of Recommendation X.300 describes this case, and the two sub-cases (CSPDN and PSTN access) are illustrated in Figure 84/X.300. 4.2.1 For the case where calls are incoming to the PSPDN, the routing of the calls in the PSPDN is in accordance with Recommendation X.110. 4.2.2 For the case of outgoing calls to a CSPDN from a PSPDN the responsibility for determining that interworking is involved and for providing the interworking will normally fall to a PSPDN in the called country. This internal interworking will be transparent to interworking conditions between the PSPDN and other networks across an international boundary; thus international routing shall be per Recommendation X.110. Note - Study is required of whether the switched access may be provided from networks other than the PSPDN in the called country. If it can, how are these networks to discriminate between case 4.2 (switched access) and 4.1 (network layer interworking)? 4.2.3 For the case of outgoing calls to a PSTN the format of the called address will be a function of the time T. 4.2.3.1 Pre time T, an internationally standardized escape code "9" may be used to indicate that the digits which follow are in E.163 format; i.e., the called address may have the format 9 + TCC + NSN. It is also possible that the called address will be in normal X.121 format. Such will be the case when the PSTN has been assigned a DNIC as a national option, or the PSTN terminal is registered on a PSPDN and assigned an X.121 address. 4.2.3.2 Post time T, (or earlier by bilateral agreement) the format of the called address will be indicated by the NAPI in X.25, X.28 and X.75 signalling. For calls to both PSTN and ISDN the NAPI must indicate E.164 format. Note - It is for further study how, post time T, it shall be indicated whether a call is for a terminal accessing a PSPDN per Recommendation X.32, or a terminal accessing an ISDN per Recommendation X.31. 4.2.3.3 In both the pre and post time T cases, where the called address is in normal X.121 format (DNIC + NTN) then the PSTN/PSPDN interworking will be transparent to interworking conditions across an international boundary; thus international routing shall be per Recommendation X.110. 4.2.3.4 Pre time T, in the case where the called address is in the format 9 + TCC + NSN, the originating and transit PSPDNs may apply one of the following routing strategies: a) a network may choose to implement full E.163 digit analysis and route on the basis of the E.163 number following the escape code "9"; b) a network may treat the 9 + TCC as a pseudo DNIC, and route using the same digit analysis algorithm it applies to X.121 format addresses; c) a network may choose to route entirely on the basis of the presence of the escape code "9". In this case, the network will route the call to a predetermined interworking interface with the PSTN, at which point a switched access will be set up to the called DTE, using X.32 procedures appropriate for an unregistered DTE. Note - Since the DTE may very well be registered with a PSPDN in the called country, the service implications of this type of routing require further study. 4.2.3.5 The post time T routing procedure to be used is for further study. (This procedure will be dependent on the solution chosen, for post time T discrimination between PSTN and ISDN). 4.3Routing principles for interworking at the network layer between CCSN and PSPDN Section 8.4 of Recommendation X.300 describes this case and illustrates it in Figure 8-5/X.300. 4.3.1 The routing principles applicable to this case are for further study. 4.4Routing principles for interworking via a non-OSI adapter between PSTN and PSPDN Section 8.5 of Recommendation X.300 describes this case, and illustrates two sub-cases: a) direct interworking, with a possible arrangement illustrated in Figure 8-6/X.300; b) port access method, with a possible arrangement illustrated in Figure 8-7/X.300. 4.4.1 In both cases access is outgoing from PSTN to PSPDN only. Since for both cases a) and b) above the interworking arrangements between the PSTN and the PSPDN are transparent to interworking conditions across an international boundary, international routing in the PSPDN shall be per Recommendation X.110. 4.5Routing principles for interworking at the network layer between PSPDN and private networks Section 8.6 of Recommendation X.300 describes this case, and it is illustrated in Figure 8-8/X.300. 4.5.1 The need for additional routing principles beyond those of Recommendation X.110 is for further study. 4.6Routing principles for interworking between ISDN and PDNs 4.6.1 Recommendation X.300 describes a set of ISDN/PSPDN interworking cases for both interworking at the network layer and port access. The routing principles applicable to these cases are defined in the following sections. 4.6.2Routing principles for interworking between CSPDN and ISDN where a circuit switched bearer is requested This type of interworking is described in Section 8.7.2 of Recommendation X.300. Figure 8-9/X.300 presents two possible scenarios for further study. 4.6.2.1 Specific routing principles for this case will be required; however, the specification must await the outcome of the further studies with respect to Recommendation X.300. Note - The address analysis requirements should be similar to those for PSPDN/ISDN interworking at the network layer, where a circuit switched bearer is requested, as specified in Section 4.6.4. 4.6.3Routing principles for interworking between PSPDN and ISDN where a packet switched bearer is requested Section 8.7.3 of Recommendation X.300 describes the case where the packet terminal on the ISDN has an ISDN virtual circuit bearer service. This case is illustrated in Figure 8-10/X.300 and the routing principles specified below in 4.6.3.1. 4.6.3.1 Terminal with ISDN virtual circuit bearer service 4.6.3.1.1 Since the ISDN is assumed to directly support X.75, no interworking function is required for this type of interworking at the cross-over point. 4.6.3.1.2 The location of the cross-over point with respect to an international boundary is not described in X.300; it can be at any point in the connection, internally within a national segment or across an international boundary. 4.6.3.1.3 For incoming calls to the PSPDN the called address will always be in X.121 format, and the PSPDN can route on the basis of this address. 4.6.3.1.4 For outgoing calls from the PSPDN the format of the called address will be a function of the time T. 4.6.3.1.5 Pre time T an escape code "0" at the DTE/DCE interface and within the PSPDN may indicate that the address which follows is in E.164 format; i.e., the called address may have the format 0 + TCC + NDC + NSN, with a pre time T length of not greater than 14 digits, including the escape code. 4.6.3.1.6 Pre time T PSPDNs may choose to apply one of the following routing strategies: a) route based on full E.164 digit analysis; b) treat the 0 + TCC as a pseudo DNIC; c) escape immediately to an ISDN. Note - The implications of this method require further study. 4.6.3.1.7 Post time T (or earlier by bilateral agreement) the format of the called address will be indicated by the NAPI. 4.6.3.1.8 Post time T the called address of calls incoming to a PSPDN will be in X.121 format, and the PSPDN can route on the basis of this address. 4.6.3.1.9 Post time T the called address for calls outing from the PSPDN will be in E.164 format. The PSPDN will be required to route on the basis of E.164 digit analysis. The maximum number of digits which may need to be analysed is for further study. 4.6.3.1.10 In both the pre and post time T cases for calls outgoing from the PSPDN it will be necessary for the PSPDN to select a cross-over point on the basis of the type of bearer service requested by the ISDN terminal (packet switched in this case), plus the type of interworking (network layer in this case). Further study is required on how this selection is to be made. 4.6.3.2 Terminal with ISDN transparent circuit switched service (For further study) 4.6.4Routing principles for interworking between a PSPDN and an ISDN where a circuit switched bearer is requested Recommendation X.300 describes two sub-cases of this type of interworking: i) interworking at the network layer as illustrated in Figure 811/X.300; ii) interworking by post access, as illustrated in Figure 812/X.300. 4.6.4.1 In both the above cases, the pre and post time T called address analysis requirements for routing are the same as in Section 4.6.3 above. 4.6.4.2 The same requirement specified in 4.6.3.1.10 above, concerning the selection of the cross-over point applies in this case, with the additional need to select an IWF appropriate to the type of called circuit switched DTE. 4.6.5Routing principles for interworking between a CSPDN and an ISDN that supports the packet switch virtual call scenario This case is described in Section 8.7.5 of Recommendation X.300, and illustrated in Figure 8-13/X.300. 4.6.5.1 For incoming calls to the CSPDN the called address will be in X.121 format, thus routing of the call in the CSPDN will be based on X.121 addresses. 4.6.5.2 For outgoing calls from the CSPDN the address analysis requirements are the same as for PSPDN - ISDN interworking in Section 4.6.3.1. 4.6.5.3 The method to be used by the CSPDN to determine that a packet switched bearer is requested by the ISDN terminal, is for further study. This information is required to select the proper IWF. 4.7Routing principles for interworking between two ISDNs for the provision of data transmission services The routing principles applicable to this type of interworking are for further study. ============================================================ Question 23/VII - Open Systems Interconnection (OSI) architecture (continuation of part of Question 42/VII studied in 19851988 on OSI architecture) considering (a) that administrations in many countries are planning to establish telecommunications services which exploit the networks now existing or due to be available in the near future; (b) that these services may be carried on different types of networks; (c) that users of these services need to communicate with each other irrespective of the diversity of interconnected networks; (d) that methodical representation of network services will further promote the effective and efficient use of networks; (e) that accommodation of conflicting services requirements and network constraints can be affected through the analysis of service and network functions. This analysis should lead to a universally applicable logical structure which may be used in the development of compatible service, interface and procedure definitions; (f) that this structure should as far as possible accommodate existing Recommendations to allow the steady evolution of networks providing the new services; (g) that the development of new telecommunications services necessitates in some cases the study of higher layer service definitions and protocol specifications; (h) that close collaboration and liaison with other Study Groups and other international bodies studying reference models and functional profiles (e.g., ISO, IEC) is highly desirable to ensure the widest applicability of resulting Recommendations, therefore, work should continue to determine: 1. Reference model What further refinements are required for Recommendation X.200? In particular, studies should include: a) reference model architecture, including impact of OSI management, transaction processing and distributed processing; b) harmonize the reference model and ISDN architecture; c) naming and addressing requirements, including which OSI entities require naming or addressing, the structure, if any, of such names and addresses and the administrative requirements for management of OSI names and addresses, including registration authority requirements, where appropriate; d) security; e) connectionless mode; f) procedure for answering questions relative to the reference model. 2. Service conventions What further study is required to refine Recommendation X.210 to elaborate the detailed properties of service primitives, including service oriented interactions among application service elements within the application layer? 3. Use of X.200-Series protocols What further study is required to maintain Recommendation X.220, so that it will accurately portray usages of X.200-Series protocols in CCITT applications? Studies should include profiles and classification schemes, with particular attention to the work of ISO/IEC JTC 1 on functional standardization. 4. Liaison What is necessary to maintain cooperation with other international organizations (e.g., ISO/IEC JTC 1) in activities concerning reference models of Open Systems Interconnection and functional profiles? ============================================================ Question 24/VII - Open Systems Interconnection (OSI) management (continuation of part of Question 42/VII studied in 19851988 on OSI management) Considering (a) that OSI will be a principal means of interconnection between systems in both the information processing and telecommunication environments; (b) that ISO international standards are being developed for an OSI management framework extension to the OSI reference model and for services and protocols in the areas of accounting management, configuration management, fault management, performance management and security management; (c) that OSI management for CCITT applications is needed and will be relevant to PDNs, ISDNs, Signalling System No. 7 networks and TMN; (d) that liaison both within the CCITT and with ISO and IEC is highly desirable to ensure, where applicable, the consistent and common development of management standards, therefore, work should continue to determine: 1. OSI reference model What extensions are required to Recommendation X.200 to define an OSI management framework for CCITT applications? 2. Management information structure What is required to satisfy the needs of CCITT applications regarding the structure of management information? 3. Management services and protocols What is required to satisfy the needs of CCITT applications regarding OSI management services and protocols? 4. Layer management What is required to satisfy the needs of CCITT applications regarding requirements and coordination of the management among individual layers? 5. Liaison What is necessary to maintain cooperation with other international organizations (e.g., ISO/IEC JTC 1) in activities concerning OSI management? ============================================================ Question 25/VII - Open Systems Interconnection (OSI) application layer (continuation of part of Question 42/VII studied in 19851988 on OSI application layer) Considering (a) that Recommendation X.200 specifies the reference model for Open Systems Interconnection for CCITT applications; (b) that Recommendation X.210 specifies the layer service definition conventions of Open Systems Interconnection for CCITT applications; (c) that Recommendation X.220 specifies the use of X.200-Series protocols in CCITT applications; (d) that Recommendations X.217 and X.227 specify the association control service and protocol of Open Systems Interconnection for CCITT applications; (e) that administrations and users in many countries are applying the Open Systems Interconnection family of Recommendations to public networks now existing or due to be available in the near future; (f) that close collaboration and liaison with other international bodies (e.g., ISO, IEC) studying Open Systems Interconnection is highly desirable, therefore, work should continue to determine: 1. Application layer a) What further study is required to extend the services and protocol of the association control Recommendations X.217 and X.227 to provide additional capabilities, such as application context management and authentication control? b) What is required to further develop application layer structure, services and protocols having wide applicability among various different CCITT applications? In particular, studies should include: i) application layer structure; ii) commitment, concurrency and recovery; iii) OSI transaction processing; iv) impact of distributed processing work on application layer structure, services and protocols; v) impact of security considerations on application layer services and protocols; vi) impact of management considerations on application layer services and protocols; vii) formal description of application layer services and protocols; viii) validation of application layer protocol specifications to avoid potential errors. c) What is required to provide for registration of information objects of concern to these application layer services and protocols? 2. Liaison What is necessary to maintain cooperation with other international organizations (e.g., ISO/IEC JTC 1) in activities concerning the application layer for OSI? ============================================================ Question 26/VII - Open Systems Interconnection (OSI) presentation and session layers (continuation of part of Question 42/VII studied in 19851988 on OSI presentation and session layers) Considering (a) that Recommendation X.200 specifies the reference model of Open Systems Interconnection for CCITT applications; (b) that Recommendation X.210 specifies the layer service definition conventions of Open Systems Interconnection for CCITT applications; (c) that Recommendation X.220 specifies the use of X.200-Series protocols in CCITT applications; (d) that Recommendations X.215 and X.225 specify the session service and protocol of Open Systems Interconnection for CCITT applications; (e) that Recommendations X.216 and X.226 specify the presentation service and protocol of Open Systems Interconnection for CCITT applications; (f) that administrations and users in many countries are applying the Open System Interconnection family of Recommendations to public networks now existing or due to be available in the near future; (g) that close collaboration and liaison with other international bodies (e.g., ISO, IEC) studying Open Systems Interconnection is highly desirable, therefore, work should continue to determine: 1. Presentation layer What further refinements are required for the presentation layer services and protocol, Recommendations X.216 and X.226, to provide additional capabilities, such as data encryption and compression? What additional work is required to provide formal descriptions of the presentation services and protocol? What is required to validate presentation layer protocol specifications to avoid potential errors? What is required to provide for registration of transfer syntaxes? 2. Session layer What further refinements are required for the session layer services and protocol, Recommendations X.215 and X.225, to provide additional capabilities, such as symmetric synchronization? What additional work is required to provide formal descriptions of the session services and protocol? What is required to validate session layer protocol specifications to avoid potential errors? 3. Liaison What is necessary to maintain cooperation with other international organizations (e.g., ISO/IEC JTC 1) in activities concerning the presentation and session layers for OSI? ============================================================ Question 27/VII - Open Systems Interconnection (OSI) transport and network layers (continuation of part of Question 43/VII studied in 1985- 1988 on OSI transport and network layers Considering (a) that Recommendation X.200 specifies the reference model of Open Systems Interconnection for CCITT applications; (b) that Recommendation X.210 specifies the layer service definition conventions of Open Systems Interconnection for CCITT applications; (c) that Recommendation X.213 specifies the network service of Open Systems Interconnection for CCITT applications; (d) that Recommendation X.214 specifies the transport service of Open Systems Interconnection for CCITT applications; (e) that Recommendation X.224 specifies the transport protocol of Open Systems Interconnection for CCITT applications; (f) that Recommendation X.244 specifies the procedure for the exchange of protocol identification during virtual call establishment on public networks; (g) that administrations and users in many countries are applying the Open Systems Interconnection family of Recommendations to public networks now existing or due to be available in the near future; (h) that close collaboration and liaison with other international bodies (e.g., ISO, IEC) studying Open Systems Interconnection is highly desirable, 1. Transport layer What further refinements are required to transport layer Recommendations X.214 and X.224? In particular, studies should include: a) What further consideration needs to be given to Quality of Service issues? b) Is there a need for further protocol to allow transport entities to negotiate the use and control of network service connections, and layer management issues in general? c) What consideration needs to be given for addition of formal descriptions to Recommendations X.214 and X.224? d) What consideration needs to be given to addressing requirements for the transport layer? e) What further relationships between the Transport Layer and adjacent layers need to be defined? f) What further consideration is needed for OSI/non OSI protocol identification? g) What further consideration needs to be given to transport layer management? h) What further consideration needs to be given to transport layer security? 2. Network Service What further refinements are required to the network service Recommendation X.213 recognizing: a) that users need to communicate with each other irrespective of the diversity of interconnected networks? b) that methodical representation of networks and their capabilities will further promote the effective and efficient use of public data networks; c) a universally applicable Network Service should be used in the development of compatible service, interface and procedure definitions; d) that such a Network Service should as far as possible accommodate existing Recommendations to allow the steady evolution of new networks and the new services. In particular, a) What further consideration needs to be given to Quality of Service issues? b) What consideration needs to be given to the addition of a formal description to Recommendation X.213? c) Does any requirement for compatibility checking within the network layer affect the network service, and if so, how? d) What further consideration needs to be given to CCITT defined services, DTE/DCE interface Recommendations, ISDN and international inter- exchange signalling system, in relation to the network service? e) Are any further refinements required to cover the case of point- multipoint operation? f) Are any further refinements required to cover the case of multi- stage connection establishment? g) What further consideration needs to be given to OSI network layer addressing? For example, what mechanisms are required to facilitate the derivation of sub-network addresses from OSI network addresses? h) What further consideration needs to be given to OSI network layer management? i) What further consideration needs to be given to OSI network layer security? 3. Liaison What is necessary to maintain cooperation with other international organizations (e.g., ISO/IEC JTC 1) in activities concerning the transport and network layers for OSI? ============================================================ Question 28/VII - Open Systems Interconnection (OSI) data link and physical Layers (continuation of part of Question 43/VII studied in 1985-1988 on OSI data link and physical layers) Considering (a) that Recommendation X.200 specifies the reference model of Open Systems Interconnection for CCITT applications; (b) that Recommendation X.210 specifies the layer service definition conventions of Open Systems Interconnection for CCITT applications; (c) that Recommendation X.211 specifies the physical service of Open Systems Interconnection for CCITT applications? (d) that Recommendation X.212 specifies the data link service of Open System Interconnection for CCITT applications; (e) that administrations and users in many countries are applying the Open Systems Interconnection family of Recommendations to public networks now existing or due to be available in the near future; (f) that close collaboration and liaison with other international bodies (e.g., ISO, IEC) studying Open Systems Interconnection is highly desirable, 1. Data link layer What refinements are required to the data link layer Recommendation X.212? In particular, studies should include: a) development of refinements and enhancements to Recommendation X.212; b) expansion of Appendix 3 of Recommendation X.212 to include additional data link layer protocols; c) consideration of data link management aspects of OSI (see Annex 1). 2. Physical layer What refinements are required to the physical layer Recommendation X.211? In particular, studies should include: a) development of refinements and enhancements to Recommendation X.211. This study should include relationships to other Recommendations; b) consideration of physical layer management aspects of OSI. 3. Liaison What is necessary to maintain cooperation with other international organizations (e.g., ISO/IEC JTC 1) in activities concerning the data link and physical layers for OSI? ANNEX 1 (to Question 28/VII) Data link management facilities Management services are provided to allow the local system management process to execute control of and to request certain test and statistical functions of the DLL. Note - This document makes no assessment as to whether the primitive action takes place at a DLSAP or at some service-access-point identified for management. This is a subject for urgent further study. (Editor's note: The potential need for the following services has been identified. Details of primitives, parameters and sequences are for further study.) Q.1 Data link service characteristics In order to effectively coordinate the choice of network protocol with the provision of data-link connectionless mode service, information relating to the characteristics of the service must be made available. Q.1.1 Function The data link service characteristics service conveys information from the DLS provider to the DLS user concerning those characteristics of the service available for a given pair of DLSAPs which are beyond the scope of those characteristics which can be expressed in a single invocation of the connectionless-mode DLS, or are optional features of the connection-mode DLS that are not negotiable during DLC establishment. Q.1.2 Types of primitives and parameters Table Q-1/X.212 illustrates the types of primitives and the parameters needed for the provision of this service. TABLE Q-1/X.212 Primitives and parameters + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + \PRIMITIVE DL-MGMT-FACILITY DL-MGMT-FACILITY PARAMETER\ Request Indication + - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - - - - Destination address x x Service characteristic/ x QOS parameter + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Q.1.2.1 Destination address The address referred to in Table Q-1/X.212 is a DLSAP address. The connection-mode and connectionless-mode DLSs both use the same DSLAP- addresses as described in sections 12.2.1 and 12.2.3 of the data link service definition. Q.1.2.2 Service characteristic/QOS parameter The value of the service characteristics/QOS parameter is a list of sub- parameters. For each sub-parameter, any value permitted according to the particular sub-parameter may be indicated. QOS parameters are described in sections 10 and 11 of this Recommendation. The following list of service characteristics is for further study. a) Congestion control: the congestion control parameter is concerned with whether a connectionless-mode DLS user is willing to accept indications from the DLS provider that transmission is refused. The specification of this parameter means that the DLS provider should not initiate discard operations (see section 16). b) Sequence preservation probability: the sequence preservation probability is the ratio of sequence-preserved transmissions to a total transmissions observed during a performance measurement. A sequence-preserved transmission is one in which the following rule is observed: for a given pair of DLSAPs, a DL-UNITDATA indication will not occur at a destination DLSAP after any other DL-UNITDATA indication corresponding to a later DL-UNITDATA request issued from the source DLSAP to the destination DLSAP. The specification of a sequence preservation probability of one (1) means that the DLS provider may not initiate change of order operations (see section 16). c) Maximum DLSDU size: this parameter defines the maximum number of octets that can be transferred in a single DLSDU. Q.1.3 Sequence of primitives The valid sequence of primitives are given in the time sequence diagrams in Figures Q-1 and Q-2/X.212. Q.2 Report service Q.2.1 Function The DL-REPORT indication conveys information about the failure of the DLS provider to provide the requested Quality of Service or service characteristic. In particular, this relates to a failure of the DLS provider to satisfy the constraints imposed upon a DL-UNITDATA request, given a particular destination DLSAP. Q.2.2 Types of primitives and parameters Table Q-2/X.212 illustrates the types of primitives and the parameters needed for the provision of this service. TABLE Q-2/X.212 Primitives and parameters + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + \PRIMITIVE DL-REPORT PARAMETER\ Indication + - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Destination address x Service characteristic/ x QOS parameter Reason for report x + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Q.2.2.1 Destination address The address referred to in Table Q-2/X.212 is a DLSAP-address. The connection-mode and connectionless-mode DLSs both use the same DLSAP- addresses as described in sections 12.2.1 and 12.2.3 of the data link service definition. Q.2.2.2 Service characteristic/QOS parameter The value of the service characteristic/QOS parameter is a list of sub- parameters. For each sub-parameter, any value permitted according to the particular sub-parameter may be indicated. QOS parameters are described in section 10 of this Recommendation. The list of service characteristics is given in section I.1.2.2. Q.2.2.3 Reason for report The value of the reason for report parameter indicates the reason why the DL-REPORT indication was initiated by the DLS provider. Reason values may be: a) no reason specified; b) transit delay exceeded; c) DLS provider congestion; d) requested QOS/service characteristic unavailable. Q.2.3 Sequence of primitives The valid sequence of primitives are given in the time sequence diagram in Figure Q-3/X.212. Q.3 Test The test service allows a local management function to initiate a pre- defined test of a particular DLS provider including the local and remote DL entities and the underlying physical connection. Q.4 Statistics The statistics service is provided to require the DLS provider to maintain "accounts" of the retransmitted data units, total data units, and any other items that may be defined by parameters. Statistics primitives will probably include connect, disconnect and transfer. Q.5 Configure The configure service provides the local system manager with the ability to add and delete DL entities from a multi-link group. ============================================================ Question 29/VII - Application of formal description techniques to X- Series Recommendations (continuation of Question 48/VII) What improvements should be made to X-Series Recommendations in view of the work on formal description techniques being pursued by Study Group X? Note - Close collaboration with Study Group X is required for this study. ============================================================ Question 30/VII - Support of X-Series interfaces in an ISDN and new interface aspects for data services in ISDNs (continuation of Question 9/VII studied in 1985-1988) Considering (a) that user/network interface characteristics of the ISDN have been defined in the I-Series Recommendations; (b) that Recommendation X.30 defines the support of X.21, X.21bis and X.20bis DTEs by means of terminal adaptors and that Recommendation X.31 defines the support of packet-mode terminals based on X.25 by an ISDN; (c) that the need to align DTE/DCE interface protocols with the OSI Model has been recognized; (d) that the following four steps have been identified for the evolution of the ISDN packet-mode services: Step 1:The service defined by Recommendation X.31. Step 2:Services as defined by Recommendation X.31 but with the addition of a Layer 2 multiplexing capability. Step 3:Additional packet-mode bearer services based on out-of-band call control and Layer 2 multiplexing. Step 4:Broadband Asynchronous Transfer Modes (ATM), which include support for narrow-band services; (e) that Question 31/VII deals with the further requirements and arrangements to be met for the provisions of data services in ISDNs; (f) that some administrations foresee the need for D-Channel access to PSPDNs, it is necessary to study the following: 1. What enhancements will be required to Recommendations X.30 and X.31 for the support of non-voice communication? Study items of particular interest are: a) impact of user facilities on the procedures of the TE interface; b) fault isolation and maintenance. 2. What Recommendation, if any, will be required for the support of Step 2 of the evolutionary process? 3. What Recommendation, if any, will be required for the support Step 3 of the evolutionary process? 4. What Recommendation, if any, will be required for the support of Step 4 of the evolutionary process? Note - Study of this Question should be closely coordinated with the related study in this and other concerned Study Groups. ============================================================ Question 31/VII - Requirements and arrangements for the provision of data services in ISDNs (continuation of Question 46/VII studied in 1985- 1988) Considering (a) that characteristics and features of circuit and packet switched data services and corresponding customer interfaces are defined in XSeries Recommendations and that new Recommendations may emerge from further studies; (b) that Study Group VII defined Recommendation X.30 specifying the support of X.21, X.21bis and X.20bis on an ISDN, and Recommendation X.31 for the support of packet mode terminals based on X.25 by an ISDN; (c) that Recommendations X.1 and X.10 have been already defined in order to take into account provision of data transmission services by the ISDN; (d) that the intention of many administrations is that customers connected to the ISDN will have access to a wide range of services including telephony and data services as those mentioned above; (e) that there is a further need to define, in a common framework, coherent standards for customer access to different services provided by the ISDN; (f) that such standards have to allow various network architectures, taking into account the varying conditions in different countries, for example, provision of some services through the ISDN by means of interworking with specialized networks; (g) that the following four steps have been identified for the evolution of ISDN packet mode services: Step 1:Services defined by Recommendation X.31 Step 2:Services as defined by Recommendation X.31 but with the addition of a Layer 2 multiplexing capability Step 3:Additional Packet Mode Bearer Services based on out of band call control and Layer 2 multiplexing Step 4:Broadband Asynchronous Transfer Modes (ATM), which include support for narrow-band services; (h) that Question 30/VII deals with studies on the interface aspects, it is necessary to study the following: 1. What further requirements and arrangements are to be established for the provision of data services on an ISDN? 2. What new Recommendation or enhancements or existing ones are needed? Annex 1 to this Question contains a list of items which will be studied under the Question. Annex 2 contains a draft Recommendation to be finalized concerning the provision of the Connection-mode Network Service in ISDN (Step 1). Note - A close liaison should be maintained with other Study Groups, in particular Study Groups II, XI, XVII and XVIII. ANNEX 1 (to Question 31/VII) The following subjects will be studied under this Question: a) Definition of the service and technical implication of the proposed evolutionary step identification of interest of new data services exploiting information transfer, access and general attributes offered by the ISDN circuit and packet bearer services. Relevant study items are for example use of Recommendation X.31 procedures for data services at rates higher than 64 kbit/s (e.g., H-channel rate) assessment of need for and subsequently technical options and requirements for the support of step 2 services. b) Technical options and requirements for the support of step 3 services based on the service characteristics developed by this and other Study Groups. In both studies of a) and b), the relationship with the OSI network service should be considered for data services operated within an ISDN. c) Requirements to be established for the provision of packet mode data services steps 1, 2 and 3 with view to interworking situations to be studied in close cooperation with related studies in concerned Study Groups. d) Definition of compatibility requirements for ISDN DTEs in their operation through either a circuit switched connection type or a packet switched connection type. e) Definition of ISDN operational requirements for the support of data services, e.g., maintenance aspects. f) The alignment between the representation for access unit (AU)/packet handler (PH)/interworking function (IWF) in Recommendation X.31 and the drawing conventions in Recommendation X.300. ANNEX 2 (to Question 31/VII) Provision of the OSI connection-mode network service by packet mode terminal equipment connected to an integrated services digital network (ISDN) for CCITT applications Recoup Recoup Recoup Recoup "call-offering procedure" which, when present, takes place before the conveyance of INCOMING CALL packets. The procedures of Recommendation Q.931 enable terminal identification and a determination of which channel (D or B) a specific INCOMING CALL packet is to be conveyed on. The following limitations apply: 1) The maximum User Data field length of DATA packets shall not exceed 256 octets. 2) The Recommendation X.25 Throughput Class used shall not exceed 16 kbit/s on a basic interface. ============================================================ Question 32/VII - Continue the preparation of definitions which arise during the study of all Questions entrusted to Study Group VII (continuation of Question 45/VII studied in 1985-1988) Encourage the Special Rapporteur and other experts preparing a draft Recommendation to develop definitions for the terms being used and to include these terms and definitions in a separate section or annex to the draft Recommendation. ============================================================ Question 33/VII - Revision of Recommendations (new Question) Study of possible amendments to the Recommendations within the purview of Study Group VII not explicitly covered by other study Questions.