home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / MISC / MERIT / 1991 / 91_017R.TXT < prev    next >
Encoding:
Text File  |  1991-05-06  |  27.1 KB  |  950 lines
  1. Network Working Group                        April 1991
  2. Internet Draft                             M.T. Rose
  3.  
  4.  
  5.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  6.  
  7.  
  8.                         An Approach to CO/CL Interworking
  9.                           -- Part II: The Short-Term --
  10.                     Conventions for Transport-Service Bridges
  11.                         in the absence of Internetworking
  12.  
  13.                              Wed Apr 17 09:21:02 1991
  14.  
  15.  
  16.                            CO/CL Interworking Workshop
  17.                                  July 24-26, 1990
  18.                                   April 5, 1991
  19.  
  20.                                 M.T. Rose (editor)
  21.                      Performance Systems International, Inc.
  22.                                   mrose@psi.com
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.           1.  Status of this Memo
  31.  
  32.           This document outlines the short-term aspects of the approach
  33.           described in "An Approach to CO/CL Interworking -- Part I:
  34.           Introduction".
  35.  
  36.           This approach has been developed at the request of the FNC and
  37.           RARE communities, but may be applicable to other communities.
  38.           This memo does not explicitly specify a standard, however, it
  39.           may form the basis for policy within the FNC, RARE, or other
  40.           communities.
  41.  
  42.           Distribution of this memo is unlimited.  Questions should be
  43.           directed to the editor.
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.           M.T. Rose (editor)                                    [Page 1]
  59.  
  60.  
  61.  
  62.  
  63.  
  64.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  65.  
  66.  
  67.           2.  Introduction
  68.  
  69.           The short-term approach outlined in [1] is based on the use of
  70.           transport-layer relays known as transport service bridges, or
  71.           TS-bridges.  Further, the short-term approach also assumes
  72.           that knowledge of the TS-bridges is present in the end-
  73.           systems.  The companion memo [2] identifies solutions in which
  74.           end-system knowledge of transport-layer relays is avoided.
  75.  
  76.           The purpose of this memo is two-fold: first, modifications to
  77.           the operational characteristics of end-systems are described;
  78.           and, second, the operational characteristics of TS-bridges are
  79.           described.
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.           M.T. Rose (editor)                                    [Page 2]
  118.  
  119.  
  120.  
  121.  
  122.  
  123.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  124.  
  125.  
  126.           3.  Impact of TS-bridges on End-Systems
  127.  
  128.           The fundamental characteristic of the short-term solution is
  129.           that initiating end-systems must have knowledge of TS-bridges;
  130.           further, the short-term solution requires that the initiating
  131.           end-system act in a non-standard fashion in order to establish
  132.           a connection when using a TS-bridge.
  133.  
  134.  
  135.           3.1.  Initiator use of TS-bridges
  136.  
  137.           Section 3 of [1] describes a conceptual algorithm that might
  138.           be used by an initiating end-system during transport
  139.           connection establishment.  For an initiating transport entity,
  140.           knowledgeable about TS-bridges, these three steps are followed
  141.           in order to establish a connection:
  142.  
  143.           (1)  The local transport entity looks at each network address
  144.                in the transport address, determines the OSI community
  145.                (as defined in [1]) that the network address belongs to,
  146.                and associates the corresponding TS-stack with each
  147.                address.
  148.  
  149.                For each network address, if the initiating end-system
  150.                does not belong to the OSI community for that address,
  151.                the entity sees if there is a reachable TS-bridge that
  152.                services that community.  If not, the address is removed
  153.                from further consideration.  Otherwise the address is
  154.                marked with a reference to that TS-bridge.
  155.  
  156.                If all of the addresses are removed, then there are no
  157.                known TS-bridges to any of the network addresses, and the
  158.                local transport entity immediately generates a transport
  159.                disconnect.
  160.  
  161.           (2)  The remaining network addresses are then ordered, based
  162.                on the desired QoS and the "closeness" of the actual
  163.                network address.
  164.  
  165.           (3)  For each network address, if there is an associated TS-
  166.                bridge, then the local transport entity starts the
  167.                protocol for the TS-stack which can reach the TS-bridge.
  168.                When establishing the connection, the entity replaces the
  169.                called transport selector with a new string of octets
  170.                formed by encoding the original network address and the
  171.  
  172.  
  173.  
  174.  
  175.  
  176.           M.T. Rose (editor)                                    [Page 3]
  177.  
  178.  
  179.  
  180.  
  181.  
  182.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  183.  
  184.  
  185.                original transport selector.  If there is a possibility
  186.                that the local network address will not be carried by the
  187.                underlying network service, then as a local option, the
  188.                local transport entity may also encode its local network
  189.                address and transport selector as the calling transport
  190.                selector.
  191.  
  192.                Otherwise, if there is no TS-bridge associated with the
  193.                network address, the local transport entity starts the
  194.                protocol machine for the TS-stack associated with that
  195.                address.
  196.  
  197.                In either case, this results in a transport protocol and
  198.                underlying network service being invoked.  Once a
  199.                transport connection is established, the remaining
  200.                network addresses are ignored.
  201.  
  202.  
  203.           3.1.1.  Use of TS-bridge knowledge
  204.  
  205.           During the steps above, the initiating end-system must be able
  206.           to make these decisions:
  207.  
  208.           (1)  Does the destination network address share a community in
  209.                common with the initiating end-system (is a destination
  210.                network address directly reachable)?
  211.  
  212.                Local knowledge is used to make this determination; for
  213.                example, a table or local directory may be employed.
  214.  
  215.           (2)  If a destination network address is not directly
  216.                reachable, which TS-bridge shall be used?
  217.  
  218.                Communities participating in the short-term solution will
  219.                manually maintain tables, which contain this information.
  220.                A separate table will be maintained for each initiating
  221.                community.  The table will contain two columns: the first
  222.                containing the NSAP prefix of a group of destination
  223.                addresses, and the second column containing the network
  224.                address of a TS-bridge which can be used to reach end-
  225.                systems in that group.  Multiple entries may be present
  226.                for the same NSAP prefix if several TS-bridges can be
  227.                used to reach end-systems in that group; each site
  228.                administrator will be responsible for ordering the TS-
  229.                bridges to account for "closeness".  Note that since a
  230.  
  231.  
  232.  
  233.  
  234.  
  235.           M.T. Rose (editor)                                    [Page 4]
  236.  
  237.  
  238.  
  239.  
  240.  
  241.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  242.  
  243.  
  244.                destination community can be described as a set of NSAP
  245.                prefixes, there may be several entries in the table for a
  246.                particular destination community.
  247.  
  248.                For ease of use, each table may be available as an ASCII
  249.                file, with each entry terminated by a CR-LF sequence.
  250.                Within an entry, the NSAP prefix along with the network
  251.                addresses of each TS-bridge may be expressed using
  252.                Kille's string encoding[3].  For example:
  253.  
  254.                NS+540072872203  Int-X25(80)=23426020017299+PID+03018000
  255.  
  256.  
  257.           (3)  How is the destination network address and transport
  258.                selector encoded?
  259.  
  260.                A compact binary encoding scheme is used to represent the
  261.                destination network address and transport selector as an
  262.                octet string of length m:
  263.  
  264.                   octets         contents                     encoding
  265.                -----------    ---------------     -----------------------------
  266. - -
  267.                      0        length of NSAP      "n" as an unsigned-integer
  268.                      1        length of NSAP      "n" as an unsigned-integer
  269.                    2-(n+1)    destination NSAP    concrete binary representatio
  270. n
  271.                (n+2)-(m-1)    destination TSEL    string of octets
  272.  
  273.                The resulting string of octets is placed in the called
  274.                transport selector by the initiating end-system.  When
  275.                examining a transport selector, s, of length m octets, a
  276.                simple check can be used to see if it encodes a network
  277.                address and transport selector:
  278.  
  279.                (m > 4) AND (s[0] = s[1]) AND (s[0] > 2) AND (s[0] <= (m-2))
  280.  
  281.                This is termed the encoded-TSEL test.
  282.  
  283.                Note that if the encoding of the original called network
  284.                address and transport selector exceeds the limitation of
  285.                the local transport entity (usually 32 octets), then a
  286.                TS-bridge can not be used.
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.           M.T. Rose (editor)                                    [Page 5]
  297.  
  298.  
  299.  
  300.  
  301.  
  302.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  303.  
  304.  
  305.           3.1.2.  Redirection procedure
  306.  
  307.           The procedure for selection of a TS bridge described in
  308.           Section 3.1.1 is based on tables describing the relation
  309.           between bridges and communities.  These tables may be
  310.           difficult to export to a large number of stations, and there
  311.           is always the risk that the knowledge table in a particular
  312.           end-system be partial, or partially out-of-date.  In order to
  313.           ease the management of these end-systems, a "redirection
  314.           procedure" is introduced:
  315.  
  316.           (1)  When a TS-bridge determines that a transport connection
  317.                request is misrouted, it can invoke a T-DISCONNECT.REQ
  318.                primitive, passing routing information in the "disconnect
  319.                information" parameter of this primitive.
  320.  
  321.           (2)  Upon reception of the T-DISCONNECT.IND, the requesting
  322.                transport station decodes the "disconnect information",
  323.                and uses the routing information to renew the T-
  324.                CONNECT.REQ.
  325.  
  326.           The "disconnect information" parameter is described in the
  327.           transport protocol specification as a string of octets.  The
  328.           routing information will be encoded as an octet string of
  329.           length m:
  330.  
  331.             octets      contents            encoding
  332.             ------      --------            ---------
  333.             0           length of SNPA      "n" as an unsigned-integer
  334.             1           length of SNPA      "n" as an unsigned-integer
  335.             2-(n+1)     destination SNPA    representation depends of
  336.                                                 subnet technology
  337.             (n+2)-(m-1) destination TSEL    string of octets
  338.  
  339.           The resulting string of octet is placed in the disconnect
  340.           information by the TS-bridge that initiates the redirection
  341.           procedure.  When receiving a T-DISCONNECT.IND, the transport
  342.           station will check that the "cause" parameter is equal to
  343.           "address unknown" and that the disconnect information
  344.           parameter is present, as a string, s, of m octets, and that it
  345.           verifies:
  346.  
  347.           (m > 4) AND (s[0] = s[1]) AND (s[0] > 2) AND (s[0] <= (m-2))
  348.  
  349.           This is termed the encoded-REDIRECT test.
  350.  
  351.  
  352.  
  353.  
  354.  
  355.           M.T. Rose (editor)                                    [Page 6]
  356.  
  357.  
  358.  
  359.  
  360.  
  361.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  362.  
  363.  
  364.           If this test fails, the T-DISCONNECT.IND should be passed to
  365.           the transport user.
  366.  
  367.           The encoding of the destination SNPA depends on the network
  368.           technology. Two encoding are specified for RFC-1006 and X.25
  369.           based subnetworks:
  370.  
  371.           (1)  When the subnetwork uses RFC-1006 technology, the SNPA is
  372.                encoded on 6 octets.  The first four octets encode the IP
  373.                address, in network order.  The last two octets encode
  374.                the TCP port, in network order.
  375.  
  376.           (2)  When the subnetwork uses X.25 technology, the "n" octets
  377.                are split into a first octet which encode the length of
  378.                the X.121 address in unsigned binary format, then "p"
  379.                octets which encode the X.121 address itself as a string
  380.                of ASCII digits, then the remaining "n-p-1" octets which
  381.                encode the X.25 "protocol identifier" passed in the call
  382.                user data field, as a string of octets.
  383.  
  384.  
  385.           3.1.3.  If the initiator can not be modified
  386.  
  387.           Of course, there is always the question of how can a transport
  388.           entity, which can not be modified, be forced to use a TS-
  389.           bridge.  In most circumstances, these implementations can be
  390.           "tricked" to use a TS-bridge, on a case-by-case basis.
  391.  
  392.           Usually, these "out of the box" implementations have an
  393.           address database.  For a small number of end-systems in other
  394.           OSI communities that the end-system needs to talk to, the
  395.           address database can be modified by hand; i.e., the address
  396.           database is modified such that these end-systems are listed as
  397.           having the same network address as the TS-bridge, and the
  398.           transport selector for the services offered by those end-
  399.           systems is modified to encode the actual network address and
  400.           transport selector.
  401.  
  402.           Obviously, such an approach does not scale, but for
  403.           implementations so limited it is a work-around.
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.           M.T. Rose (editor)                                    [Page 7]
  415.  
  416.  
  417.  
  418.  
  419.  
  420.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  421.  
  422.  
  423.           3.2.  Responder use of TS-bridges
  424.  
  425.           A responding transport entity need not be modified with this
  426.           approach.
  427.  
  428.           However, as a local matter responding implementations may
  429.           apply the encoded-TSEL test to the calling transport selector
  430.           and accordingly note the actual initiator transport address.
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.           M.T. Rose (editor)                                    [Page 8]
  474.  
  475.  
  476.  
  477.  
  478.  
  479.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  480.  
  481.  
  482.           4.  Operation of TS-bridges
  483.  
  484.           The state machine and parameterization described in Sections
  485.           6.1 and 6.2 of [1] is used.
  486.  
  487.           When a TS-bridge receives a T-CONNECT.IND primitive, as
  488.           described in [4]:
  489.  
  490.           (1)  If the called transport selector fails the encoded-TSEL
  491.                test, the incoming connection is disconnected.
  492.                Otherwise, the TS-bridge decodes the actual destination
  493.                network address and transport selector from the called
  494.                transport selector.
  495.  
  496.           (2)  The TS-bridge examines the calling transport selector,
  497.                and if this fails the encoded-TSEL test, then the
  498.                encoding is applied to the calling network address and
  499.                transport selector, and the resulting string of octets
  500.                replaces the calling transport selector.  If the length
  501.                of the resulting string of octets exceeds the limitation
  502.                of the local transport entity (usually 32 octets), then
  503.                no substitution is made.
  504.  
  505.           (3)  The TS-bridge now determines if it can directly reach the
  506.                destination network address.  If so, a T-CONNECT.REQ
  507.                primitive is invoked with the called transport selector
  508.                equal to the value determined in step 1 (the actual
  509.                destination transport selector), and the calling
  510.                transport selector equal to the value determined in step
  511.                2.
  512.  
  513.           (4)  If the TS-bridge determines that it can not directly
  514.                reach the destination network address, then the TS-bridge
  515.                determines the network address of the next TS-bridge in
  516.                sequence, and invokes a T-CONNECT.REQ primitive, with the
  517.                original (encoded) called transport selector, and the
  518.                calling transport selector equal to the value determined
  519.                in step 2.
  520.  
  521.           (5)  If the TS-bridge determines that the network address of
  522.                the next TS-bridge (step 4) or that of the called system
  523.                (step 3) is reachable via the same "subnetwork" through
  524.                which the call is incoming, then the TS-bridge can elect
  525.                to use the redirection procedure specified in Section
  526.                3.1.2.  It will invoke a T-DISCONNECT.REQ primitive,
  527.  
  528.  
  529.  
  530.  
  531.  
  532.           M.T. Rose (editor)                                    [Page 9]
  533.  
  534.  
  535.  
  536.  
  537.  
  538.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  539.  
  540.  
  541.                where the DR information parameter will contain the
  542.                encoding of the address to use on the "subnetwork" and
  543.                that of the "called transport selector" determined in
  544.                step 3 or step 4, and where the "cause" parameter will be
  545.                set to "address unknown".
  546.  
  547.           When a TS-bridge receives a T-CONNECT.CNF primitive, as
  548.           described in [4]:
  549.  
  550.           (1)  The TS-bridge invokes a T-CONNECT.RSP primitive with an
  551.                empty responding address parameter.
  552.  
  553.           If instead of receiving a T-CONNECT.CNF primitive the TS-
  554.           bridge receives receives a T-DISCONNECT.IND it will:
  555.  
  556.           (1)  Check whether the "cause" and "disconnect information"
  557.                parameter pass the encoded-REDIRECT test.  Otherwise, the
  558.                incoming connection will be disconnected.
  559.  
  560.           (2)  Check whether this call has already been redirected.  If
  561.                a "maximum number of redirection" threshold is reached,
  562.                the incoming connection will be disconnected.
  563.  
  564.           (3)  Invoke a new T-CONNECT.REQ primitive towards the address
  565.                deduced in step 1 from the "disconnect information"
  566.                parameter, using the called transport selector determined
  567.                in step 1 and the calling transport selector of the
  568.                original T-CONNECT.REQ primitive.
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.           M.T. Rose (editor)                                   [Page 10]
  592.  
  593.  
  594.  
  595.  
  596.  
  597.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  598.  
  599.  
  600.           5.  Operation of TS-Bridge Where X.25(84) With Address
  601.           Extension Fields is Supported
  602.  
  603.           The procedures in section 4 of this document are modified as
  604.           described below when TP0 is operating over X.25(84) with
  605.           address extension facilities which can accommodate 40
  606.           digits/20 octets NSAP addresses.  In this environment the TS-
  607.           bridge and initiating systems on the X.25(84) subnetwork
  608.           insert the called and calling NSAP addresses in the address
  609.           extension fields and the Transport selectors are not used to
  610.           carry NSAP addresses.  Thus the encoding scheme in 3.1.1 item
  611.           (3) does not apply over the X.25(84) hop and the Transport
  612.           selectors are used for their normal purposes, or may be null.
  613.  
  614.  
  615.           5.1.  For calls to the TP0/X.25(84) subnetwork
  616.  
  617.           When a TS-bridge receives a T-CONNECT.IND primitive, as
  618.           described in [4]:
  619.  
  620.           (1)  If the called transport selector fails the encoded-TSEL
  621.                test, the incoming connection is disconnected.
  622.                Otherwise, the TS-bridge decodes the actual called NSAP
  623.                address and transport selector from the called transport
  624.                selector.  The called NSAP address is inserted in the
  625.                X.25(84) called address extension field.
  626.  
  627.           (2)  The TS-bridge decodes the calling transport selector and
  628.                inserts the derived calling NSAP address in the X.25(84)
  629.                calling address extension field.  If the calling
  630.                transport selector fails the encoded-TSEL test, then the
  631.                transport selector is passed on unmodified and nothing is
  632.                inserted in the X.25(84) calling address extension field.
  633.  
  634.           (3)  The TS-bridge now determines if it can directly reach the
  635.                destination NSAP address.  If so, a T-CONNECT.REQ
  636.                primitive is invoked with the called transport selector
  637.                equal to the value determined in step 1, and the calling
  638.                transport selector equal to the value determined in step
  639.                2.  The associated X.25 network connection uses the NSAP
  640.                addresses derived from steps 1 and 2 in the address
  641.                extension fields.
  642.  
  643.           (4)  If the TS-bridge determines that it cannot directly reach
  644.                the destination NSAP address, then the TS-bridge
  645.  
  646.  
  647.  
  648.  
  649.  
  650.           M.T. Rose (editor)                                   [Page 11]
  651.  
  652.  
  653.  
  654.  
  655.  
  656.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  657.  
  658.  
  659.                determines the X.25 subnetwork address of the next TS-
  660.                bridge in sequence, and invokes a T-CONNECT.REQ
  661.                primitive, and associated X.25 network conection with the
  662.                parameters as described in (3).
  663.  
  664.           When a TS-bridge receives a T-CONNECT.CNF primitive, as
  665.           described in [4]:
  666.  
  667.           (1)  The TS-bridge invokes a T-CONNECT.RSP primitive with an
  668.                empty responding address parameter.
  669.  
  670.  
  671.           5.2.  For calls from the TP0/X.25(84) subnetwork
  672.  
  673.           When a TS-bridge receives a T-CONNECT.IND primitive, as
  674.           described in [4]:
  675.  
  676.           (1)  If the incoming call does not contain a called address
  677.                extension field the procedures of section 4 apply.  If
  678.                there is a called address extension field present, then
  679.                the encoding is applied to this NSAP address and the
  680.                called transport selector, and the resulting string of
  681.                octets replaces the called transport selector.  If the
  682.                length of the resulting string of octets exceeds the
  683.                limitation of the local transport entity (usually 32
  684.                octets), the incoming connection is disconnected.
  685.  
  686.           (2)  The encoding is applied to the calling NSAP address, if
  687.                present, and the calling transport selector, and the
  688.                resulting string of octets replaces the calling transport
  689.                selector.  If the length of the resulting string of
  690.                octets exceeds the limitation of the local transport
  691.                entity (usually 32 octets), no substitution is made.
  692.  
  693.           (3)  The TS-bridge now determines if it can directly reach the
  694.                destination NSAP address.  If so, a T-CONNECT.REQ
  695.                primitive is invoked with the called transport selector
  696.                equal to the value derived in step 1, and the calling
  697.                transport selector equal to the value derived in step 2.
  698.  
  699.           (4)  If the TS-bridge determines that it cannot directly reach
  700.                the destination NSAP address, then the TS-bridge
  701.                determines the subetwork address of the next TS-bridge in
  702.                sequence, and invokes a T-CONNECT.REQ primitive, with
  703.                called and calling transport selectors derived in steps 1
  704.  
  705.  
  706.  
  707.  
  708.  
  709.           M.T. Rose (editor)                                   [Page 12]
  710.  
  711.  
  712.  
  713.  
  714.  
  715.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  716.  
  717.  
  718.                and 2.
  719.  
  720.           When a TS-bridge receives a T-CONNECT.CNF, as described in
  721.           [4]:
  722.  
  723.           (1)  The TS-bridge invokes a T-CONNECT.RSP primitive with an
  724.                empty responding address parameter.
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.           M.T. Rose (editor)                                   [Page 13]
  769.  
  770.  
  771.  
  772.  
  773.  
  774.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  775.  
  776.  
  777.           6.  Acknowledgements
  778.  
  779.           The original version of this memo was produced by the CO/CL
  780.           Interworking Workshop, which met on July 24-26, 1990:
  781.  
  782.                Les Clyne, JNT
  783.                Walid Dabbous, INRIA
  784.                Phill Gross, NRI
  785.                Christian Huitema, INRIA
  786.                Steve Kille, UCL
  787.                Kevin Mills, NIST
  788.                Julian Onions, Nottingham University
  789.                Marshall Rose, PSI
  790.                Rachid Sijelmassi, NIST
  791.                Mitchell Tasman, University of Wisconsin
  792.  
  793.  
  794.  
  795.  
  796.  
  797.  
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.           M.T. Rose (editor)                                   [Page 14]
  828.  
  829.  
  830.  
  831.  
  832.  
  833.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  834.  
  835.  
  836.           7.  References
  837.  
  838.           [1]  M.T. Rose (editor).  An Approach to CO/CL Interworking:
  839.                Part I: Introduction, CO/CL Interworking Workshop,
  840.                (April, 1991).
  841.  
  842.  
  843.           [2]  C. Huitema (editor).  An Approach to CO/CL Interworking:
  844.                -- Part III: The Long-Term -- Conventions for Network-
  845.                Layer Relays and Transport-Service Bridges in the
  846.                presence of Internetworking, CO/CL Interworking Workshop,
  847.                (April, 1991).
  848.  
  849.  
  850.           [3]  S.E. Kille.  A string encoding of Presentation Address.
  851.                Research Note RN/89/14.  Department of Computer Science,
  852.                University College London, (February, 1989).
  853.  
  854.  
  855.           [4]  International Organization for Standardization.
  856.                Information Processing Systems--Open Systems
  857.                Interconnection--Transport Service Definition.
  858.                International Standard 8072.  (June, 1986).
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.           M.T. Rose (editor)                                   [Page 15]
  887.  
  888.  
  889.  
  890.  
  891.  
  892.           Internet Draft      CO/CL Interworking -- Short-Term         Apr 91
  893.  
  894.  
  895.           Table of Contents
  896.  
  897.  
  898.           1 Status of this Memo ...................................    1
  899.           2 Introduction ..........................................    2
  900.           3 Impact of TS-bridges on End-Systems ...................    3
  901.           3.1 Initiator use of TS-bridges .........................    3
  902.           3.1.1 Use of TS-bridge knowledge ........................    4
  903.           3.1.2 Redirection procedure .............................    6
  904.           3.1.3 If the initiator can not be modified ..............    7
  905.           3.2 Responder use of TS-bridges .........................    8
  906.           4 Operation of TS-bridges ...............................    9
  907.           5 Operation of TS-Bridge Where X.25(84)  With  Address
  908.                Extension Fields is Supported ......................   11
  909.           5.1 For calls to the TP0/X.25(84) subnetwork ............   11
  910.           5.2 For calls from the TP0/X.25(84) subnetwork ..........   12
  911.           6 Acknowledgements ......................................   14
  912.           7 References ............................................   15
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.           M.T. Rose (editor)                                   [Page 16]
  946.  
  947.  
  948. ------- End of Forwarded Message
  949.  
  950.