Internet Draft CO/CL Interworking -- TS Bridges An Approach to CO/CL Interworking -- Part II: Specification -- Conventions for Transport-Service Bridges Wed Apr 24 17:47:04 1991 CO/CL Interworking Workshop July 24-26, 1990 May 31, 1991 C. Huitema (editor) INRIA Christian.Huitema@MIRSA.INRIA.FR 1. Status of this Memo This document outlines the conventions of Transport Service bridges following 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. C. Huitema (editor) [Page 1] Internet Draft CO/CL Interworking -- TS Bridges 2. A phased approach During the initial analysis of transport bridges, it appeared necessary to envisage a two phases approach for their introduction in the network: - in the short term, the routing protocols used by OSI communities are still primitive, and the bridges must be explicitely addressed, - in the long term, knowledge of the TS-bridges should be hidden from the end systems. This is termed the "ES- transparency" effect: no local knowledge of TS-bridges should exist at an end-system; further, use of a TS- bridge should not result in non-standard behavior at an end-system. In the short term, we observe several largely disconnected communities, based on technologies such as X.25 (1980 or 1984) or RFC-1006. A community based on the ISO connection-less network protocol (CLNP) is growing fast. In the long term, we expect to see the following: - A large CL-mode community will exist that uses dynamic routing (ES-IS and IS-IS protocols). - A global CO-mode community will exist, consisting of several concatenated CONS-capable subnetworks. This community will contain a significant number of CO-mode end-systems (either attached to WANs or LANs). - A significant TCP/IP community will exist. For those sites not running OSI applications, application gateway technology will be used. Otherwise, OSI-capable sites will participate using RFC1006. - Residual communities using implementations of X.25 1980 will still exist. A general increase of bandwidth available to (and requested by) applications is likely. As such, the performance impact of TS-bridges will be of concern. C. Huitema (editor) [Page 2] Internet Draft CO/CL Interworking -- TS Bridges In fact, nobody can predict the duration of the short term. Thus, this specification is applicable for both periods. The analysis of three cases: (1) explicit addressing procedures for transport bridges, (2) use of transport bridges in networks providing the connection oriented service, (3) use of transport bridges in networks providing the connection less service. Is followed by a description of the operation of TS-bridges. C. Huitema (editor) [Page 3] Internet Draft CO/CL Interworking -- TS Bridges 3. Explicit gateway addressing 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. C. Huitema (editor) [Page 4] Internet Draft CO/CL Interworking -- TS Bridges 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 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.2. 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- C. Huitema (editor) [Page 5] Internet Draft CO/CL Interworking -- TS Bridges systems in that group; each site administrator will be responsible for ordering the TS-bridges to account for "closeness". Note that since a 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[2]. For example: NS+540072872203 Int-X25(80)=23426020017299+PID+03018000 3.3. Encoding of network address and transport selector 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 representation (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. C. Huitema (editor) [Page 6] Internet Draft CO/CL Interworking -- TS Bridges 3.4. Redirection procedure The procedure for selection of a TS bridge described in Section 3.2 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. This string of octet will contain: (1) The network address (NSAP) of the network station towards which the call should be rerouted, (2) The transport selector that should be used for this new call. The NSAP and transport selector will be encoded according to the transport selector encoding described in the previous paragraph. As the new transport selector may in some case include routing information when the call is redirected towards another gateway, we could find cases where "double encoding" is used. This should however be transparent to the calling station. The redirection procedure should only be used when the calling station belongs to the community served by the gateway: the gateway should be sure that this station will "understand" the new NSAP. C. Huitema (editor) [Page 7] Internet Draft CO/CL Interworking -- TS Bridges 3.5. 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. A consequence of allowing such station in the network is that the redirection procedure described above should be used with care: it will result in a refusal of the call, and the manager of the "dump" station will have to enter manually the new routing information in the address database. In particular, the redirection procedure should not be used for implementing a form of "load sharing". 3.6. 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. C. Huitema (editor) [Page 8] Internet Draft CO/CL Interworking -- TS Bridges 4. Insertion of gateways in CLNS networks Several attempts to define such transparent bridges have been investigated during the CO/CL Interworking Workshop, and two particular problems have been (1) the problem of connection establishment, (2) the problem of connection maintenance. These problems appears mostly in the case of connections initiated from a connection-less host. Their analysis leads to a simple recommandation. A corresponding recommandation for connections forwarded towards a CLNS host is then presented. 4.1. The problem of connection establishment One of the most important differences between a normal transport connection and a connection that uses a TS-bridge lies in the connection set up phase, as the transport connection must be routed through a TS-bridge rather than directly to the target end-system. There are basically two ways to accumplish this: (1) require the end-system to identify the TS-bridge prior to the connection, (2) use the normal routing mechanism to route the packets through the TS-bridge. The first solution is used in the "short term" approach. It does certainly lack "transparency", as it requires the addition of extra code in all systems in order to perform the "TS-bridge selection" algorithm. Perhaps more important, it requires the distribution of TS-bridge identifications throughout the network, using some ad-hoc mechanism. The second approach is obtained by disguising the TS-bridge as a "network relay". For example, if a TS-bridge interfaces between a CL network and a set of CO systems, the routing protocols (e.g. IS/IS) will be used to indicate that the TS- bridge is located "at a short distance" from the end systems -- which are identified by a set of network addresses (NSAPs), C. Huitema (editor) [Page 9] Internet Draft CO/CL Interworking -- TS Bridges or more probably by a set of NSAP-prefixes. The datagrams bound to these NSAPs will then "naturally" be routed by the CL-mode network towards the TS-bridge. Similarly, the routing tables in a CO-mode network will ultimately direct a call for the called NSAP to a TS-bridge at the CO/CL-boundary. The routing tables will contain NSAP- prefixes, and may likely be maintained manually given the absence of automated interdomain routing information exchange protocol on the CO-mode networks. 4.2. Connection Maintenance from the CL-mode side Once a TS-bridge at the CO/CL-boundary is active, it is necessary to ensure that all further traffic for that connection, which originates at the CL-mode end-system, is routed to that particular TS-bridge. This is not a problem on the CO-mode network, where the network connection will be present for all the duration of the transport connection. This is however much more problematic if several TS-bridges can be used "in parallel" on the CL-mode side. Let suppose a CL-mode network, connected by two TS-bridges to a CO-mode network: _____________________________________________________ | CL Network | | CO Network | |_________________|_________________|________________| | ->| TS-bridge (1) | <--> System B| | | | | | | | | | | | System A <- | | | |_________________| Boundary | | | | | | | | TS-bridge (2) | | |_________________|_________________|________________| Both TS-bridges announce, via the CL routing protocols, that they can reach the systems of the CO network. The effect of most routing protocols will be to delimitate a "boundary" within the connection less network: the distance to system "B" is shorter through "TS-bridge(1)" for the systems above the boundary, and is on the contrary shorter through "TS- bridge(2)" for the systems under the boundary. The first C. Huitema (editor) [Page 10] Internet Draft CO/CL Interworking -- TS Bridges datagram of the connection, bound to "B" from "A", is then routed through the first TS-bridge. It triggers the establishment of a virtual circuit on the CO side, towards system B, and the initialization of a "transport relay context" in the TS-bridge. It is essential, for a correct operation, that the subsequent datagrams bound to "B" from "A" are also routed through "TS- bridge(1)". These datagrams carry a TPDU, whose header contains a 16 bits "transport connection identifier" which identifies the connection within "TS-bridge(1)", but which may well have a quite different meaning within "TS-bridge(2)". These is ensured as long as the routing tables remain stable, but can be defeated either if the network configuration change or if some aggressive load balancing procedure is used on the CL network. Let suppose that the status of some links change within the CL network: the routing tables will be recomputed, and the boundary referred above may move, leading to the following situation: _____________________________________________________ | Cl Network | CO Network | | |_________________|_________________|________________| | | TS-bridge (1) | <--> System B| | | | | |_________________| Boundary | | | System A <- | | | | | | | | | | | | | | ->| TS-bridge (2) | | |_________________|_________________|________________| The datagrams now arrive to "TS-bridge(2)". Depending on the status of TS-bridge(2), they will be either recognized as erroneous, leading to a transport level disconnection, or be associated to another connection which happens to be identified within "TS-bridge(2)" by the same 16 bits "transport connection identifier" that was used by the first TS-bridge, leading to application errors. Note that, once the boundary as been moved, the connection from B to A will fail if they are routed through "TS-bridge (1)", as the response from A to B will be directed to another route. Evenmore, there is a risk of confusion if both "TS- C. Huitema (editor) [Page 11] Internet Draft CO/CL Interworking -- TS Bridges bridge(1)" and "TS-bridge(2)" relay a valid TPDU from B to A: they may use the same transport connection identifier, and they may also at the network level use the same "datagram identifier", which could result in the improper partial concatenations of segments. As mentionned earlier, the situation is made much worse if "agressive load balancing" is used on the CL side. Under this strategy, datagrams are randomly routed through several "almost equivalent" routes, in order to optimally utilize all network ressources: TPDU from A to B would then be equally spread between TS-bridges (1) and (2), leading to some unpredictable results... 4.3. Procedures for CLNS networks Different solutions were investigated during the CO-CL workshop. They can be summarized by three variants: (1) guarantee, e.g. by freezing the routing tables, that the bridge which receive the initial connection request will also receive all further packets bound to the destination; a similar result can be achieved with management procedures that guarantee that only one TS- bridge will serve a given NSAP address. (2) require that the CLNS user explicitely address the gateway, e.g. by using source routing. (3) use some modification of the transport protocol in order to allow for "adaptative routing". None of these solutions is completely satisfactory: (1) The first solution may be used when a single bridge can serve a closed community, e.g. when a CLNS local network interfaces a CONS wide area network. It is probably unacceptable for a large Internet, where a large degree of redundancy will be necessary for good performance and reliability. (2) The secund solution does not bring much added value relatively to the explicit gateway addressing used in the short term. C. Huitema (editor) [Page 12] Internet Draft CO/CL Interworking -- TS Bridges (3) The third solution would require several years of negociations within ISO and CCITT committees. After reviewing these alternatives, we propose the following approach: (1) A bridge that receives a connection request from a CLNS user will accept it, and forward towards its destination, if and only if it knows that all further packets bound to that destination are guaranteed to reach this bridge. This will be the case if the routing table are fixed, or if the bridge is the only bridge serving the destination, or if the bridge was explicitely addressed using some form of source routing. (2) A bridge that cannot guarantee that all further packets will be correctly forwarded should reject the connection. More precisely, the bridge should attempt to "redirect" the connection, using the redirection procedure defined in the short term specification. The CLNS station which receives the redirection indication should indeed repeat the connection attempt, using the network and transport address stated in the redirection parameter. This will result in an explicit addressing of the bridge, so that the connection could be properly forwarded. 4.4. Connection towards a CLNS host The route maintenance problem is much easier to solve for connections forwarded through a bridge towards a CLNS hosts: all the CLNP datagrams should carry the NSAP of the TS-bridge, and not that of the initial originator of the connection. As a result, the packets will naturally be routed towards the bridge. The originator address will be encoded in the "calling transport selector" parameter. C. Huitema (editor) [Page 13] Internet Draft CO/CL Interworking -- TS Bridges 5. Insertion of TS-bridges in CONS networks In CO-mode networks, mostly implemented by the of X.25(84) or X.25(88), implementation of the ES-Routing Exchange Protocol will be expected in both end-systems and intermediate-systems. This gives a redirection capability. As in the case of connection-less networks, one can expect that the end systems will not have to explicitely address the TS-bridges. In this environment the TS-bridge and initiating systems on the X.25 subnetwork insert the called and calling NSAP addresses in the "address extension fields" of the X.25 call packets; they dont have to use the Transport selectors to carry NSAP addresses. 5.1. Connection requests from the CONS network When a TS-bridge receives a T-CONNECT.IND primitive, it can extract the destination and source NSAP from the *(lqaddress extension fields" of the X.25 call packets. In order to ensure compatibility with the "short term" specification, the TS-bridge should indeed give precedence to the information which might be encoded in the transport selectors over that presented by the "network layer". 5.2. Connections towards the CONS network When relaying a connection towards a station belonging to a CONS network, the destination NSAP should be encoded in the network layer "address extension fields". The source NSAP should be encoded in the calling transport selector. This procedure has two advantages: (1) It leaves the network layer "address extension fields" available for identifying the gateway, (2) It is completely compatible with the short term solution, and with the solution proposed on CLNS networks. C. Huitema (editor) [Page 14] Internet Draft CO/CL Interworking -- TS Bridges In fact, when relaying the connection over the CONS network towards another TS-Bridge, the relaying bridge can elect to encode the destination NSAP within the called transport selector. C. Huitema (editor) [Page 15] Internet Draft CO/CL Interworking -- TS Bridges 6. Operation of transport bridges The state machine and parameterization described in Sections 6.1 and 6.2 of [1] is used. 6.1. Relaying a call When a TS-bridge receives a T-CONNECT.IND primitive, as described in [3]: (1) If the called transport selector passes the encoded-TSEL test, the TS-bridge decodes the actual destination network address and transport selector from the called transport selector. (2) If the called transport selector failed the encoded-TSEL test, the network layer information is considered, i.e. either the address extension fields from a CONS network, or the destination NSAP carried in a CLNP packet. If no information is present, or if the NSAP present at the network layer only identifies the gateway, the call shall be cleared. (3) If the destination NSAP has been read from a CLNP packet, the TS-bridge should assert the "resilience" of the routing. If there is a risk that further packets might be misrouted to another bridge, the TS-bridge shall clear the connection by executing a redirection procedure towards itself. It will first build up an encoded TSEL from the destination NSAP and the original called transport selector. It will then invoke a T- DISCONNECT.REQ primitive, where the DR information parameter will contain the encoding of the network address of the TS-Bridge and that of the encoded TSEL that it just built. (4) 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 C. Huitema (editor) [Page 16] Internet Draft CO/CL Interworking -- TS Bridges no substitution is made. (5) 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. (6) 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. (7) 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 "community" through which the call is incoming, then the TS-bridge can elect to use the redirection procedure specified in Section 3.4. It will invoke a T-DISCONNECT.REQ primitive, where the DR information parameter will contain the encoding of the network address of the next station 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 [3]: (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" field is set to "address unknown" and whether the "disconnect information" parameter pass the encoded-TSEL test. Otherwise, the incoming connection will be disconnected. C. Huitema (editor) [Page 17] Internet Draft CO/CL Interworking -- TS Bridges (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. C. Huitema (editor) [Page 18] Internet Draft CO/CL Interworking -- TS Bridges 7. 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 The initial drafts produced during the workshop were revised by members of RARE working group 4 and of the IETF. This memo is the result of the successive revisions. 8. References [1] M.T. Rose (editor). An Approach to CO/CL Interworking: Part I: Introduction, CO/CL Interworking Workshop, (April, 1991). [2] S.E. Kille. An interim approach to use of Network Addresses. Research Note RN/89/13. Department of Computer Science, University College London, (February, 1989). [3] International Organization for Standardization. Information Processing Systems--Open Systems Interconnection--Transport Service Definition. International Standard 8072. (June, 1986). C. Huitema (editor) [Page 19] Internet Draft CO/CL Interworking -- TS Bridges Table of Contents 1 Status of this Memo ................................... 1 2 A phased approach ..................................... 2 3 Explicit gateway addressing ........................... 4 3.1 Initiator use of TS-bridges ......................... 4 3.2 Use of TS-bridge knowledge .......................... 5 3.3 Encoding of network address and transport selector .................................................... 6 3.4 Redirection procedure ............................... 7 3.5 If the initiator can not be modified ................ 8 3.6 Responder use of TS-bridges ......................... 8 4 Insertion of gateways in CLNS networks ................ 9 4.1 The problem of connection establishment ............. 9 4.2 Connection Maintenance from the CL-mode side ........ 10 4.3 Procedures for CLNS networks ........................ 12 4.4 Connection towards a CLNS host ...................... 13 5 Insertion of TS-bridges in CONS networks .............. 14 5.1 Connection requests from the CONS network ........... 14 5.2 Connections towards the CONS network ................ 14 6 Operation of transport bridges ........................ 16 6.1 Relaying a call ..................................... 16 7 Acknowledgements ...................................... 19 8 References ............................................ 19 C. Huitema (editor) [Page 20]