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