DSLCP: Dynamically Switched Link Control Protocol
Protocol for a host to control circuit-switched network links.
Young, J. and A. Nicholson, "Dynamically Switched Link Control Protocol", RFC 1307, DOI 10.17487/RFC1307, March 1992, <https://www.rfc-editor.org/info/rfc1307>.
@misc{rfc1307,
series = {Request for Comments},
number = 1307,
howpublished = {RFC 1307},
publisher = {RFC Editor},
doi = {10.17487/RFC1307},
url = {https://www.rfc-editor.org/info/rfc1307},
author = {J. Young and A. Nicholson},
title = {{Dynamically Switched Link Control Protocol}},
pagetotal = 13,
year = 1992,
month = mar,
} RFC text
Contents
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.
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.
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
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:
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.
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.
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 |---
+---------------+
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
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.
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:
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.
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.
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
AI ELI5
On this page
§1Connecting Temporary High-Speed Links
DSLCP addresses the challenge of efficiently using expensive circuit-switched networks. Unlike always-on packet-switched networks, circuit-switched networks (such as T3 services) require explicit connection setup, have significant per-use costs, and are disconnected when not in use.
The protocol was developed at Cray Research, Inc., as part of a project team's work with circuit-switched T3 networks. Rather than have each application or transport provider implement switch control, DSLCP provides a standardized interface between the transport provider (the part of the system that handles data transfer) and the link controller (the system entity managing the physical switch).
The key insight is that the transport provider knows when a data connection needs to start (when a transport user requests service) and when it needs to end (when the user is finished), but should not need to understand the details of how to prepare different types of network links. DSLCP hides those details in the link controller.
When a program needs a fast connection for important data, it asks DSLCP to turn on the circuit-switched link. When done, it asks DSLCP to turn it off. DSLCP handles the actual switch control, so the program does not have to.
§2The Architecture: Transport, DSLCP, and Switch
DSLCP sits between two layers. Above it, the transport provider (TCP, UDP, or similar) communicates with DSLCP when it needs to prepare a link. Below it, the link controller is the entity responsible for actually controlling the physical switch and understanding its specific command set and behavior.
The transport provider does not track the link status itself; instead, it requests setup or release and waits for DSLCP to report success or failure. DSLCP maintains a state machine that represents the link's state (down, coming up, up, going down, bring up, or bring down), hiding the complexity of multiple requests arriving while a previous request is still being processed.
For example, if the transport provider requests link setup while another setup is already in progress, DSLCP does not pass this request directly to the switch. Instead, it tracks that multiple entities need the link and responds to the second request once the first setup completes, potentially without sending a second message to the switch. This way, the transport provider does not need to understand reference counting or multi-user link sharing.
The transport provider asks DSLCP to turn on the link. DSLCP tells the actual switch to do it. The switch does it (or fails). DSLCP tells the transport provider the result. If multiple programs ask at the same time, DSLCP handles the complexity.
§3Control Messages and Link Status
DSLCP messages are carried as UDP or IP datagrams. Each control message is 8 bytes of header plus a variable-length message body. The header contains a 16-bit identifier (assigned by DSLCP to uniquely identify the transaction), a 16-bit total length, a 16-bit function code (0 for bring up, 1 for bring down), and a 16-bit event status code.
The function field indicates the operation being requested or the response being sent. The event status field carries the outcome: setup succeeded (value 2), setup failed (value 3), teardown succeeded (value 4), teardown failed (value 5), or asynchronous network down (value 7).
The message includes two 32-bit endpoint addresses (the source and destination IP addresses of the communicating parties) and a variable-length message body (up to 65,499 octets) containing site-specific control strings. These strings are configured by the site administrator and are meaningful to the particular link controller being used. The message body allows protocol-neutral communication of link-specific parameters without the DSLCP protocol itself needing to define them.
A DSLCP message says: with ID 123, turn on the link between these two addresses using this magic command string that the switch understands.
§4The Six-State Machine
DSLCP uses a six-state state machine to manage the lifecycle of a controlled link. The states are:
Down: No active connection and the link is not prepared. Coming Up: The transport provider requested setup, DSLCP has sent a setup message to the link controller, and it is waiting for a response. Up: At least one transport connection is active and the link is ready. Going Down: All transport connections have been released, DSLCP has sent a teardown request to the link controller, and it is waiting for a response. Bring Down: A teardown was requested while Coming Up; DSLCP waits for the setup response before sending teardown. Bring Up: A setup was requested while Going Down; DSLCP waits for the teardown response before sending setup.
This design allows the protocol to handle overlapping requests from the transport provider without losing any. For example, if a setup request arrives while a teardown is in progress, DSLCP enters the Bring Up state and will send a new setup request as soon as the teardown completes. The transport provider making each request receives only success or failure; DSLCP manages the sequencing.
The link can be down, coming up, up, going down, waiting to come up, or waiting to go down. As requests arrive, DSLCP moves between these states and tells the switch what to do.
- Down start
- Coming Up
- Up
- Going Down
- Bring Down
- Bring Up
| From | To | Event |
|---|---|---|
| Down | Coming Up | Setup request |
| Coming Up | Up | Setup succeeded |
| Coming Up | Bring Down | Teardown request |
| Coming Up | Down | Setup failed |
| Up | Going Down | Teardown request |
| Going Down | Down | Teardown succeeded |
| Going Down | Bring Up | Setup request |
| Bring Down | Down | Setup failed |
| Bring Down | Going Down | Teardown succeeded |
| Bring Up | Coming Up | Teardown succeeded |
| Bring Up | Up | Setup succeeded |
§5Message Handling and Timeouts
DSLCP processes three types of events: setup requests from the transport provider, teardown requests from the transport provider, and messages from the link controller (setup/teardown success or failure, asynchronous network down, or timeout).
When the transport provider requests link setup from the Down state, DSLCP sends a setup message to the link controller and moves to Coming Up, telling the transport provider to wait. If a setup succeeds while in Coming Up, DSLCP moves to Up and notifies waiting transport providers. If setup fails, DSLCP returns to Down.
Teardown requests from the Up state trigger a teardown message to the switch and a transition to Going Down. From Going Down, a successful teardown response returns to Down. Various states handle unexpected or redundant messages gracefully, typically by ignoring them (since network reordering or retransmission of earlier requests may cause them).
Because DSLCP does not require a reliable transport (messages travel over UDP or IP), it must implement timeouts and retransmission. The RFC recommends a 5-second timeout with a 3-retransmit limit for local network contexts, with the caveat that different networks and switch controllers may require different values. A self-adapting algorithm would be suitable for general deployment.
When the transport provider asks to set up the link, DSLCP sends the request to the switch and waits. If the switch does not answer within 5 seconds, DSLCP asks again, up to 3 times. Depending on what the switch says, DSLCP tells the transport provider success or failure.