Network Working Group Ott Internet-Draft Kutscher Expires: January 19, 2005 TZI Universität Bremen July 21, 2004 Persistent Connection Management Protocol nodraft-tzi-pcmp-01.txt Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 19, 2005. Abstract This document specifies the Persistent Connection Management Protocol (PCMP), a transport protocol that enables long-lived communication sessions in the presence of intermittent connectivity. This specification defines the PCMP operation, protocol messages and PCMP peer requirements. Version $Revision: 1.1.1.1 $ Ott & Kutscher Expires January 19, 2005 [Page 1] Internet-Draft PCMP July 2004 Table of Contents 1. Introduction and Motivation . . . . . . . . . . . . . . . . 3 2. Key Requirements . . . . . . . . . . . . . . . . . . . . . . 4 3. System and Connection Model . . . . . . . . . . . . . . . . 6 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Message Formats and Semantics . . . . . . . . . . . . . . . 9 5.1 Message Types . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Message Field Types . . . . . . . . . . . . . . . . . . . . 10 5.2.1 General Encoding Rules . . . . . . . . . . . . . . . . . . . 15 5.2.2 Variable Length Encoding . . . . . . . . . . . . . . . . . . 15 5.3 Common Header . . . . . . . . . . . . . . . . . . . . . . . 15 5.4 CLRC_SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.5 CLRC_SETUP_ACK . . . . . . . . . . . . . . . . . . . . . . . 17 5.6 CLRC_SETUP_REJ . . . . . . . . . . . . . . . . . . . . . . . 18 5.7 SETUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.8 DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.9 ACCEPT . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.10 REJECT . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.11 DATA_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.12 DATA_NAK . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.13 CLRC_TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . 24 5.14 CLRC_DIAG . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 27 6.1 CLRC Management . . . . . . . . . . . . . . . . . . . . . . 27 6.1.1 CLRC Establishment . . . . . . . . . . . . . . . . . . . . . 27 6.1.2 CLRC Teardown . . . . . . . . . . . . . . . . . . . . . . . 31 6.1.3 CLRC Error Signaling . . . . . . . . . . . . . . . . . . . . 32 6.2 Session Management . . . . . . . . . . . . . . . . . . . . . 32 6.2.1 Session Initiation . . . . . . . . . . . . . . . . . . . . . 33 6.2.2 Session Initiation and Data Transmission . . . . . . . . . . 33 6.2.3 Data Transmission . . . . . . . . . . . . . . . . . . . . . 34 6.2.4 Session Suspension . . . . . . . . . . . . . . . . . . . . . 34 6.2.5 Session Termination . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35 A. Change History . . . . . . . . . . . . . . . . . . . . . . . 36 Ott & Kutscher Expires January 19, 2005 [Page 2] Internet-Draft PCMP July 2004 1. Introduction and Motivation The Persistent Connection Management Protocol (PCMP) is intended for environments with intermittent and potentially short-lived connectivity which may also experience highly variable performance characteristics (e.g. in terms of achievable throughput, round-trip time, bit error and packet loss rate, etc.). PCMP will also need to support more general environments with intermittent connectivity but reasonably low RTTs (i.e. in the order of seconds). The Drive-thru environment is a good starting point such a protocol design as it already covers rather extreme networking scenarios. The protocol is intended to be employed by dedicated Drive-thru intermediaries that provide the service of managing intermittent connectivity and other challenges for applications on the endpoints. The intermediaries maintain a "connection" state for communication sessions between endpoints that survives loss of connectivity and is not tied to the endpoints IP addresses and their current location of attachment. +-------+ +-------+ | | | | | Drive | PCMP | Drive | [Client] ----- | thru | ========== | thru | ----- [Server] |Client | | Server| | | | | +-------+ +-------+ Figure 1: Fundamental architecture The connections between the intermediaries themselves and between the endpoints and the intermediaries may be lost or deliberately terminated without affecting the persistence of the session. The session may be later resumed, e.g., as soon as connectivity can be established. Unlike other solutions such as Mobile-IP, the Drive-thru mechanisms provide mobility and connection persistence on the transport and application layer, not on the network layer, thus accommodating longer phases of connectivity outages. Ott & Kutscher Expires January 19, 2005 [Page 3] Internet-Draft PCMP July 2004 2. Key Requirements This document specifies an experimental transport protocol for experimentation and rapid prototyping purposes called Persistent Connection Management Protocol (PCMP). Bearing this in mind, the requirements for PCMP can be relaxed and the design start out with a fairly minimal basis. Therefore, we will initially concentrate on the following key requirements: 1. Lower-layer independence The protocol MUST be usable on top of UDP and TCP (well, and SCTP, DCCP, and ultimately plain IP -- but those requirements will be considered in a future version of this document). Note that the TCP will be the initial lower transport protocol of choice so that we do not need to address error and congestion control at all. However, the packet/message format of the transport protocol should allow for datagram-based communication. At the IP layer, both IPv4 and IPv6 MUST be supported from the beginning. 2. Reliability, Flow Control, Congestion Control Usual reliable global Internet transport protocol attributes are required. Note that these are implicitly achieved by using TCP or SCTP underneath and require no further action. 3. Survivability Transport connections MUST be able to resynchronize after a failure and resume communications (roughly) where they left off. This MUST NOT lead to any loss of data transmitted. However, it MAY lead to to duplicate transmission of some of the data. 4. Multiplexing The transport protocol MUST allow multiplexing of several communication sessions. That is, within a single PCMP transport connection, multiple application layer connections may be multiplexed. For each application layer connection, connection setup latency SHOULD be reduced as much as possible. Ott & Kutscher Expires January 19, 2005 [Page 4] Internet-Draft PCMP July 2004 Application layer connections SHOULD ideally be flow-controlled independently. It is noted, however, that this will not be possible if TCP is chosen as communication substrate. 5. Security * Authentication User authentication SHOULD be provided. It is yet to be determined whether or not user authentication is required with respect to the Drive-thru PEP or the Drive-thru Proxy. Conversely, server authentication SHOULD be provided so that the mobile user can be sure which peer she is communicating with. * Confidentiality The information exchanged via PCMP MUST be kept confidential. It should be noted that this feature is readily achieved if TLS is used over TCP. * Integrity Information exchanged via PCMP MUST be integrity protected. The initial version of PCMP will experiment with TLS over TCP to provide the requested security. In a second stage, (some of) these security features may need to be incorporated into PCMP for efficiency reasons (and because TLS does not work over UDP). As noted above, the first revision of the protocol specification will reduce some of these requirements. In particular, lower-layer independence will only be of secondary importance; instead, the use of TCP is assumed. With this, requirement #2 becomes obsolete for the time being -- but the protocol will need to be augmented appropriately later on. Ott & Kutscher Expires January 19, 2005 [Page 5] Internet-Draft PCMP July 2004 3. System and Connection Model The basic model is depicted below. A Drive-thru client accepts (TCP) connections from any number of clients, multiplexes them via a single Drive-thru connection (Connectivity-loss resilient connection, CLRC), and the server demultiplexes the incoming information again into individual transport connections. The same applies in the opposite direction. +-------+ +-------+ [Client #1] ----- | | | | ----- [Server #1] | Drive | CLRC | Drive | [Client #2] ----- | thru | ========== | thru | ----- [Server #2] |Client | | Server| [Client #n] ----- | | | | ----- [Server #n] +-------+ +-------+ All communications is assumed to be bidirectional. The setup of "end-to-end" connections occurs in two steps. First, the CLRC is established (either triggered by an incoming client connection or by link layer detection of an available network). The establishment of the CLRC involves full (client and server) authentication, potentially incurring multiple round-trips. This stage is also used to create a shared context for reliability, confidentiality, compression, and other functions at the client and the server side. In the next step, individual transport sessions are set up. Each connection intended to run from a client to a server is mapped to a single session within the CLRC. The session setup procedure is much simplified and does not require additional round-trips. It should be noted that sessions may also be created for internal use between Drive-thru client and proxy. The purpose of the CLRC is to act as a container for efficient authentication, re-use of congestion and error control information, and for encryption. But CLRCs are ephemeral. The embedded transport sessions are the ones to be made persistent across connectivity interruptions. They are set up in one CLRC and continued in a another one in the next connectivity island. For each individual session, both parties maintain a session state. For example, it is monitored how many bytes have been transmitted in each direction in order to allow for a seamless resuming should the session be paused or the CLRC be closed or interrupted. Congestion control is done for the CLRC as a whole. Error control and flow control should ultimately be done individually for each of the virtual connections -- but with TCP as a substrate are just performed for the CLRC as a whole. Recovery after connection Ott & Kutscher Expires January 19, 2005 [Page 6] Internet-Draft PCMP July 2004 interruption is done at the session level. In principle, PCMP will ultimately be designed to allow for different transports (TCP, SCTP, UDP, DCCP etc.) linking two peers. Different transports may utilize different interfaces (and thus different IP addresses) and connectivity for these interfaces may be available at different times. Initially, however, only a minimal variant will be defined. This variant will employ a single TCP connection only. In any case, for the time being, each underlying transport (identified by the quintuple consisting of the IP addresses or both peers, their port numbers, and the protocol id, e.g. UDP or TCP) will be used to carry exactly one CLRC. That is, no multiplexing will take place. If a client wants to open a second CLRC, it needs to set up a separate transport connection. The sessions that are instantiated or resumed within a CLRC do not rely on IP addresses as host identifiers. Instead, we use the concept of "peer names" -- globally unique identifiers that are independent of a host's IP address. For this version of the protocol specification, peer names are represented as host names, e.g., on-the-road.example.com. It should be noted that these do not have to be resolvable but are merely used to identify endpoints. Finally, it should be noted that a Drive-thru PEP may be inserted between Drive-thru client and Drive-thru server. This PEP is expected to perform some kind of connection splitting and may implement additional services. Whether the Drive-thru PEP just creates two linked but otherwise independent CLRCs to client and proxy or whether some more sophisticated pass-thru mechanism for a single CLRC is employed requires further investigation. Ott & Kutscher Expires January 19, 2005 [Page 7] Internet-Draft PCMP July 2004 4. Terminology Connectivity Loss Resilient Connection (CLRC) A Connectivity Loss Resilient Connection (CLRC) is a container for one or more PCMP transport sessions. The CLRC is set up between a client and a server and provides client and server authentication, error control, congestion and flow control, and secure data transport. Persistent Connection Management Protocol (PCMP) The Persistent Connection Management Protocol (PCMP) is a transport protocol that enables long-lived communication sessions in the presence of intermittent connectivity. PCMP is used by two communication partners, a PCMP client and a PCMP server. The client establishes a PCMP association to a server by setting up a Connectivity Loss Resilient Connection (CLRC) and by creating transport sessions within that CLRC. Transport session One or more transport sessions may be set up within a Connectivity Loss Resilient Connection using the Persistent Connection Management Protocol (PCMP). Ott & Kutscher Expires January 19, 2005 [Page 8] Internet-Draft PCMP July 2004 5. Message Formats and Semantics 5.1 Message Types The first revision of PCMP is deliberately kept simple. The following PCMP messages are defined: CLRC_SETUP Sets up a CLRC between a Drive-thru client and a Drive-thru server. The setup message sequence is also used to create a shared connection context and resume transmission where one left off. CLRC_SETUP_ACK Confirms the creation of a new CLRC. Note that the setup process will get more complex (and thus require additional messages) to implement some kind of challenge-response or other authentication scheme. CLRC_SETUP_REJ Rejects the creation of a new CLRC. Note that this message may be used to initiate a challenge-response message exchange for client authentication. CLRC_TEARDOWN Terminate the CLRC to the peer. CLRC_DIAG Provides a means to convey CLRC status information. SETUP Establishes a new session within a CLRC. This message is used to explicitly create a new session within a CLRC. A flag is used to indicate whether a new session shall be established or an existing one resumed. DATA Carries data transmitted within a session in a CLRC. Also provides window-based flow control information per session. ACCEPT Acknowledges the establishment of a new session. Ott & Kutscher Expires January 19, 2005 [Page 9] Internet-Draft PCMP July 2004 REJECT Refuses the establishment of a new connection. DATA_ACK Confirms the receipt of one or more DATA messages for unreliable transports. Will later be used for error repair and to clock congestion control. DATA_NAK Provides information about missing DATA messages for unreliable transports. Will later be used to request selective retransmissions of data packets and also to clock congestion control. 5.2 Message Field Types This section summarizes the names, semantics, and encodings of all the protocol fields to avoid repeated (and possibly even contradictory) definitions below. The fields are specified in alphabetical order. AuthScheme -- 16 bits Identifies the proposed authentication scheme. The following values are defined for now: value | semantics --------+----------------------------- 0x0000 | No authentication 0x0001 | Simple (user name, password) 0x0002 | Challenge-response Further schemes may be defined at a later stage. For the simple scheme, the user name is placed in the AuthName field and the password in the AuthCredentials field. For challenge-response authentication, the user name is placed in the AuthName field and the AuthCredentials field is left empty. It is filled in a repeated request after having received the challenge from the server with the calculated response based upon the server's challenge. The challenge-response scheme is not yet fully defined. Ott & Kutscher Expires January 19, 2005 [Page 10] Internet-Draft PCMP July 2004 AuthName -- variable length Contains the name of the user (or server) for authentication purposes. AuthCredentials -- variable length Contains the authentication information of the user or server. CLRCId -- 64 bits A unique id to be used as end-to-end connection identifier between the CLRC peers. The value is proposed by the initiator and may be refused by the peer (or an intermediary) if the respective value is already in use. A possible approach to create a CLRC identifier is to concatenate the two PeerNames and augment this value by a locally unique identifier (e.g. process id plus some counter): tmp_val = InitiatorName ":" ResponderName ":" pid ":" no Then, an MD5 checksum is calculated yielding CLRCId = MD5 (tmp_val) DataSeq -- 48 bits Data sequence number counting transmitted bytes per session counting from zero. Used for resynchronizing two peers after a temporary disconnection. EmbeddedData -- variable length Arbitrary data to be conveyed along with a message. Length -- 16 bits The total length of the message including the message header. NItems -- 8 bits This field is used to indicate the number of occurrences of other items. 0 is a legal value and indicates the absence of any content items. Ott & Kutscher Expires January 19, 2005 [Page 11] Internet-Draft PCMP July 2004 PeerName -- variable length The PeerName contains a globally unique identifier for the endpoint that is constant and independent of its IP address. Although cryptographic names are to be used in the long run, using a domain name is considered sufficient for the time being. ReasonCode -- 8 bits Value | Name | Allowed in messages -------+---------------------------+------------------------------ 0xff | Unknown | all 0x00 | RegularShutdown | CLRC_TEARDOWN 0x01 | AuthenticationRequired | CLRC_SETUP_REJ 0x02 | AuthenticationFailure | CLRC_SETUP_REJ 0x03 | NoResources | CLRC_SETUP_REJ, REJECT, CLRC_TEARDOWN 0x04 | NoContext | REJECT | | 0x10 | NoRoute | REJECT 0x11 | NoAddress | REJECT 0x12 | NoPort | REJECT 0x13 | NoResponse | REJECT 0x14 | NoService | REJECT To be completed further. ReasonPhrase -- variable length Contains a text-encoded (ISO 8859-1) and null-terminated reason phrase. Reserved -- n bits as necessary Every "reserved" field must be set to "0" upon transmission, and its content must be ignored (i.e. *not* checked against "0") upon reception. CLRCSeq -- 32 bits Sequence number for all messages exchanged in a CLRC. Will later be used for error repair. The value is incremented by one for each new CLRC packet transmitted. Will be initialized to a random value upon connection setup for each direction. ServiceType -- 16 bits Indicates the service type (i.e. the higher layer protocol) to be Ott & Kutscher Expires January 19, 2005 [Page 12] Internet-Draft PCMP July 2004 used for a particular session. The following ones are defined using the 12 low order bits of the field: Value | Semantics -------+------------------------------------------ 0x000 | No extra service, transparent forwarding 0x001 | SMTP 0x002 | POP3 0x003 | FTP Control 0x004 | FTP Data 0x010 | HTTP The four high order bits are used to indicate further attributes of the service type as follows: Value | Semantics --------+----------------------------------------- 0x0000 | TCP 0x1000 | UDP 0x2000 | DCCP 0x3000 | SCTP SessionId -- 32 bits The SessionId is used to identify the session within a CRLC; it is valid for a single CRLC only and will be newly chosen when the session is resumed over a different CRLC. The SessionId will always be chosen by the initiator of a session. To avoid clashes in the number space, the most significant bit (MSB) will be set to '0' for sessions initiated by the initiator of the CLRC (usually the client), and to '1' for sessions initiated by the other party. The SessionIds 0x00000000 indicates that the packet applies to the entire CLRC; the SessionIds 0x80000000, 0x7FFFFFFF, 0xFFFFFFFF are reserved for future use. SessionName -- variable length Globally unique and persistent identifier for a session within a CLRC. The session name is a structured identifier assigned by the entity initiating/resuming a session in a unique fashion. The following structure is suggested for the SessionId (in simple null-terminated ASCII encoding): string.time(usec).time(sec).pid@host.domain Ott & Kutscher Expires January 19, 2005 [Page 13] Internet-Draft PCMP July 2004 with "string" being a simple counter or other locally unique string maintained by the peer, time(usec) and time(sec) referring to the time passed since 1970-01-01, 00:00:00 (as returned by gettimeofday), "pid" being the process ID of the peer, "host" its host name, and domain its home domain. Instead of host.domain, an IPv4 or IPv6 address may be used, provided that these addresses are globally routable. The receiver MUST NOT not interpret this value in any way but MUST only store it and use it for comparison. TargetAddress -- variable length Contains the target address to connect to. type = 0x01: Arbitrary URL. type = 0x02: IPv4 address + TCP port number type = 0x03: IPv6 address + TCP port number type = 0x04: Some local identifier at the peer (TBD.) Type -- 8 bits The message type, i.e. one of the types defined in section 4.1. The following type values are defined: Type | Message ------+--------------- 0x01 | CLRC_SETUP 0x02 | CLRC_SETUP_ACK 0x03 | CLRC_SETUP_REJ 0x04 | DATA 0x05 | DATA_ACK 0x06 | DATA_NAK 0x07 | ACCEPT 0x08 | REJECT 0x09 | CLRC_TEARDOWN 0x0A | CLRC_DIAG 0x0B | SETUP UserData -- variable length This field contains the user data carried in a message for a session. The length is implied from its starting position in the message and the total message length indicated by the length field. Ott & Kutscher Expires January 19, 2005 [Page 14] Internet-Draft PCMP July 2004 Version -- 4 bits Identifies the version number of the protocol. The currently specified version is 1. Window -- 32 bits Receiver window size (in units of 256 bytes) for flow control purposes. 5.2.1 General Encoding Rules All multi-octet values (16, 32, 48, 64 bits) are transmitted in network byte order (i.e., big endian). 5.2.2 Variable Length Encoding Variable length encoding uses the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+ | | | : value (length byes) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "Length" (8 bits) specifies the length of the following value in bytes. A length of "0" indicates that no content is present. This may be used as padding. A length of "255" indicates a length of 255 bytes for a first part of the value and that the another variable length field will follow containing the further information belonging to the same value. If a value of 255 shall be encoded, this will look as follows: 0xff - <255 octets value> - 0x00 "Value" contains the actual value encoded according to the rules of the respective field. As described above, the values of multiple variable length fields may be concatenated. 5.3 Common Header The common header precedes every PCMP message, regardless of the transport being used. The common header contains the following Ott & Kutscher Expires January 19, 2005 [Page 15] Internet-Draft PCMP July 2004 fields. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 |Version|Reservd| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 04 | | + CLRCId + 08 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0C | SessionId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | CLRCSeq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.4 CLRC_SETUP The first message to be sent over a newly established TCP connection. CLRC_SETUP has the following parameters: InitiatorName - PeerName ResponderName - PeerName (should be known) UserScheme - AuthScheme Requested authentication scheme for user ServerScheme - AuthScheme Requested authentication scheme for server UserName - AuthName (only present if UserScheme != 0x0000) UserCredentials - AuthCredentials (only present if UserScheme != 0x0000) This message will be augmented further. For example, keying or Diffie-Hellman information need to be added and probably others. The resulting CLRC_SETUP message format is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | | : InitiatorName : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ResponderName : Ott & Kutscher Expires January 19, 2005 [Page 16] Internet-Draft PCMP July 2004 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UserScheme | ServerScheme | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : UserName : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : UserCredentials : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the fields of this message are not necessarily 32-bit-aligned even though the above figure may suggest so. 5.5 CLRC_SETUP_ACK The positive response to a CLRC_SETUP message contains the following fields: InitiatorName - PeerName (copied from CLRC_SETUP) ResponderName - PeerName (copied from CLRC_SETUP) UserScheme - AuthScheme to be used later for challenge-response methods ServerScheme - AuthScheme Authentication scheme used for server ServerName - AuthName (only present if ServerScheme != 0x0000) ServerCredentials - AuthCredentials (only present if ServerScheme != 0x0000) This message will be augmented further. For example, keying or Diffie-Hellman information need to be added and probably others. Packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | | : InitiatorName : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ResponderName : | | Ott & Kutscher Expires January 19, 2005 [Page 17] Internet-Draft PCMP July 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UserScheme | ServerScheme | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ServerName : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ServerCredentials : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the fields of this message are not necessarily 32-bit-aligned even though the above figure may suggest so. 5.6 CLRC_SETUP_REJ The negative response to a SETUP message contains the following fields: InitiatorName - PeerName (copied from CLRC_SETUP) ResponderName - PeerName (copied from CLRC_SETUP) UserScheme - AuthScheme Requested authentication scheme for user ServerScheme - AuthScheme Authentication scheme used for server ServerName - AuthName (only present if ServerScheme != 0x0000) ServerCredentials - AuthCredentials (only present if ServerScheme != 0x0000) ReasonCode - failure reason ReasonPhrase - additional textual description Packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | | : InitiatorName : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ResponderName : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UserScheme | ServerScheme | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ott & Kutscher Expires January 19, 2005 [Page 18] Internet-Draft PCMP July 2004 | | : ServerName : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ServerCredentials : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ReasonCode | | +-+-+-+-+-+-+-+-+ + : ReasonPhrase : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the fields of this message are not necessarily 32-bit-aligned even though the above figure may suggest so. Note: It would be nicer if the reason code would be located at a fixed offset. But this packet structure allows for common basic parsing routines for all SETUP messages which is considered more important. 5.7 SETUP SETUP messages are used to initiate or to resume transport sessions within a CLRC. A SETUP messages can optionally carry user data. The following parameters are included in a SETUP message: SequenceNo - DataSeq; sequence number of the first byte in the present message (starting from 1). MUST be set to 0 if the message does not contain any user data Flags (8 bits) - SYN flag (0x01) - SUSPEND flag (0x02) (used to explicitly suspend a session) - RESUME flag (0x04) (used after disconnection) - CONNECT flag (0x08) (need to connect to a remote entity) - FIN flag (0x10) (used to signal session termination) - RST flag (0x20) (used to signal session abortion) ReceiveWindow - Window LastRxSeqNo - DataSeq (MUST be set to zero when SUSPEND flag is not set) Ott & Kutscher Expires January 19, 2005 [Page 19] Internet-Draft PCMP July 2004 LastTxSeqNo - DataSeq (MUST be set to zero when SUSPEND flag is not set) AddressType - AddressType; type of following target address TargetAddress - (variable length) SessionName (chosen by the initiator, variable length) UserData - optional, the actual data to be transmitted; when used with UDP, the total message size MUST NOT exceed the interface and path MTU (or 1,460 bytes if the other two are unknown) (we need to be careful here which information to provide as we may have a Drive-thru-PEP in the middle that may or may not be able to preserve packet boundaries; so maybe we should just work with bytes) The SessionId field (contained in the common header) MUST be chosen by the initiator. Packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | | + SequenceNo +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18 | | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1C | ReceiveWindow | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | | + LastRxSeqNo +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LastTxSeqNo + 28 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3C | AddressType | | +-+-+-+-+-+-+-+-+ TargetAddress : Ott & Kutscher Expires January 19, 2005 [Page 20] Internet-Draft PCMP July 2004 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + SessionName + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : UserData : + (optional) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the trailing fields of this message are not necessarily 32-bit-aligned (TargetAddress, SessionName, UserData) even though the above figure may suggest so. 5.8 DATA DATA messages are used to convey user data within a session that has been established or resumed using SETUP before. DATA messages may carry piggybacked error and flow control messages as well as timing information for later congestion control. For now, only the flow control window is relevant (empty DATA messages are sent to convey just an updated flow control window). The following parameters are included in a DATA message: SequenceNo - DataSeq; sequence number of the first byte in the present message Flags (8 bits) - SYN flag (0x01) - SUSPEND flag (0x02) (used to explicitly suspend a session) - RESUME flag (0x04) (used after disconnection) - CONNECT flag (0x08) (need to connect to a remote entity) - FIN flag (0x10) (used to signal session termination) - RST flag (0x20) (used to signal session abortion) ReceiveWindow - Window UserData - the actual data to be transmitted; when used with UDP, the total message size MUST NOT exceed the interface and path MTU (or 1,460 bytes if the other two are unknown) Ott & Kutscher Expires January 19, 2005 [Page 21] Internet-Draft PCMP July 2004 (we need to be careful here which information to provide as we may have a Drive-thru-PEP in the middle that may or may not be able to preserve packet boundaries; so maybe we should just work with bytes) The SessionId field (contained in the common header) MUST provide the value specified in SETUP message. Piggybacked acknowledgments will be added later. Packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | | + SequenceNo +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18 | | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1C | ReceiveWindow | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | : UserData : + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.9 ACCEPT The ACCEPT message is used to confirm the successful setup of a session. Three cases need to be considered for generating ACCEPT messages: 1. A new session is to be established to an entity local (i.e. internal) to the peer. In this case, the responding peer may decide about acceptance of the new session right away and return an ACCEPT message immediately. 2. A new session is to be established to a remote entity (e.g. a web or mail server) as indicated by the TargetAddress field of the DATA message. In this case, the ACCEPT message MUST only be sent after the Ott & Kutscher Expires January 19, 2005 [Page 22] Internet-Draft PCMP July 2004 remote entity has confirmed a successful TCP connection setup. 3. An existing session to a local entity at the responder or to a remote entity shall be resumed. In this case, the responder can check the validity of the request right away and may return an ACCEPT message immediately. The ACCEPT message contains the following fields: - ServiceType - Flags (8 bits) - ReceiveWindow - Window - LastRxSeqNo - DataSeq (optional, only present if resume flag set) - LastTxSeqNo - DataSeq Packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | ServiceType | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18 | ReceiveWindow | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1C | | + LastRxSeqNo +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LastTxSeqNo + 24 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.10 REJECT The REJECT message is used to indicate rejection of a session setup request. ReasonCode - failure reason - NoContext -- the indicated session does not exist and hence cannot be resumed - NoResources -- insufficient resources Ott & Kutscher Expires January 19, 2005 [Page 23] Internet-Draft PCMP July 2004 available at the responding entity - NoService -- the requested service is not available - NoAddress -- no IP address associated with indicated hostname - NoPort -- destination port unreachable - NoRoute -- no route to host - NoResponse -- remote entity not responding ReasonPhrase - additional textual description The REJECT message has the following packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | ReasonCode | | +-+-+-+-+-+-+-+-+ ReasonPhrase + : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the trailing fields of this message are not necessarily 32-bit-aligned even though the above figure may suggest so. 5.11 DATA_ACK TBD. (not yet needed) 5.12 DATA_NAK TBD. (not yet needed) 5.13 CLRC_TEARDOWN The CLRC_TEARDOWN message is used to terminate a CLRC. This message is responded to by a TEARDOWN. This message contains the following fields: - ReasonCode -- Shutdown reason - RegularShutdown -- voluntary termination - LocalError -- some local error occurred - NoResources -- no more resources - NoConnectivity -- connectivity is disappearing - Unknown -- anything else Ott & Kutscher Expires January 19, 2005 [Page 24] Internet-Draft PCMP July 2004 - ReasonPhrase -- textual description of the reason code The CLRC_TEARDOWN message uses the following packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | ReasonCode | | +-+-+-+-+-+-+-+-+ ReasonPhrase + : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the trailing fields of this message are not necessarily 32-bit-aligned even though the above figure may suggest so. 5.14 CLRC_DIAG The CLRC_DIAG message is used to convey general error or other diagnostic information between the two peers. The information related to the session identified by the SessionId. The CLRC_DIAG message does not affect the state machine and just provides a general purpose mechanism for information exchange. This message contains the following fields: - nItems -- indicates the the number of embedded data items - ReasonPhrase -- contains a description of the event reported - EmbeddedData -- conveys arbitrary extra information; repeated nItems times The CLRC_DIAG message uses the following packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | nItems | | +-+-+-+-+-+-+-+-+ ReasonPhrase + : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : EmbeddedData #1 : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : EmbeddedData #2 : | | Ott & Kutscher Expires January 19, 2005 [Page 25] Internet-Draft PCMP July 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : EmbeddedData #n : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the fields of this message are not necessarily 32-bit-aligned even though the above figure may suggest so. Ott & Kutscher Expires January 19, 2005 [Page 26] Internet-Draft PCMP July 2004 6. Protocol Operation PCMP provides two fundamental services: 1. CLRC Management CLRCs may be initiated using different underlying transport protocols (considering TCP only for the moment). A CLRC is a temporary relation between two peers in which transport sessions can be established and managed. A CRLC may be terminated, either explicitly or by a loss of the underlying transport connection e.g., the TCP connection. When the communication between two peers is later resumed, a new CRLC is established that does not relate to the previous CRLC. In other words, a CLRC between two peers is independent of previous or concurrent CLRCs and does not share state with them. 2. Session Management Within a CLRC, one or more sessions may be initiated. Although sessions are created in a specific CLRC they can be CLRC-persistent, i.e., their existence is not bound to the existence of the CRLC. For example, if the CRLC is terminated, either implicitly or explicitly, the session context persists. In other words, when the CLRC is terminated, the session is NOT implicitly terminated as well. PCMP peers should apply implementation-specific timeouts for suspended transport sessions, depending on available resources, the utilization, the usage profile etc. Sessions are created implicitly using the DATA message; they may be paused and resumed (again implicitly by sending a DATA message). 6.1 CLRC Management 6.1.1 CLRC Establishment A CLRC is established between a CLRC initiator and a CLRC responder. The initiator sends a CLRC_SETUP request that is answered by a CLRC_SETUP_ACK message, as depicted in Figure 33. CLRC Initiator CLRC Responder | CLRC_SETUP(CLRCId) | |---------------------------------->| | | | CLRC_SETUP_ACK | |<----------------------------------| Ott & Kutscher Expires January 19, 2005 [Page 27] Internet-Draft PCMP July 2004 | | Figure 33: Successful CLRC Establishment For establishing a CLRC, a CLRC initiator first creates an underlying transport connection, i.e., a TCP connection. For datagram transports such as UDP, no explicit connection setup is required and the initiator SHOULD create the CLRC transport relationship implicitly by sending a UDP message. After a transport connection has been established, the initiator MUST send a CLRC_SETUP message. For a CLRC_SETUP message, the initiator MUST set the message fields to the following values: Version 1 Type CLRC_SETUP (0x01) Length total length of message including header CLRCId proposed by initiator SessionId 0 CLRCSeq random number between 0 and (2^32)-1 InitiatorName Host Identifier (name) ResponderName Host Identifier (name) UserScheme one of 0x0, 0x1,0x2 ServerScheme one of 0x0, 0x1,0x2 UserName user identifier (only when UserScheme != 0) UserCredentials user authentication info (only when UserScheme != 0) The fields UserName and UserCredentials are only present when user authentication has been specified in the UserScheme field, i.e., when UserScheme is not equal to zero. Before accepting the CLRC_SETUP request and creating the corresponding CLRC state, a CLRC responder MUST perform the following checks: o The responder MUST determine if the specified UserScheme is acceptable and, if this is the case, MUST subsequently authenticate the user based on the UserScheme, UserName and UserCredentials specified in the CLRC_SETUP message. If the specified UserScheme is not acceptable, or when the authentication fails, the request MUST be rejected (see below). o The responder MUST verify the specified InitiatorName and ResponderName and reject the request if the ResponderName is incorrect or if the InitiatorName is unacceptable. o The responder MUST verify the CLRCId, especially it MUST check the CLRCId for uniqueness in the realm of the responder and reject the Ott & Kutscher Expires January 19, 2005 [Page 28] Internet-Draft PCMP July 2004 request otherwise. If the responder decides to accept the request, it MUST create a CLRC state for the CLRC. The CLRC state MUST at least provide the following information: o CLRCId o InitiatorName o Initiator's CLRC sequence number o Responder's CLRC sequence number (see below) In addition, the CLRC state will typically contain the responder's endpoint address. If the responder decides to accept the request, it MUST acknowledge the CLRC_SETUP message by sending a CLRC_SETUP_ACK message providing the following fields: Version 1 Type CLRC_SETUP_ACK (0x02) Length total length of message including header CLRCId copied from CLRC_SETUP message SessionId 0 CLRCSeq random number between 0 and (2^32)-1 InitiatorName Host Identifier (name), copied from CLRC_SETUP ResponderName Host Identifier (name), copied from CLRC_SETUP UserScheme one of 0x0, 0x1,0x2 ServerScheme one of 0x0, 0x1,0x2, copied from CLRC_SETUP ServerName server identifier (only when ServerScheme != 0) ServerCredentials server authentication info (only when ServerScheme != 0) The ServerScheme field MUST be copied from the corresponding CLRC_SETUP message. If responder authentication has been requested in the CLRC_SETUP message, the responder MUST provide sufficient authentication information in the ServerName and ServerCredentials fields. The ServerName and ServerCredentials fields are only present, if server authentication has been specified in the ServerScheme field, i.e., when ServerScheme is not equal to zero. For version 1 of PCMP, the UserScheme fields MUST be set to 0. The responder MUST generate a new random number for the starting value of the Sequence#. Before accepting the CLRC_SETUP_ACK message, a CLRC initiator MUST perform the following checks: Ott & Kutscher Expires January 19, 2005 [Page 29] Internet-Draft PCMP July 2004 o The initiator MUST determine if the specified ServerScheme is acceptable and, if this is the case, MUST subsequently authenticate the server based on the ServerScheme, ServerName and ServerCredentials specified in the CLRC_SETUP_ACK message. If the specified UserScheme is not acceptable, or when the authentication fails, the request MUST be rejected (see below). o The initiator MUST verify that the specified InitiatorName and ResponderName are identical to the corresponding message fields of the CLRC_SETUP request. o The responder MUST verify that the CLRCId is identical to the CLRCId specified in the CLRC_SETUP message. reject the request otherwise. o For version 1 of PCMP, the responder MUST ignore the UserScheme field. If the initiator decides to maintain the CLRC it does nothing. If the initiator decides to cancel the CLRC, e.g., because of an server authentication failure, it MUST terminate the CLRC as specified in section 5.1.2. If a CLRC responder decides to not accept a CLRC_SETUP request, it MUST respond with a CLRC_SETUP_REJ message as depicted in Figure 36. CLRC Initiator CLRC Responder | CLRC_SETUP(CLRCId) | |---------------------------------->| | | | CLRC_SETUP_REJ(Reason) | |<----------------------------------| | | Figure 36: Rejecting a CLRC_SETUP request Version 1 Type CLRC_SETUP_REJ (0x03) Length total length of message including header CLRCId copied from CLRC_SETUP message SessionId 0 CLRCSeq random number between 0 and (2^32)-1 InitiatorName Host Identifier (name), copied from CLRC_SETUP ResponderName Host Identifier (name), copied from CLRC_SETUP UserScheme one of 0x0, 0x1,0x2 ServerScheme one of 0x0, 0x1,0x2 Ott & Kutscher Expires January 19, 2005 [Page 30] Internet-Draft PCMP July 2004 ServerName server identifier (only when ServerScheme != 0) ServerCredentials server authentication info (only when ServerScheme != 0) ReasonCode a valid reason code ReasonPhrase a corresponding reason phrase The ServerScheme field MUST be copied from the corresponding CLRC_SETUP message. If responder authentication has been requested in the CLRC_SETUP message, the responder SHOULD provide sufficient authentication information in the ServerName and ServerCredentials fields. The ServerName and ServerCredentials fields are only present, if server authentication has been specified in the ServerScheme field, i.e., when ServerScheme is not equal to zero. If the responder is not able to provide the requested authentication information e.g., when it does support required algorithm, it MUST set ServerScheme to 0 and omit the fields ServerName and ServerCredentials. For version 1 of PCMP, the UserScheme fields MUST be set to 0. The responder MUST generate a new random number for the starting value of the Sequence#. In addition, the CLRC_SETUP_REJ message MUST provide a reason code and a textual reason phrase. The reason code MUST provide one of the following values: 0x01 AuthenticationRequired 0x02 AuthenticationFailure 0x03 NoResources 6.1.2 CLRC Teardown Each of the CLRC peers can teardown the CLRC. When the CLRC is established over a connection-oriented channel such as a TCP connection and the connection is lost, the CLRC session is terminated implicitly. CLRC Initiator CLRC Responder | CLRC_TEARDOWN(CLRCId) | |---------------------------------->| | | Ott & Kutscher Expires January 19, 2005 [Page 31] Internet-Draft PCMP July 2004 | CLRC_TEARDOWN_ACK | |<----------------------------------| | | CLRC Initiator CLRC Responder | CLRC_TEARDOWN(CLRCId) | |<--------------------------------->| | | | CLRC_TEARDOWN_ACK | |---------------------------------->| | | 6.1.3 CLRC Error Signaling TBD 6.2 Session Management PCMP provides a set of messages that implement the session management service: session initiation, data transmission, session suspension and session termination. The session management messages are exchanged within a CLRC. Each session management message relates to a specific session, which is expressed by the message id header field. Communication within a CLRC is symmetric, i.e., both peers can establish sessions. Sessions are identified by a SessionName, which is a persistent identifier that is fixed when the session is initiated. When a session has been suspended or when the corresponding CLRC has been terminated and the session is to be resumed (possibly in a new CLRC), the SessionName is used to identify the session. Within a CLRC, a SessionName is mapped to a (shorter) SessionId. The SessionId is used in messages such as DATA to refer to the SessionName. The scope of the SessionId is limited to a specific CLRC, i.e., when a previously suspended or interrupted session is to be resumed in a new CLRC, a new SessionId is generated for that CLRC. The DATA message is used to implement most of the session management functions such as data transmission, session suspension and session termination. For each DATA message, the desired purpose is specified Ott & Kutscher Expires January 19, 2005 [Page 32] Internet-Draft PCMP July 2004 by the message flags. This allows, e.g., to combine session initiation with the sending of a first segment of user data. 6.2.1 Session Initiation Session initiation is implemented with the SETUP message. The SETUP message may also be used to convey user data. This allows an initiator to combine the session setup with the transmission of an initial payload thus reducing the number of round trips required for many communication scenarios. Session Initiator Passive Party |SETUP(CLRCId, SessionName, SessionId, TargetAddress, ServiceType,Window) | |------------------------------------------------------------------------>| | | | ACCEPT(CLRCId, SessionId) | |<------------------------------------------------------------------------| | | Flags for the DATA message: SYN Session Initiator Passive Party | SETUP(CLRCId, SessionName, SessionId, TargetAddress, ServiceType,Window) | |<------------------------------------------------------------------------| | | | ACCEPT(CLRCId, SessionId) | |------------------------------------------------------------------------>| | | Flags for the DATA message: SYN 6.2.2 Session Initiation and Data Transmission Session Initiator Passive Party | SETUP(CLRCId, SessionName, SessionId, TargetAddress, Window, user data) | |----------------------------------------------------------------------->| | | | ACCEPT(CLRCId, SessionId) | |<-----------------------------------------------------------------------| | | | DATA_ACK(CLRCId, SessionId) | |<-----------------------------------------------------------------------| | | Ott & Kutscher Expires January 19, 2005 [Page 33] Internet-Draft PCMP July 2004 The DATA_ACK message is currently not needed when CLRC is used over TCP). 6.2.3 Data Transmission Data transmission is implemented with the DATA message. The DATA message refers to a session that has been estabslished with the SETUP message before. DATA messages are symmetric. Peer A Peer B | DATA(CLRCId, SessionId, Window, user data) | |----------------------------------------------------------------------->| | | | | | DATA_ACK(CLRCId, SessionId) | |<-----------------------------------------------------------------------| | | | DATA(CLRCId, SessionId, Window, user data) | |<-----------------------------------------------------------------------| | | | | | DATA_ACK(CLRCId, SessionId) | |----------------------------------------------------------------------->| | | Peer A Peer B | DATA(CLRCId, SessionId, Window, user data) | |----------------------------------------------------------------------->| | | | | | DATA_NAK(CLRCId, SessionId, ReasonCode, ReasonPhrase) | |<-----------------------------------------------------------------------| 6.2.4 Session Suspension Peer A Peer B | DATA(CLRCId, SessionId) | |----------------------------------------------------------------------->| | | | | | DATA_ACK(CLRCId, SessionId) | Ott & Kutscher Expires January 19, 2005 [Page 34] Internet-Draft PCMP July 2004 |<-----------------------------------------------------------------------| | | Flags for the DATA message: SUSPEND 6.2.5 Session Termination Peer A Peer B | DATA(CLRCId, SessionId) | |----------------------------------------------------------------------->| | | | | | DATA_ACK(CLRCId, SessionId) | |<-----------------------------------------------------------------------| | | Flags for the DATA message: FIN Authors' Addresses Joerg Ott TZI Universität Bremen Dirk Kutscher TZI Universität Bremen Ott & Kutscher Expires January 19, 2005 [Page 35] Internet-Draft PCMP July 2004 Appendix A. Change History o 1.1 -- 1.12 * neues Flag: SUSPEND * Many :-) o 1.13 * New message SETUP for initiating a session, removed some message fields from DATA. All fields in DATA message now start at 32-bit-boundaries. * More protocol operation requirements in section 5.1. o 1.14 * Added description of SETUP message to section 4.1. * Removed PAUSE message from section (renumbered message codes) * Unified message field names in section 4.2 and section 5. * Misc. minor corrections. o 1.15 * renamed strawman to PCMP o 1.16 * included SETUP in list of types in Section 5.2 and corrected type numbers; updated Section 6.2.1 and Section 6.2.3. o Draft version 01: * added abstract. * added terminology section. * mentioned timeouts for maintaining suspended transport sessions in Section 6. Ott & Kutscher Expires January 19, 2005 [Page 36]