| TOC |
|
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.
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.
$Revision: 1.1.1.1 $
| TOC |
| TOC |
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 |
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:
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 |
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 |
- 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 |
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.
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-responseFurther 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 ":" noThen, 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 | HTTPThe 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.domainwith "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.
All multi-octet values (16, 32, 48, 64 bits) are transmitted in network byte order (i.e., big endian).
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
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.
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.
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 :
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ACCEPT message is used to confirm the successful setup of a session. Three cases need to be considered for generating ACCEPT messages:
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
TBD. (not yet needed)
TBD. (not yet needed)
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.
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 |
PCMP provides two fundamental services:
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
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 |
|---------------------------------->|
| |
TBD
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.
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
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).
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) | |<-----------------------------------------------------------------------|
Peer A Peer B | DATA(CLRCId, SessionId) | |----------------------------------------------------------------------->| | | | | | DATA_ACK(CLRCId, SessionId) | |<-----------------------------------------------------------------------| | |
Flags for the DATA message: SUSPEND
Peer A Peer B | DATA(CLRCId, SessionId) | |----------------------------------------------------------------------->| | | | | | DATA_ACK(CLRCId, SessionId) | |<-----------------------------------------------------------------------| | |
Flags for the DATA message: FIN
| TOC |
| Joerg Ott | |
| TZI Universität Bremen | |
| Dirk Kutscher | |
| TZI Universität Bremen |
| TOC |