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