Internet DRAFT - draft-hay-mcc

draft-hay-mcc



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:19:30 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 17 Mar 1998 16:34:00 GMT
ETag: "2e9aed-365e-350ea5f8"
Accept-Ranges: bytes
Content-Length: 13918
Connection: close
Content-Type: text/plain








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]