Internet DRAFT - draft-ietf-telnet-mpx-option
draft-ietf-telnet-mpx-option
INTERNET DRAFT Jean-Philippe Caradec, Author
Marjo F. Mercado, Editor
Hewlett-Packard Company
July 1993
TELNET MPX option
Status of this Memo
This document is 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. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other
than as a ``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil,
nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au
to learn the current status of any Internet Draft.
Abstract
This Internet Draft specifies a multiplexing protocol for TELNET
hosts and devices using the Internet TCP/IP protocol stack. Hosts
that exchange TELNET Multiplexing (MPX) information within the
TELNET protocol are expected to adopt and implement this
protocol.
By negotiating the MPX option, both client and server agree to
use the specified multiplexing protocol. This negotiation is on a
per transport link basis. The goal of this option is to use a
single TCP connection to link device servers and remote hosts.
This link is then used to carry out multiple session traffic.
The MPX protocol will be responsible for establishing sessions
between TELNET client ports and TELNET server hosts. The protocol
will also be responsible for doing session flow control. To
handle these two functions, a header will be added to the TELNET
data path specifying the session, the data-length, the flow
control process and the session packet type.
Document expiration date
The expiration date for this Internet Draft is December 31, 1993.
1
1. Command Name and Code
MPX XX
2. Command meanings
IAC WILL MPX
Sender is willing to send TELNET data using the session
multiplexing process on the TCP connection.
IAC WON'T MPX
Sender refuses to use the session multiplexing process.
IAC DO MPX
Sender is willing to receive TELNET data using the session
multiplexing process on the TCP connection.
IAC DON'T MPX
Sender refuses to receive TELNET data with session multiplexing
encapsulation.
3. Default
WON'T MPX
The session multiplexing encapsulation is not used to send
TELNET data.
DON'T MPX
The session multiplexing encapsulation is not used to receive
TELNET data.
4. Motivation for the option.
On most of the UNIX (R) machines implementing the ARPA
protocol stack, the application traffic is character mode
oriented. This implies a large number of packets containing a
limited number of characters to handle either on client and
server side. TELNET clients are supporting more and more
sessions to a single TELNET server. Moreover, TELNET traffic
can use an asynchronous link as a physical link with limited
bandwidth, i.e. SLIP or PPP.
To avoid an escalation in terms of performance requirements
either on the client or the server side, the session
multiplexing TELNET option has been defined to limit the amount
of exchanged packets using a single TCP connection to carry out
multiple session traffic.
2
5. Description of the TELNET option.
By negotiating the MPX option, both client and server agree to
use the specified multiplexing protocol. This negotiation is on
a per transport link basis. The goal of this option is to use a
single TCP connection to link device servers and remote hosts.
This link is then used to carry out multiple session traffic.
The MPX protocol will be responsible for establishing sessions
between TELNET client ports and TELNET server hosts. The protocol
will also be responsible for doing session flow control. To
handle these two functions, a header will be added to the
TELNET data path specifying the session, the data-length, the
flow control process and the session packet type.
5.1 MPX header format
| 7 | 6 | 5 | 4 | 3 | 2 | 1| 0 |
+++++++++++++++++++++++++++++++++
+pkt type | credit |High L.|
+++++++++++++++++++++++++++++++++
+ Low data length +
+++++++++++++++++++++++++++++++++
+ local session number +
+++++++++++++++++++++++++++++++++
+ reserved for future usage +
+++++++++++++++++++++++++++++++++
WHERE:
--> The packet type can take the following values:
0 : TELNET data end session packet.
1 : TELNET data continue session packet.
2 : TELNET non-flow controlled data end session packet.
3 : start request session packet.
4 : start confirm session packet.
5 : close session packet.
6 : echo request/reply session packet.
--> the credit can take values from 0 to 7.
--> the (High L./Low) data length can take values from 0 to 1023.
--> the session number can take values from 0 to 255.
--> The reserved byte must be set to zero.
3
5.2 Session number
The session number identifies the session on both sides.
Both sides of the connection should have the same session
number. During the start session process, this field is
filled in by the caller. The session number is linked to a
dedicated TCP connection to a remote host.
To avoid collision on the allocated session number, the
TELNET client will use the first available session number
starting from 0 going to 255 whereas the TELNET server will
use the first available session number starting from 255
going to 0. If a start session collision occurs
on the same session number, the TELNET client will refuse
the TELNET server session open whereas the TELNET server has
to accept the start session from the TELNET client. This
gives priority to the client start session over the server
start session.
5.3 Data length field
The data length specifies the user data size that can be
found after the protocol header for that specific session
packet. If larger packets have to be sent, the "data
continue/data end" mechanism can be used to reassemble the
large packet. This data length does not include the MPX
header size.
5.4 Credit field
The credit field can take values from 0 to 7.
At session opening, both entities advertise the amount of
data (the absolute credit) they can receive. The absolute
credit is defined in units. A unit can be a session data
packet or a subset of a session data packet if the session
data packet size is larger than the unit size.
Suppose that the unit size is equal to 10 bytes, a session
data packet of one byte represents one unit but a session
data packet of 40 bytes represents 4 units. The absolute
credit represents the number of units that the entity can
receive.
The absolute credit is defined in the start packets. The
following credits proposed in the credit field represents an
incremental number of units.
Credit increment can be delayed to avoid sending data packet
with length equal to 0 just to increment credit. A credit
increment timer can be started to favor piggy-backing of
credit incremental information with data packet to send.
4
5.5 Packet type field.
5.5.1 TELNET data end session packet.
This packet type will contain TELNET data including either
user data or TELNET command. All the TELNET commands are
supported over this mechanism. The credit increment packets
have to be sent using a data end packet with data-length
equal to zero.
5.5.2 TELNET data continue session packet
This packet type will contain TELNET data including either
user data or TELNET command. The "data continue" packet type
is used when the notion of "fragment" sent over session
packet is required to reassemble large reads or writes on
the remote site. In that case, multiple data continue
packets can be sent followed by a data end packet.
5.5.3 Start session packet.
The start session packet is used to establish a session
over the transport link. The start session packet contains
the absolute credit value, unit size and information linked
to the caller identification.
The start session can be accepted or refused by the called
entity.
| 7 | 6 | 5 | 4 | 3 | 2 | 1| 0 |
+++++++++++++++++++++++++++++++++
+pkt type | credit |High L.|
+++++++++++++++++++++++++++++++++
+ Low data length +
+++++++++++++++++++++++++++++++++
+ local session number +
+++++++++++++++++++++++++++++++++
+ reserved for future usage +
+++++++++++++++++++++++++++++++++
+ MPX data length +
+++++++++++++++++++++++++++++++++
+ Credit unit size (higher b.)+
+++++++++++++++++++++++++++++++++
+ Credit unit size (low b.) +
+++++++++++++++++++++++++++++++++
+ 2 bytes reserved +
+++++++++++++++++++++++++++++++++
+ upper layer data lgth (h) +
+++++++++++++++++++++++++++++++++
+ upper layer data lgth (l) +
+++++++++++++++++++++++++++++++++
+ Upperlayer info +
+++++++++++++++++++++++++++++++++
5
The MPX data length represents the data length of the MPX
parameters in the start session packet. Currently, that length
is set to 4 (credit parameter + 2 bytes reserved).
The upper layer information follows the MPX parameter fields.
The upper layer data length field has to be calculated by
adding the fixed header size plus one byte for the MPX data
length field plus the MPX data length itself.
5.5.4 Start confirm session packet.
The start confirm session packet is sent by the called
TELNET device to accept the session opening. No session data
must be sent between the start session and the start
confirm.
| 7 | 6 | 5 | 4 | 3 | 2 | 1| 0 |
+++++++++++++++++++++++++++++++++
+pkt type | credit |High L.|
+++++++++++++++++++++++++++++++++
+ Low data length +
+++++++++++++++++++++++++++++++++
+ local session number +
+++++++++++++++++++++++++++++++++
+ reserved for future usage +
+++++++++++++++++++++++++++++++++
+ MPX data length +
+++++++++++++++++++++++++++++++++
+ Credit unit size (higher b.)+
+++++++++++++++++++++++++++++++++
+ Credit unit size (low b.) +
+++++++++++++++++++++++++++++++++
+ 2 bytes reserved +
+++++++++++++++++++++++++++++++++
+ local session number +
+++++++++++++++++++++++++++++++++
+ upper layer data lgth (h) +
+++++++++++++++++++++++++++++++++
+ upper layer data lgth (l) +
+++++++++++++++++++++++++++++++++
+ Upperlayer info +
+++++++++++++++++++++++++++++++++
The same convention as start session packet is used for start
confirm packet fields.
6
5.5.5 Close session packet.
The close session packet is sent for two reasons. The called
entity specifies that the session is refused or the session
is ended by one of the entities.
| 7 | 6 | 5 | 4 | 3 | 2 | 1| 0 |
+++++++++++++++++++++++++++++++++
+pkt type | credit |High L.|
+++++++++++++++++++++++++++++++++
+ Low data length +
+++++++++++++++++++++++++++++++++
+ local session number +
+++++++++++++++++++++++++++++++++
+ reserved for future usage +
+++++++++++++++++++++++++++++++++
+ MPX data length +
+++++++++++++++++++++++++++++++++
+ MPX close reason +
+++++++++++++++++++++++++++++++++
When all sessions are closed on a TCP link, the link must
be disconnected. The MPX data length value is currently one
because the only MPX field is the close reason.
The close reason can take multiple values:
1 : session closed by user.
2 : session closed on modem down.
3 : session closed on reset.
4 : session closed by upper layer.
5 : session closed by TELNET server.
5.5.6 Non-flow controlled data session packet.
The non-flow controlled data packet is used to bypass normal
data path for urgent delivery. There is no non-flow
controlled data continue session packet.
5.5.7 Echo request/reply.
The echo request/reply packet is used to determine the
network delay between the TELNET client and the TELNET
server. After the link is established, an echo packet is
sent requesting from the server an immediate reply. The time
measurement between the request and the reply is then
computed to optimize the multiplexing timer (see next
sections).
The data length is null and the echo request/reply packet is
not subject to flow-control (no credit unit is consumed to
send the echo request/reply session packet).
7
5.6 Multiplexing session over a transport connection.
The multiplexing algorithm is based on a multiplexing timer
which concatenates the traffic of multiple TELNET sessions.
The multiplexing timer can take values from 10 to 120 ms.
The recommended value on client side is 80 ms and on server
side 10/20 ms. These values are appropriate for interactive
traffic.
When the multiplexing timer pops, TELNET data is collected
from multiple sessions. Before each session user data, the 4
byte protocol header is added. The data length field of each
session data permits the demultiplexing process to occur.
6. Implementation issues.
The MPX protocol implies an encapsulation of the user data
within a session packet. This new mode is enabled once
the TELNET MPX option is negotiated between the two
entities.
To avoid mixing TELNET packets with and without headers, we
expect that any TELNET device implementing MPX option will
start its TELNET negotiation with the MPX option negotiation.
Further TELNET negotiation occurs once the session is
established.
The multiplexing timer value needs to be dynamically adapted
to any echo delay modification to favor echo response time.
The echo request packet should be sent every 10 seconds to
test response time depending on IP network routes. If
traffic is rerouted because of router failure, the timer
should be automatically updated to offer the best echo
delay/performance compromise.
8
7. Example
users client server
user1 "connect" ------ TCP SYN ------------->
<-- TCP SYN/ACK ---------
-------TCP ACK -------->
<-- IAC WILL/DO MPX ____________
-- IAC WILL/DO MPX ____________>
------- start session -->
<-------start confirm -----------
<------ [ TELNET neg ] ----------
------- [ TELNET neg ] --------->
user2 "connect"
------- start session --------->
<-------start confirm -----------
<------ [ TELNET neg ] ----------
------- [ TELNET neg ] --------->
user1 data |
|
user2 data |-> -----<header1>data1<header2>data2 -->
8. Reference
[1] Postel, J., and J. Reynolds, "TELNET PROTOCOL
SPECIFICATION", RFC 854, USC Information Science
Institute, May 1983
9
9. Author's Address
Jean-Philippe Caradec
Grenoble Networks Division
Hewlett Packard France
5, Rue Raymond Chanas
38320 Eybens
France
Phone: +33 76625518
Email: caradec@gnlab030.grenoble.hp.com
Marjo F. Mercado
Grenoble Networks Division - Cupertino
Hewlett Packard Company
19420 Homestead Road, MS 43 LH
Cupertino, CA 95014
U.S.A.
Phone: (408) 447-2826
Email: marjo@cup.hp.com
Document expiration date
The expiration date for this Internet Draft is December 31, 1993.
10
