INTERNET-DRAFT G. Hiddink Expires: 22 July 2002 Jan 2002 draft-hiddinkg-wwcp-part2-01.txt WWCP Part 2: Network Interface Layer 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``. To learn the current status of any Internet-Draft, please check the 1id- abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before October 1996. Distribution of this draft is unlimited, but all copyrights are reserved to G. Hiddink. The ideas contained herein are intellectual property of G. Hiddink. Abstract The Network Interface Layer is a thin adaptation layer that takes care of making, maintaining and removing network connections. It is a multi- protocol layer, in the sense that it accepts connections from different ``entities'' (eg. an IRC client, a WWCP client or a peer conferencing server) and directs the protocol messages via the appropriate handler to the next layer. CONTENTS 1. Introduction ............................................... 1.1 General message format .................................... Hiddink [Page 1] Internet Draft WWCP Part 2 22 Jan 2002 2. Making a connection ........................................ 2.1 The "IAM" message ......................................... 2.2 Protocol versions ......................................... 2.3 Connection flags .......................................... 3.1 Traffic shaping ........................................... 3.2 Faulty messages ........................................... 3.3 Keeping a connection alive ................................ 3.4 Packet size considerations ................................ 1. Introduction The Network Interface Layer takes care of everything that needs to be done in order to setup a connection across any network, receive and send data on it, and disconnecting it. Connections can be made across any network offering a reliable data transport layer, for example using the TCP/IP protocol. But also connections across other types of networks are possible. The Network Interface Layer (NIL) is designed to provide a uniform interface towards the protocol layers above. It is a protocol to setup one on one connections between so-called `nodes'. A node is a process that is capable of communicating using the NIL protocol. It is identified using a unique 32-bit numerical ID, which is assigned `for life', i.e. an ID is never reused (see also section 4.2 of part 1). Different types of messages are exchanged via the connections between WWCP nodes: NIL messages, MCAST messages, and application protocol messages. In order to identify NIL messages from MCAST messages, all NIL messages start with a '.', so that implementations can easily detect what protocol layer should be activated to handle a certain message. 1.1 General message format Protocol messages are sent in plain text, terminated with a carriage return (acii 13) and/or line feed (ascii 10). A null terminator shall not be used. Future extensions of this protocol will include a binary version, in which all plain text messages will be replaced with codes. 2. Making a connection Nodes can make connections to each other to exchange data. The "IAM" message is used for nodes to identify themselves to the other nodes. Hiddink [Page 2] Internet Draft WWCP Part 2 22 Jan 2002 2.1 The "IAM" message WWCP nodes identify themselves using the "IAM" message and a three-phase handshake. The format of the "IAM" message is as follows: .IAM For example: .IAM SERV 32 S3Cr3T 1.00 cnd 0.14.3 The entity that initiated the connection shall first send its "IAM" message. The receiving entity can respond in a number of ways: * if the password is not correct, the receiving entity shall send a ".NAK" message (no parameters required) and terminate the connection; * if the id is invalid, the receiving entity shall send a ".INVID" message and terminate the connection; * if the node does not wish to accept more incoming connections in general (i.e. due to a too high load), then a ".FULL" message can be sent, after which the connection shall be terminated; * if the node does not wish to accept more incoming connections from this particular initiating node, then a ".NOMORE" message can be sent, after which the connection shall be terminated. * if the node does not have protocol support for the initiating node's entity, or is not willing to talk to it, then a ".SNPNI" message shall be sent, after which the connection shall be terminated. * if the receiving node accepts the connection, it will reply by sending its own "IAM" message to the initiating node. This node will then verify the password and all other parameters that are relevant, and if these are ok, it shall send an ".OK" message. If the initiating node does not approve of the other node's IAM message, then it shall reply with one of the above error messages. After the ".OK" message, both nodes can safely assume that the connection is valid. 2.2 Protocol versions The protocol version field indicates the WWCP protocol version that the node conforms to. 2.3 Connection flags There are currently no connection flags. 3.1 Traffic shaping Hiddink [Page 3] Internet Draft WWCP Part 2 22 Jan 2002 A node can employ traffic shaping to limit the rate of incoming data on a connection. If a node decides that it is receiving data too fast from a particular connection, it shall send an ".XOFF" message to the source. Although TCP itself also uses ICMP Source Quench messages, this still does not prevent long receive buffers from building up. A node that reveives an .XOFF message shall attempt to reduce its traffic (e.g. by no longer accepting connections itself, or by creating connections to other nodes to leverage the routing load on the node that sent the 3.2 Faulty messages A node may respond with the message ".ERROR" to any message that it does not understand. 3.3 Keeping a connection alive Connections are kept alive by periodically sending a ".PING" message, after which the node at the other end of the connection should reply with a ".PONG" message within a predefined amount of time. The precise amount of time depends greatly upon the network characteristics used by the nodes to build connections. If this timeout is too small, then slightly lagged connections are mistaken for broken connections; if it is too large, then broken connections go unnoticed for too long. 3.4 Packet size considerations The WWCP protocol suite is inteded for use as multimedia multicasting infrastructure. This means that large amounts of data need to be transmitted. In order to keep the per-packet overhead relatively low, relatively large packet sizes should be chosen. Although this specification does not prescribe a packet size, it is recommended that the packet size is chosen in the order of several kilobytes. For interactive real-time applications, such as Internet telephony or teleconferencing, the packet sizes should be kept sufficiently small to not cause excessive delays. Hiddink [Page 4]