Internet-Draft K.J.Hay
<draft-hay-mcc-00.txt> QUALCOMM, Incorporated
Expires on 1 October 1997 26 March 1997
Multicast Chat (MCC) Protocol
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 and may be
updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet-Drafts as material or to cite them
other than as ``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 ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document is an rough draft for a proposed new Internet
conferencing protocol called multicast chat (MCC) which uses IP
multicast for the internet layer.
IP Multicast
IP multicast (also known as Internet multicast) is an Internet
delivery mechanism such that a single host can broadcast to a group
of hosts who are interested in listening. This differs from the
standard point-to-point messaging (unicasting), that allows a
connection between two hosts and from broadcasting, which to
everyone, even those hosts who could care less.
A multicast group is a group of hosts who are all listening to the
same broadcast. Each multicast group has a class D IP address which
is used when broadcasting to the group. To send to a group a host
sends his message to the group's IP address. To listen to a group a
host informs the network that it wishes to receive packets for the
group's IP address. A host can join and leave any number of
multicast groups at will.
Multicast Chat
Hay [Page 1]
Internet Draft Multicast Chat (MCC) Protocol 26 March 1997
Multicast chat (MCC) is a proposed application protocol to allow
real-time conferencing using IP multicast.
Conceptual Actual
|-------------| |--------------|
| Application | | MCC |
|-------------| |--------------|
| Transport | | TBD |
|-------------| |--------------|
| Internet | | IP Multicast |
|-------------| |--------------|
An MCC client is any application that uses the MCC protocol to do
real-time conferencing. A client can set up a chat room, which is
then used to conference among a group of people. Each MCC room is
assigned a multicast IP address. The MCC protocol has a reserved
multicast address which it refers to as the CC. The CC, which stands
for control channel, is used to pass room and client between clients.
Once a room is created the client can inform other clients of its
existence on the CC, allowing them to then join the room. The
collection of all MCC clients is referred to as the MCC Network
Connecting a Client to the Network
All that a client needs to do to join the MCC network is to connect
to the CC IP address and send a CLIENT JOIN message. The CLIENT
message gives the other clients information about you along with
informing them that you have connected to the MCC network. There is
a corresponding CLIENT QUIT message to inform others that you have
disconnected.
Rooms and Folders
When a room is created a multicast IP address is associated with it
(How a available multicast IP address is acquired has not yet been
figured out). The creator of the room also specifies the following
information for the room:
Room Path - This is the rooms name and folder path (see below).
Topic - This is a optional string describing what the topic of the
room is.
One of the things specified in the creation of a room is the rooms
path. MCC organizes rooms into a nested hierarchy of folders. The
rooms path indicates what folder the channel can be found in. The
folder path is considered part of the room path and appears as
follows.
Hay [Page 2]
Internet Draft Multicast Chat (MCC) Protocol 26 March 1997
<room path> = /<folder>{/<sub-folder>}/<room name>
The same name can be used for different channels if the folder paths
are different. For example the room "Computers/Internet/C++" is
considered a different room then "Computers/Software/C++". The top
folder level is known as the lobby. The lobby contains only folders,
no rooms, which is done to prevent the cluttering up of the lobby.
This makes the room "/C++" an illegal room, since it can not be at
the top level.
Creating a Room
To create a room, the user specifies a room name (including the
folder path) and optionally a topic name for the room. If the channel
in the specified folder already exists, then the create will fail.
If the creation is successful then an IP address for the new channel
is assigned (once again, how this is done needs to be determined) and
the client notifies the other clients by sending a ROOM OPEN message
on the CC.
Joining a Room
To join a room, a client must first get the room's IP address. One
of the ways this can be done is by sending out a ROOMREQUEST command
on the CC. If the room exist then the Room Keeper (see below)
responds with a ROOM INFO command that includes the room's IP
address. Once a client has the IP address it can connect to the
address and listen into the room.
Room Upkeep
When a client sends a CHANNELREQUEST message a response should come
from the room. The room itself is incapable of sending the response.
That means someone in the room must send it for the room. That
someone is known as the room keeper. The room keeper is the client
who has been on the channel the longest.
MCC Commands
There are two types of commands in MCC. They are CC commands and
room commands. CC commands are sent on the CC address while room
commands are sent on the room address. The format for both are the
same though.
<host> <command> <parameters> CR/LF
The host is the machine that sent the command. Following the host is
the command and its parameters. A CR/LF indicates the end of a
Hay [Page 3]
Internet Draft Multicast Chat (MCC) Protocol 26 March 1997
command line. Both CC and room commands are described in detail in
the following sections.
CC Command Reference
CLIENT < action > <client name> { <tag> <data> }
The CLIENT command is used to send the user's client information to
other clients. The <action> parameter indicates the action being
performed and can have the value JOIN, CHANGE, QUIT or INFO. JOIN
informs the other clients that the user has just joined the MCC
network. CHANGE informs of a change in the users client information.
QUIT informs the other clients when quitting the MCC network. The
QUIT action ignores all of the other parameters, and they therefore
need not be sent. INFO is in response to a CLIENTREQUEST command
asking for your client information.
All actions, except QUIT, also supply a name the client will be known
as while connected to the MCC network. A client also has the option
of sending other information about itself. It does this by sending a
tag describing what the data being sent is followed by the data
itself. A client can send as much information about himself as he
chooses. Data tage would be such things as real name, address, e-
mail, home page, etc...
CLIENTREQUEST < client name >
The CLIENTREQUEST command is used to request client information about
another client. The client being asked for information will respond,
if it chooses to, with a CLIENT INFO command.
CTC <command> <parameters>
The CTC command stands for client-to-client, and allows client
application to send specialized commands for their applications. If
a client does not recognize a CTC command then it should ignore it
completely.
PING [ <room name> ]
The PING command is used to tell other clients that you are still on
the MCC network. A client should ping nor more then once a minute.
If a room name is specified as a parameter then this means the ping
is from a room, which the keeper is responsible for, and is used to
tell others that the room still exists.
ROOM < action > <room path> <room ip address> [ <topic> ]
Hay [Page 4]
Internet Draft Multicast Chat (MCC) Protocol 26 March 1997
The ROOM command is used to send the room information to other
clients. The <action> parameter indicates the action being performed
and can have the value OPEN, CLOSE or INFO. OPEN informs the other
clients that a client has created a new room. CLOSE informs the other
clients when a room has closed down. The CLOSE action only supplies
a <room path> and no ther parameters. INFO is in response to a
ROOMREQUEST command asking for room information.
ROOMREQUEST <path>
The ROOMREQUEST command is used to request room information. If
<path> is a complete room path, then only the keeper of that channel
should respond with a ROOM INFO command. If <path> if a folder path,
then all channels in that folder, or any sub folder, should respond
with a ROOM INFO command.
Room Command Reference
ACTION <message>
The ACTION command is used to describe an action being performed. If
Bob sent an ACTION message with the message "is thinking about it",
Then everyone else should see "Bob is thinking about it".
AWAY [ <message> ]
The AWAY command is used to indicate when you are away from your
computer, but stay connected to the room. If a message is specified
(the message should tell why you are away) then the message is also
sent to all other people in the room. If an AWAY message is sent
without a message, then that person is no longer away.
CTC <command> <parameters>
This is similar to the CC version of the command except only people
in the room receive the command.
JOIN <client name>
A person uses this command to announce their arrival into a room.
LEAVE <client name>
A person uses this command to announce when they are leaving a room.
PING
The PING command should be sent every so often by everyone in the
Hay [Page 5]
Internet Draft Multicast Chat (MCC) Protocol 26 March 1997
room to indicate they are still there.
POST <message>
This is used to post your standard message to the room.
TBDs
This document gives an overview of the proposed MCC protocol. But
there are still some things that need to be worked out. One of the
things mentioned earlier was how exactly does a room obtain a
multicast IP address and then notify the MBONE. (The MBONE is a term
currently used to describe those networks that support multicast IP
routing. In the next version of IP, multicast will be fully
supported.) There is a program called SDR that keeps a sessions
directory which may meet this need.
Another question is what to use as a transport protocol. UDP seems
obvious but it does not support guaranteed delivery. TCP guarantees
delivery but does not seem implementable on a broadcast protocol like
multicast IP. This entire subject needs to be worked out.
Another problem is private rooms. The concept of private rooms has
not been addressed in this document but it would probably be a
desirable feature. The answer is probably to encrypt the session and
not tell anyone about the channels.
The concept of folders is very useful. It allows the breaking down
of rooms into categories and allows people to find rooms they are
interested in easier. The headache is how to implement folders. The
protocol currently has a flaw in respect to folders. Given the
following hierarchy (so its a little contrived):
Technology ---+---Computers---+--- Software (room)
| |
| |--- Hardware (room)
|
|---VCRs---+---(60 different rooms)
|
|
|---General (room)
Say I want to know what is in the folder Technology. There are two
folders and a room (Computers, VCRs and General). To get that
information 63 rooms will respond (Software, Hardware, VCR's 60 rooms
and General). Computers and VCRs can not respond because there is no
one person in charge of the folder. This leads into the possible
concept of having a folder keeper, similar to that of the room
Hay [Page 6]
Internet Draft Multicast Chat (MCC) Protocol 26 March 1997
keeper.
Author's Address
Kevin J. Hay
QUALCOMM, Incorporated
Eudora Division
6455 Lusk Blvd.
San Diego, CA 92121-2779
Phone: (619) 658-2954
EMail: khay@qualcomm.com
Draft expires on 1 October 1997
Hay [Page 7]