Network Working Group Internet Engineering Task Force Internet-Draft Network Working Group Jeff Young Andy Nicholson Cray Research, Inc. January 1992 Link Control Protocol Status of this Memo Information This memo describes a 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. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers. This draft document will be submitted to the RFC editor as an informational document. It is a working document only, it should neither be cited nor quoted in any formal document. This document will expire before May 1, 1992. Please send comments to droid@cray.com. Distribution of this memo is unlimited. Abstract 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. 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 draft documents the Link Control Protocol (LCP), which is used for creation and control of downstream network links by a host. Network Working Group [Page 1] Internet-Draft Link Control Protocol January 1992 1.0 INTRODUCTION The Link Control Protocol (LCP) 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 LCP 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 LCP 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 LCP 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 LCP commands of the transport provider. This entity is called the link controller. The LCP 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 LCP 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. Network Working Group [Page 2] Internet-Draft Link Control Protocol January 1992 1.3 Interfaces There are no specific user level interfaces to LCP, although they are not precluded. Link control is a function of the network layer, initiated by requests from the transport provider. An LCP 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 LCP transaction. Either party to an LCP transaction may asynchronously generate messages. 1.4 Operation The purpose of the LCP 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. LCP 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. LCP 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. 2.0 LCP Architecture LCP 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 LCP 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 LCP to send a link setup message to the link controller. The transport provider does not attempt to use the connection until LCP 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 Network Working Group [Page 3] Internet-Draft Link Control Protocol January 1992 transport provider will call LCP to release the link. The transport provider may now assume that the link is no longer available. In general, LCP 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 LCP 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 LCP 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 LCP 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 LCP 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, including the header of this LCP control message. Function: 16 bits The operation to be processed or being responded to. Network Working Group [Page 4] Internet-Draft Link Control Protocol January 1992 Functions currently defined are: Bring up Bring down 77 value 0 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 Setup request failed Teardown request succeeded Teardown request failed Asynchronous network down 77777 value 2 value 3 value 4 value 5 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 65519 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 LCP 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 LCP. The LCP 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. Network Working Group [Page 5] Internet-Draft Link Control Protocol January 1992 Going Down: All transport connections have been terminated and the transport provider has sent a an equivalent number of up requests and down requests to the LCP. The LCP has sent a teardown request to the link controller and is awaiting a response. Bring Down: While LCP is in the Coming Up state, the transport provider requested link teardown. As soon as a response is received from the link controller, the LCP 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 LCP will send a setup request. Network Working Group [Page 6] Internet-Draft Link Control Protocol January 1992 LCP 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 |--- +---------------+ Network Working Group [Page 7] Internet-Draft Link Control Protocol January 1992 Events and State Transitions The LCP will process three type of events: A link control request from the transport provider An LCP message from the link controller LCP message timeout The transport provider will make link setup and and teardown requests to the LCP 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 LCP. The transport provider may be unaware of redirection or other processing of link setup requests performed by LCP, so this is a function best left to LCP. The LCP 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 LCP will always return a success response to a teardown request). The LCP 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, LCP should not wait indefinitely for message responses from link controllers to which it has sent messages. Since LCP does not require the use of a reliable transport protocol to carry LCP messages, LCP must have a timeout and retransmission mechanism. Since we have used LCP 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 LCP 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 LCP response from link controller Network Working Group [Page 8] Internet-Draft Link Control Protocol January 1992 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. Coming 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 LCP must return appropriate errors when it detects multiple transport setup requests for that link. Transport provider link teardown request. Down: Bring Down: Coming Down: Notify transport provider that link is down. Coming Up: Enter Bring Down state. Notify transport provider that link is down. Bring Down: Enter Coming Down state. Notify transport provider that link is down. Up: Send teardown request. Network Working Group [Page 9] Internet-Draft Link Control Protocol January 1992 Enter Coming Down state. Notify transport provider that link is down. Link setup request failed Down: Coming 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. Coming 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 Coming Down state. Link teardown request Down: Coming Up: Bring Down: Unexpected message, possibly due to duplicate requests - ignore it. Up: Network Working Group [Page 10] Internet-Draft Link Control Protocol January 1992 Unexpected message, possibly due to duplicate requests and reordering of request packets by network. Send teardown request. Enter Coming down state. Notify transport providers that link has gone down. Bring Up: Send setup request Enter Coming Up state Coming Down: Enter Down state Link teardown request failed Down: Coming up: Bring Down: Bring Up: Going Down: Up: LCP sent a teardown request message for an invalid transaction. The link controller has no identifier/endpoints transaction record for the request. 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 LCP response from controller Down: Up: LCP protocol error - fix bug, don't set timer when there are no outstanding requests. Coming Up: Bring Down: Send teardown request. Network Working Group [Page 11] Internet-Draft Link Control Protocol January 1992 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] "Experiences with By-Request Circuit-Switched T3 Networks", Internet draft, Andy Nicholson and Jeff Young, November 1991. Authors' Addresses Jeff Young Cray Research, Inc. 655F Lone Oak Drive Eagan, MN 55123 Phone: (612) 452-6650 Mailing List: (none) EMail: jsy@cray.com Andy Nicholson Cray Research, Inc. 655F Lone Oak Drive Eagan, MN 55123 Phone: (612) 452-6650 Mailing List: (none) EMail: droid@cray.com Network Working Group [Page 12]