Internet Standards

home *** CD-ROM | disk | FTP | other *** search

/ Internet Standards / CD1.mdf / MISC / MERIT / 1991 / 91_036.PS < prev next >

Wrap

Text File | 1991-05-06 | 36.8 KB | 1,181 lines

Internet Draft CO/CL Interworking -- Long-Term Apr 90 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 Wed Apr 24 17:47:04 1991 CO/CL Interworking Workshop July 24-26, 1990 April 24, 1991 C. Huitema (editor) INRIA FR Christian.Huitema@MIRSA.INRIA.FR 1. Status of this Memo This document outlines the long-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. C. Huitema (editor) [Page 1] Internet Draft CO/CL Interworking -- Long-Term Apr 90 2. Introduction The long-term approach outlined in [1] is based on the use of transport-layer relays known as transport service bridges, or TS-bridges. Further, the long-term approach also assumes that knowledge of the TS-bridges is hidden from the end-systems. The companion memo [2] identifies the short-term approach towards TS-bridges. The purpose of this memo is three-fold: first, to identify the infrastructure which is expected to exist in the long-term; second, to describe the use of NL-relays in such an environment. and, third, to describe the use of TS-bridges in such an environment. C. Huitema (editor) [Page 2] Internet Draft CO/CL Interworking -- Long-Term Apr 90 3. Assumptions of the Long-Term Environment (1) A large CL-mode community will exist that uses dynamic routing (ES-IS and IS-IS protocols) (2) 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). (3) 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 as CO-mode end-systems (using the CO- mode extensions to RFC1006). (4) 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 3] Internet Draft CO/CL Interworking -- Long-Term Apr 90 4. The Use of NL-relays in the Long-Term 4.1. in CL-mode networks In CL-mode networks, end-systems will be expected to implement ES-IS, and intermediate-systems will be expected to implement both ES-IS and IS-IS. Further, an inter-domain dynamic routing protocol will most likely be in use. 4.2. in CO-mode networks In CO-mode networks, implementation of the ES-Routing Exchange Protocol will be expected in both end-systems and intermediate-systems. This gives a redirection capability. C. Huitema (editor) [Page 4] Internet Draft CO/CL Interworking -- Long-Term Apr 90 5. The Use of TS-bridges in the Long-Term Ideally, the existence of ubiquitous and homogeneous network service will reduce the need for solutions other than the network-layer relay. However, in those environments in which NL-relays will not suffice, TS-bridges must also be used. In contrast to the short-term solution proposed in [2], the long-term solution seeks to hide knowledge of the TS-bridges 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. Several attempts to define such transparent bridges have been investigated during the CO/CL Interworking Workshop, and two particular problems have been distinguished: (1) the problem of connection establishment, (2) the problem of connection maintenance. 5.1. The problem of connection establishment One of the most important differences between a normal transport connection and a connection that uses one 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 ([2]). 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 C. Huitema (editor) [Page 5] Internet Draft CO/CL Interworking -- Long-Term Apr 90 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), 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. 5.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" C. Huitema (editor) [Page 6] Internet Draft CO/CL Interworking -- Long-Term Apr 90 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 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 A to B are also routed through B. 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. C. Huitema (editor) [Page 7] Internet Draft CO/CL Interworking -- Long-Term Apr 90 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- 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... 6. A review of CO/CL TS-bridge designs In order to solve the problems described in the preceeding sections, several "solutions" have been proposed: (1) Do nothing special, hope for the best, (2) Freeze the routing tables, (3) Use source routing, (4) Use a single TS-bridge or multiple NSAPs, (5) Identify the TS-bridge during the connection, (6) Synchronize the TS-bridges. These various solutions will be reviewed in this section. 6.1. Do nothing special, hope for the best If the CL network does not use agressive load sharing strategies, the problem of misrouted packets mentioned above only appears if the network configuration changes, i.e. if a line breaks. As a break on the CO side of the network would C. Huitema (editor) [Page 8] Internet Draft CO/CL Interworking -- Long-Term Apr 90 have resulted in the loss of the virtual circuit and thus of the transport connection, one could imagine that loosing the TS-bridged transport connection when this rare event occurs on the CL side is acceptable. This solution suffers from several draw-backs, the most critical being that it is likely to work well when the network is not heavily loaded, leading users to rely on it only to see the quality of service vanish when the size of the network or its load increases. Moreover, the addition of new TS-bridges at a short distance from the initial ones, or the operation of a more agressive CL routing protocol, could disrupt the whole operation. 6.2. Freeze the routing tables The ISO report [3] mentions that the routing of all datagrams to the same TS-bridge can be obtained by using "frozen" routing tables, in order to guarantee that a packet from a given source will always be be routed through the same TS- bridge. This solution works, but: (1) limits the usefulness of several TS-bridges, as the load balancing is static. If a TS-bridge fails, all its "clients" become isolated. (2) is not compatible with the current developments of the CL routing protocols, which very naturally implement dynamic routing and redirections. 6.3. Use source routing The ISO protocol for providing the CL service includes a "source routing" facility: one can specify that a packet shall be routed through a particular path within the network, e.g. from "A" to "B" through "TS-bridge(1)": the CL-mode end-system could use source-routing at the network layer to ensure that the bound TS-bridge is always used. This solution works, but cannot be exactly considered "transparent": in order to insert the source routing request C. Huitema (editor) [Page 9] Internet Draft CO/CL Interworking -- Long-Term Apr 90 in the packets, the CL host must have identified the TS- bridge. This initial knowledge of the TS-bridge may come from the end-system, through either local or protocol-derived means. Moreover, one must remark that the support of the "source routing" facility is not widespread. It is not considered mandatory by the current profiles, and is not necessarily implemented in the simple end-systems. 6.4. Use a single TS-bridge or multiple NSAPs The problem of misrouted datagrams disappears if a single TS- bridge is responsible of servicing a given CO system. This can be ensured if the NSAP prefix, corresponding to a group of CO system, is declared as being accessible through only one TS- bridge to the CONS world. Redundancy can be achieved by allocating several NSAPs, with different prefixes, to the same CO system; each prefix will be served by a different TS-bridge. During the connection phase, these NSAPs will be sorted according to some metric, and then tried successively, to the result of selecting the nearest "in order" TS-bridge. This technic is truly transparent, in the sense that it does not place any specific requirements on the end systems or on the routing protocols. However, it has a high administrative cost, as the various NSAPs must be negotiated between the end systems and the TS-bridges, and registered in the application level directories. 6.5. Identify the TS-bridge during the connection The problem of misrouted datagrams, as well as the related problems of segmentation/concatenation, would be solved if the headers of the datagrams exchanged on the connection would carry the address of the TS-bridge, rather than that of the CO-system. In fact, one can imagine the following: - When a connection is made from a TS-bridge on behalf of a CO system, the initial TPDU is carried on a datagram sourced at the TS-bridge; a TPDU parameter indicates the C. Huitema (editor) [Page 10] Internet Draft CO/CL Interworking -- Long-Term Apr 90 address of the CO system. The CL system will naturally respond to the TS-bridge. - When a connection is made from a CL system to a CO system, the initial TPDU is carried in a datagram bound to the CO system. After setting up the connection on the CO side, the TS-bridge respond in a datagram sourced at CO system; one of the parameter of the connection confirmation TPDU identifies the network address of the TS-bridge; this address is used by the CL system as destination address of the datagrams carrying the next TPDUs. This strategy requires an extension of the TP4 protocol, so that the CR TPDU carries an optional "proxy" parameter, indicating the "real" network address of the end system requiring the connection, and so that the CC TPDU carries an optional "TS-bridge" parameter, indicating the network address of the TS-bridge. In the absence of such a protocol extension, existing fields could be used. For example, the "real" network address could be carried by formatting the "calling transport selector" parameter according to the conventions defined in [2]. One should note that this strategy will only be effective if the corresponding algorithm is implemented in the end stations. 6.6. Synchronize the TS-bridges A TS-bridge synchronization protocol could be defined, in order to synchronize all the TS-bridges servicing the same CO-mode community. The definition of this protocol is left as an (interesting) exercise to the reader; it should render at least the following synchronization services: (1) guarantee the same "transport connection identifier" cannot be used by two TS-bridges for the same pair of source and destination NSAPs, (2) guarantee that the same "unique datagram identifier" cannot be used by two TS-bridges for the same pair of source and destination NSAPs, C. Huitema (editor) [Page 11] Internet Draft CO/CL Interworking -- Long-Term Apr 90 (3) provide a mean to reroute the misrouted TPDUs towards the proper TS-bridge. One should however realize that there are limits to what such a protocol can achieve. In particular, it is only possible to reroute a complete TPDU, which means that all segments of the datagram sent from the CL system to the CO system must be received by a single TS-bridge; this condition will not be realized if what we have called "agressive load balancing" is used in conjunction with segmentation. There is indeed another disadvantage to this solution, i.e. the need of an administrative procedure in order to guarantee that all TS-bridges targeting a given CO-mode community are participating to the synchronization. This may well be somewhat incompatible with the current anarchy of research networks. 6.7. Conclusions The establishment of "transparent" CO/CL bridges poses two problems: TS-bridge identification and connection maintenance. The identification of the TS-bridge can be performed transparently through the standard network level routing mechanism. Several proposal have been made to solve the problem of "connection maintenance": (1) Do nothing special, hope for the best, (2) Freeze the routing tables, (3) Use source routing, (4) Use a single TS-bridge or multiple NSAPs, (5) Identify the TS-bridge during the connection, (6) Synchronize the TS-bridges. All these solutions have advantages and disadvantages, which can be summed up in the following table: C. Huitema (editor) [Page 12] Internet Draft CO/CL Interworking -- Long-Term Apr 90 _____________________________________________________ | | 1 2 3 4 5 6| |____________________________|_______________________| | - Error prone | Y . . . . .| | - Support redundancy | | | (multiple bridges) | N N . - . .| | - Support network | | | reconfigurations | N N . . . .| | - Support agressive | | | load balancing | N N . . . N| | - Requires | | | heavy administration | . . . Y . Y| | - Requires special | | | software in end systems| . . Y . Y .| | - Requires TS-bridge | | | identification by ES | . . Y . . .| | - Requires special | | | network features | . Y Y . . .| | - Requires | | | extension to TP4 | . . . . Y .| | - Requires | | | new protocol | . . . . . Y| |____________________________|_______________________| When the original version of this document was produced, none of these solution emerged as ``the recommanded strategy''. However, since this analysis, the transport protocol has been revised by the ISO committees. This revision has led to the introduction of new transport protocol parameters, including the ``responding network address'' parameter necessary for the solution number 5. In that case, the two disadvantage of this solution disappear, or at least are lessened: - The requirement of ``special software in end systems'' can be rewritten as a need to ``support the last version of the transport protocol'', - The ``extension to TP4'' is already standardized. In that case, it becomes quite reasonable to recommend the solution (5), i.e. to ``identify the TS-bridge during the connection'' by using the ``responding network address'' parameter. C. Huitema (editor) [Page 13] Internet Draft CO/CL Interworking -- Long-Term Apr 90 7. Dynamic bridge identification 7.1. Insertion of the TS-Bridge in the networks From a conceptual point of view, the TS bridge is connected to several ``realms''. A ``realm'' is characterized by: (1) A network service, which may be ``connection-less'' or ``connection-oriented'', (2) A set of routing mechanisms, that guarantee connectivity betwen the members of the ``realm''. In each of these ``realms'', the routing mechanism must be set in such a way that when a connection request is issued towards an NSAP belonging to another ``realm'' served by the TS- bridge, the connection get established with the TS-bridge. In a connection less network, this means that datagrams sent to an NSAP belonging to another ``realm'' are routed towards the TS-bridge. The specification supports the insertion of multiple bridges. When multiple TS bridges serve the same realms, the connections or datagrams may be routed towards any of these bridges. 7.2. Operation of the TS bridge 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, it shall perform the following actions: (1) Select the target ``realm'' as a function of the destination NSAP, and invoke a T-CONNECT.REQ primitive addressed in this ``realm''. (2) If the destination NSAP does not belong to any of the ``realms'' supported by the bridge, clear the incoming connection. (3) In any case, the source network address identifies the TS bridge. C. Huitema (editor) [Page 14] Internet Draft CO/CL Interworking -- Long-Term Apr 90 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. (2) When the initial connection was received over a connection-less network, the ``responding network address'' parameter of this primitive shall be set the address of the TS Bridge in this connection-less network. If instead of receiving a T-CONNECT.CNF primitive the TS- bridge receives receives a T-DISCONNECT.IND it will disconnect the incoming connection. 7.3. Compatibility with the short term specification The memo cited in reference [2] specifies a ``source routing'' procedure, where the calling station explicitely addresses the gateway, and encode the destination NSAP in the first bytes of the called transport selector. When the ``long term'' TS bridges will be introduced, they will have to interoperate with stations which relie on the ``short term'' specification for connectivity. When a TS-bridge receives a T-CONNECT.IND primitive, it shall perform the following actions: (1) If the called transport selector passes the encoded-TSEL test described in section 3.1.1 of reference [2], the TS-bridge decodes the actual destination network address and transport selector from the called transport selector. (2) If the calling transport selector passes the encoded-TSEL test, then the TS-bridge decodes actual source network address and transport selector from the calling transport selector. A ``long term'' TS Bridge may optionnally be parametrized to interoperate with bridges following the ``short term'' specification, and listed in the ``knowledge table'' described in section 3.1.1 of reference [2]. In this case, the procedure for outgoing call described in section 4 of reference [2] shall be followed. C. Huitema (editor) [Page 15] Internet Draft CO/CL Interworking -- Long-Term Apr 90 7.4. Use of the redirection procedure As the ``long term'' TS bridge are suppose to be connected to networks capable of routing on the basis of the NSAP, there is in principle no need for the redirection procedure described in section 3.1.2 of reference [2]. However, the TS bridge may in some case be used for providing global connectivity to communities with restricted networking capability, e.g. using the RFC-1006 specification. The TS bridge when it discovers that the destination and the source are connected to the same subnetwork, shall only use the redirection procedure if the called transport selector received in the T-CONNECT.IND primitive passes the encoded- TSEL test: this is an indication that the calling station follows the ``short term'' specification, and supports the redirection procedure. C. Huitema (editor) [Page 16] Internet Draft CO/CL Interworking -- Long-Term Apr 90 8. Impact on end systems The implementation of the ``dynamic bridge identification'' procedure is detailed in a following paragraph. As explained in [1], the use of TS bridges as a negative impact on the overall quality of service: the ``end-to-end'' character of error control and error recovery is lost. We will not try to quantify this loss of service, but rather to examine how the operation of TS bridges affects the connection establishment procedures for CO and CL stations, i.e. how ``transparent'' the bridges really are. 8.1. Impact on CO stations The only impact of the insertion of TS bridge on CO stations concern the identification of the calling systems, during incoming calls. 8.2. Impact on CL stations In order to support the operation of TS bridges, the CL station must take into account the ``responding network address'' parameter in the T-CONNECT.CNF primitives. This responding address shall be used as destination address for all the ``UNIT-DATA.REQ'' primitive used in the connection. If the CL station ignores the ``responding network address'' parameter, and if parallel bridges are used, then there is a risk that the TPDU will be randomly routed to another bridge, resulting in a disconnection request. 8.3. Impact on the security When TS-bridges are used, the ``calling network addresses'' shall not be used as the basis of security procedures. One may in fact argue that network level information should never be used as the basis of security procedures... C. Huitema (editor) [Page 17] Internet Draft CO/CL Interworking -- Long-Term Apr 90 9. 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 C. Huitema (editor) [Page 18] Internet Draft CO/CL Interworking -- Long-Term Apr 90 10. References [1] M.T. Rose (editor). An Approach to CO/CL Interworking: Part I: Introduction, CO/CL Interworking Workshop, (July, 1990). [2] M.T. Rose (editor). An Approach to CO/CL Interworking -- Part II: The Short-Term -- Conventions for Transport- Service Bridges in the absence of Internetworking, CO/CL Interworking Workshop, (July, 1990). [3] ISO/IEC JTC1. Information Processing Systems -- Data Communications -- Network/Transport Protocol Interworking Specification, ISO DTR 10172, Final version of Proposed Draft Technical Proposal, (July, 1990). C. Huitema (editor) [Page 19] Internet Draft CO/CL Interworking -- Long-Term Apr 90 Table of Contents 1 Status of this Memo ................................... 1 2 Introduction .......................................... 2 3 Assumptions of the Long-Term Environment .............. 3 4 The Use of NL-relays in the Long-Term ................. 4 4.1 in CL-mode networks ................................. 4 4.2 in CO-mode networks ................................. 4 5 The Use of TS-bridges in the Long-Term ................ 5 5.1 The problem of connection establishment ............. 5 5.2 Connection Maintenance from the CL-mode side ........ 6 6 A review of CO/CL TS-bridge designs ................... 8 6.1 Do nothing special, hope for the best ............... 8 6.2 Freeze the routing tables ........................... 9 6.3 Use source routing .................................. 9 6.4 Use a single TS-bridge or multiple NSAPs ............ 10 6.5 Identify the TS-bridge during the connection ........ 10 6.6 Synchronize the TS-bridges .......................... 11 6.7 Conclusions ......................................... 12 7 Dynamic bridge identification ......................... 14 7.1 Insertion of the TS-Bridge in the networks .......... 14 7.2 Operation of the TS bridge .......................... 14 7.3 Compatibility with the short term specification ..... 15 7.4 Use of the redirection procedure .................... 16 8 Impact on end systems ................................. 17 8.1 Impact on CO stations ............................... 17 8.2 Impact on CL stations ............................... 17 8.3 Impact on the security .............................. 17 9 Acknowledgements ...................................... 18 10 References ........................................... 19 C. Huitema (editor) [Page 20]