As per Relevance of the word switched, we have this rfc below:
Network Working Group A.
Request for Comments: 1306 J.
Cray Research, Inc
March 1992
Experiences Supporting By-Request Circuit-Switched T3
Status of this
This RFC provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This memo describes the experiences of a project team at
Research, Inc., in implementing support for circuit-switched T
services. While the issues discussed may not be directly relevant
the research problems of the Internet, they may be interesting to
number of researchers and implementers
Developers at Cray Research, Inc. were presented with an
to use a circuit-switched T3 network for wide area networking.
devised an architectural model for using this new resource.
involves activating the circuit-switched connection when
application program engages in a bulk data transfer, and
the connection when the transfer is complete
Three software implementations for this feature have been tested,
the results documented here. A variety of issues are involved,
further research is necessary. Network users are beginning
recognize the value of this service, and are planning to make use
by-request circuit-switched networks. A standard method of
will be needed to ensure interoperability among vendors of circuit
switched network support products
The authors thank the T3 project team and other members of
Networking Group at Cray Research, Inc., for their efforts:
Roiger, Gary Klesk, Joe Golio, John Renwick, Dave Borman and
Alesso
Nicholson & Young [Page 1]
RFC 1306 Experiences with Circuit-Switched T3 March 1992
Users of wide-area networks often must make a compromise between
cost and high speed when accessing long haul connections. The
money cost of dedicated high speed connections makes
uneconomical for scientists and engineers with limited budgets.
many traditional applications this has not been a problem.
can be maintained on the remote computer and results were
in a text-only form where a low-speed connection would suffice
However, for visualization and other data transfer
applications, this limitation can severely impact the usability
high performance computing tools which are available only
long-haul network connections
Supercomputers are one such high performance tool. Many users
can benefit from access to supercomputers are limited by slow
connections to a centrally located supercomputer. A solution to
problem is to use a circuit-switched network to provide high
network connectivity at a reduced cost by allocating the network
when it is needed
Consider how a researcher using a visualization application
efficiently use a dedicated low speed link and a circuit
high speed link. The researcher logs in to the remote
over the low speed link. After running whatever programs
necessary to prepare the visualization, the high speed connection
activated and used to transfer the graphics data to the researcher'
workstation
We built and demonstrated this capability in September, 1990, at
Telecommunications Association show in San Diego, using this type
visualization application. Further, it will be available in
forthcoming release of our system software
Architectural
We developed our support for circuit switched services around
simple model of a switched network. At some point in the
between two hosts, there is a switched network connection.
connection is likely to connect two enterprise networks operated
the same organization. Administrative overlap between the
networks is useful for accounting and configuration purposes.
believe that with further investigation circuit switched
support could be extended to multiple switched links in an
environment
The switch which makes the network connection operates on a "by
request" basis (also called "on-demand"). When it receives a
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
the connection when requested. The switch will not
automatically if there is an attempt to transfer data over
incomplete connection
We also made the assumption that the circuit would be switched on
connection basis rather than a packet basis. When an
begins sending data utilizing the switched connection, it will
all the data it has, without stopping, until it is finished. At
time it will release the connection. It is assumed that the
of data will be large enough that the circuit setup time
negligible relative to the period of the transfer. Otherwise, it
not worth the effort to support the circuit switched network
small data transfers
This model requires that just before the application begins a
bulk transfer of data, a request message is sent to the switch
that the switched network connection be activated. Once the link
up, the application begins sending data, and the network routes
the data from the application through the switched network. As
as all the data has been sent, a message is sent to the switch
turn off the switched link, and the network returns to routing
through the slower link
The prototype system we built for the TCA show was designed
this model of circuit switched services. We connected a
backbone at Cray Research in Eagan, Minnesota to the TCA show's
network through 2 NSC 703 FDDI/T1/T3 routers. MCI provided
dedicated T1 line and a switched T3 line, using a DSC DS3 T3
located in Dallas, Texas. These networks provided
between a Cray Research computer in Eagan to a Sun workstation on
show floor in San Diego
Alternative Solution
The first aspect of using the switched services involved the
switch. The DS3 switch available to us was accessed via a dial
modem, and it communicated using a subset of the CCITT Q.295
protocol. Activating the switch required a 4 message exchange
deactivation required a 3 message exchange. We felt the protocol
awkward and might be different for other switch hardware
Furthermore, we believed that the dial up aspect of
with the switch suffered from the same drawbacks. A good
would require a cleaner method of controlling the switch from
source host requesting the switched line
The next aspect of using switched services involves the source
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
place and it is released as soon as all data has been sent.
considered using special utility programs which a user could
to control the link, special system libraries which
programs could call, or building the capability into the kernel.
also considered the possibility that these methods could
messages to a daemon running on the source host which would
communicate with another entity actually controlling the switch
The last aspect of using switched services we considered is
of the switch controlled network. This involves both policy
and routing issues. Policy issues include which users running
applications will be able to use higher cost switched links.
packets must be routed amongst multiple connections offering
levels of service after they leave their source
We have developed a model for switch control through the
which we believe to be reasonable. However, we have
with three different source host implementations. These
implementations are detailed here
Switch
Our simplest design decisions involved the switch itself. We
that the complex protocol and dial up line must be hidden from
source host requesting the switched link. We decided that the
host would use a simple request/release protocol with messages
through the regular network (as opposed to dial up lines or
connections). Some host accessible through the local network
run a program translating the simple request and release
into the more complicated switch protocol and also have the modem
handle the dial up connection
This has a variety of advantages. First, it isolates differences
switch hardware. Second, multiple hosts may access the
without requiring multiple modems for the dial up line. And
provides a central point of control for switch access. We did
consider any alternatives to this model of switch control
Our initial implementation used a simple translator daemon running
a Sun workstation. Listening on a raw IP port, this program
wait for switch control messages. Upon receipt of such a message,
would dial up the switch and attempt to handle the request. It
then send back a success or failure response. This host,
conjunction with the translator daemon software, is referred to
the switch controller. The switch controller we used was local
Nicholson & Young [Page 4]
RFC 1306 Experiences with Circuit-Switched T3 March 1992
our enterprise network; however, it could reside anywhere in
Internet
Later we designed a simple protocol for switch control, which
implemented in the translator daemon. This protocol is documented
RFC 1307, "Dynamically Switched Link Control Protocol".
Source Control of the Switched
This problem involves a decision regarding what entity on the
host will issue the switch request and release messages to the
controller, and when those messages will be issued. Because we
not have very much field experience with this service, we do not
that it is appropriate to recommend one method over the others.
all have advantages and disadvantages
What we did do is make 3 different implementations of the
software and can report our experiences with each. These are one
of special utility programs which communicate with the
controller, and 2 kernel implementations. We did not experiment
special libraries, nor did we implement a daemon for switch
messages on the source host
Switch control user
This implementation of source host control of the switch is
simplest. Two programs were written which would communicate
to the switch controller; one for activating the connection,
another to deactivate the connection. The applications using
feature were then put into shell scripts with the switch
programs for simple execution
This approach has the significant advantage of not requiring
kernel modifications to any machine. Furthermore,
programs do not need to be modified to access this feature.
access to the circuit-switched links can be controlled using
access permissions for the switch-control programs
However, there are disadvantages as well. First, there
significant potential for the switch to be active (and billing
user) for the dead time while the application program is doing
other than transferring bulk data. The granularity of turning
switch on and off is limited to a per-application basis
Another disadvantage is that most applications use only
destination host's address for transfer, and this is the
information available to the transport and network layers for
data packets. Some other method must be used to distinguish
Nicholson & Young [Page 5]
RFC 1306 Experiences with Circuit-Switched T3 March 1992
traffic which should use the circuit-switched connection and lower
priority traffic. This problem can be addressed using route aliases
described below
Kernel switch
We have made two different implementations of switch
facilities within the operating system kernel. Both rely upon
routing lookup code in the kernel to send switch connect and
down messages. The difference is in how the time delay
request of the switch and a response is handled
For starters, routing table entries were expanded to include
internet address of the switch controller and state information
the switched connection. If there is a switch controller
specified, then the connection must be set up before packets may
sent on this route. We also added a separate module to handle
sending and receiving of the switch control messages
When a routing lookup is satisfied, the routing code would
whether the routing table entry specified a switch controller.
so, then the routine requesting switch setup would be called.
would send a message on the Internet to the switch controller
setup the connection
In our first implementation, the routing lookup call would
immediately after sending the switch connection request message.
would be the responsibility of the transport protocol to deal
the time delay while the connection is setup, and to tear down if
switched connection could not be made. This has
ramifications. In the case of UDP and IP, packets must be
for later transmission or face almost certain extermination as
will probably start arriving at the switched connection before it
ready to carry traffic. Because of this problem, we decided
this feature would not be available for UDP or IP traffic
We did make this work for TCP. Since TCP is already designed to
so that it buffers all data for possible later retransmission,
was not a problem. Our first cut was to change TCP to check that
route it was using was up if it is a switch controlled route.
would not send any data until the route was complete, and it
close the connection if the switch did not come up
This did not work well at first because every time TCP tried to
data before the switch came up, the retransmit time would be
and backed off. The rtt estimate, retransmit timeouts and
congestion control mechanism were seriously skewed before any
was ever sent. The retransmit timer would expire as many as 3
Nicholson & Young [Page 6]
RFC 1306 Experiences with Circuit-Switched T3 March 1992
before data could be transmitted. We solved this problem by
another timer for handling the delay while the route came up, and
allowing the delay to affect any of the normal rtt timers
Our experiences with this approach were not particularly positive
and we decided to try another. We also felt that unreliable
protocols should be able to use the service without
reworking. Our alternative still sends the switch control
when a routing lookup finds a controlled route. However, we
suspend execution of the thread of control until a response
back from the switch controller
This proved to be easier to implement in many ways. However,
were two major areas requiring changes outside the routing code
First, we decided that if the switch refused to activate
connection, it was pointless to try again. So we changed the
lookup interface so that it could return an error specifying
permanent error condition. The transport layer could then return
appropriate error such as a host unreachable condition
The other, more complex issue deals with the suspension of the
of execution. Our operating system, UNICOS, is an ATT System
derivative, and our networking subsystem is based on the BSD
and reno releases. The only way to suspend execution is to sleep
This is fine, as long as there is a user context to put to sleep
However, it is not a good idea to go to sleep when processing
interrupts, as when forwarding a packet
We solved this problem by using a global flag regarding whether
was ok for the switch control message code to sleep. If it
necessary to send a message and sleep, then the flag must be set
an error is returned if sleeping is not allowed. User system
which might cause a switch control message to be sent set and
the flag upon entrance and exit. We also made it impossible
forward packets on a switch controlled route. We feel that this
reasonable since the overhead of switch control should be
only when an application program has made an explicit request
begin transfer of data
The one other change we made was to make sure that TCP freed
route it is using upon entering TIME_WAIT state. There is no
in holding the circuit open for two minutes in case we need
retransmit the final ack. Of course, this assumes that an
path exists for the the peer to retransmit its fin
The advantage of building this facility into the kernel is that
allows a fine degree of control over when the switch will and
not need to be activated. Many applications which open a
Nicholson & Young [Page 7]
RFC 1306 Experiences with Circuit-Switched T3 March 1992
connection, transmit their bulk data, and then close the
will not require modifications and will make efficient use of
resource. It also opens the possibility that applications written
use type-of-service can use the same network connection for low
bandwidth interactive traffic, change the type-of-service (
activating the switched connection) for bulk transfers, and
release the switch upon returning to interactive traffic
Putting this feature into the kernel also allows strong control
when and how the switched link can be used, keeping
information, and limiting multiple use access to the switched link
The disadvantage is that significant kernel modifications
required, and some implementation details can be very difficult
handle
Switch control
The switch control programs we used were built on a library of
switch control routines; however, we did not alter any
applications to use this library. We did consider some
and disadvantages. On the plus side, it is possible to achieve
satisfactory degree of switch control without requiring any
modifications
The primary disadvantage of this approach is that all
must be altered and recompiled. This is particularly
when source is not available
Link
When an application wishes to send data over a circuit-
connection, it will be necessary to select the switched link
other links. This selection process may need to take place
times, depending on the local network between the source host and
bridge to the circuit switched connection
For example, if the kernel routing code is controlling the link,
there must be a way to choose a controlled route over another route
Further downstream, there must be a way to route packets to
switched link rather than other links
This issue has the potential for great complexity, and we avoided
much of the complexity as possible. Policy routing and local
across multiple connections are fertile areas for work and it
outside the scope of this work to address those issues. Instead
opted for simple answers to difficult questions
Nicholson & Young [Page 8]
RFC 1306 Experiences with Circuit-Switched T3 March 1992
First of all, we added no special policies to link
beyond that already found in UNICOS. And we handled local
issues to the NSC FDDI/T1/T3 routers with routing table
and IP Type-of-Service
We came up with three solutions for selecting a routing table entry
The first possibility is to use the type-of-service bits,
seemed natural to us. We changed the routing table to include type
of-service values associated with routing entries, and the
lookups would select using the type-of-service. UNICOS
supports a facility to mark connections with a type-of-service value
A controlled route could be marked with high throughput type-of
service and an application wishing to transfer bulk data could
the socket for high throughput before making the connection.
could also be possible to change the type-of-service on an
connection and start using the switched link if one is available
Using the type-of-service bits have the advantage that
routers can also use this information. In our demonstration system
the NSC FDDI/T1/T3 routers were configured to transfer packets
high throughput type-of-service over the T3 connection and all
over the T1 connection
Another possibility is to take advantage of the multiple addresses
a multi-homed host. Routing tables could be set up so that
for one of the addresses get special treatment by traveling over
switched link. The routing table in the source host would have
entry for accessing the switch controller when sending to the
throughput destination address
We also derived a method we call route aliasing. Route
involves associating extra addresses to a single host. However
rather than the destination being an actual multi-homed host,
alias is known only to the source host and is used as an
lookup key. When an application tries to connect to the
address the routing lookup returns an aliased route. The route
contains the actual address of the host, but because of looking
the special address, the switch is activated. The alias could
specify a type-of-service value to send in the packets so
downstream routers could properly route the packets to the
link. We realize that some may bemoan the waste of the
Internet address space for aliases; however, only the source host
aware of the alias, and the primary shortage is with Internet
addresses rather than host addresses. In fact, we argue that this
a more efficient use of the already sparse allocation of
addresses available with each network address
Nicholson & Young [Page 9]
RFC 1306 Experiences with Circuit-Switched T3 March 1992
Future
We believe that by-request services will become
important to certain classes of users. Many data centers make
performance resources available over a wide area, and these will
the first users to take advantage of wide-area circuit-
networks. Some users, such as CICNet ([2]), are already
in deploying this capability and telecom vendors are working
satisfy this need. However, there are a lot of issues involved
providing this functionality. We are working to involve others
this process
[1] Nicholson, et. al., "High Speed Networking at Cray Research",
Computer Communications Review, January 1991.
[2] CICNet DS3 Working Group, "High Performance Applications
CICNet: Impact on Design and Capacity", public report, CICNet
Inc., June 1991.
[3] Young, J., and A. Nicholson, "Dynamically Switched Link
Protocol", RFC 1307, Cray Research, Inc., March 1992.
Security
Security issues are not discussed in this memo
Authors'
Andy
Cray Research, Inc
655F Lone Oak
Eagan, MN 55123
Phone: (612) 452-6650
EMail: droid@cray.
Jeff
Cray Research, Inc
655F Lone Oak
Eagan, MN 55123
Phone: (612) 452-6650
EMail: jsy@cray.
Nicholson & Young [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
