rfc1306.txt

中、英文RFC文档大全打包下载完全版 .

Network Working Group                                       A. Nicholson
Request for Comments: 1306                                      J. Young
                                                     Cray Research, Inc.
                                                              March 1992


     Experiences Supporting By-Request Circuit-Switched T3 Networks

Status of this Memo

   This RFC provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This memo describes the experiences of a project team at Cray
   Research, Inc., in implementing support for circuit-switched T3
   services.  While the issues discussed may not be directly relevant to
   the research problems of the Internet, they may be interesting to a
   number of researchers and implementers.

   Developers at Cray Research, Inc. were presented with an opportunity
   to use a circuit-switched T3 network for wide area networking.  They
   devised an architectural model for using this new resource.  This
   involves activating the circuit-switched connection when an
   application program engages in a bulk data transfer, and releasing
   the connection when the transfer is complete.

   Three software implementations for this feature have been tested, and
   the results documented here.  A variety of issues are involved, and
   further research is necessary.  Network users are beginning to
   recognize the value of this service, and are planning to make use of
   by-request circuit-switched networks.  A standard method of access
   will be needed to ensure interoperability among vendors of circuit-
   switched network support products.

Acknowledgements

   The authors thank the T3 project team and other members of the
   Networking Group at Cray Research, Inc., for their efforts: Wayne
   Roiger, Gary Klesk, Joe Golio, John Renwick, Dave Borman and Craig
   Alesso.








Nicholson & Young                                               [Page 1]

RFC 1306          Experiences with Circuit-Switched T3        March 1992


Overview

   Users of wide-area networks often must make a compromise between low
   cost and high speed when accessing long haul connections.  The high
   money cost of dedicated high speed connections makes them
   uneconomical for scientists and engineers with limited budgets.  For
   many traditional applications this has not been a problem.  Datasets
   can be maintained on the remote computer and results were presented
   in a text-only form where a low-speed connection would suffice.
   However, for visualization and other data transfer intensive
   applications, this limitation can severely impact the usability of
   high performance computing tools which are available only through
   long-haul network connections.

   Supercomputers are one such high performance tool.  Many users who
   can benefit from access to supercomputers are limited by slow network
   connections to a centrally located supercomputer.  A solution to this
   problem is to use a circuit-switched network to provide high speed
   network connectivity at a reduced cost by allocating the network only
   when it is needed.

   Consider how a researcher using a visualization application might
   efficiently use a dedicated low speed link and a circuit switched
   high speed link.  The researcher logs in to the remote supercomputer
   over the low speed link.  After running whatever programs are
   necessary to prepare the visualization, the high speed connection is
   activated and used to transfer the graphics data to the researcher's
   workstation.

   We built and demonstrated this capability in September, 1990, at the
   Telecommunications Association show in San Diego, using this type of
   visualization application.  Further, it will be available in a
   forthcoming release of our system software.

Architectural Model

   We developed our support for circuit switched services around a
   simple model of a switched network.  At some point in the path
   between two hosts, there is a switched network connection.  This
   connection is likely to connect two enterprise networks operated by
   the same organization.  Administrative overlap between the two
   networks is useful for accounting and configuration purposes.  We
   believe that with further investigation circuit switched network
   support could be extended to multiple switched links in an internet
   environment.

   The switch which makes the network connection operates on a "by-
   request" basis (also called "on-demand").  When it receives a request



Nicholson & Young                                               [Page 2]

RFC 1306          Experiences with Circuit-Switched T3        March 1992


   to make a network connection it will do so (if possible), and breaks
   the connection when requested.  The switch will not activate
   automatically if there is an attempt to transfer data over an
   incomplete connection.

   We also made the assumption that the circuit would be switched on a
   connection basis rather than a packet basis.  When an application
   begins sending data utilizing the switched connection, it will send
   all the data it has, without stopping, until it is finished.  At this
   time it will release the connection.  It is assumed that the quantity
   of data will be large enough that the circuit setup time is
   negligible relative to the period of the transfer.  Otherwise, it is
   not worth the effort to support the circuit switched network for
   small data transfers.

   This model requires that just before the application begins a large
   bulk transfer of data, a request message is sent to the switch asking
   that the switched network connection be activated.  Once the link is
   up, the application begins sending data, and the network routes all
   the data from the application through the switched network.  As soon
   as all the data has been sent, a message is sent to the switch to
   turn off the switched link, and the network returns to routing data
   through the slower link.

   The prototype system we built for the TCA show was designed around
   this model of circuit switched services.  We connected a FDDI
   backbone at Cray Research in Eagan, Minnesota to the TCA show's FDDI
   network through 2 NSC 703 FDDI/T1/T3 routers.  MCI provided a
   dedicated T1 line and a switched T3 line, using a DSC DS3 T3 switch
   located in Dallas, Texas.  These networks provided connectivity
   between a Cray Research computer in Eagan to a Sun workstation on the
   show floor in San Diego.

Alternative Solution Strategies

   The first aspect of using the switched services involved the circuit
   switch.  The DS3 switch available to us was accessed via a dial up
   modem, and it communicated using a subset of the CCITT Q.295
   protocol.  Activating the switch required a 4 message exchange and
   deactivation required a 3 message exchange.  We felt the protocol was
   awkward and might be different for other switch hardware.
   Furthermore, we believed that the dial up aspect of communicating
   with the switch suffered from the same drawbacks.  A good solution
   would require a cleaner method of controlling the switch from the
   source host requesting the switched line.

   The next aspect of using switched services involves the source host
   software which requests and releases the switched network.  Ideally,



Nicholson & Young                                               [Page 3]

RFC 1306          Experiences with Circuit-Switched T3        March 1992


   the switched network is activated just before data transfer takes
   place and it is released as soon as all data has been sent.  We
   considered using special utility programs which a user could execute
   to control the link, special system libraries which application
   programs could call, or building the capability into the kernel.  We
   also considered the possibility that these methods could send
   messages to a daemon running on the source host which would then
   communicate with another entity actually controlling the switch.

   The last aspect of using switched services we considered is selection
   of the switch controlled network.  This involves both policy issues
   and routing issues.  Policy issues include which users running which
   applications will be able to use higher cost switched links.  And
   packets must be routed amongst multiple connections offering varying
   levels of service after they leave their source.

Implementations

   We have developed a model for switch control through the internetwork
   which we believe to be reasonable.  However, we have experimented
   with three different source host implementations.  These different
   implementations are detailed here.

Switch control

   Our simplest design decisions involved the switch itself.  We decided
   that the complex protocol and dial up line must be hidden from the
   source host requesting the switched link.  We decided that the source
   host would use a simple request/release protocol with messages sent
   through the regular network (as opposed to dial up lines or other
   connections).  Some host accessible through the local network would
   run a program translating the simple request and release messages
   into the more complicated switch protocol and also have the modem to
   handle the dial up connection.

   This has a variety of advantages.  First, it isolates differences in
   switch hardware.  Second, multiple hosts may access the switch
   without requiring multiple modems for the dial up line.  And it
   provides a central point of control for switch access.  We did not
   consider any alternatives to this model of switch control.

   Our initial implementation used a simple translator daemon running on
   a Sun workstation.  Listening on a raw IP port, this program would
   wait for switch control messages.  Upon receipt of such a message, it
   would dial up the switch and attempt to handle the request.  It would
   then send back a success or failure response.  This host, in
   conjunction with the translator daemon software, is referred to as
   the switch controller.  The switch controller we used was local to



Nicholson & Young                                               [Page 4]

RFC 1306          Experiences with Circuit-Switched T3        March 1992


   our enterprise network; however, it could reside anywhere in the
   Internet.

   Later we designed a simple protocol for switch control, which was
   implemented in the translator daemon.  This protocol is documented in
   RFC 1307, "Dynamically Switched Link Control Protocol".

Source Control of the Switched Link

   This problem involves a decision regarding what entity on the source
   host will issue the switch request and release messages to the switch
   controller, and when those messages will be issued.  Because we do
   not have very much field experience with this service, we do not feel
   that it is appropriate to recommend one method over the others.  They
   all have advantages and disadvantages.

   What we did do is make 3 different implementations of the request
   software and can report our experiences with each.  These are one set
   of special utility programs which communicate with the switch
   controller, and 2 kernel implementations.  We did not experiment with
   special libraries, nor did we implement a daemon for switch control
   messages on the source host.

Switch control user programs

   This implementation of source host control of the switch is the
   simplest.  Two programs were written which would communicate requests
   to the switch controller; one for activating the connection, and
   another to deactivate the connection.  The applications using this
   feature were then put into shell scripts with the switch control
   programs for simple execution.

   This approach has the significant advantage of not requiring any
   kernel modifications to any machine.  Furthermore, application
   programs do not need to be modified to access this feature.  And
   access to the circuit-switched links can be controlled using the
   access permissions for the switch-control programs.

   However, there are disadvantages as well.  First, there is
   significant potential for the switch to be active (and billing the
   user) for the dead time while the application program is doing tasks
   other than transferring bulk data.  The granularity of turning the
   switch on and off is limited to a per-application basis.

   Another disadvantage is that most applications use only the
   destination host's address for transfer, and this is the only
   information available to the transport and network layers for routing
   data packets.  Some other method must be used to distinguish between



Nicholson & Young                                               [Page 5]