rfc1306.txt

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


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 control

   We have made two different implementations of switch control
   facilities within the operating system kernel.  Both rely upon the
   routing lookup code in the kernel to send switch connect and tear
   down messages.  The difference is in how the time delay between
   request of the switch and a response is handled.

   For starters, routing table entries were expanded to include the
   internet address of the switch controller and state information for
   the switched connection.  If there is a switch controller address
   specified, then the connection must be set up before packets may be
   sent on this route.  We also added a separate module to handle the
   sending and receiving of the switch control messages.

   When a routing lookup is satisfied, the routing code would check
   whether the routing table entry specified a switch controller.  If
   so, then the routine requesting switch setup would be called.  This
   would send a message on the Internet to the switch controller to
   setup the connection.

   In our first implementation, the routing lookup call would return
   immediately after sending the switch connection request message.  It
   would be the responsibility of the transport protocol to deal with
   the time delay while the connection is setup, and to tear down if the
   switched connection could not be made.  This has significant
   ramifications.  In the case of UDP and IP, packets must be buffered
   for later transmission or face almost certain extermination as they
   will probably start arriving at the switched connection before it is
   ready to carry traffic.  Because of this problem, we decided that
   this feature would not be available for UDP or IP traffic.

   We did make this work for TCP.  Since TCP is already designed to work
   so that it buffers all data for possible later retransmission, this
   was not a problem.  Our first cut was to change TCP to check that the
   route it was using was up if it is a switch controlled route.  TCP
   would not send any data until the route was complete, and it would
   close the connection if the switch did not come up.

   This did not work well at first because every time TCP tried to send
   data before the switch came up, the retransmit time would be reset
   and backed off.  The rtt estimate, retransmit timeouts and the
   congestion control mechanism were seriously skewed before any data
   was ever sent.  The retransmit timer would expire as many as 3 times



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


   before data could be transmitted.  We solved this problem by adding
   another timer for handling the delay while the route came up, and not
   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 datagram
   protocols should be able to use the service without excessive
   reworking.  Our alternative still sends the switch control message
   when a routing lookup finds a controlled route.  However, we now
   suspend execution of the thread of control until a response comes
   back from the switch controller.

   This proved to be easier to implement in many ways.  However, there
   were two major areas requiring changes outside the routing code.
   First, we decided that if the switch refused to activate the
   connection, it was pointless to try again.  So we changed the routing
   lookup interface so that it could return an error specifying a
   permanent error condition.  The transport layer could then return an
   appropriate error such as a host unreachable condition.

   The other, more complex issue deals with the suspension of the thread
   of execution.  Our operating system, UNICOS, is an ATT System V
   derivative, and our networking subsystem is based on the BSD tahoe
   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 network
   interrupts, as when forwarding a packet.

   We solved this problem by using a global flag regarding whether it
   was ok for the switch control message code to sleep.  If it is
   necessary to send a message and sleep, then the flag must be set and
   an error is returned if sleeping is not allowed.  User system calls
   which might cause a switch control message to be sent set and clear
   the flag upon entrance and exit.  We also made it impossible to
   forward packets on a switch controlled route.  We feel that this is
   reasonable since the overhead of switch control should be incurred
   only when an application program has made an explicit request to
   begin transfer of data.

   The one other change we made was to make sure that TCP freed the
   route it is using upon entering TIME_WAIT state.  There is no point
   in holding the circuit open for two minutes in case we need to
   retransmit the final ack.  Of course, this assumes that an alternate
   path exists for the the peer to retransmit its fin.

   The advantage of building this facility into the kernel is that it
   allows a fine degree of control over when the switch will and will
   not need to be activated.  Many applications which open a data



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


   connection, transmit their bulk data, and then close the connection
   will not require modifications and will make efficient use of the
   resource.  It also opens the possibility that applications written to
   use type-of-service can use the same network connection for low-
   bandwidth interactive traffic, change the type-of-service (thus
   activating the switched connection) for bulk transfers, and then
   release the switch upon returning to interactive traffic.

   Putting this feature into the kernel also allows strong control over
   when and how the switched link can be used, keeping accounting
   information, and limiting multiple use access to the switched link.

   The disadvantage is that significant kernel modifications are
   required, and some implementation details can be very difficult to
   handle.

Switch control libraries

   The switch control programs we used were built on a library of simple
   switch control routines; however, we did not alter any standard
   applications to use this library.  We did consider some advantages
   and disadvantages.  On the plus side, it is possible to achieve a
   satisfactory degree of switch control without requiring any kernel
   modifications.

   The primary disadvantage of this approach is that all applications
   must be altered and recompiled.  This is particularly inconvenient
   when source is not available.

Link Selection

   When an application wishes to send data over a circuit-switched
   connection, it will be necessary to select the switched link over
   other links.  This selection process may need to take place many
   times, depending on the local network between the source host and the
   bridge to the circuit switched connection.

   For example, if the kernel routing code is controlling the link, then
   there must be a way to choose a controlled route over another route.
   Further downstream, there must be a way to route packets to the
   switched link rather than other links.

   This issue has the potential for great complexity, and we avoided as
   much of the complexity as possible.  Policy routing and local routing
   across multiple connections are fertile areas for work and it is
   outside the scope of this work to address those issues.  Instead we
   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 accessibility
   beyond that already found in UNICOS.  And we handled local routing
   issues to the NSC FDDI/T1/T3 routers with routing table manipulation
   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, which
   seemed natural to us.  We changed the routing table to include type-
   of-service values associated with routing entries, and the routing
   lookups would select using the type-of-service.  UNICOS already
   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 set
   the socket for high throughput before making the connection.  It
   could also be possible to change the type-of-service on an existing
   connection and start using the switched link if one is available.

   Using the type-of-service bits have the advantage that downstream
   routers can also use this information.  In our demonstration system,
   the NSC FDDI/T1/T3 routers were configured to transfer packets with
   high throughput type-of-service over the T3 connection and all others
   over the T1 connection.

   Another possibility is to take advantage of the multiple addresses of
   a multi-homed host.  Routing tables could be set up so that packets
   for one of the addresses get special treatment by traveling over the
   switched link.  The routing table in the source host would have an
   entry for accessing the switch controller when sending to the high
   throughput destination address.

   We also derived a method we call route aliasing.  Route aliasing
   involves associating extra addresses to a single host.  However,
   rather than the destination being an actual multi-homed host, the
   alias is known only to the source host and is used as an alternative
   lookup key.  When an application tries to connect to the alias
   address the routing lookup returns an aliased route.  The route alias
   contains the actual address of the host, but because of looking up
   the special address, the switch is activated.  The alias could also
   specify a type-of-service value to send in the packets so that
   downstream routers could properly route the packets to the switched
   link.  We realize that some may bemoan the waste of the limited
   Internet address space for aliases; however, only the source host is
   aware of the alias, and the primary shortage is with Internet network
   addresses rather than host addresses.  In fact, we argue that this is
   a more efficient use of the already sparse allocation of host
   addresses available with each network address.





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


Future considerations

   We believe that by-request services will become increasingly
   important to certain classes of users.  Many data centers make high
   performance resources available over a wide area, and these will be
   the first users to take advantage of wide-area circuit-switched
   networks.  Some users, such as CICNet ([2]), are already interested
   in deploying this capability and telecom vendors are working to
   satisfy this need.  However, there are a lot of issues involved in
   providing this functionality.  We are working to involve others in
   this process.

References

   [1]  Nicholson, et. al., "High Speed Networking at Cray Research",
        Computer Communications Review, January 1991.

   [2]  CICNet DS3 Working Group, "High Performance Applications on
        CICNet: Impact on Design and Capacity", public report, CICNet,
        Inc., June 1991.

   [3]  Young, J., and A. Nicholson, "Dynamically Switched Link Control
        Protocol", RFC 1307, Cray Research, Inc., March 1992.

Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Andy Nicholson
   Cray Research, Inc.
   655F Lone Oak Drive
   Eagan, MN 55123

   Phone: [phone]
   EMail: [e-mail]


   Jeff Young
   Cray Research, Inc.
   655F Lone Oak Drive
   Eagan, MN 55123

   Phone: [phone]
   EMail: [e-mail]





Nicholson & Young                                              [Page 10]