Network Working Group April 1991 Internet Draft M.T. Rose Internet Draft CO/CL Interworking -- Short-Term Apr 91 An Approach to CO/CL Interworking -- Part II: The Short-Term -- Conventions for Transport-Service Bridges in the absence of Internetworking Wed Apr 17 09:21:02 1991 CO/CL Interworking Workshop July 24-26, 1990 April 5, 1991 M.T. Rose (editor) Performance Systems International, Inc. mrose@psi.com 1. Status of this Memo This document outlines the short-term aspects of the approach described in "An Approach to CO/CL Interworking -- Part I: Introduction". This approach has been developed at the request of the FNC and RARE communities, but may be applicable to other communities. This memo does not explicitly specify a standard, however, it may form the basis for policy within the FNC, RARE, or other communities. Distribution of this memo is unlimited. Questions should be directed to the editor. M.T. Rose (editor) [Page 1] Internet Draft CO/CL Interworking -- Short-Term Apr 91 2. Introduction The short-term approach outlined in [1] is based on the use of transport-layer relays known as transport service bridges, or TS-bridges. Further, the short-term approach also assumes that knowledge of the TS-bridges is present in the end- systems. The companion memo [2] identifies solutions in which end-system knowledge of transport-layer relays is avoided. The purpose of this memo is two-fold: first, modifications to the operational characteristics of end-systems are described; and, second, the operational characteristics of TS-bridges are described. M.T. Rose (editor) [Page 2] Internet Draft CO/CL Interworking -- Short-Term Apr 91 3. Impact of TS-bridges on End-Systems The fundamental characteristic of the short-term solution is that initiating end-systems must have knowledge of TS-bridges; further, the short-term solution requires that the initiating end-system act in a non-standard fashion in order to establish a connection when using a TS-bridge. 3.1. Initiator use of TS-bridges Section 3 of [1] describes a conceptual algorithm that might be used by an initiating end-system during transport connection establishment. For an initiating transport entity, knowledgeable about TS-bridges, these three steps are followed in order to establish a connection: (1) The local transport entity looks at each network address in the transport address, determines the OSI community (as defined in [1]) that the network address belongs to, and associates the corresponding TS-stack with each address. For each network address, if the initiating end-system does not belong to the OSI community for that address, the entity sees if there is a reachable TS-bridge that services that community. If not, the address is removed from further consideration. Otherwise the address is marked with a reference to that TS-bridge. If all of the addresses are removed, then there are no known TS-bridges to any of the network addresses, and the local transport entity immediately generates a transport disconnect. (2) The remaining network addresses are then ordered, based on the desired QoS and the "closeness" of the actual network address. (3) For each network address, if there is an associated TS- bridge, then the local transport entity starts the protocol for the TS-stack which can reach the TS-bridge. When establishing the connection, the entity replaces the called transport selector with a new string of octets formed by encoding the original network address and the M.T. Rose (editor) [Page 3] Internet Draft CO/CL Interworking -- Short-Term Apr 91 original transport selector. If there is a possibility that the local network address will not be carried by the underlying network service, then as a local option, the local transport entity may also encode its local network address and transport selector as the calling transport selector. Otherwise, if there is no TS-bridge associated with the network address, the local transport entity starts the protocol machine for the TS-stack associated with that address. In either case, this results in a transport protocol and underlying network service being invoked. Once a transport connection is established, the remaining network addresses are ignored. 3.1.1. Use of TS-bridge knowledge During the steps above, the initiating end-system must be able to make these decisions: (1) Does the destination network address share a community in common with the initiating end-system (is a destination network address directly reachable)? Local knowledge is used to make this determination; for example, a table or local directory may be employed. (2) If a destination network address is not directly reachable, which TS-bridge shall be used? Communities participating in the short-term solution will manually maintain tables, which contain this information. A separate table will be maintained for each initiating community. The table will contain two columns: the first containing the NSAP prefix of a group of destination addresses, and the second column containing the network address of a TS-bridge which can be used to reach end- systems in that group. Multiple entries may be present for the same NSAP prefix if several TS-bridges can be used to reach end-systems in that group; each site administrator will be responsible for ordering the TS- bridges to account for "closeness". Note that since a M.T. Rose (editor) [Page 4] Internet Draft CO/CL Interworking -- Short-Term Apr 91 destination community can be described as a set of NSAP prefixes, there may be several entries in the table for a particular destination community. For ease of use, each table may be available as an ASCII file, with each entry terminated by a CR-LF sequence. Within an entry, the NSAP prefix along with the network addresses of each TS-bridge may be expressed using Kille's string encoding[3]. For example: NS+540072872203 Int-X25(80)=23426020017299+PID+03018000 (3) How is the destination network address and transport selector encoded? A compact binary encoding scheme is used to represent the destination network address and transport selector as an octet string of length m: octets contents encoding ----------- --------------- ----------------------------- - - 0 length of NSAP "n" as an unsigned-integer 1 length of NSAP "n" as an unsigned-integer 2-(n+1) destination NSAP concrete binary representatio n (n+2)-(m-1) destination TSEL string of octets The resulting string of octets is placed in the called transport selector by the initiating end-system. When examining a transport selector, s, of length m octets, a simple check can be used to see if it encodes a network address and transport selector: (m > 4) AND (s[0] = s[1]) AND (s[0] > 2) AND (s[0] <= (m-2)) This is termed the encoded-TSEL test. Note that if the encoding of the original called network address and transport selector exceeds the limitation of the local transport entity (usually 32 octets), then a TS-bridge can not be used. M.T. Rose (editor) [Page 5] Internet Draft CO/CL Interworking -- Short-Term Apr 91 3.1.2. Redirection procedure The procedure for selection of a TS bridge described in Section 3.1.1 is based on tables describing the relation between bridges and communities. These tables may be difficult to export to a large number of stations, and there is always the risk that the knowledge table in a particular end-system be partial, or partially out-of-date. In order to ease the management of these end-systems, a "redirection procedure" is introduced: (1) When a TS-bridge determines that a transport connection request is misrouted, it can invoke a T-DISCONNECT.REQ primitive, passing routing information in the "disconnect information" parameter of this primitive. (2) Upon reception of the T-DISCONNECT.IND, the requesting transport station decodes the "disconnect information", and uses the routing information to renew the T- CONNECT.REQ. The "disconnect information" parameter is described in the transport protocol specification as a string of octets. The routing information will be encoded as an octet string of length m: octets contents encoding ------ -------- --------- 0 length of SNPA "n" as an unsigned-integer 1 length of SNPA "n" as an unsigned-integer 2-(n+1) destination SNPA representation depends of subnet technology (n+2)-(m-1) destination TSEL string of octets The resulting string of octet is placed in the disconnect information by the TS-bridge that initiates the redirection procedure. When receiving a T-DISCONNECT.IND, the transport station will check that the "cause" parameter is equal to "address unknown" and that the disconnect information parameter is present, as a string, s, of m octets, and that it verifies: (m > 4) AND (s[0] = s[1]) AND (s[0] > 2) AND (s[0] <= (m-2)) This is termed the encoded-REDIRECT test. M.T. Rose (editor) [Page 6] Internet Draft CO/CL Interworking -- Short-Term Apr 91 If this test fails, the T-DISCONNECT.IND should be passed to the transport user. The encoding of the destination SNPA depends on the network technology. Two encoding are specified for RFC-1006 and X.25 based subnetworks: (1) When the subnetwork uses RFC-1006 technology, the SNPA is encoded on 6 octets. The first four octets encode the IP address, in network order. The last two octets encode the TCP port, in network order. (2) When the subnetwork uses X.25 technology, the "n" octets are split into a first octet which encode the length of the X.121 address in unsigned binary format, then "p" octets which encode the X.121 address itself as a string of ASCII digits, then the remaining "n-p-1" octets which encode the X.25 "protocol identifier" passed in the call user data field, as a string of octets. 3.1.3. If the initiator can not be modified Of course, there is always the question of how can a transport entity, which can not be modified, be forced to use a TS- bridge. In most circumstances, these implementations can be "tricked" to use a TS-bridge, on a case-by-case basis. Usually, these "out of the box" implementations have an address database. For a small number of end-systems in other OSI communities that the end-system needs to talk to, the address database can be modified by hand; i.e., the address database is modified such that these end-systems are listed as having the same network address as the TS-bridge, and the transport selector for the services offered by those end- systems is modified to encode the actual network address and transport selector. Obviously, such an approach does not scale, but for implementations so limited it is a work-around. M.T. Rose (editor) [Page 7] Internet Draft CO/CL Interworking -- Short-Term Apr 91 3.2. Responder use of TS-bridges A responding transport entity need not be modified with this approach. However, as a local matter responding implementations may apply the encoded-TSEL test to the calling transport selector and accordingly note the actual initiator transport address. M.T. Rose (editor) [Page 8] Internet Draft CO/CL Interworking -- Short-Term Apr 91 4. Operation of TS-bridges The state machine and parameterization described in Sections 6.1 and 6.2 of [1] is used. When a TS-bridge receives a T-CONNECT.IND primitive, as described in [4]: (1) If the called transport selector fails the encoded-TSEL test, the incoming connection is disconnected. Otherwise, the TS-bridge decodes the actual destination network address and transport selector from the called transport selector. (2) The TS-bridge examines the calling transport selector, and if this fails the encoded-TSEL test, then the encoding is applied to the calling network address and transport selector, and the resulting string of octets replaces the calling transport selector. If the length of the resulting string of octets exceeds the limitation of the local transport entity (usually 32 octets), then no substitution is made. (3) The TS-bridge now determines if it can directly reach the destination network address. If so, a T-CONNECT.REQ primitive is invoked with the called transport selector equal to the value determined in step 1 (the actual destination transport selector), and the calling transport selector equal to the value determined in step 2. (4) If the TS-bridge determines that it can not directly reach the destination network address, then the TS-bridge determines the network address of the next TS-bridge in sequence, and invokes a T-CONNECT.REQ primitive, with the original (encoded) called transport selector, and the calling transport selector equal to the value determined in step 2. (5) If the TS-bridge determines that the network address of the next TS-bridge (step 4) or that of the called system (step 3) is reachable via the same "subnetwork" through which the call is incoming, then the TS-bridge can elect to use the redirection procedure specified in Section 3.1.2. It will invoke a T-DISCONNECT.REQ primitive, M.T. Rose (editor) [Page 9] Internet Draft CO/CL Interworking -- Short-Term Apr 91 where the DR information parameter will contain the encoding of the address to use on the "subnetwork" and that of the "called transport selector" determined in step 3 or step 4, and where the "cause" parameter will be set to "address unknown". When a TS-bridge receives a T-CONNECT.CNF primitive, as described in [4]: (1) The TS-bridge invokes a T-CONNECT.RSP primitive with an empty responding address parameter. If instead of receiving a T-CONNECT.CNF primitive the TS- bridge receives receives a T-DISCONNECT.IND it will: (1) Check whether the "cause" and "disconnect information" parameter pass the encoded-REDIRECT test. Otherwise, the incoming connection will be disconnected. (2) Check whether this call has already been redirected. If a "maximum number of redirection" threshold is reached, the incoming connection will be disconnected. (3) Invoke a new T-CONNECT.REQ primitive towards the address deduced in step 1 from the "disconnect information" parameter, using the called transport selector determined in step 1 and the calling transport selector of the original T-CONNECT.REQ primitive. M.T. Rose (editor) [Page 10] Internet Draft CO/CL Interworking -- Short-Term Apr 91 5. Operation of TS-Bridge Where X.25(84) With Address Extension Fields is Supported The procedures in section 4 of this document are modified as described below when TP0 is operating over X.25(84) with address extension facilities which can accommodate 40 digits/20 octets NSAP addresses. In this environment the TS- bridge and initiating systems on the X.25(84) subnetwork insert the called and calling NSAP addresses in the address extension fields and the Transport selectors are not used to carry NSAP addresses. Thus the encoding scheme in 3.1.1 item (3) does not apply over the X.25(84) hop and the Transport selectors are used for their normal purposes, or may be null. 5.1. For calls to the TP0/X.25(84) subnetwork When a TS-bridge receives a T-CONNECT.IND primitive, as described in [4]: (1) If the called transport selector fails the encoded-TSEL test, the incoming connection is disconnected. Otherwise, the TS-bridge decodes the actual called NSAP address and transport selector from the called transport selector. The called NSAP address is inserted in the X.25(84) called address extension field. (2) The TS-bridge decodes the calling transport selector and inserts the derived calling NSAP address in the X.25(84) calling address extension field. If the calling transport selector fails the encoded-TSEL test, then the transport selector is passed on unmodified and nothing is inserted in the X.25(84) calling address extension field. (3) The TS-bridge now determines if it can directly reach the destination NSAP address. If so, a T-CONNECT.REQ primitive is invoked with the called transport selector equal to the value determined in step 1, and the calling transport selector equal to the value determined in step 2. The associated X.25 network connection uses the NSAP addresses derived from steps 1 and 2 in the address extension fields. (4) If the TS-bridge determines that it cannot directly reach the destination NSAP address, then the TS-bridge M.T. Rose (editor) [Page 11] Internet Draft CO/CL Interworking -- Short-Term Apr 91 determines the X.25 subnetwork address of the next TS- bridge in sequence, and invokes a T-CONNECT.REQ primitive, and associated X.25 network conection with the parameters as described in (3). When a TS-bridge receives a T-CONNECT.CNF primitive, as described in [4]: (1) The TS-bridge invokes a T-CONNECT.RSP primitive with an empty responding address parameter. 5.2. For calls from the TP0/X.25(84) subnetwork When a TS-bridge receives a T-CONNECT.IND primitive, as described in [4]: (1) If the incoming call does not contain a called address extension field the procedures of section 4 apply. If there is a called address extension field present, then the encoding is applied to this NSAP address and the called transport selector, and the resulting string of octets replaces the called transport selector. If the length of the resulting string of octets exceeds the limitation of the local transport entity (usually 32 octets), the incoming connection is disconnected. (2) The encoding is applied to the calling NSAP address, if present, and the calling transport selector, and the resulting string of octets replaces the calling transport selector. If the length of the resulting string of octets exceeds the limitation of the local transport entity (usually 32 octets), no substitution is made. (3) The TS-bridge now determines if it can directly reach the destination NSAP address. If so, a T-CONNECT.REQ primitive is invoked with the called transport selector equal to the value derived in step 1, and the calling transport selector equal to the value derived in step 2. (4) If the TS-bridge determines that it cannot directly reach the destination NSAP address, then the TS-bridge determines the subetwork address of the next TS-bridge in sequence, and invokes a T-CONNECT.REQ primitive, with called and calling transport selectors derived in steps 1 M.T. Rose (editor) [Page 12] Internet Draft CO/CL Interworking -- Short-Term Apr 91 and 2. When a TS-bridge receives a T-CONNECT.CNF, as described in [4]: (1) The TS-bridge invokes a T-CONNECT.RSP primitive with an empty responding address parameter. M.T. Rose (editor) [Page 13] Internet Draft CO/CL Interworking -- Short-Term Apr 91 6. Acknowledgements The original version of this memo was produced by the CO/CL Interworking Workshop, which met on July 24-26, 1990: Les Clyne, JNT Walid Dabbous, INRIA Phill Gross, NRI Christian Huitema, INRIA Steve Kille, UCL Kevin Mills, NIST Julian Onions, Nottingham University Marshall Rose, PSI Rachid Sijelmassi, NIST Mitchell Tasman, University of Wisconsin M.T. Rose (editor) [Page 14] Internet Draft CO/CL Interworking -- Short-Term Apr 91 7. References [1] M.T. Rose (editor). An Approach to CO/CL Interworking: Part I: Introduction, CO/CL Interworking Workshop, (April, 1991). [2] C. Huitema (editor). An Approach to CO/CL Interworking: -- Part III: The Long-Term -- Conventions for Network- Layer Relays and Transport-Service Bridges in the presence of Internetworking, CO/CL Interworking Workshop, (April, 1991). [3] S.E. Kille. A string encoding of Presentation Address. Research Note RN/89/14. Department of Computer Science, University College London, (February, 1989). [4] International Organization for Standardization. Information Processing Systems--Open Systems Interconnection--Transport Service Definition. International Standard 8072. (June, 1986). M.T. Rose (editor) [Page 15] Internet Draft CO/CL Interworking -- Short-Term Apr 91 Table of Contents 1 Status of this Memo ................................... 1 2 Introduction .......................................... 2 3 Impact of TS-bridges on End-Systems ................... 3 3.1 Initiator use of TS-bridges ......................... 3 3.1.1 Use of TS-bridge knowledge ........................ 4 3.1.2 Redirection procedure ............................. 6 3.1.3 If the initiator can not be modified .............. 7 3.2 Responder use of TS-bridges ......................... 8 4 Operation of TS-bridges ............................... 9 5 Operation of TS-Bridge Where X.25(84) With Address Extension Fields is Supported ...................... 11 5.1 For calls to the TP0/X.25(84) subnetwork ............ 11 5.2 For calls from the TP0/X.25(84) subnetwork .......... 12 6 Acknowledgements ...................................... 14 7 References ............................................ 15 M.T. Rose (editor) [Page 16] ------- End of Forwarded Message