TOC 
Network Working Group Ott
Internet-Draft Kutscher
Expires: January 19, 2005TZI 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 $



 TOC 

Table of Contents




 TOC 

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



 TOC 

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.

    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.



 TOC 

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



 TOC 

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).



 TOC 

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

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

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.
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 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                         :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |           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                         :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |           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          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               |
   :                         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)

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



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

     - 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                            :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   :                                                               :
   :                                                               :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               |
   :                    EmbeddedData #n                            :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	  

Note that the fields of this message are not necessarily 32-bit-aligned even though the above figure may suggest so.



 TOC 

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

 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:

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:

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:

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

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 established 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)                |
 |<-----------------------------------------------------------------------| 
 |                                                                        |
	    

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



 TOC 

Authors' Addresses

  Joerg Ott
  TZI Universitšt Bremen
  
  Dirk Kutscher
  TZI Universitšt Bremen


 TOC 

Appendix A. Change History