Here it is! DRAFT December 85 ___________________________ Transition to OSI Standards _____________________________________________________ Report of the Academic Community OSI Transition Group __________________ 0. Management Summary ____ This is always the last bit that gets written. It will emphasise the transition as a dynamic process, needing careful management. It will flag addressing as a major problem area. When it exists, it will be followed by a page break. _____________________________ SECTION ONE. GENERAL OVERVIEW The aim of this section is to provide senior technical management in the computing service organizations within the UK Academic Community with the information needed to plan for the transition to ISO standards. The second section of the document contains technical detail needed by those involved in implementing the transition. __________ 1. Background ____________________________ 1.1. Why International Standards? The advantages of open working have been clearly demonstrated in the UK Academic Community. Machines from a large variety of suppliers are regularly communicating with one another, and can do so with sufficient commonality of interpretation to perform useful work. This achievement is based on a set of interim UK protocols known as the "Coloured Books", which are now stable and well established. The question which must therefore be asked is "why upset all this and introduce a new set of standards?". The answer can be seen in the history of protocol development in the community. The set of protocols used has been adopted only erratically outside the community, and so the main effort of implementation has fallen directly or indirectly on the academic sector. The provision of protocol support for a new machine represents an added cost, and more importantly an added delay. The protocols are not immediately available on new operating systems, and there is therefore often a delay before new developments are available to the network user. If there is a widespread acceptance of OSI standards, and if the community adopts these standards, then we can expect to receive full protocol support as a part of manufacturers' main line operating systems, and we can expect the protocol support to be developed by the manufacturers, as a standard product; it will be available on the same timescale as the rest of the operating system and within the normal software cost. Unfortunately, we have not, so far, had any choice. There is not a defined set of OSI protocols which the community could have used. We had to take the initiative, and by doing so we have established a level of interworking which is the envy of the world. However, the situation is now changing and we must plan to accommodate the change. - 1 - DRAFT December 85 ______________________ 1.2 European Harmonization The international effort to create OSI standards has a very broad scope. As a result of the inclusion of many different styles of communication, the series of layer (or base) standards contain options allowing subsets of the full function and tailoring the facilities available to fit the user requirements. Unfortunately, unconstrained choice of the combinations of standards and options would defeat the purpose of OSI standardization, making it unlikely that different systems would use the same options, and so preventing communication. In order to control this variability, a second level of standardization is in progress, yielding so called "functional standards". These functional standards each deal with either a specific user requirement (such as file transfer) or a specific technology (such as token buses). For the selected area, the functional standard states which base standards are to be used, and the values to be selected for any options. In this way, the probability of effective communication is greatly increased. The pressure for functional standardization is coming, at present, from European interests. The European Commission is pressing, via the European standards bodies CEN and CENELEC and the PTT group CEPT, for the creation of European functional standards. It is the intention to exploit these European agreements wherever appropriate, in order to gain the advantages of being part of a large market; manufacturers are much more likely to support popular combinations quickly and integrate them fully into their main-line products. For the same reason, the community will also take account of the DTI Intercept Strategy, which represents preferred UK solutions. The generation of OSI standards is a joint activity between ISO and CCITT. In general, the academic community will look towards the ISO standards for higher level protocols, because they contain the additional features necessary to support privately operated equipment, and to the CCITT recommendations where appropriate for the lower layer, network specific, standards, so as to gain the benefits of compatability with the public networks. _______________________________ 1.3 Progress of ISO Standardization The development of a standard within the ISO involves a number of steps. The theory is as follows. Initially, a need is identified and support for a standardization project is confirmed by ballot among the national standards bodies on a new work item (NWI). A technical group then develops a working draft for the standard to the point where it is believed to be technically stable. This is approved by the controlling sub-committee and registered as a Draft Proposal (DP). At this point, the national standards bodies take part in a ballot on the technical content. Each may vote "yes" without qualification, or vote "yes" but give comments on possible improvements it would like to see, or vote "no" giving the reasons for its objections and an indication of what action would make the standard acceptable. If there is substantial agreement with little comment, the draft becomes a Draft International Standard (DIS). At this point it is processed editorially to conform to the ISO house style, and translated into French. - 2 - DRAFT December 85 A further ballot by a higher level committee then allows it to progress to a full International Standard (IS). If any of these ballots does not show support then the document must be revised and the ballot repeated. In favourable circumstances, the passage from DP to DIS and from DIS to IS each take about a year. Although in principle the technical content should be agreed before registration as a DP, pressure for rapid progress often results in significant instability beyond this point, making early implementation a risky business. In practice, a draft might be ready for pilot implementation by the time it reaches a second DP or DIS stage. [Timescales will be added at the last minute to keep the information fresh. A diagram showing the expected progress of the various standards will be included.] A full list of the standards referenced in this report is given in Annex C. __________________________________ 2. General Architecture of Transition _______________________ 2.1. Managing the transition The academic community does not have the luxury of a clean start; the very success of the Coloured Books creates a problem. The facilities offered by these protocols are in heavy use, and loss of the communication infrastructure which has been established would be a serious blow to users of all kinds. The prime consideration, therefore, must be to ensure users can continue to communicate with remote facilities. This would not be a problem if a change could be made throughout the community at a stroke, but the wide range of equipment and the programme of phased replacement makes a single coordinated change impossible. Hosts and access facilities will be changed in a piecemeal way, and the change must be managed so that there is continuity of user service without dividing the community into two or more mutually inaccessible fragments. The implication is that means must be found for communication between equipment using the old protocols and equipment using the new protocols. (In principle, all systems could be made to run both sets of protocols for a transitional period, but the cost implications rule out such a proposal immediately.) There is, therefore, a need for facilities to convert between the protocols. Can this be done? Clearly, any arbitrary pair of protocols cannot be converted one to the other. There is a need for the basic objective and facilities offered to be similar. In architectural terms, this is equivalent to the two protocols providing the same communication service. Each of the new protocols in the ISO set aims to provide a defined service, and these services can be compared with the facilities available in the corresponding Coloured Book protocol. The Coloured Book application protocols typically have a less clearly separated service definition, and so this process may require some interpretation based on actual practice. If a feature has no parallel in the new standards, conversion cannot be performed, and users should be given advanced warning of its impending removal. - 3 - DRAFT December 85 Equivalence of service makes conversion possible, but it still leaves open the question of where the function is to be performed. Some of the possibilities are given here, together with an indication of the levels of protocol to which they apply. - to place a converter on the access to each new host, so that all network traffic is in terms of the old protocols (all protocols); - to place a converter in internetwork gateways, so that different subnetworks may have different conventions (network and lower layer protocols); - to provide a separate converter as a value added service on the network, relying on common network protocols; such a configuration is called a VANS converter (protocols above the network service); - to place a converter on the access to each old host, so that all network traffic is in terms of the new protocols (all protocols). These solutions have different applications. Specific provision for a new host may be appropriate early in the process, and specific provision for an old one may be more applicable towards the end. Gateway conversion apply to network protocols, and VANS conversion to application ones. However, similar functions and possibly similar equipment are involved in several of the cases, so that transition aids may be reused within the community at different stages in the migration process. ________________ 2.2 Transition Steps Another aspect of the transition which requires discussion is phasing. The ISO Architecture is layered, and transition could in principle take place a layer at a time. However, this would maximize the number of different combinations which would have to co-exist, and thus the number and variety of converters which would have to be provided. The process would be much simpler to organize if it takes place as a small number of large steps. This implies the replacement of each of the application protocols by the corresponding set of ISO layers when they are sufficiently mature to provide a usable service. For file transfer, for example, the Blue Book specification would be replaced at one step by the ISO File Transfer, Access and Management protocol, together with its supporting presentation, session and transport protocols. It should be noted that the ISO Transport Protocols are end-to-end and so have a subtly different function from the Yellow Book which, although called a Transport Service, is, in ISO terms, more correctly regarded as a network service; Yellow Book gateways exist, so that the protocols do not necessarily operate on an end-to-end basis. - 4 - DRAFT December 85 ----------------- ------------------- | | | FTAM | | | |-------------------| | | | Presentation | | | |-------------------| | Blue Book | ====> | Session | | | |-------------------| | | | Transport | |=================| |===================| | | | | | Yellow Book | | Network | | | | | ----------------- ------------------- Replacement Strategy Networks, on the other hand, are dominated by the constraints applied by the connecting gateways, and these will have a major influence on the planning of the lower layer transition. In the Coloured Book architecture, the internetworking function is provided by the yellow book, and the detailed protocols on each network are isolated by yellow book gateways. These are functionally very similar to ISO relay entities, so that conversion can be managed on a subnetwork by subnetwork basis. The proposal, then, is to identify major transitions corresponding to the application components (file transfer, terminal access, job transfer, electronic mail) and a separately managed transition for the network components. In view of the comments above on the disadvantage of managing a number of separate transitions, this separation requires some justification. It arises from the desire to progress unrelated components independently. Since the one set of network protocols provides infrastructure for all the applications, combining the network and application transitions would effectively bind all the application transitions together, forcing the timescales to those of the most slowly developing standards. If, on the other hand, each application had separate network support, there would be a need for both hosts and gateways to support both old and new network protocols for an extended period. Separating the application and network transitions would simplify the situation, and reduce the complexity of the gateway implementations necessary. On the basis of the above arguments, either the network or the application transition could be performed first. However, to reduce the number of combinations converters have to handle, and to reflect the greater stability of the network protocols, particularly for X.25 networks, it is proposed that conversion below the network service should be performed first. _______________________ 2.3 Tracking and Transition It has been pointed out that various actions to harmonize use of OSI protocols are under way, particularly on a European basis. These will take time, and there is bound to be a period of instability during which all those involved gain experience. It will be important for the UK to gain expertise from taking part in this activity, but it would be disruptive to mount service activity on a basis which is less stable than our current - 5 - DRAFT December 85 usage of Coloured Books. On the other hand, communication with sites outside the UK academic community will become possible during this first phase, and UK groups will wish to take advantage of the opportunities offered. The resolution of this conflict is to distinguish two roles for protocol converting gateways. In the first phase, a small number (possibly only one _________________ per protocol) of tracking gateways will be needed. These will be maintained by groups with a strong development interest, and will allow traffic from a stable Coloured Book community to external sites developing OSI usage. The gateways will be updated to follow the developing consensus, and may have to cope with a variety of options. ___________________ At a later stage, conversion gateways will be introduced. These will be installed to a stable specification in a full service environment, and their purpose is to handle traffic within the UK academic community between sites which are at different stages of the transition process. __________ 2.4 Addressing Addressing presents problems at various levels. In the Coloured Book protocols, addressing is concentrated in the Yellow Book and supporting subnetwork protocols. In the OSI standards there are many levels of addressing. Consistant mappings must be defined between the two schemes. More seriously, the transition will be accompanied with widespread changes of addressing. Before a particular system is changed, other Coloured Book systems address it directly, while OSI systems address a converter which then communicates with the called system on the OSI systems behalf. After the transition, OSI systems address it directly, while remaining Coloured Book systems now address the converter in the first instance. The result will be a practically continuous process of address change and updating. The users must be isolated from this process if there is to be continuity of service. Fortunately, steps are already being taken to decouple user visible names from addresses. The introduction of the Name Registration Scheme (NRS) has given a tool for managing changes of addressing within a stable naming environment. Changes to the conversion facilities envoked can be brought about by manipulating the addresses registered and the addressing contexts used. There remains the question of the stability of the top levels of the naming and addressing structures used. The ISO approach is to allocate identifiers on a hierarchical basis, generally starting at a national level. Approaches are being made to Oftel for early registration of the UK Academic Community within the relevant network level and application level naming plans. - 6 - DRAFT December 85 _____________________________ SECTION TWO. THE LOWER LAYERS The following sections provide technical detail of the transition steps, and are intended for communication group managers and their staff, who will be directly involved in the implementation of the transition to ISO standards. _____________________ 3. Lower Layers - Target ___________________ 3.1 The Network Service The aim in the transition is to provide communication between cooperating systems, providing the functionality currently available over JANET and the existing campus networks. Developments in communication will also make possible closely coupled distributed systems and introduce new services, such as mixed voice and data. New services are, however, not constrained by a need for transition from existing practice, and so are not addressed in this report. The aim, then, is to provide the Connection Oriented Network Service. This is an idealization of the type of service currently offered by JANET and the campus networks and defined in the Yellow Book. The OSI Network Service is defined in DIS 8348. The Expedited Service, which is optional in DIS 8348, shall be provided by networks for use in the academic community. The Receipt Confirmation Service will not be used and its implementation is not required. Support for Quality of Service parameters is desirable, but it is expected that initial use will be on the basis of acceptance of a default quality of service. All systems must be configurable so as to operate without the explicit negotiation of network service quality of service. Work within the ISO committees is still in progress to define standard services and protocols for network management. It is expected that these will be widely adopted once stable, but are not considered here because they do not represent a transition issue; rather their generation is an attempt to fill a vacuum, since network management is currently performed in a variety of ad hoc ways. __________________ 3.2 Network Addressing _________________ 3.2.1 Addressing in OSI The addressing currently in use, defined in the Yellow Book, assumed that addresses were allocated by independent authorities, with no single over all control. This gives great flexibility, but generates some logical problems because the form of addresses is location dependent. The solution (the Address primitive) was too radical for general acceptance. ISO has taken the centralist approach of assuming that addresses are global. The other major difference between the Yellow Book and ISO schemes is that Yellow Book provided a distributed high level addressing scheme. Addresses were expected to be text rather than digit strings, and there was emphasis on late binding. For addresses, this means that decisions on route and - 7 - DRAFT December 85 location are postponed until as near the called system as possible. Late binding allows a site with various services on a LAN to publish a service name to be used as part of the Yellow Book address; the binding of this name to a physical location and network route could be done at the relay giving access to the LAN. In ISO, the addresses, called Network Service Access Point Addresses, are seen as machine oriented objects (strings of 40 decimal digits or binary fields). User oriented titles must be resolved at the point of establishment of a connection. This could be by local table look up or by nameserver interaction, but it must be complete. You can no longer bind the leading part of a name and pass the rest on. This implies larger local tables and more frequent update mechanisms. It becomes necessary to broadcast a change of service name throughout the community. _____ However, the existence of these differences should not cause undue alarm. By adopting the NRS, the community has effectively provided an alternative to the Yellow Book form. A service name and its complete Yellow Book string are "published" by inclusion in the database and everyone's tables must be updated accordingly (unless the database is accessed dynamically). Thus binding is often complete at the source of the call. ___ There are problems when international communication is taken into account. Unless we have a "global" or ISO defined NRS, we will be obliged to publish the full 40 digit NSAP addresses of our services and enable users to make calls using this explicit form. This situation is worse than at present due principally to the user-non-friendliness of numbers rather than text strings. The directory service work in progress in ISO may eventually give rise to the equivalent of a global NRS. ISO have made some gesture to the user requirement, by allowing character forms in their local format, but this does not really represent a general solution to the academic community problem. This is because any use of the local format is obviously restricted to the UK academic community, and so communication outside this community, with industry or overseas, would not be predictable. Any other group is at liberty to define meanings for the local format, and an unambiguous interpretation becomes impossible. Finally, it should not be forgotten that NSAP addresses need not be tightly bound to the supporting subnetwork addresses. Although the caller must resolve fully from user-oriented name to NSAP address, the local site still has the flexibility to move services around in its subnetwork address space. This obviously requires suitable gateway software between, for example, a LAN and a WAN. ______________ 3.2.2 The ISO scheme ISO have allowed called and calling address fields of up to 40 decimal digits (or equivalent). The limit in the corresponding CCITT recommendation is 32 digits, but there is every expectation that this will be increased to 40. ISO have produced an addendum to the OSI Network Service which defines the form of global addresses. In the ISO model of multiple networks (the internal organization of the network layer, IONL) ISO distinguish between the OSI Network Service (abstract, end to end) and the constituent sub-networks and associated subnetwork services. The global address is carried across each subnetwork, but each subnetwork is provided with a - 8 - DRAFT December 85 subnetwork address to select the exit point from the subnetwork. Thus, for example, X.25(1984) carries a pair of OSI addresses in the facilities field, but routes on the basis of the DTE addresses in the first part of the connect packet. The ISO addressing scheme provides for a number of allocation schemes and for a set of hierarchically nested registration schemes. Each address starts with an initial domain part, which itself consists of an Authority and Format Identifier (AFI) (giving the following format, syntax and authority name) and an Initial Domain Identifier (IDI) (giving the initial addressing domain and authority responsible for that domain). This is then followed by a Domain Specific Part (DSP). [Figure giving format and annotated example.] There are AFIs for common PTT network types (X.121, PSTN, Telex etc.) and for ISO network independent schemes. These are the ISO-DCC scheme (naming national registration authorities) and the ISO-6523-ICD scheme (naming international organizations and authorities (still not fully agreed)). The UK academic community has applied to register the equivalent of UK.AC under the UK arm of the ISO-DCC scheme. ________________ 3.2.3 Size limitations The major shortcoming of all these schemes is the limit on the total length. The limit of 40 digits was chosen to allow an X.121 address followed by an IEEE 802 LAN address. We also have a requirement (not acknowledged in ISO since management functions have not yet been standardized) for authorization information for control and charging in gateways. There is not room for all of these. Luckily, there is no need to carry two separate global addresses, one for WAN and one for LAN use. All that is required is for a subnetwork address to be derived at each subnetwork point of attachment, and this may be the result of a mixture of: a) insertion of fixed information characteristic of the subnetwork; b) extraction and possible algorithmic manipulation of pieces of the global address; c) table look up based on pieces of the global address. Thus addresses for use within the academic community will have the following general form: ISO DCC + UK allocation + Academic Community Address + Charging tag The Academic community address will be based on the current JANET addressing, extended by a further eight digits to give further local addressing. The division of this extended address string between JANET, local X.25 and other local networks will be a matter of local choice, based on the configuration and technologies in use. - 9 - DRAFT December 85 It should be noted that the addresses used in JANET already allocate several of the subnetwork digits for site use, so that the total space for site use is significant. Sites will generally have at least twelve digits available for allocation. site space is big. The charging tag will be inserted into the calling address by originating systems, and must identify an end user oriented account. This field will be ignored in the called and responding addresses. Provision of charging information within the address reflects the lack of a charging and accounting (and network management support in general) within the OSI Network Service. It is hoped that better mechanisms will eventually be standardized. Gateways making use of the charging information may zero the field in the calling address to simplify recall routing. [More details of the scheme, with examples, to be provided.] The above scheme is workable, but is of necessity a compromise between conflicting requirements. There will be little room for future expansion, but the standards do not allow great freedom. ___________________________ 3.2.4 Implications on procurement The implications for host systems are that we need quite elaborate facilities for name to address binding, with interactions with nameservers and NRS. In relays, we will need installation dependent algorithms and/or large tables for subnetwork address resolution. We may need dynamic facilities to give at least an element of logical to physical mapping control (virtual addresses). __________________________ 3.2.5 Addressing of Applications The OSI protocols for the Transport and Session layers both contain facilities for addressing (by means of transport and session selectors), and further facilities may be added to the higher layers. These facilities provide a variety of different ways of selecting an application once the called end system has been reached. The result is a wide range of choices as to how application oriented addressing mechanisms are implemented. Some manufacturers may, in their products, constrain addressing so that particular layer address selectors must be used. However, where freedom of choice exists, the community should adopt a consistent approach, based on the advantages of late binding. Addresses should, therefore, be passed by the lowest protocol layer possible, subject to constraints imposed by the system being addressed. Because, however, it is likely that system specific constraints will exist, the NRS support for OSI contexts will need to provide for the possibility of address selectors at each of the protocol levels for which they are defined. Thus a name will be resolved into a set of protocol address values, the preference being for null values associated with the higher layers. In consequence, reverse lookup of a network service address alone may not yield a unique context, and a concept of "reverse look-up in the forward context" may need to be added to the NRS. - 10 - DRAFT December 85 _________________________ 4. Lower Layers - Transition __________________________ 4.1 Mapping to the Yellow Book ____________ 4.1.1. Introduction The services provided by the Yellow Book and the OSI Network Service appear very similar, but are different at the detailed level. This specification establishes: a) the intersection of the two services, defining the mapping to be used by higher level Coloured Book protocols (in 4.1.2); b) the actions to be taken by a gateway in converting from the Yellow Book service to the OSI Network Service (in 4.1.3); c) the actions to be taken by a gateway in converting from the OSI Network Service to the Yellow Book Service (in 4.1.4). ___________________ 4.1.2. Service equivalence The following direct parallels between the services are defined: Yellow Book OSI Network Service Y-CONNECT N-CONNECT request/indication called address called address calling address calling address Y-ACCEPT N-CONNECT response/confirm recall address responding address Y-DISCONNECT request/ind N-DISCONNECT request/indication coded reason reason (see Annex A) location originator (see clauses 4.1.3 and 4.1.4) Y-DISCONNECT response/confirm none Y-DATA N-DATA data data Y-PUSH End of NSDU - see below Y-EXPEDITED N-EXPEDITED data data of length 1 Y-ADDRESS none Y-RESET N-RESET coded reason reason (see Annex A) location originator (see clauses 4.1.3 and 4.1.4) ____________________________________________________ 4.1.3. Gateway actions - Yellow book to OSI Network Service For each of the defined equivalences in clause 4.1.2, the gateway receiving a Yellow Book primitive shall issue the equivalent OSI Network Service - 11 - DRAFT December 85 primitive. It shall transform the following primitives and parameters, and take the following actions where direct equivalences are not defined: ____________ a) Coded reason shall be translated to an OSI reason according to the table in annex A. __________ b) The originator shall be set on the basis of the location parameter, so that the originator is set to "user" if the location parameter is equal to the address of the Yellow Book service access point (either the calling or responding address); otherwise, the originator parameter shall be set to "provider". c) The gateway terminates each Network Service Data Unit (NSDU) sent on receiving a Y-PUSH primitive. If two Y-PUSH primitives are received successively then the second is ignored. d) The gateway attempts to negotiate availability of expedited data in the OSI Network Service. e) The gateway sends each byte of Y-EXPEDITED data received as a separate expedited NSDU. If the negotiation of expedited data failed, the gateway generates a Reset in both services on receiving Y-EXPEDITED data. Parameters without defined equivalence are set by the gateway as follows: f) The gateway discards any explanatory text parameters received. g) The gateway does not insert any NS-user data into the Network Service primitives it issues. h) The gateway may insert a locally determined Quality of Service parameter into N-CONNECT requests issued. ____________________________________________________ 4.1.4. Gateway actions - OSI Network Service to Yellow Book For each of the defined equivalences in clause 4.1.2, the gateway receiving an OSI Network Service primitive shall issue the equivalent Yellow Book primitive. It shall transform the following primitives and parameters, and take the following actions where direct equivalences are not defined: ______ a) Reason shall be translated to a Yellow Book coded reason according to the table in annex A. b) The location shall be set to the gateway's address if the originator is set to "provider"; the location shall be set to the NSAP address if the originator is set to "user". The gateway may insert explanatory text naming the subnetwork from which the indication was received. c) The gateway generates a Y-PUSH primitive for each end of network service data unit received. d) The gateway generates an explanatory text message on the Y-ACCEPT primitive if the connection is established without expedited data. The explanatory text shall be "Expedited data - 12 - DRAFT December 85 not available.". e) The gateway sends any single byte expedited NSDUs received as Y-EXPEDITED data. If multi-byte expedited NSDUs are received, the gateway generates a Reset in both services. Parameters without defined equivalences are set by the gateway as follows: f) The gateway discards any NS-user data received, but generates a warning explanatory text message, stating "ISO Network Service User Data lost.". g) The gateway may insert explanatory text on the Y-ACCEPT primitive identifying itself and giving additional information into appropriate Yellow Book primitives. h) The gateway may negotiate Quality of Service in the OSI Network Service on the basis of local information available to it. ________________ 4.2 Mixed Addressing In order to interwork with YBTS addressing domains during the transition period it will be necessary to make use of the LOCAL format of NSAP address. Examples of situations which require NSAP-YBTS address transformations are as follows. Note that if any of the operations specified produces an ambiguous result, the call attempt fails. _________________ 4.2.1 OSI to YBTS relay The called address sent by the source NSAP to the relay is in LOCAL format. This allows up to 19 ISO 646 characters to be sent, which is sufficient to contain the full NRS abbreviated form (18 characters) of the destination service, plus a leading NRS context character which identifies the protocol required. The relay uses the NRS short form and context to get the routing information and the full YBTS address of the destination. Further hops within the YBTS domain are then processed as normal. The calling NSAP address of the source entity must be converted to a YBTS string at the relay. It is recommended that the YBTS calling address sent from the relay is of the form ISO.nsap(s) where nsap(s) is the NSAP address of the source expressed as an ISO646 string of decimal digits. The NSAP address will have the ISO DCC format and structure outlined previously. _________________ 4.2.2 YBTS to OSI relay The called address sent to the relay will be a YBTS string of the form ISO.nsap(d) where nsap(d) is the NSAP address of the destination entity in the OSI domain and has the ISO DCC format and structure described previously. The calling address identifies the source YBTS service. This address is converted by reverse look-up in the NRS database to its context and short form name, which are then encoded in the LOCAL character format of NSAP address, and sent to the destination NSAP. Note that the encoding of the necessary contexts into a single character will be defined by the NRS. - 13 - DRAFT December 85 ____________________________________ 4.2.3 OSI to YBTS to OSI multiple relaying When two global OSI addressing domains are separated by a YBTS addressing domain, the following transformations take place at the two relays. The called address sent by the source NSAP to the first relay is in one of the defined formats. The relay identifies the remote site from the contents of the NSAP address and routes the call to the relay at the remote site. It is recommended that the called address is encoded as the final part of the YBTS address in the form ISO.nsap(d) where nsap(d) is the NSAP address of the destination entity. The remote YBTS to OSI relay recognises that an NSAP address is being presented by the ISO prefix. The source NSAP sends a calling address in one of the defined formats to the OSI to YBTS relay. The YBTS calling address sent by this relay is of the form ISO.nsap(s) where nsap(s) is the NSAP address of the source. The remote YBTS to OSI relay recognises that an NSAP address is being presented by detecting the string "ISO" as the next to last component of the source YBTS address string. _________________ 4.3 Transition stages [This section will talk about converters, gateways and domains in more detail. It will discuss site strategies for dealing with new hosts, network transitions and residual old equipment, keeping wide area connectivity the while! It will cover the addressing mechanisms used to route traffic through protocol converters.] SECTION THREE. THE HIGHER LAYERS _____________________ 5. Applications - Target This section outlines the services which are to be available to the network user as a result of the transition. Further sections then outline how these services are to be achieved, and what transition mechanisms are necessary to provide interworking with the existing Coloured Book implementations. _______________ 5.1 Terminal Access This area covers: - the provision of an X.29 - like service over the OSI NS - the choice of protocol(s) to provide this service - conversion (if necessary) between the 1980 and 1984 variants These issues are discussed separately below. _________________________________________________ 5.1.1. Provision of an X29-like Service over the OSI NS Whilst the OSI NS as specified over ISO 8208 in DP 8878 is almost sufficient to support X29, there exist two significant deficiencies. There - 14 - DRAFT December 85 is currently no provision for the use of the X25 Q-bit; as the operation of X29 depends heavily upon it, this becomes a stumbling block. The optional status of N-EXPEDITED poses another problem. There are two possible solutions; either run a new protocol (called NS29) which is based on X.29, but without the Q-bit dependence, over the Network Service (having previously ensured the implementation of N-EXPEDITED), or allow use of the Q-bit. The first option requires no additions to the Network Service, and allows a very straightforward mapping in a relay to TS29 over YBTS. However, since many WAN entities do not support TS29, it is likely that the relay will be required to perform a significant amount of work mapping NS29 into X29 (in both directions). It is also probable that manufacturers will be reluctant to implement a protocol which is not an international standard as their prime terminal communication method. The second option deviates from the OSI Network Service, as the Q-bit is not explicitly included therein. It is included in ISO 8208 for the purpose of providing a signalling function for CCITT higher level entities (specifically X29), and is redundant in the Network Service as it is assumed that this signalling function will be the responsibility of higher layers of the model. X29 uses the Q-bit explicitly; to provide an implementation of the ISO 8208/DP 8878 Network Service which used it would not be a serious inconvenience, and would enable provision of both X29 and NS29 over the Network Service (e.g. N-EXPEDITED, as noted above). The Q-bit approach should be adopted; there are no other requirements for it except to support X29, for which there is an evident need. As implementations of the higher levels of OSI protocols become available, the need for it may diminish, but X29 will not become obsolete in practice for at least ten years. __________________ 5.1.2 Choice of Protocol Most X25-based WANs in the UK run a close approximation to X29 derived from requirements for PSS compatability. However, X29(84) contains explicit instructions for responses to X25 packets with the D-bit set; the 1980 revision does not. However, in the context of X29 operation, this will probably not be a important matter, as its effects are unlikely to be visible to the terminal user. In general, the 1984 revision is a superset of the 1980 one, including several extra parameters, facilities and error codings. Use of X29(84) would involve more problems of protocol conversion in the relay than would the use of X29(80); further to this, most sites external to the network will be providing X29(80). Thus, for ease of conversion, it should be a requirement that all Network Service entities (both hosts and PADs) can accept this. X29(84) is also a desirable option, but at this stage of network evolution, is not essential. The provision of NS29 is not recommended; the additional addressing capability of X25(84), and its ability to cater for multiple-hop calls, will prove sufficient to provide Network Service communication without resorting to a YBTS-like addressing scheme. Furthermore, NS29 is not a standard protocol. Another advantage of omitting it is that the - 15 - DRAFT December 85 non-mandatory N-EXPEDITED primitive is no longer required to be present in the Network Service. It should be noted that, as a consequence of the single hop nature of X25(80), X29(80)/X25(80) calls incoming to the network will be required to interact with the relay and place a further call on to the network. The same will be true of network entities attempting to make an X29(80) call to a 1980-based WAN, unless sufficient addressing information can be carried in the underlying X25(84) packet (Note: this problem, where it exists, could be solved by installing a mnemonic address translation table in the relay). TS29 calls received at the relay should be mapped into X29(80), and output on the network. Thus, the provision of X29(80) over the network is a requirement; sites which have also implemented X29(84) must be prepared to accept default settings and values for those parameters not defined in X29(80), when communicating with an X29(80)-only entity. The schema for conversion between the two revisions is outlined in the next section. _______________________________________ 5.1.3 Differences Between X29(80) and X29(84) The important differences between the the revisions are all additions in the 1984 version. They are: - additional X3 parameters and values for existing parameters (all of which are optional rather than mandatory) - the Reselection PAD message - explicit D-bit behaviour - Parameter Indication PAD messages carry error codes for invalid attempts to adjust parameters (always 0 in 1980) - additional codes for the Error Pad message _______________________________ 5.1.4 Conclusions and Recommendations Given the preceding discussions, the following recommendations are made: It is MANDATORY to provide X29(80) for both hosts and PADs on the network, and also DESIRABLE to provide X29(84). Where both options are available, the required version should be selectable on a per call basis. For PADs this selection is by configuration options and for hosts is by using different NSAP addresses. The use of NS29 is NOT RECOMMENDED. For calls incoming to the network: - X29(80) must enter an interactive dialogue with the relay in order to initiate a further call on the network - TS29 is converted to X29(80) over X25(84) - 16 - DRAFT December 85 For calls outgoing from the network: - X29(80) is mapped on to X29(80) or TS29, depending upon the number of subsequent hops required. Hosts on the network must be able to accept X29(80). It is desirable that they should also be able to accept X29(84). Network hosts and PADs should merely generate X29(80), conversion tasks being left to the relay. _____________ 5.2 File Transfer ____________ 5.2.1 Introduction The need for conversion between NIFTP (the Blue Book) and ISO File Transfer, Access and Management during a transitional phase has been referred to earlier. This arises from the requirement of users to be able to transfer files between all the computer systems in the academic community domain regardless of the protocols which happen to be implemented on each of the systems concerned. The ability also to perform file transfers involving systems external to the academic community is a desirable, but not essential, feature of the method of transition to be adopted. This part of the report is concerned with identifying the functionality which would be expected to be maintained throughout the transition. It is not intended to imply a target level of functionality to be expected in a host implementation of FTAM; that would be the subject of a different document, and may involve specification of new features. Two areas for investigation have been identified. First is the actual use made of Blue Book at present; the importance of supporting the existing uses of file transfer during a transitional period should be paramount. The second area is the comparison of the elements of protocol of the Blue Book and FTAM; this will determine the functionality of which a converter would be capable. The synthesis of the findings in each area will determine what we expect from a Blue Book to FTAM converter. _________________________ 5.2.2 Existing use of Blue Book The existing use of NIFTP which needs to be considered in the context of transition to ISO protocols comprises both transfers between similar machines (homogeneous transfers) and transfers between dissimilar machines (heterogeneous transfers). The need to consider homogeneous transfers arises from the likelihood of having several machines of the same type, but running different operating system versions, needing to communicate amongst themselves. Taking heterogeneous transfers first, it is clear that the minimum level of functionality which could be expected is reflected in the minimum subset of the Blue Book. It is equally clear, however, that most implementations are more sophisticated, allowing users to make use of other features of the Blue Book than the minimum. It is important to identify any use of optional features of the Blue Book which it is necessary to incorporate in a Blue Book to FTAM converter. This information is expected in the form of feed-back to the report. It is the responsibility of those who provide file - 17 - DRAFT December 85 transfer services to ascertain whether the proposed converter actually meets the needs of their users. The same problem affects homogeneous transfers, except more acutely, as the nature of such transfers encourages the use of more sophisticated features of the Blue Book. In particular, the transfer of binary files in locally significant formats would require increase complexity in the functionality of the converter. _______________________________________ 5.2.3 Proposed functionality of the Converter This section defines the proposed functionality available to users whose file transfers must pass via the converter. The specific details of how this functionality is to be achieved is detailed in section 8.1 The aim should be to minimise the impositions which the converter places on the user - as far as possible he should be able to achieve the desired effect without change to his existing method of working. __________________ 5.2.3.1 The User interface It is desirable that for the class of transfers supported the user need specify nothing different when initiating a transfer with a remote site whether access via the converter is required or not. This implies a strict mapping of attribute values leaving little or no flexibility to the user, but the aim of the transition should be to maintain the existing user service in as transparent a manner as possible, not to introduce new facilities which may be incompatible with existing practice. In other words, it is desirable for the user to be able to use the same command line to initiate a file transfer with a remote host, regardless of the protocols in use at each end. Although the implications of this aim are clear where a transfer is initiated from a Blue Book host, the situation regarding FTAM hosts is confused by the lack of a user interface to work from. It can be assumed, however, both that the interface is much the same as for Blue Book hosts and that the same principle applies, viz. that a different form of command should not be necessary, whatever the protocol supported by the remote host. _____________________ 5.2.3.2 Direction of transfer The converter should allow both directions of data flow from the standpoint of the initiator and the responder. ______________ 5.2.3.3 File Placement Where the responder is also the receiver it should be possible to create a new file on the receiver's filestore both where there is and there is not an existing file with the same name. (This corresponds to the 'Make' and 'Replace or Make' modes of access defined in the Blue Book). ________ 5.2.3.4 Filename The user should be able to specify the file on the remote system which is to be the object of the file transfer. - 18 - DRAFT December 85 ________ 5.2.3.5 Username The user must be able to specify the username on the remote system which will assume responsibility for the transfer. _____________ 5.2.3.6 Authorisation The user should be able to specify any relevant information, for example passwords; also it may be necessary to indicate an account to which the use of any resources associated with the transfer may be charged. ___________ 5.2.3.7 File Format As a minimum, the converter must support the transfer of text files formatted in the default formatting style of the Blue Book. It would seem likely however, that the transfer of text files containing embedded formatting characters and of binary files may well be required. For instance, the transfer of binary files between homogeneous systems represents a significant use of file transfer and in order to preserve this ability the converter would need to be capable of handling binary files. ________________________ 5.2.3.8 Facilities not supported It is not required that the converter should provide the recovery and restart functional units. Support for the 'Take Job Input' and 'Take Job Output' modes of access in the Blue Book cannot be provided. _______________________ 5.2.4 Required subset of FTAM Current work on this subject is based on the 2nd DP of the ISO File Transfer, Access and management standards DP8571 (presumably this will be superseded; presumably also CASE will be used). The FTAM standard defines functional units which may be combined to form different file service classes. The class required for the FTAM to Blue Book converter is the File Transfer class. The functional units required in the converter are the kernel functional unit, the grouping functional unit, both the read and write functional units and the limited file management functional unit. The enhanced file management functional unit, the recovery functional unit and the restart data functional unit are not required. The Presentation and Session functions required for the converter are defined in sections 7.3 and 7.2. ____________ 5.3 Job Transfer This report does not include a detailed discussion of the requirements for the OSI Job Transfer and Manipulation Service. Study of the problems involved will continue, but there is less urgency given the expected timescales for production of manufacturer supported products in this area. The study will also benefit from the steadily growing user experience of the current Red Book implementations, and practical trials of status modify facilities. - 19 - DRAFT December 85 However, the marked similarity between the OSI and Coloured Book work in this area, reflecting the importance of UK input to the ISO standards, should give some confidence that transition will be feasible. ____ 5.4 Mail Use of X.400 - text from Mail Group. Emphasis on MOTIS as eventual reference. Aside on multiplicity of mail systems and need for community gateways. ________________ 6. New Applications This clause covers new and exciting things OSI will offer. ________________ 6.1 Virtual Terminal This is not a transition problem. Some new facilities. (Should there be discussion of SSMP and its relation to VTP?) The value added by VTP at present is not clear. __________________ 6.2 Directory Services _____________________________ 6.3 Distributed Database Services ______________________ 7. Higher Layers - Target Summary to be provided ___________________ 7.1 Transport Protocols The minimum class of transport protocol required for interworking is class 0. This class gives practically no added value, and is correspondingly cheap to implement and operate. However, it satisfies the basic requirements of the currently established services in the academic community. It is therefore recommended as the mandatory class to which all systems shall conform. Any system capable of supporting a more complex class of transport protocol shall be capable of negotiating the use of class 0. The major user facility provided by the higher classes is transmission of T-EXPEDITED data. Some applications may require class 2 for the support of Expedited to allow the provision of higher layer synchronization services. Classes of transport protocol greater than or equal to 2 provide multiplexing facilities. However, the networks of primary interest in this community already provide adequately for multiplexing, and there are no tariff pressures for the function to be duplicated. It is not therefore expected that the multiplexing classes will be used during the OSI transition. - 20 - DRAFT December 85 _________________ 7.2 Session Protocols Fill in this section after application specific sections. BAS for X.400. BSS for FTAM (but note MAP subset could run over BCS). Express above as functional units. ______________________ 7.3 Presentation Protocols The presentation protocols provide powerful tools for the dynamic control and management of syntax and encoding between systems. It is the presentation layer which negotiates a suitable transfer syntax between incompatible systems. The full power of the presentation layer may be needed in future, but for transition purposes comparatively simple facilities will suffice. The support of the abstract syntax notation ASN.1 and of the corresponding encoding rules will be mandatory to support the OSI application protocols. They will also support the representation of the file types currently used with the Blue Book file transfer protocol, and will therefore be adequate for the transition. The protocol functions necessary are determined by the application protocols to be supported. Support of file transfer requires the support of multiple contexts. Defined context set restoration is not required. Context management may in future be desirable to allow the transfer of a wider range of file types, but will not be needed for transition purposes; any necessary abstract syntaxes can be requested when communication is established. ____ 7.4 CASE The functions defined in the first version of the Common Application Service Elements (CASE) kernel are very simple, and are necessary for the support of file transfer. There is no immediate need for the implementation of the Commitment, Concurrency and Recovery facilities (CCR), although they will be needed later for full support of Job Transfer. _________________________ 8. Applications - Transition ________________________________________ 8.1 Mapping of Blue Book and FTAM protocols. ____________ 8.1.1 Introduction In section 5.2 the facilities required in a Blue Book-FTAM converter were described. This section explains how those facilities can be realised. It is not necessarily intended as a design for a converter, but it will demonstrate the feasibility of performing the conversion described earlier. ______________________ 8.1.2 Blue Book as Initiator - 21 - DRAFT December 85 8.1.2.1 The user initiates a file transfer request (the manner of which is not of concern here). The name of the target site must be specified and such other information relating to filename, mode of access, authorisation and format as is appropriate. The request is then passed to the Blue Book File Transfer Server. 8.1.2.2 The Blue Book File Transfer Server must subsequently attempt first a connection to the required system. The NRS information for the remote system in NIFTP context will direct the call to the Blue Book to FTAM converter. The YBTS tag may contain information permitting the converter to make the appropriate onward call. The converter does not at this stage, however, have sufficient information to request an F-INITIALZE as it does yet know what presentation contexts will be required. At this stage the converter will simply accept the YBTS connection. 8.1.2.3 The Blue Book File Transfer Server will now send an SFT which may contain an arbitrary combination of parameters (there is no constraint on existing implementations of Blue Book - if the converter cannot support the actions implied by the supplied parameter values it will of course reject the transfer with RNEG). Assuming the SFT is acceptable, the converter will issue an F-INITIALIZE request with the following parameters:- Called and Calling address - (see section 4.3) Service Type - user correctable service Service Class - transfer class Functional Units - read, write, limited management and grouping Attribute Groups - storage group Communication Quality of Service - default Presentation Context Name - the set of presentation contexts which can be supported by the filestore Identity of initiator - derived from Username Current Account - derived from Account attribute value Filestore Password - derived from Username Password 8.1.2.4 The F-INITIALIZE request will be either rejected or accepted by the FTAM responder service in the target system. If the request is rejected then an RNEG must be returned to the Blue Book entity. The error information will be derived from the diagnostic returned with the confirm indication. It is essential that the distinction between retryable and non-retryable failures is preserved. 8.1.2.5 If the F-INITIALIZE is successful then the converter will issue a concatenated sequence of F-BEGIN-GROUP, F-SELECT or F-CREATE, F-OPEN and F-END-GROUP The parameters to the F-SELECT or F-CREATE are as follows:- Filename - derived from Filename attribute value Attributes - for further study Access Control - derived from Mode of Access attribute value Override - for F-CREATE if "Replace or Make" specified - 22 - DRAFT December 85 8.1.2.6 The converter will receive an indication of the success or failure of the attempt to establish an open regime. If the result was unsuccessful then an RNEG is returned to the Blue Book entity specifying the appropriate failure information. If successful, an RPOS is returned. 8.1.2.7 Following the normal path, the Blue Book entity then sends a GO, which is mapped by the converter to an F-READ or F-WRITE according to the Mode of Access specified on the SFT. 8.1.2.8 In case of F-WRITE the converter awaits SS from the Blue Book entity followed by data. This is mapped into F-DATA requests. 8.1.2.9 Eventually ES is received from the Blue Book entity and this is mapped to an F-DATA-END request followed by an F-TRANSFER-END request. 8.1.2.10 When the F-TRANSFER-END confirm is received by the converter it is able to issue an ER (or QR if necessary) back to the Blue Book entity. 8.1.2.11 In the case of F-READ the converter awaits data from the FTAM responder. SS is sent before any data which is received is transformed as appropriate and sent to the Blue Book entity. 8.1.2.12 Eventually an F-DATA-END indication is received by the converter and it responds by sending F-TRANSFER-END. 8.1.2.13 When the F-TRANSFER-END confirm is received the converter sends ES to the Blue Book entity, which responds with ER. 8.1.2.14 The Blue Book entity, on both read and write cases, now sends STOP. This is mapped by the converter to a single concatenated sequence to release the file open regime consisting of F-BEGIN-GROUP, F-CLOSE, F-DESELECT and F-END-GROUP. 8.1.2.15 When the F-BEGIN-GROUP, F-CLOSE, F-DESELECT and F-END-GROUP confirms are received (as a single concatenated sequence) the converter sends a STOPACK to the Blue Book entity. _________________ 8.1.3 FTAM as Initiator 8.1.3.1 The user initiates a transfer with a remote system and in due course an F-INITIALIZE will be requested by the FTAM entity with the following parameters :- Called and Calling address - (see section 4.3) Service Type - user correctable service Service Class - transfer class Functional Units - read, write, limited file management and grouping Attribute Groups - empty or possibly storage group Communication Quality of Service - as required Presentation Context Name - set of presentation contexts required for the transfer Identity of Initiator - used for generating Username Current Account - used for generating Account Filestore Password - used for generating Username Password - 23 - DRAFT December 85 8.1.3.2 The F-INITIALIZE indication is received by the converter. Assuming its parameters are acceptable, the called address is used to generate a YBTS address to which a connexion is attempted. Any failure causes the appropriate negative response to be issued but if the connexion is successful a positive response is issued. 8.1.3.3 On receipt of a positive F-INITIALIZE confirm, the FTAM entity issues a concatenated sequence of F-BEGIN-GROUP, F-SELECT or F-CREATE, F-OPEN and F-END-GROUP. The parameters to the F-SELECT or F-CREATE are as follows :- Filename - used for generating Blue Book Filename attribute value Attributes - for further study Access Control - used for generating Mode of Access; only one of "read" or "extend" is allowed. Override - set if "Replace or Make" is required 8.1.3.4 The converter, on receipt of the group of primitives, may reject it if any of the supplied parameters are unacceptable. Otherwise it constructs and sends an SFT request with the following parameters :- Protocol Identification - FTP-B(80) Mode of Access - Read, Make or Replace or Make (Replace Only?) Text Formatting - choice of default or embedded control characters Text Transfer Code - Private (if required) Private Transfer Code Name - if required for specific formats Facilities - compression Data Type - Binary (if required) Filename - derived from F-SELECT or F-CREATE Username - derived from F-INITIALIZE Username Password - derived from F-INITIALIZE Account - derived from F-INITIALIZE 8.1.3.5 The Blue Book entity returns either an RPOS or an RNEG enabling the converter to generate the appropriate response to the FTAM entity. 8.1.3.6 Assuming the successful case, the FTAM entity now sends an F-WRITE or an F-READ request. When this has been received by the converter the converter sends GO to the Blue Book entity. 8.1.3.7 In the case of F-WRITE, the converter waits F-DATA indications then forwards the received data to the Blue Book entity. When F-DATA-END and F-TRANSFER-END have been received the converter send ES, waits for ER and then returns an F-TRANSFER-END response. 8.1.3.8 In the case of F-READ, the converter waits for data from the Blue Book entity, then forwards it in F-DATA requests. When ES is received, the converter sends F-DATA-END and waits for an F-TRANSFER-END indication. When this is received, the converter sends ER to the Blue Book entity and an F-TRANSFER-END response to the FTAM entity. - 24 - DRAFT December 85 8.1.3.9 In both cases the converter now awaits the F-CLOSE and F-DESELECT grouping, then sends STOP to the Blue Book entity. 8.1.3.10 When STOPACK is received by the converter it can respond to the F-CLOSE and F-DESELECT. 8.1.3.11 Receipt of F-TERMINATE causes the YBTS connexion to be released. ____________ 8.2 Job Transfer See section 5.3. ____ 8.3 Mail Text from mailgroup. _________________________ 9. Timescales and Milestones To be provided. This should talk about critical steps. Consultation and action timetable. Provision of converters and gateways. User information and publicity needed. Identify key dependencies (mostly ISO et al). - 25 - DRAFT December 85 ________ Annexe A ___________________________ Network Service Error Codes This annex states the mapping to be performed between Yellow Book error codes and OSI Network Service reason codes. Two tables give the functions for mapping to and from the OSI Reasons. Since these mappings are not one to one, mapping to a Yellow Book code should be accompanied by an explanatory text message of the form "OSI-NS code nn" where "nn" is the hex representation of the X.25 diagnostic code defined to represent the original OSI Network Service reason. These codes are defined in DP 8878 and are reproduced here in a third table for convenience. - 26 - DRAFT December 85 _________ Table A.1 _______________________________________________ Yellow Book to OSI Network Service Code Mapping Successful Completion of call disconnection - normal condition / NS User Disconnect in response to None received disconnect No connection (unspecific) connection rejection - reason unspecified (permanent) Number busy connection rejection (transient condition) Out of order connection rejection (permanent condition) Invalid address connection rejection - NSAP address unknown (permanent condition) Access barred connection rejection - reason unspecified (permanent condition) Incompatible facilities (QoS) connection rejection - QoS not available (permanent condition) No reverse charging connection rejection - reason unspecified (permanent condition) Network congestion connection rejection - NSAP unreachable (transient condition) Message too long connection rejection - incompatible information in NS-User-Data Protocol error Disconnect - permanent condition Application failure Reset - reason unspecified Transport service failure Disconnect to Reset Disconnect - permanent condition Reset before Accept Network failure Disconnect - transient condition Flow control error Reset - reason unspecified Timeout Node going out of service No record of connection disconnect - transient condition Call killed by operator Call abandoned by ts Congestion disconnect - transient condition reset - congestion - 27 - DRAFT December 85 _________ Table A.2 _______________________________________________ OSI Network Service to Yellow Book Code Mapping Disconnect - permanent condition Transport service failure Disconnect - transient condition Congestion Connection rejection - NSAP address Invalid address unknown (permanent condition) Connection rejection - NSAP unreachable Number busy (transient condition) Connection rejection - QoS not available Incompatible facilities (permanent condition) Connection rejection - QoS not available Congestion (transient condition) Connection rejection - reason unspecified Access barred (permanent condition) Connection rejection - reason unspecified Node going out of service (transient condition) Disconnection - normal condition Successful completion Disconnection - abnormal condition Application failure Connection rejection - incompatible Message too long information in NS-User-Data Reset - congestion Congestion Reset - reason unspecified Network failure Reset - user resynchronization Successful completion - 28 - DRAFT December 85 _________ Table A.3 _____________________________ Representation of OSI reasons Reason Value (hex) Reset - Reason Unspecified / NS Provider E9 Reset - Congestion / NS Provider EA Reset - User Resynchronization / NS User FA Disconnection - permanent condition / NS Provider E2 Disconnection - transient condition / NS Provider E1 Connection rejection - NSAP address unknown (permanent) E8 / NS Provider Connection rejection - NSAP unreachable (transient) E7 / NS Provider Connection rejection - QoS not available (permanent) E6 / NS Provider Connection rejection - QoS not available (transient) E5 / NS Provider Connection rejection - reason unspecified (permanent) E4 / NS Provider Connection rejection - reason unspecified (transient) E3 / NS Provider Disconnection - normal condition / NS User F1 Disconnection - abnormal condition / NS User F2 Connection rejection - permanent condition / NS User F5 Connection rejection - transient condition / NS User F4 Connection rejection - QoS not available (permanent) F7 / NS User Connection rejection - QoS not available (transient) F6 / NS User Connection rejection - incompatible information in F8 NS-User-Data / NS User - 29 - DRAFT December 85 _______ Annex B ________ Glossary This annex provides a brief glossary of terms used in the body of the report. It includes the expansion of common acronyms and abbreviations. CASE Common Application Service Elements; CEN CENELEC CEPT DTI Department of Trade and Industry FTAM File Transfer, Access and Management; the only real OSI standard. Intercept Strategy ? ISO ? LAN Local Area Network NRS Name Registration Scheme NSAP Network Service Access Point NSDU Network Service Data Unit OSI Open Systems Interconnection; a style of communuication based on vendor independent standards, in which the aim is to remove technical impediment from the process of communication between unlike systems. OSI Reference Model An architectural model which defines the relationship between the various standards needed to support OSI, and establishes common terminology for use therein. Presentation The layer in the OSI Reference Model which is concerned with the negotiation of encodings and formats to be used between open systems. VANS Value Added Network Service; a service provided by one host on a network to others, which provides facilities accessed via the network in support of the application being performed. WAN Wide Area Network _______ Annex C - 30 - DRAFT December 85 ___________________________ References to OSI Standards [To be provided] - 31 -