summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1307.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1307.txt')
-rw-r--r--doc/rfc/rfc1307.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc1307.txt b/doc/rfc/rfc1307.txt
new file mode 100644
index 0000000..ca48dc6
--- /dev/null
+++ b/doc/rfc/rfc1307.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group J. Young
+Request for Comments: 1307 A. Nicholson
+ Cray Research, Inc.
+ March 1992
+
+
+ Dynamically Switched Link Control Protocol
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. Discussion and suggestions for improvement are requested.
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" for the standardization state and status of this protocol.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ This memo describes an experimental protocol developed by a project
+ team at Cray Research, Inc., in implementing support for circuit-
+ switched T3 services. The protocol is used for the control of
+ network connections external to a host, but known to the host. It is
+ documented here for the benefit of others who may wish to perform
+ further research.
+
+ While working with circuit-switched T3 networks, developers at Cray
+ Research, Inc., defined a model wherein a host would generate control
+ messages for a network switch. This work is described in RFC 1306,
+ "Experiences Supporting By-Request Circuit-Switched T3 Networks". In
+ order to simplify the model it was decided that the inconsistencies
+ of switch control should be hidden from the host generating the
+ control messages. To that end, a protocol was defined and
+ implemented. This RFC documents the Dynamically Switched Link
+ Control Protocol (DSLCP), which is used for creation and control of
+ downstream network links by a host.
+
+1.0 INTRODUCTION
+
+ The Dynamically Switched Link Control Protocol (DSLCP) allows a host
+ with knowledge of a special downstream network link to issue messages
+ to control the status of that link.
+
+ This document describes the functions of the DSLCP to control
+ external network connections.
+
+
+
+
+
+
+
+Young & Nicholson [Page 1]
+
+RFC 1307 Dynamically Switched Link Control Protocol March 1992
+
+
+1.1 Motivation
+
+ Circuit Switched Networks are becoming available to the Internet
+ community. These networks are made available by requesting a
+ connection through a switch. Normally circuit switched network links
+ are disconnected, and their prohibitive cost suggests that it is very
+ costly to leave them connected at all times.
+
+ Internet users and hosts wish to send data over a circuit switched
+ networks, but only connect the network links when a transport
+ connection is to be established. While it would be possible to use
+ packet routers to identify the need for switching a connection on and
+ off, only the transport provider can positively identify the
+ beginning and end of a transport session. There must be a mechanism
+ to activate and deactivate the link at the beginning and end of a
+ transport session.
+
+ The DSLCP assumes that a transport provider has knowledge of a
+ downstream link which must be setup before data transfer may take
+ place. However, the details of link setup may vary by the type of
+ link (circuit-switched or other), specific hardware, or
+ administrative differences. The DSLCP hides these details from the
+ transport provider by offering a simple request/release model of link
+ preparation. The model assumes an entity in control of the link
+ which handles the details of connection preparation while responding
+ to the DSLCP commands of the transport provider. This entity is
+ called the link controller.
+
+ The DSLCP allows internet hosts to dynamically change the fabric of
+ the internet by sending messages through the internet in advance of
+ data which is to travel across the newly created links.
+
+1.2 Scope
+
+ DSLCP is intended to provide an interface between transport providers
+ and arbitrary network links requiring creation, control, setup, or
+ conditioning before data communications may take place.
+
+1.3 Interfaces
+
+ There are no specific user level interfaces to DSLCP, although they
+ are not precluded. Link control is a function of the network layer,
+ initiated by requests from the transport provider.
+
+ A DSLCP transaction is defined as a transport provider communicating
+ with a link controller for the duration of transport session. A
+ network path between the host providing transport services and the
+ link controller must exist in advance of the DSLCP transaction.
+
+
+
+Young & Nicholson [Page 2]
+
+RFC 1307 Dynamically Switched Link Control Protocol March 1992
+
+
+ Either party to an DSLCP transaction may asynchronously generate
+ messages.
+
+1.4 Operation
+
+ The purpose of the DSLCP is to allow a transport provider to request
+ the setup of a downstream network link so that data transfer may take
+ place through that link. DSLCP messages are assumed to be
+ communicated between the transport provider and the link controller
+ through a transport service, such as UDP or TCP, or through a network
+ service such as IP.
+
+ DSLCP provides messages for link setup and teardown. All the details
+ of link management are left to the link controller. The transport
+ provider is interested only whether the link is ready to carry data.
+
+1.5 Transmission
+
+ DSLCP messages are carried through the network in datagrams using
+ either IP or UDP. DSLCP is designed to not require a reliable
+ transport protocol.
+
+2.0 DSLCP Architecture
+
+ DSLCP is used in a host environment. Normally, transport users on
+ the host will make requests of a transport provider to carry data to
+ other hosts. Some of these requests may require the preparation of a
+ downstream network link. The transport provider has knowledge of
+ these special network links, and issues a request to DSLCP that the
+ link be prepared to carry data. This happens transparently to the
+ transport user.
+
+ When a transport user requests transport services, the transport
+ provider will normally attempt to establish a connection. In the
+ event the transport provider discovers that the connection requires
+ special link control, the transport provider will call upon DSLCP to
+ send a link setup message to the link controller. The transport
+ provider does not attempt to use the connection until DSLCP informs
+ the transport provider that the link is setup or that the setup
+ attempt failed. If the setup failed, then the transport provider is
+ free to attempt to find another way to create a connection.
+
+ When the transport user is finished using the services, then the
+ transport provider will call DSLCP to release the link. The
+ transport provider may now assume that the link is no longer
+ available.
+
+ In general, DSLCP maintains and hides the status of link control
+
+
+
+Young & Nicholson [Page 3]
+
+RFC 1307 Dynamically Switched Link Control Protocol March 1992
+
+
+ transactions from the transport provider. This way the transport
+ provider does not need to keep track of multiple DSLCP transactions.
+ For example, if the transport provider requests a link be setup for a
+ new transport user while another transport user has the link active,
+ the DSLCP may inform the transport provider that the link is ready
+ without delay, provided that the link can support multiple transport
+ connections.
+
+3.0 FUNCTIONAL SPECIFICATION
+
+ This document specifies both a message format and a state machine for
+ DSLCP protocol transactions.
+
+3.1 Control Message Format
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier | Total length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Function | Event Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Endpoint 1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Endpoint 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Body |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Identifier: 16 bits
+
+ The identifier is a value assigned by the DSLCP used to uniquely
+ identify link setup transactions. It is intended to be used with
+ the endpoint addresses by a link controller to identify a
+ transaction.
+
+ Total length: 16 bits
+
+ The total length, in octets, including the header of this DSLCP
+ control message.
+
+ Function: 16 bits
+
+ The operation to be processed or being responded to.
+
+ Functions currently defined are:
+
+
+
+Young & Nicholson [Page 4]
+
+RFC 1307 Dynamically Switched Link Control Protocol March 1992
+
+
+ Bring up value 0
+ Bring down value 1
+
+ Event Status: 16 bits
+
+ The state of the controlled link, relative to the last function
+ request.
+
+ The possible event states are:
+ Setup request succeeded value 2
+ Setup request failed value 3
+ Teardown request succeeded value 4
+ Teardown request failed value 5
+ Asynchronous network down value 7
+
+ Endpoint addresses: 32 bits each
+
+ The internet addresses of the two communicating parties for which
+ the link is being prepared.
+
+ Message body: arbitrary length up to 65499 octets
+
+ An ascii string which is meaningful the link controller. When the
+ requesting host is configured, the system administrator sets the
+ control strings for each network link that may be accessed by the
+ requesting host.
+
+3.2 State Machine
+
+ The transport provider is aware of only 2 possible states for the
+ controlled link: up or down. Furthermore, transport users may
+ request or release transport services from the transport provider at
+ any time. Thus, there must be a state machine employed by DSLCP when
+ communicating between the transport provider and the controlled link.
+ This state machine hides the details of link control transactions
+ from the transport provider. The state machine has 6 possible
+ states.
+
+ Down: There is no active transport connection and the controlled
+ link is not setup.
+
+ Coming Up: A transport user has requested a connection for which
+ the transport provider has given a setup request to the DSLCP.
+ The DSLCP has sent a setup request to the link controller and is
+ awaiting a response.
+
+ Up: At least one transport connection is active and the
+ controlled link is setup.
+
+
+
+Young & Nicholson [Page 5]
+
+RFC 1307 Dynamically Switched Link Control Protocol March 1992
+
+
+ Going Down: All transport connections have been terminated and
+ the transport provider has sent an equivalent number of up
+ requests and down requests to the DSLCP. The DSLCP has sent a
+ teardown request to the link controller and is awaiting a
+ response.
+
+ Bring Down: While DSLCP is in the Coming Up state, the transport
+ provider requested link teardown. As soon as a response is
+ received from the link controller, the DSLCP will send a
+ teardown request if the link setup was successful.
+
+ Bring Up: While in the Going Down state, the transport provider
+ requested connection setup. As soon as a response is received
+ from the link controller, the DSLCP will send a setup request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Young & Nicholson [Page 6]
+
+RFC 1307 Dynamically Switched Link Control Protocol March 1992
+
+
+ DSLCP state diagram:
+
+ ------- +----------------+
+ Transport | Down |<---------\
+ Connect ---->+----------------+ \
+ Request / ^ ^ \
+ ------- Setup | | \
+ Send Failed | | Teardown \ Response Timeout
+ Setup /------ | | Success \ ---------------
+ / / | | -------- |
+ | | | | |
+ | | | | |
+ | | Teardown Response | | |
+ | | Success Timeout | | |
+ | | ----------------- | | +----------+ |
+ | | Send---------|--|-----| Bring Up |--|----\
+ | | Setup | | +----------+ | | Transport
+ | | / | | ^ | | Teardown
+ | | / | | Transport | | Request
+ | | / | | Connect| | | ---------
+ | | / Setup | Request| | |
+ | | | Failed | -------| | |
+ v | v ------ | | | v
+ +--------------+ | | +-------------+
+ | Coming Up |----------+----|--|--Response--->| Going Down |
+ +--------------+ ^ | | Timeout +-------------+
+ | ^ | | | | -------- ^ ^
+ | | Transport | | | Send | |
+ | Transport Teardown | | | Teardown | |
+ | Connect Request | | | / |
+ | Request ------- | | | / |
+ | ------- v | | | / /
+ | \ +------------+ - | | / /
+ | -| Bring Down | ------ | / /
+ \ +------------+ --------|--Setup----- /
+ \ | Success /
+ \ | ------- /
+ \ Setup Network | Send / Transport
+ \ Success Is Down | Teardown / Teardown
+ \ ------- ------- | / Request
+ \ | / --------
+ \ | / Send
+ \ +---------------+ / Teardown
+ \----------->| Up |---
+ +---------------+
+
+
+
+
+
+
+Young & Nicholson [Page 7]
+
+RFC 1307 Dynamically Switched Link Control Protocol March 1992
+
+
+Events and State Transitions
+
+ The DSLCP will process three type of events:
+
+ A link control request from the transport provider
+ An DSLCP message from the link controller
+ DSLCP message timeout
+
+ The transport provider will make link setup and and teardown requests
+ to the DSLCP when transport users request and release services
+ requiring link control operations. The transport provider should not
+ keep track of the status of a particular link, as this is a function
+ of the DSLCP. The transport provider may be unaware of redirection
+ or other processing of link setup requests performed by DSLCP, so
+ this is a function best left to DSLCP. The DSLCP will inform the
+ transport provider as to the success or failure of a particular setup
+ request, and transport providers may assume the success of teardown
+ requests (the DSLCP will always return a success response to a
+ teardown request).
+
+ The DSLCP will engage in link control transactions with link
+ controllers. This will include accepting messages from link
+ controllers in response to requests as well as unexpected messages
+ from the link controller. Unexpected messages may include redundant
+ responses to redundant requests sent as a result of timeouts.
+
+ Because of the possibility of unavailable links and link controllers,
+ DSLCP should not wait indefinitely for message responses from link
+ controllers to which it has sent messages. Since DSLCP does not
+ require the use of a reliable transport protocol to carry DSLCP
+ messages, DSLCP must have a timeout and retransmission mechanism.
+ Since we have used DSLCP in a local network context with switch
+ controllers which offer a quick turnaround (on the order of 1
+ second), we use a 5 second timeout with a 3 retransmit limit. These
+ figures would require adaptation to different network and link
+ controller configurations, and a self-adapting algorithm would be
+ most appropriate for a general solution.
+
+ The specific events of interest to the DSLCP are:
+
+ Transport provider link setup request
+ Transport provider link teardown request
+
+ Link setup request failed
+ Link setup request succeeded
+ Link teardown request succeeded
+ Link teardown request failed
+ Network link is down
+
+
+
+Young & Nicholson [Page 8]
+
+RFC 1307 Dynamically Switched Link Control Protocol March 1992
+
+
+ Timeout waiting for DSLCP response from link controller
+
+ The necessary processing for each event while in each state is as
+ follows:
+
+ Transport provider link setup request
+
+ Down:
+ Send setup request to link controller.
+ Enter Coming Up state.
+ Notify transport provider to wait until link is up.
+
+ Coming Up:
+ Bring Up:
+ Notify transport provider to wait until link is up.
+
+ Up:
+ Notify transport provider that link is up.
+
+ Bring Down:
+ Enter Coming Up state.
+ Notify transport provider to wait until link is up.
+
+ Going Down:
+ Enter Bring Up state.
+ Notify transport provider to wait until link is up.
+
+ Discussion:
+
+ If the controlled link is not capable to support multiple
+ transport connections, then the DSLCP must return
+ appropriate errors when it detects multiple transport setup
+ requests for that link.
+
+ Transport provider link teardown request.
+
+ Down:
+ Bring Down:
+ Going Down:
+ Notify transport provider that link is down.
+
+ Coming Up:
+ Enter Bring Down state.
+ Notify transport provider that link is down.
+
+ Bring Down:
+ Notify transport provider that link is down.
+
+
+
+
+Young & Nicholson [Page 9]
+
+RFC 1307 Dynamically Switched Link Control Protocol March 1992
+
+
+ Up:
+ Send teardown request.
+ Enter Going Down state.
+ Notify transport provider that link is down.
+
+ Link setup request failed
+
+ Down:
+ Going Down:
+ Bring Up:
+ Unexpected message, possibly due to duplicate requests -
+ ignore it.
+
+ Up:
+ Unexpected message, link controller may be refusing
+ multiple setup requests sent because of timeout - ignore
+ it.
+
+ Coming Up:
+ Bring Down:
+ Enter down state.
+
+ Link setup request succeeded
+
+ Down:
+ Unexpected message, possibly due to duplicate requests
+ and reordering of request packets by network.
+ Send teardown request.
+
+ Going Down:
+ Bring Up:
+ Up:
+ Unexpected message, possibly due to duplicate requests -
+ ignore it.
+
+ Coming Up:
+ Enter Up state.
+ Notify transport provider(s) waiting for link that it is
+ available.
+
+ Bring Down:
+ Send teardown request.
+ Enter Going Down state.
+
+ Link teardown request succeeded
+
+ Down:
+ Coming Up:
+
+
+
+Young & Nicholson [Page 10]
+
+RFC 1307 Dynamically Switched Link Control Protocol March 1992
+
+
+ Bring Down:
+ Unexpected message, possibly due to duplicate requests -
+ ignore it.
+
+ Up:
+ Unexpected message, possibly due to duplicate requests
+ and reordering of request packets by network.
+ Send teardown request.
+ Enter Going Down state.
+ Notify transport providers that link has gone down.
+
+ Bring Up:
+ Send setup request
+ Enter Coming Up state
+
+ Going Down:
+ Enter Down state
+
+ Discussion:
+
+ If a teardown request succeeded message arrives when the
+ DSLCP is in the UP state, then some error has occurred, and
+ the conservative approach is to bring down the connection
+ and resynchronize. However, it may be satisfactory to
+ ignore the message without ill effect.
+
+
+ Link teardown request failed
+
+ Down:
+ Coming up:
+ Bring Down:
+ Bring Up:
+ Going Down:
+ Up:
+ DSLCP sent a teardown request message for an invalid
+ transaction. The link controller has no
+ identifier/endpoints transaction record for the request.
+ Continue as if request had succeeded.
+
+ Network link is down
+
+ Down:
+ Ignore message.
+
+ Bring Down:
+ Going Down:
+ Enter Down state.
+
+
+
+Young & Nicholson [Page 11]
+
+RFC 1307 Dynamically Switched Link Control Protocol March 1992
+
+
+ Coming up:
+ Bring Up:
+ Up:
+ Enter down state.
+ Notify transport provider that link is down.
+
+
+ Timeout waiting for DSLCP response from controller
+
+ Down:
+ Up:
+ DSLCP protocol error - fix bug, don't set timer when
+ there are no outstanding requests.
+
+ Coming Up:
+ Bring Down:
+ Send teardown request.
+ Enter Going down state.
+
+ Going Down:
+ Enter Down state.
+
+ Bring Up:
+ Send setup request.
+ Enter Coming Up state.
+
+References
+
+ [1] Nicholson, et. al., "High Speed Networking at Cray Research",
+ Computer Communications Review, January, 1991.
+
+ [2] Nicholson, A., and J. Young, "Experiences Supporting By-Request
+ Circuit-Switched T3 Networks", RFC 1306, Cray Research, Inc.,
+ March 1992.
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Young & Nicholson [Page 12]
+
+RFC 1307 Dynamically Switched Link Control Protocol March 1992
+
+
+Authors' Addresses
+
+ Jeff Young
+ Cray Research, Inc.
+ 655F Lone Oak Drive
+ Eagan, MN 55123
+
+ Phone: (612) 452-6650
+ EMail: jsy@cray.com
+
+
+ Andy Nicholson
+ Cray Research, Inc.
+ 655F Lone Oak Drive
+ Eagan, MN 55123
+
+ Phone: (612) 452-6650
+ EMail: droid@cray.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Young & Nicholson [Page 13]
+ \ No newline at end of file