1 0 Ref. A4 - SECNET - ADDRESSING SCHEME (Ref. A4) + ______ __________ ______ ___ __ 0 Version 2 + _______ _ 0 8 March 1982 + _ _____ ____ 0 P M Girard + _ _ ______ 1. The Basic Mechanism + ___ _____ _________ 0 The scheme is designed to be compatible with the Study Group 3 Transport Service specification (Ref. A6). 0 Process A wishes to communicate with Process B across a number of networks joined by "gateways". There is a "transport station" at each end, and these, together with the intervening gateways, are responsible for setting up the necessary "connection". 0 Logically, a "transport station" is very similar to a "gateway", and to simplify the description the term "gateway" will be used to cover both, except where a distinction is necessary. A transport station can be thought of as a gateway between a network and a host system. 0 To set up the connection, a "connection request" must be launched by Process A, and must find its way via the intervening gateways to Process B. To cross each network, a Level 3 network "call" must be created, and the connection request (which can be considered as belonging to Level 4) must be passed across it as if it were ordinary data - this is essential to maintain a proper separation of protocol levels. In X25 networks, the connection request will thus in practice be carried in the Call User Data Field (CUDF). 0 The main ingredient in the connection request is the "called address" parameter. Each gateway must be able to understand the "called address" sufficiently well to set up a call across the next network in the series. It must also pass on a "called address" that will be likewise + _______ comprehensible to the next gateway. Thus the "called + ____ address" is not a fixed field: it is liable to undergo a transformation in each gateway. 0 A less important ingredient in the connection request is the "calling address" parameter. This is initially empty, but as the connection request passes through the gateways, the field will undergo transformations such that by the time it reaches Process B, it contains the address of A as seen from B. 0 In what follows, attention will be focussed mainly on the - SERCNET - ADDRESSING SCHEME PAGE 1 1 0 Ref. A4 0 "called address"; it should be remembered that similar considerations apply to the "calling address". - 2. "Names" and "Domains" + _____ ___ _______ 0 The type of "called address" transformation that gateways must perform depends on how entities in the multi-network system are named. 0 The basic mechanism is so flexible, that in principle each gateway could define its own names for all entities accessed through it. It would then have to transform any such name into a new "called address" understandable to the next gateway. Needless to say, such an absence of co- ordination would be intolerable to users, because they would then find themselves using different names for the same service, depending on which host they were calling from and which gateways the connection had to go through. 0 Hence there is a need for Naming Authorities, able to establish the use of particular names within a given "domain" of the multi-network system. 0 The chaotic situation referred to above would result if there were single-host domains. The simplest type of domain which is basically satisfactory would appear to be a single-network domain. The Naming Authority for such a domain would assign names to all addressable entities in the network, and all gateways into it would be expected to understand these names rather than others. 0 Where there is a lot of inter-network traffic, a number of networks may be combined to form a multi-network domain,with a single Naming Authority covering them all. This leads to a larger number of names, more elaborate address transformation tables, and greater difficulty in choosing short unique names; however, it is technically quite feasible. 0 The remainder of this paper concentrates on the naming of entities in SERCnet, considered primarily as a single- network domain. However, to the extent that Daresbury Network names will be directly usable from SERCnet and vice versa, the elements of a two-network domain will be already present. - 3. What we need to specify for SERCnet + ____ __ ____ __ _______ ___ _______ 0 a) How DTEs are to be addressed at X25 Level 3. - SERCNET - ADDRESSING SCHEME PAGE 2 1 0 Ref. A4 0 b) How the X25 CUDF is to be used, and its maximum length. 0 c) How entities are to be named at Level 4 (transport level). 0 d) What sort of address transformations are required. 0 e) What sort of user interface is required. - 4. Level 3 DTE Addresses in SERCnet + _____ _ ___ _________ __ _______ 0 A decimal number of up to 15 digits is used. When placed in the header of a Call Request packet, it is stored in packed decimal form in the normal X25 manner. If the number is 12 digits long or less, it represents a pure DTE number. If it is more than 12 digits long, any digits beyond the 12th represent a Level 3 sub-address. Leading zeroes may be optionally omitted in all contexts if the address is a pure DTE number. 0 It will be noted that the above provisions are a superset of the PSS rules, which require a DTE number to be 12 or 14 digits long. To ensure compatibility with PSS, any sub-addresses assigned on SERCnet must in practice be 2 digits long. 0 Eight digits should be sufficient at the present time, split up as follows:- aasssppp where aa = area code, sss = packet switch, ppp = processor. 0 This assignment of digits has a format compatible with X121, but the DNIC field is defined to be zero. The suppression of leading zeroes could be eliminated from the network either by defining a DNIC beginning with a non- zero digit, or by being assigned an official DNIC from the range assigned to the UK. - 5. X25 Call User Data Field + ___ ____ ____ ____ _____ 0 Within the SERCnet, this should have a maximum length of 128 bytes. The connection request, consisting of a "called address" followed by a "calling address", should start at the 5th byte of the CUDF, and no overflow into subsequent packets should be allowed. 0 Gateways into networks that allow such overflow must be able to cope with it. In particular, this will probably apply to a gateway into PSS, at least for international calls. - SERCNET - ADDRESSING SCHEME PAGE 3 1 0 Ref. A4 - The format of the CUDF is described and illustrated in a later Section. - 6. Level 4 Names in SERCnet + _____ _ _____ __ _______ 0 In the SG3 specification, two types of Level 4 name are discussed. An "address" is a name specifying the location + ________ of an entity, and this may change if the network is re- configured. A "title" identifies an entity without implying a particular location: thus the title will remain the same even if the address changes. 0 (Note: "Address" in this sense should not be confused with its special meaning in the terms "called address" and "calling address".) 0 In SERCnet, every DTE (or "host") has a Level 4 "address", which is defined to be the same as its Level 3 address. It is therefore numeric and up to 15 digits long. When such an address appears in a connection request, it is stored as up to 15 IA5 characters with arbitrary parity- bit settings, and is delimited by '.' (dot). 0 A "title" in SERCnet is an alphanumeric string of up to 8 characters, the first character being alphabetic. Upper and lower case letters are equivalent, and IA5 parity-bit settings are arbitrary. A title (unlike an address, which is defined only for a DTE) may be assigned to any entity + ___ ______ accessible via the network, for instance to a service, to a host, to a gateway, or to a sub-address within a host. When a title appears as part of a "called address" or "calling address" parameter, it must be delimited by a dot if it is not the last field of the parameter. 0 Non-ambiguous abbreviations of titles may be allowed by some gateways. - 7. Use of Numeric Addresses + ___ __ _______ _________ 0 A gateway into SERCnet must always be able to accept a "called address" which begins with a numeric address followed by a dot. Hence all hosts in the network are necessarily addressable at least in this form. 0 The numeric address is converted to packed decimal form for use as a DTE number in the X25 packet header. The required conversion of the "called address" before forwarding it in the CUDF is to remove the DTE number and dot from the front, and forward the rest transparently. - SERCNET - ADDRESSING SCHEME PAGE 4 1 0 Ref. A4 0 The "calling address" may be transformed by adding the name of the previous gateway to the front, and then + ________ substituting a title for the whole, if there is one. 0 Wherever possible, titles should be used rather than addresses, because addresses may change if the network configuration is altered. - 8. Use of Titles + ___ __ ______ 0 Although all titles used in the network should be defined by the central Naming Authority, gateways and transport stations are not obliged to recognise the full set. Indeed the transport station of a small machine may only need to recognise a few titles that are commonly used from that system. Where no title is provided, it is necessary to fall back on the use of numeric addresses. 0 Titles should be interpreted entirely by table look-up, and the transformation to be applied to obtain the beginning of the new "called address" for forwarding should also be completely specified in the table entry. If this principle is consistently followed, it becomes a fairly simple matter to incorporate new titles as required, and also to extend the system to cover multi- network domains. 0 If the title is terminated by a dot, then everything following the dot should be passed through transparently on the end of the new "called address" given by the table. 0 Titles should as far as possible identify services rather than hosts, because then the user normally needs to input only a single name, rather than a host name followed by a sub-address name. 0 However, where a host supports a lot of services, it may be more economical to define a name for the host and require the user to specify a sub-address as well. - 9. Host Sub-addresses + ____ ___ _________ 0 The term "sub-address" (at Level 4) relates specifically to addressing within destination hosts, as distinct from gateways into other networks. 0 In SERCnet hosts, a sub-address should normally consist of a name identifying the service, optionally followed by a dot and further sub-addressing: e.g: ITP - SERCNET - ADDRESSING SCHEME PAGE 5 1 0 Ref. A4 0 HASP49 ITP.T123 0 In the first example, the protocol name alone is assumed to be sufficient to connect to the required service. In the second example, the number incorporated in the name would in practice be a HASP sign-on number. In the third example, the number might represent a particular slot or process. Any addressing after the dot may be considered to select a "sub-service". 0 Where a title represents a host, the user must supply an appropriate sub-address explicitly. Where a title represents a service, however, the software can supply the sub-address, or at least part of it (e.g: ITP in the third example) from its table. 0 Sub-addresses for private servers should be given names beginning with USR, to distinguish them from standard system services. - 10. User Interface + ____ _________ 0 A connection request coming in across a user interface is logically the same as a connection request coming in via a gateway. Indeed the user interface software may be considered to convert the user's actual input to look exactly like a standard connection request, before passing it to his local gateway - i.e: to his transport station. Hence this section does not need to deal with the problems of title and address conversion by a transport station; these matters have already been covered by earlier sections. The question here is of what the user actually inputs, and ideally this should be the same everywhere, as far as possible. 0 When a connection request is made from a user device or by a user-level process, it is necessary for the local software to know what protocol it should use. Each such device or process should therefore have associated with it a default protocol so that requests from that device will + ________________ automatically assume this protocol. If more than one protocol is supported from a given device, then local commands are needed to allow the default setting to be altered. If a particular title in the local table represents a service known to use a certain protocol, then the correct protocol can be ensured by inserting a protocol identifier in the table entry as well. This would then override whatever default was in use for the requesting device or process. 0 To achieve a uniform appearance to users everywhere, it is - SERCNET - ADDRESSING SCHEME PAGE 6 1 0 Ref. A4 0 recommended that requests for connections should be introduced by a common escape sequence such as !! so that a terminal user, for instance, might input connection requests looking like the following: !!RLGAI !!ELEC !!TSO !!DL.999999.123 - 11. Examples + ________ 0 (a) The following table illustrates the essential components of a transport station (or gateway) addressing table:- 0 *********************************************************** * TITLE * DTE * Transformed Title for CUDF * Protocol * *********************************************************** * RLGAI * 4 * ITP * ITP * * RLGAF * 4 * FTP * FTP * * RLIAH * 1 * HASP19 * HASP * * DL * 2 * - * - * * TSO * 2 * 064700 * ITP * * PSS * 9 * - * - * * XXNETFTP * 9999 * XXNET.ABCD.123.E * - * *********************************************************** 0 The title RLGAI in this example implies use of ITP protocol and specifies sub-address ITP at the other end. RLIAH implies HASP protocol and remote number 19. The title DL is the name of the Daresbury gateway: no particular protocol is implied, and the title transforms to nothing, the remainder of the user's input going straight into the new "called address" field. 0 The title TSO is effectively a common title belonging to a two-network "domain" (as previously defined), and it transforms into a name meaningful to the Daresbury gateway. XXNETFTP illustrates that the transformations can in principle be arbitrarily complex. 0 (b) Examples of User Input:- 0 If the user types !!RLGAI, he will automatically select ITP protocol, and call the ITP service in DTE 4. 0 If this service happens to provide independently addressable sub-services (e.g: particular slot numbers), the user could input for instance: !!RLGAI.T123 The first field is the title to be looked up in the local table, the rest being simply added on to the result of the - SERCNET - ADDRESSING SCHEME PAGE 7 1 0 Ref. A4 0 transformation specified by the table entry. Thus the new "called address" will become: ITP.T123 0 Similarly, if the user inputs: !!XXNETFTP.9876.ABCD the new "called address" will be as follows: XXNET.ABCD.123.E.9876.ABCD 0 If the user wants to access some facility in the Daresbury Network for which there is no explicit title in his local table, then he can use the title for the Daresbury gateway, and add on whatever further addressing may be needed: e.g: DL.099900.123 The table will then cause 099900.123 to become the new "called address". 0 Finally, the user may have no title in his table at all for accessing a particular service or even a particular host. In that case, he can fall back on the use of a numeric address (DTE number) as the first field: e.g: 5.ITP 9.436710.QWERT (9 being a gateway). - 12. Format of Address Fields in the CUDF + ______ __ _______ ______ __ ___ ____ 0 The connection request must start at the 5th byte. The "called address" and "calling address" are parameters with the same format and follow one another in that order. Further parameters should at present be tolerated but ignored. The first byte of each parameter is a 'length byte', which is the length of the parameter excluding the length byte itself (maximum 63 bytes). However, the top bit of the length byte must always be set on, so its minimum value is actually 128 (or X'80'). 0 Example: The CUDF contents required to access the ITP service in the RAL IBM from DTE 8, ITP process T123, would be: 0 5th byte: X'83' 6th to 8th byte: ITP 9th byte: X'86' 10th to 17th byte: ITP.T123 0 In this example, the CUDF must be exactly 17 bytes long. The DTE addresses 1 and 8 will be in the packet header in packed decimal form. - - SERCNET - ADDRESSING SCHEME PAGE 8 1 0 Ref. A4 0 13. References + __________ 0 A5) SERCnet - Addressing Summary (P.M.Girard) A6) A Network Independent Transport Service (PSS User Forum Study Group 3) - - - - - - - - - - - - - - - - - SERCNET - ADDRESSING SCHEME PAGE 9