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]