rfc1307.txt

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

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
 +--------------+               |  |              +-------------+