[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                           P. Harsh
Internet-Draft                                                 R. Newman
Intended status: Informational               CISE, University of Florida
Expires: May 20, 2010                                  November 16, 2009


    A Hierarchical Multicast Session Directory Service Architecture
                    draft-mdns-rfc-informational-00

Abstract

   This document describes a globally scalable and hierarchical approach
   to multicast session directory service architecture.  This approach
   allows for sessions to be discovered using keywords as soon as they
   are registered with the system.  It allows session registration to be
   tagged with geographical data to provide location-based search
   capability to the end users.  It is able to assign URI strings to
   multicast sessions.  This document provides a general overview of the
   architecture and describes the protocol used.  The architecture is
   able to operate in networks supporting either traditional ASM or the
   newer SSM.

Status of this Memo

   Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 May 20, 2010.





Harsh & Newman            Expires May 20, 2010                  [Page 1]


Internet-Draft         Multicast Session Directory         November 2009


Table of Contents

   1.  Definitions and Assumptions  . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  mDNS Domain Components . . . . . . . . . . . . . . . . . .  4
       2.1.1.  URI Registration Server  . . . . . . . . . . . . . . .  4
       2.1.2.  Multicast Session Directory Server . . . . . . . . . .  5
       2.1.3.  DNS Server . . . . . . . . . . . . . . . . . . . . . .  6
       2.1.4.  Client Tools . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Workload Distribution (Key-Space Allotment)  . . . . . . .  6
     2.3.  Hierarchy Setup and Maintenance  . . . . . . . . . . . . .  7
   3.  Session Records Structure  . . . . . . . . . . . . . . . . . .  9
     3.1.  Domain local database session record . . . . . . . . . . . 10
     3.2.  Global session database record . . . . . . . . . . . . . . 12
     3.3.  URS Multicast Session Record . . . . . . . . . . . . . . . 12
   4.  Protocol Message Formats . . . . . . . . . . . . . . . . . . . 13
     4.1.  Common message fields  . . . . . . . . . . . . . . . . . . 15
     4.2.  URL Registration Server - Message Formats  . . . . . . . . 18
     4.3.  Session Registration Tool - Message Formats  . . . . . . . 23
     4.4.  Multicast Session Directory Server - Message Formats . . . 26
     4.5.  End User Search Tool - Message Formats . . . . . . . . . . 38
   5.  Protocol Message Semantics . . . . . . . . . . . . . . . . . . 42
     5.1.  URS Protocol Message Semantics . . . . . . . . . . . . . . 43
     5.2.  Registration (Reg.) Tool Protocol Message Semantics  . . . 46
     5.3.  MSD Server Protocol Message Semantics  . . . . . . . . . . 48
     5.4.  End User Search Tool Protocol Message Semantics  . . . . . 62
   6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 65
     6.1.  Routing Table Management . . . . . . . . . . . . . . . . . 65
       6.1.1.  Protocol Messages and Routing Table  . . . . . . . . . 68
     6.2.  Leader Election Algorithm  . . . . . . . . . . . . . . . . 70
     6.3.  Node Failures  . . . . . . . . . . . . . . . . . . . . . . 70
     6.4.  Data Syncing Among Local MSD servers . . . . . . . . . . . 71
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 72
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 73
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 73
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 73
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 73
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75
   Intellectual Property and Copyright Statements . . . . . . . . . . 76












Harsh & Newman            Expires May 20, 2010                  [Page 2]


Internet-Draft         Multicast Session Directory         November 2009


1.  Definitions and Assumptions

   This section defines some of the terms used throughout this document.

   o  Any Source Multicast (ASM) - Any network that conforms to RFC-1112
      and supports some shared distribution tree, typically using
      rendezvous points (RP) based tree, implements MSDP, runs some
      version of multicast routing protocol such as PIM-SM, DVMPR, CBT,
      etc., and supports IGMP v 1 or higher or MLD v 1 or greater.

   o  Source Specific Multicast (SSM) - Any network that conforms to
      RFC-4607 and runs PIM-SM as its multicast protocol, supports IGMP
      v 3 or MLD v 2, and may or may not implement MSDP or any shared
      multicast distribution tree.

   o  Network Administrative Domain - Any domain with a managed DNS
      server and a fully qualified domain name URL string (FQDN)
      assigned to it.

   We will assume that the network administrator of any network
   administrative domain knows the IGMP or MLD protocol version
   supported by the multicast routers installed in that domain and also
   knows the FQDN string of its parent domain. 'domain' at several
   places in this document is also referred as 'node'.  Thus 'node' and
   'domain' is used interchangeably.  Also unless explicitly stated
   otherwise, any reference to MSD server should be read as designated-
   MSD server.


2.  Introduction

   Multicast has long been considered an efficient mechanism for
   relaying live multimedia streams to multiple receivers.  Still the
   use of this technology is not widespread compared to IP unicast
   delivery.  One of the possible obstacles is the lack of a scalable
   session discovery service that will enable an end user to search for
   a session.  With IGMP version 3 becoming a standard, and with
   emerging deployment of SSM capable networks, multicast source
   discovery is increasingly becoming the responsibility of end users.
   SSM with IGMP v 3 and MLD v 2 aims to reduce some of the network
   complexity inherent in the traditional ASM deployment.  The purpose
   of this document is to describe a hierarchical multicast session
   directory architecture that is globally scalable and which enables
   user-friendly access to multicast streams.  The proposed approach
   also solves the delay problem between session registration and
   session discovery by the end users present in some of the alternative
   solutions.  Sessions can now be discovered in real time.  Geotagging
   of registered sessions grants even finer search/query parameter



Harsh & Newman            Expires May 20, 2010                  [Page 3]


Internet-Draft         Multicast Session Directory         November 2009


   control to the clients.

   The hierarchy construction is similar to the DNS hierarchy.  The
   architecture is also tightly integrated with the existing DNS service
   and because of this it supports assignment of a long term URI to each
   multicast stream.  This allows an end user to bookmark multicast
   sessions just like any normal domain URI.  On subsequent occasions,
   the end user can access the multicast session through the bookmarked
   URI instead of initiating a fresh search or remembering an IP
   multicast address.  The architecture is capable of translating the
   URI string and mapping it to the correct multicast session parameters
   that allow the end user to access the stream.  The architecture is
   also designed for incremental deployment.

2.1.  mDNS Domain Components

   Each domain under an mDNS hierarchy must have at least the first
   three domain components listed below.

   1.  URI Registration Server (URS)

   2.  Multicast Session Directory (MSD) server(s)

   3.  DNS Server

   4.  Client Tools

2.1.1.  URI Registration Server

   One of the main tasks of a URS is to enforce uniqueness among the
   registered session identifier keywords relative to its own domain.
   Assuming that each domain has a DNS server running and it has a valid
   FQDN assigned to the network domain, one can construct a unique URI
   for every multicast session that has a unique identifier registered
   with the URS.  The URI will be relative to the URS server URI.  For
   example, if the FQDN for a domain is dom1.somenetwork.example, and
   the URS server has an 'A' entry in the DNS server with value 'mcast',
   then the URI of the URS becomes mcast.dom1.somenetwork.example.
   Furthermore if a multicast session creator has registered a unique
   identifier 'netstream' with this URS server, the URI for his
   multicast stream in this architecture becomes
   mcast.dom1.somenetwork.example/netstream.  In every participating
   domain there must be a URS installed and operational.

   A URS also acts as bootstrap node for one or more MSD Servers (see
   Section 2.1.2) running in that domain that helps the designated MSD
   server join the mDNS hierarchy.  It can also be configured to act as
   a relay point for intra-domain MSD Server communication to facilitate



Harsh & Newman            Expires May 20, 2010                  [Page 4]


Internet-Draft         Multicast Session Directory         November 2009


   leader election and data synchronization among multiple MSD servers
   running in the same domain.

   System administrators must configure at least these 4 parameters in
   the URS during startup -

   1.  PMCAST

   2.  CMCAST

   3.  IGMP version support

   4.  URL string of the parent domain, if no root URL exist/specified,
       then set to 'void'

   PMCAST is the multicast address for the channel used to receive
   communication from the parent domain.  CMCAST is the multicast group
   address for this domain to send communication to the children
   domains.  More details on PMCAST and CMCAST are given later in this
   document.  The inclusion of the URL string of the parent domain
   enables the URS to query the unicast host details of the designated
   MSD server in that domain, which are needed to subscribe to the
   PMCAST channel using IGMP v 3.

2.1.2.  Multicast Session Directory Server

   Every domain that joins our service hierarchy must have one or more
   MSD server(s) installed and operational.  If multiple MSD servers are
   installed in a network administrative domain, then they must be
   capable of running some leader election algorithm.  They choose one
   MSD server to act as designated MSD server (leader) of that domain.
   Other servers act as standby and can take the role of designated MSD
   server in case the leader fails.

   The designated MSD server in a domain is responsible for registering
   multicast sessions originating in that domain.  It also handles
   session search requests from users in that domain.  Additionally it
   is responsible for maintaining globally scoped multicast session
   registration records against keywords whose hash values lie in the
   hash space assigned to this server.  The designated MSD server is
   also responsible for establishing communication links with designated
   MSD servers in its children domains and its parent domain.  Finally,
   it maintains a correct keyword routing table in order to handle
   registration and search request forwarding towards the correct
   domain.






Harsh & Newman            Expires May 20, 2010                  [Page 5]


Internet-Draft         Multicast Session Directory         November 2009


2.1.3.  DNS Server

   Proposed approach requires every domain's URS server to have an 'A'
   entry in the DNS Server database.  We suggest using an alias 'mcast'
   for the URS.  This enables a client to resolve the multicast session
   URI assigned under this scheme.  Upon successful resolution, a client
   has all the pertinent details that allow it to subscribe to the
   multicast session and start receiving the content stream, if one is
   active at that time.  We suggest that a client should not cache the
   session details received upon successful URI resolution, as they may
   change in future.  The URI itself could be bookmarked, as we foresee
   it to be long-lived.

2.1.4.  Client Tools

   Several end user clients that work with the service hierarchy can be
   provided depending on the functionality they support.  A session
   registration tool that allows a session creator to register its
   session is a must.  Tools that allow the intended receivers to search
   for candidate sessions and receive selected sessions may be provided.
   These functions may be combined as a single package or they may be
   implemented as separate packages.

2.2.  Workload Distribution (Key-Space Allotment)

   During session registration step, the registrant must provide a few
   keywords describing the session s/he is trying to register, in
   addition to other details.  These keywords later allow the multicast
   session to be reported to the end user in case s/he searched for
   sessions using one of the keywords the registrant provided.
   Currently the number of keywords that can be assigned to a multicast
   session is limited to a maximum of 10 keywords.  Each keyword is
   hashed using the MD5 hashing algorithm resulting in a 128 bit hash.
   This 128 bit hash value is used to route the registration and search
   queries to an appropriate MSD server.  In order to balance the data
   load at every designated MSD server participating in the service
   hierarchy, every domain is assigned a fraction of the overall keyword
   hash space for which the designated MSD server in that domain is
   responsible for maintaining the session registration database.












Harsh & Newman            Expires May 20, 2010                  [Page 6]


Internet-Draft         Multicast Session Directory         November 2009


                  +-------+ 8
                  |A      |
                  +-------+
 1                 1  |              5
    +-----------------+-----------------+
    |                 |                 |
+-------+         +-------+         +-------+
|B      |         |C      |         |D      |
+-------+         +-------+         +-------+
          1                 1           |     1                 1
             +-----------------+--------+--------+-----------------+
             |                 |                 |                 |
         +-------+         +-------+         +-------+         +-------+
         |F      |         |E      |         |G      |         |H      |
         +-------+         +-------+         +-------+         +-------+

   A simple domain hierarchy.

                                 Figure 1

   Each domain periodically reports to its parent domain.  The
   periodicity of this report is SELF_REPORT_CYCLE_TIME.  In the report,
   the total count of children domains including self is also sent.
   Refer to Figure 1, the number on top of every domain shows the domain
   count being reported to the parent domain.  This mechanism allows the
   root node to determine the total count of domains participating in
   the hierarchy.  It uses this information to approportion the overall
   keyword-hash space among itself and all the children domains.
   Ignoring the bias introduced by asymmetrical keyword usage frequency,
   this hash space division mechanism tries to distribute the database
   load evenly across all the participating domains.

2.3.  Hierarchy Setup and Maintenance

   Every MSD server contacts the domain local URS server to discover
   channel details of three different multicast channels:

   1.  MSD-LOCAL administratively scoped multicast channel (deprecated)

   2.  PMCAST - globally scoped (GLOP) multicast channel

   3.  CMCAST - globally scoped (GLOP) multicast channel

   If a network domain supports traditional ASM mode of multicast, MSD-
   LOCAL multicast channel may be used.  Its use is deprecated and all
   the functionality achieved using MSD-LOCAL channel can also be
   achieved over unicast.  MSD-LOCAL multicast channel is
   administratively scoped.  If used, all session registration and



Harsh & Newman            Expires May 20, 2010                  [Page 7]


Internet-Draft         Multicast Session Directory         November 2009


   search query requests as well as domain local control messages
   including leader election requests arrive at this multicast channel.
   Every MSD server in traditional ASM network may subscribe to this
   channel (deprecated).  The use of MSD-LOCAL channel is discouraged as
   such a communication channel can not be supported in a network that
   does not support shared distribution tree.

   PMCAST is an acronym for 'Parent Multicast'.  This is a globally
   scoped multicast channel belonging to the GLOP address range (IPv4).
   Therefore this address must be obtained from the ISP and configured
   into the URS server by the system administrator during URS startup.
   Any communication from the parent domain is received on this
   multicast channel provided a multicast path exists between the parent
   and the child domain.

   CMCAST is an acronym for 'Child Multicast'.  This is a globally
   scoped multicast channel belonging to the GLOP address range.
   Therefore this address must be obtained from the ISP and configured
   into the URS server by the system administrator during URS startup.
   Any communication to the children domains is sent on this multicast
   channel.

   Any communication to be sent to the parent domain by the children
   domains is done via unicast.  In the absence of a continuous
   multicast path from the parent domain to any child node, the top-down
   (parent to child) communication also resorts to IP unicast (upon
   notification by the affected child domain).

   Upon completion of the leader selection algorithm at every domain,
   the designated MSD server subscribes to the PMCAST multicast channel
   and uses the CMCAST channel to send any communication to the children
   domains.  In addition it may also subscribe to MSD-LOCAL channel
   (deprecated).  The values of PMCAST and CMCAST channels are set such
   that the CMCAST channel at the parent domain is same as the PMCAST
   channel at each child domain.  Figure 2 shows a very simple two level
   hierarchy with two domains, A and B. The CMCAST details at domain A
   are the same as PMCAST channel at domain B, thus enabling the two
   domains to form a hierarchy.  This scheme is replicated at all the
   domains thereby allowing multiple domains to join in a large scale
   global multicast session directory hierarchy.











Harsh & Newman            Expires May 20, 2010                  [Page 8]


Internet-Draft         Multicast Session Directory         November 2009


       +-----------------------Domain A----+
       |    +-------+         +-------+    |
       |    |URS    |         |MSD    |    |
       |    |Server |         |Server |    |
       |    +-------+         +-------+    |
       |        |                 |        |
       |        +--------+--------+        |
       |        |        |        |        |
       |    +-------+    O        |        |
       |    |DNS    |   /|\    CMCAST      |
       |    |Server |    |       \|/       |
       |    +-------+   / \       V        |
       |              User        |        |
       +----------------------    |    ----+
                         +----    |    ----------------------+
                         |     PMCAST                        |
                         |        |                          |
                         |    +-------+    |    +-------+    |
                      Domain  |MSD    |----+----|DNS    |    |
                         |    |Server |    |    |Server |    |
                      B  |    +-------+    |    +-------+    |
                         |    +-------+    |        O        |
                         |    |URS    |----+----   /|\       |
                         |    |Server |    |        |        |
                         |    +-------+    |       / \       |
                         |                       User        |
                         +-----------------------------------+

                                 Figure 2


3.  Session Records Structure

   Multicast session registration data are maintained as registration
   records in various databases maintained at MSD and URS servers.  In
   our scheme we make use of three types of records:

   1.  Domain local session database records - part of MSD database

   2.  Global session database records - part of MSD database

   3.  Multicast session records - part of URS database

   Administratively scoped multicast channels are registered only with
   the domain local MSD server that operates in the same domain as the
   multicast channels themselves.  No keyword hash based registration
   routing happens in this case.  The URS registers and maintains a
   record for every multicast session that originates in that domain



Harsh & Newman            Expires May 20, 2010                  [Page 9]


Internet-Draft         Multicast Session Directory         November 2009


   regardless of the scope of such multicast sessions.  In the
   subsections that follow, any mention of the word in parenthesis
   (optional) in the record structure must be read as being optional for
   the session creator to provide the value for that field.  Logically,
   there will be one record for each keyword for each session.  How the
   database is implemented is up to the MSD implementer.  The database
   must be capable of handling geo-specific searches as well.

3.1.  Domain local database session record

   As the title suggests the 'Domain local database session record'
   forms the basic data component of the database used to store the
   session details of all multicast sessions hosted in a given mDNS
   domain.

   o  Expiration Time - Time after which session record may be purged
      from the MSD database

   o  Start Time - Time before which a session may not exist

   o  Keyword - One of possibly several keywords used to tag this
      session

   o  URS Identifier - Unique session identifier registered with the URS
      Server

   o  Channel IP - Multicast session IP

   o  Channel Port - Multicast session port

   o  Source IP - if network type is SSM, this IP determines the content
      host machine

   o  Fail Over Unicast IP - backup unicast stream source IP address
      (optional)

   o  Fail Over Unicast Port - backup unicast stream port (optional),
      mandatory if 'Fail Over Unicast IP' is provided, must not be
      present if 'Fail Over Unicast IP' field is not present.

   o  Channel Scope - Multicast stream scope (global/local)

   o  Geographical Common Name - Common Name of the place associated
      with the stream

   o  Latitude - Latitude value associated with this session





Harsh & Newman            Expires May 20, 2010                 [Page 10]


Internet-Draft         Multicast Session Directory         November 2009


   o  Longitude - Longitudinal value associated with this session

   o  Network Type - multicast compatibility of the session's hosting
      network (ASM/SSM)

   o  Stream Type - identifies the type and nature of the multicast
      stream (optional)

   o  Preferred Application - Identifies the suggested application to be
      used to access the stream data (optional)

   o  Command Line Interface Arguments (CLI) - arguments to be supplied
      to the preferred application (optional)

   o  Mime Type - MIME type of the stream data (optional), must be one
      of the IANA registered MIME types

   The keyword, application name, and stream type in this scheme can
   contain only alpha-numeric symbols or the underscore character, and
   must begin with an alphabetic character.  The maximum size of any
   keyword is limited to 32 characters.  Expiration time is the absolute
   CPU time in seconds.  Stream Type currently could be one of these
   possible values:

      NULL if type not specified

      OTHER@value - 'value' is string literal describing the session

      Text Stream

      Video Stream

      Audio Stream

      Audio/Video Stream

      Conference

      Whiteboard

      Disaster Alert

      Weather Alert

      Network Alert

   Before storing/transmitting the stream type, preferred application
   and CLI arguments, their values are cleansed using character stuffing



Harsh & Newman            Expires May 20, 2010                 [Page 11]


Internet-Draft         Multicast Session Directory         November 2009


   where any occurrences of SPACE character [' '] or a new line
   character [\n] must be replaced with their HTML number codes [1] of
   the form [&#..;].  For example, a SPACE character [' '] must be
   replaced with  

3.2.  Global session database record

   This record structure describes the format of database element stored
   in the global session database.  This database is used to store
   details of sessions whose keywords lie in the hash space assigned to
   an MSD server.  Logically, there will be one record for each keyword
   for each session.  How the database is implemented is up to the MSD
   implementer.

   o  Keyword

   o  URI - URI of the URS server in the domain of the MSD server where
      the registration request was originated

   o  URS Identifier

   o  Expiration Time

   o  Latitude

   o  Longitude

   o  Network Type

   o  Stream Type

   o  Inversion Flag - this flag denotes whether the keyword hash-
      validity for storage is determined using regular MD5 hash value or
      the value computed using bit-inverted hash value

   The URI string must begin with the alias 'A' entry value for the URS
   server.  We suggest using 'mcast'.  Refer to Section 3.1 for details
   on record elements already mentioned there.

3.3.  URS Multicast Session Record

   URS multicast session records help in resolution of an mDNS URI
   assigned to a multicast session.  If a receiver uses a bookmarked
   mDNS URI string to access a session, the URI resolves to a URS server
   and the URS identifier part of the URI is used to locate the relevant
   multicast session record.  This contains all necessary parameters for
   the client to join the multicast group and start receiving the stream
   data.  The records structure is almost same as Section 3.1 with minor



Harsh & Newman            Expires May 20, 2010                 [Page 12]


Internet-Draft         Multicast Session Directory         November 2009


   differences.  Elements from Section 3.1 that are NOT maintained as
   part of a URS multicast session record are:

   o  Start Time

   o  Keyword

   See Section 3.1 for details of URS database record elements and their
   usage.


4.  Protocol Message Formats

   The proposed multicast session directory service uses both unicast as
   well as multicast to send/receive protocol messages.  These messages
   can be broadly categorized into two types:

   o  Data messages - related to end user activity and multicast
      sessions

   o  Control messages - used in establishment, maintenance, and upkeep
      of service hierarchy

   Unicast messages are transmitted using TCP or UDP datagrams.  The
   specified protocol will be clearly stated in this document wherever
   necessary.  The protocol messages are made of US-ASCII character
   streams unless otherwise stated.  Each message component is separated
   from others using a single SPACE character and every protocol message
   ends with a new line character [\n].  Further every message component
   in this document will be enclosed within square brackets [ ... ] for
   representation clarity, the square brackets [ ] do not themselves
   form part of the actual protocol field.  Protocol fields are case-
   insensitive unless otherwise noted.  Any occurrence of a space
   character [' '] or a new line character [\n] within a protocol field
   must be replaced with their HTML number codes of the form [&#..;].
   In the situation where the HTML number codes for SPACE and [\n]
   themselves appear in the protocol variable, they must be character
   stuffed by inserting their corresponding duplicate codes.

   Protocol messages before being processed by the corresponding mDNS
   network components must be converted to all lowercase symbols.

   Major network components are:

   1.  URL Registration Server

   2.  Session Registration Tool




Harsh & Newman            Expires May 20, 2010                 [Page 13]


Internet-Draft         Multicast Session Directory         November 2009


   3.  Multicast Session Directory Server

   4.  End User Search Tool

   Protocol messages' syntax for the above components are presented
   next.  The message purpose and actions (semantics) will be described
   in Section 5.

   Wherever MD5 hash is mentioned, we will assume the big-endian
   representation of the hash value is used so that the most significant
   bit is stored in the leftmost bit position. 128 bits of hash output
   will always be represented as 32 bytes of hexadecimal representation
   as a US-ASCII string.

   Every protocol field is constructed/interpreted using the US-ASCII
   character set unless otherwise stated.  Every protocol message
   described next is of the form:

   [Message Type] [Message Direction] [Number of Fields] [variable
   part][\n].

   [Message Type] is the constant string literal that specifies the type
   of the protocol message.  Refer to Table 1, Table 2, Section 4.4, and
   Table 4 for list of various [Message Type] values.

   [Message Direction] field is a 1 byte long field that contains the
   message transmission direction information.  This value is
   interpreted as a binary value and not as US-ASCII encoded string
   literal.  This field is set according to the rules described below:

      0x00 : Client to MSD Server - sent on MSD-LOCAL multicast channel

      0x01 : Client to URS Server - unicast

      0x02 : MSD Server to URS Server - unicast

      0x03 : URS Server to Client - unicast

      0x04 : MSD Server to MSD Server - sent on MSD-LOCAL channel

      0x05 : URS Server to URS Server - unicast

      0x06 : MSD Server to MSD Server - sent on CMCAST channel

      0x07 : MSD Server to Client - unicast (UDP)






Harsh & Newman            Expires May 20, 2010                 [Page 14]


Internet-Draft         Multicast Session Directory         November 2009


      0x08 : MSD Server to Client - unicast

      0x09 : URS Server to MSD Server - unicast

      0x0A : Client to MSD Server - unicast

      0x0B : MSD Server to MSD Server - unicast

      0x0C - 0xFF : Reserved

   [Number of Fields] protocol field denotes the count value of total
   number of variable message fields that follows after this field.  It
   is represented as an US-ASCII encoded decimal number.  This count
   excludes the mandatory [\n] terminating character.

   [variable part] represents the 0 or more SPACE delimited protocol
   fields present in a protocol message.  This is governed by the
   [Message Type] field.

4.1.  Common message fields

   Before describing the protocol syntax for various network components,
   we list here some of the frequently used protocol elements and their
   syntax and meaning.

      Syntax for IP addresses including [channel IP], [unicast IP],
      [source IP], [IP], and [msd IP] will be governed by the syntax
      specification for [IP address] given below.  Syntax for any time
      representations including [expiration time] and [start time]
      fields will be governed by the syntax specification for [Time]
      given below.  Syntax for all the port values including [unicast
      port], [msd port], [client port], [port], and [cached port] will
      be governed by the syntax specification for [port] given below.
      The syntax for keyword specified by [keyword] or for each
      individual \ keywords specified in [keyword list] is governed by
      the syntax specification for [keyword] specified below.

      [IP address] represents the dotted-decimal IP (IPv4) addresses or
      colon (:) separated IPv6 addresses.  This parameter if not
      provided must be set to 0.0.0.0.  If IPv6 addressing is used, it
      is represented as US-ASCII encoding of eight groups of four
      hexadecimal digits, where each group is separated by a colon (:).
      If no value is provided - IPv6 value must be set to
      '0:0:0:0:0:0:0:0'.  The maximum allowed size of this field is 16
      bytes (IPv4) or 40 bytes (IPv6).






Harsh & Newman            Expires May 20, 2010                 [Page 15]


Internet-Draft         Multicast Session Directory         November 2009


      [Time] represents the US-ASCII encoded UNIX time.  It is the
      elapsed time in seconds since midnight Jan 1, 1970.

      [port] represents the US-ASCII representation of the port value.
      If not set - the value is set to 0000 - four zeroes.  The maximum
      allowed size is 8 bytes (no comma ',' allowed).

      [char-set] represents the character encoding standard that is used
      to interpret the [URS-Identifier], [keyword] and [keyword list]
      fields.  It can be up to 16 bytes long and must be an IANA
      registered character set [2].  Wherever available a preferred MIME
      name must be used.  If preferred MIME name is not defined, then an
      MIB number may be used.  [RFC1345] [RFC3808]

      [keyword] can be up to 32 bytes long.  Interpretation of keywords
      are governed by [char-set].  Keywords must not contain any SPACE
      [' '] or comma (,) or (&) or (%) or (:) characters in them.

      [channel IP] represents the multicast channel group IP address.

      [channel port] represents the US-ASCII representation of the
      multicast group port value.  The maximum allowed size is 8 bytes
      (no comma ',' allowed).

      [Geographic CN] represents the common name for the geographical
      location associated with the channel.  Generally this will be the
      US-ASCII encoded city name.  SPACE in the name must be replaced by
      (_) an underscore character.

      [Lat] represents the US-ASCII representation of the latitude in
      the floating point decimal-degrees format [3].

      [Long] represents the US-ASCII representation of the longitude in
      the floating point decimal-degrees format [3].

      [unicast IP] represents the dotted-decimal fail-over unicast IP
      address for the multicast channel.  This field is optional.

      [unicast port] represents the fail-over unicast stream port value.
      This field is optional but must be provided if [unicast IP] value
      has been provided.

      [channel scope] represents the scope of the multicast channel.
      Must be either "local" or "global".







Harsh & Newman            Expires May 20, 2010                 [Page 16]


Internet-Draft         Multicast Session Directory         November 2009


      [URS-Identifier] is the registered unique session identifier whose
      session details are being sought.  It can be up to 32 bytes long
      and must not contain any SPACE character.  Its interpretation is
      governed by [char-set] value.

      [network type] represents the nature of multicast supported at the
      content host.  The value must be "asm" or "ssm".

      [source IP] represents the IP address of the host machine.

      [start time] represents the time before which the multicast
      session may not exist.

      [expiration time] represents the time after which the multicast
      session record may be erased.

      [preferred application] if set represents the name of the target
      application of the client machine that should be used to access
      this multicast stream.  It is set to 'null' if the value is not
      set by the content creator.  It can be maximum of 32 US-ASCII
      bytes long.  The interpretation of this field is left up to the
      implementers.

      [CLI argument] is the optional command line argument that could be
      supplied to the [preferred application] for accessing this
      multicast stream.  It must be US-ASCII encoded.  Any occurrence of
      SPACE or [\n] character must be replaced by the HTML number codes
      of the form [&#..;].  In the scenario where the HTML number codes
      for SPACE [' '] and [\n] themselves appear in the [CLI argument],
      they must be character stuffed by inserting their corresponding
      duplicate codes.  The maximum allowable size for [CLI argument] is
      128 bytes including any stuffed characters.

      [mime-type] represents the MIME encoding of the multicast stream.
      It may be used by the receiving application to interpret the
      stream correctly.  This protocol field is optional.  The value
      must be one of the IANA registered MIME types [4].  If this value
      is not set, then this value is set to 'null', US-ASCII
      representation of the word 'null'.

      [stream type] describes the nature of the multicast session data
      stream.  It is set to 'null' if the value is not set by the
      session creator.  It can take one of these possible values:

         null






Harsh & Newman            Expires May 20, 2010                 [Page 17]


Internet-Draft         Multicast Session Directory         November 2009


         text_stream

         video_stream

         audio_video_stream

         conference

         whiteboard

         disaster_alert

         weather_alert

         network_alert

         other@[value]

      If [stream type] 'other' is set then [value] after @ specifies the
      type of the session. [value] must not contain any SPACE or [\n]
      character in it.  This [stream type] field can be a maximum of 32
      US-ASCII bytes long.

4.2.  URL Registration Server - Message Formats

   +-----------------------+--------------+-----------+----------------+
   | Message Type          |    Message   | Number of |       Variable |
   |                       |   Direction  |   Fields  |     Parameters |
   +-----------------------+--------------+-----------+----------------+
   | bye                   |   0x01 0x02  |     0     |           none |
   |                       |   0x03 0x05  |           |                |
   |                       |     0x09     |           |                |
   | query                 |     0x01     |     2     |    see details |
   | query-response        |     0x03     |     1     |           null |
   | query-response        |     0x03     |     17    |    see details |
   | check                 |     0x01     |     2     |    see details |
   | check-response        |     0x03     |     1     |   true / false |
   | register              |     0x01     |     17    |    see details |
   | register-status       |     0x03     |     1     |   true / false |
   | request               |   0x01 0x02  |     1     |  mcast_param / |
   |                       |     0x05     |           |     designated |
   | request-response      |   0x03 0x05  |  11 or 3  |    see details |
   |                       |     0x09     |           |                |
   | unicast-update        |     0x02     |     3     |    see details |
   | unicast-update-status |     0x09     |     1     |   true / false |
   | resync                |     0x02     |     0     |           none |
   | resync-status         |     0x09     |   1 or 3  |    see details |
   +-----------------------+--------------+-----------+----------------+



Harsh & Newman            Expires May 20, 2010                 [Page 18]


Internet-Draft         Multicast Session Directory         November 2009


    Summary of [message types] and possible [message direction] values
                             for a URS server.

                                  Table 1

   Table 1 shows the summary of all the message types processed by any
   URS server.  We present the detailed syntax of each of the protocol
   messages next.  Wherever the fields [true] or [false] appear, they
   stand for the US-ASCII encoding of words 'true' and 'false'.

4.2.1.  bye

   [bye] [message direction] [0][\n]

   See Table 1 for possible [message direction] values.

4.2.2.  query

   [query] [0x01] [2] [char-set] [URS-Identifier][\n]

   See Section 4.1 for more details on the interpretation of the fields.

4.2.3.  query-response

   URS server could send two types of [query-response] protocol
   messages.  Both are described next.

4.2.3.1.  query-response - type 1

   [query-response] [0x03] [1] [null][\n]

   [null] is US-ASCII representation of the word 'null'.

4.2.3.2.  query-response - type 2

   [query-response] [0x03] [17] [char-set] [channel IP] [channel port]
   [Geographic CN] [Lat] [Long] [unicast IP] [unicast port] [channel
   scope] [URS-Identifier] [expiration time] [network type] [source IP]
   [stream type] [preferred application] [CLI argument] [mime-type][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

4.2.4.  check

   [check] [0x01] [2] [char-set] [keyword][\n]

   See Section 4.1 for more details on the interpretation of the fields.



Harsh & Newman            Expires May 20, 2010                 [Page 19]


Internet-Draft         Multicast Session Directory         November 2009


   [keyword] represents the element that is to be checked against all
   registered URS-Identifiers so find whether this value can be
   registered as an URS-Identifier.

4.2.5.  check-response

   [check-response] [0x03] [1] [true][\n]

   [check-response] [0x03] [1] [false][\n]

4.2.6.  register

   [register] [0x01] [17] [char-set] [expiration time] [URS-Identifier]
   [channel IP] [channel port] [unicast IP] [unicast port] [channel
   scope] [Geographic CN] [Lat] [Long] [network type] [source IP]
   [stream type] [preferred application] [CLI argument] [mime-type][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

4.2.7.  register-status

   [register-status] [0x03] [1] [true][\n]

   [register-status] [0x03] [1] [false][\n]

4.2.8.  request

   URS server can handle two kinds of [request] messages, both are
   described next.

4.2.8.1.  request - type 1

   [request] [message-direction] [1] [mcast_param][\n]

4.2.8.2.  request - type 2

   [request] [message-direction] [1] [designated][\n]

   See Table 1 for possible [message direction] values.

4.2.9.  request-response

   MSD server can return two kinds of [request-response] messages, both
   are discussed next.






Harsh & Newman            Expires May 20, 2010                 [Page 20]


Internet-Draft         Multicast Session Directory         November 2009


4.2.9.1.  request-response - type 1

   [request-response] [message-direction] [11] [mcast_param] [cmcast IP]
   [cmcast port] [pmcast IP] [pmcast port] [pmcast source IP] [msd-local
   IP] [msd-local port] [msd IP] [msd port] [IGMP version][\n]

   See Table 1 for possible [message direction] values.

   [mcast_param] is the US-ASCII representation of the string constant
   'mcast_param'.

   [cmcast IP] is the child multicast channel IP address.

   [cmcast port] is the US-ASCII representation of the child multicast
   channel port value.

   [pmcast IP] is the parent multicast channel IP address.

   [pmcast port] is the US-ASCII representation of the parent multicast
   channel port value.

   [pmcast source IP] is the unicast IP of the designated MSD server in
   the parent domain.

   [msd-local IP] is the MSD-LOCAL multicast channel IP address.  This
   field is deprecated.

   [msd-local port] is the US-ASCII representation of the MSD-LOCAL
   channel port value.  This field is deprecated.

   [msd IP] is the unicast server IP running at the designated MSD
   server in that domain.

   [msd port] is the port value of the unicast server running at the
   designated MSD server in that domain.

   [IGMP version] tells the IGMP version supported by the network
   multicast routers in this domain.  This value could be 1, 2, or 3.

4.2.9.2.  request-response - type 2

   [request-response] [message-direction] [3] [designated] [msd IP] [msd
   port][\n]

   See Table 1 for possible [message direction] values.

   [designated] is the US-ASCII representation of the string constant
   'designated'.



Harsh & Newman            Expires May 20, 2010                 [Page 21]


Internet-Draft         Multicast Session Directory         November 2009


   [msd IP] is the unicast server IP running at the designated MSD
   server in this domain.

   [msd port] is the port value of the unicast server running at the
   designated MSD server in thais domain.

4.2.10.  unicast-update

   [unicast-update] [0x02] [3] [idhash] [msd IP] [msd port][\n]

   [idhash] is the US-ASCII representation of the unique ID of the MSD
   server sending this message.  The maximum size of this field could be
   32 bytes.  This is generally set to the MD5 hash of the MSD domain
   URI string represented as hexadecimal US-ASCII encoded character
   string of 32 bytes.

   [msd IP] is the unicast server IP running at the designated MSD
   server in that domain.

   [msd port] is the port value of the unicast server running at the
   designated MSD server in that domain.

4.2.11.  unicast-update-status

   [unicast-update-status] [0x09] [1] [true][\n]

   [unicast-update-status] [0x09] [1] [false][\n]

4.2.12.  resync

   [resync] [0x02] [0][\n]

4.2.13.  resync-status

   URS server can send two kinds of [resync-status] protocol messages.
   Both are described below -

4.2.13.1.  resync-status - type 1

   [resync-status] [0x09] [1] [false][\n]

4.2.13.2.  resync-status - type 2

   [resync-status] [0x09] [3] [true] [msd IP] [msd port][\n]

   [msd IP] is the unicast server IP running at the designated MSD
   server in that domain.




Harsh & Newman            Expires May 20, 2010                 [Page 22]


Internet-Draft         Multicast Session Directory         November 2009


   [msd port] is the port value of the unicast server running at the
   designated MSD server in that domain.

4.3.  Session Registration Tool - Message Formats

   Table 2 shows the summary of all the message types processed by any
   session registration tool.  The detailed syntax of each of the
   protocol messages is given in the following sub-sections.  Wherever
   the fields [true] or [false] appear, they stand for the US-ASCII
   encoding of words 'true' and 'false'.

   +------------------+----------------+-------------+-----------------+
   | Message Type     |     Message    |  Number of  |        Variable |
   |                  |    Direction   |    Fields   |      Parameters |
   +------------------+----------------+-------------+-----------------+
   | bye              | 0x01 0x03 0x08 |      0      |            none |
   |                  |      0x0A      |             |                 |
   | check            |      0x01      |      2      |     see details |
   | check-response   |      0x03      |      1      |    true / false |
   | register         |    0x0A 0x01   |   19 or 17  |     see details |
   | register-status  |    0x03 0x08   |      1      |    true / false |
   | request          |      0x01      |      1      |      designated |
   | request-response |      0x03      |      3      |     see details |
   +------------------+----------------+-------------+-----------------+

    Summary of [message types] and possible [message direction] values
              handled by a client session registration tool.

                                  Table 2

4.3.1.  bye

   [bye] [message direction] [0][\n]

   Refer to Table 2 for possible values of [message direction] field.

4.3.2.  check

   [check] [0x01] [2] [char-set] [keyword][\n]

   See Section 4.1 for more details on the interpretation of the fields.

   [keyword] represents the element that is to be checked against all
   registered URS-Identifiers so find whether this value can be
   registered as an URS-Identifier.






Harsh & Newman            Expires May 20, 2010                 [Page 23]


Internet-Draft         Multicast Session Directory         November 2009


4.3.3.  check-response

   [check-response] [0x03] [1] [true][\n]

   [check-response] [0x03] [1] [false][\n]

4.3.4.  register

   Session registration tool has to process two different types of
   [register] protocol messages, both are described next.

4.3.4.1.  register - type 1

   [register] [0x0A] [19] [char-set] [expiration time] [start time] [URS
   Identifier] [channel IP] [channel port] [unicast IP] [unicast port]
   [channel scope] [Geographic CN] [Lat] [Long] [keyword list] [network
   type] [source IP] [stream type] [preferred application] [CLI
   argument] [mime-type][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [start time] represents the time before which the multicast session
   may not exist.

   [keyword list] is the comma (,) separated list of keywords provided
   by the session creator to tag the multicast session.  Up to a total
   of 10 keywords are allowed.

4.3.4.2.  register - type 2

   [register] [0x01] [17] [char-set] [expiration time] [URS-Identifier]
   [channel IP] [channel port] [unicast IP] [unicast port] [channel
   scope] [Geographic CN] [Lat] [Long] [network type] [source IP]
   [stream type] [preferred application] [CLI argument] [mime-type][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

4.3.5.  register-status

   [register-status] [message-direction] [1] [true][\n]

   [register-status] [message-direction] [1] [false][\n]

   Refer to Table 2 for possible values of [message direction] field.





Harsh & Newman            Expires May 20, 2010                 [Page 24]


Internet-Draft         Multicast Session Directory         November 2009


4.3.6.  request

   [request] [0x01] [1] [designated][\n]

   [designated] is the US-ASCII representation of the string constant
   'designated'.

4.3.7.  request-response

   [request-response] [0x03] [3] [designated] [msd IP] [msd port][\n]

   [designated] is the US-ASCII representation of the string constant
   'designated'.

   [msd IP] is the unicast server IP running at the designated MSD
   server in that domain.

   [msd port] is the port value of the unicast server running at the
   designated MSD server in that domain.
































Harsh & Newman            Expires May 20, 2010                 [Page 25]


Internet-Draft         Multicast Session Directory         November 2009


4.4.  Multicast Session Directory Server - Message Formats

   +---------------------+----------+--------+-------------+-----------+
   | Message Type        | Directio | No. of |   Variable  |  Category |
   |                     | n  Bits  | Fields |  Parameters |           |
   +---------------------+----------+--------+-------------+-----------+
   | register            |   0x0A   |   19   |     ...     | user/data |
   | register-status     |   0x08   |    1   |  true/false | user/data |
   | remote-register     |   0x06   |   10   |     ...     | user/data |
   |                     |   0x0B   |        |             |           |
   | invalidate          |   0x0A   |    7   |     ...     | user/data |
   | msd-probe           |   0x06   |    6   |     ...     | user/data |
   |                     |   0x0B   |        |             |           |
   | msd-probe-reply     |   0x0B   |    5   |     ...     | user/data |
   | search              |   0x0A   |    3   |     ...     | user/data |
   | redirect            |   0x07   |    5   |     ...     | user/data |
   | hello               |   0x0B   |    5   |     ...     |   control |
   | rep-hello           |   0x06   |    3   |     ...     |   control |
   |                     |   0x0B   |        |             |           |
   | unicast-update      |   0x02   |    3   |     ...     |   control |
   | unicast-update-stat |   0x09   |    1   |  true/false |   control |
   | us                  |          |        |             |           |
   | dsearch             |   0x0A   |    2   |     ...     | user/data |
   | bye                 |   0x02   |    0   |     none    | user/data |
   |                     |   0x08   |        |             |           |
   |                     |   0x09   |        |             |           |
   |                     |   0x0A   |        |             |           |
   | ext-search          |   0x0A   |    5   |     ...     | user/data |
   | null-space          |   0x06   |    1   |   ID-Hash   |   control |
   |                     |   0x0B   |        |             |           |
   | add-space           |   0x06   |    4   |     ...     |   control |
   |                     |   0x0B   |        |             |           |
   | ext-search-invalid  |   0x08   |    2   |     ...     | user/data |
   | search-response     |   0x07   |  11 or |     ...     | user/data |
   |                     |          |   17   |             |           |
   | ext-search-response |   0x08   |   11   |     ...     | user/data |
   | tx-end              |   0x07   |    3   |     ...     | user/data |
   |                     |   0x08   |        |             |           |
   | resync              |   0x02   |    0   |     none    |   control |
   | resync-status       |   0x09   | 1 or 3 |     ...     |   control |
   | request             |   0x02   |    1   | mcast_param |   control |
   | request-response    |   0x09   |   11   |     ...     |   control |
   | get-backup-msd      |   0x0A   |    4   |     ...     | user/data |
   +---------------------+----------+--------+-------------+-----------+

   [message types] and [message direction] values used at an MSD server.

                                  Table 3



Harsh & Newman            Expires May 20, 2010                 [Page 26]


Internet-Draft         Multicast Session Directory         November 2009


   MSD servers handle the majority of protocol messages.  For
   convenience we have clubbed these messages under two categories
   namely:

   o  Control messages - protocol messages that are used in construction
      and maintenance of the global service hierarchy.

   o  Data / User messages - protocol messages dealing with user
      activity including session registration, query, etc.

   The use of MSD-LOCAL multicast channel for communication among intra-
   domain mDNS components is discouraged (deprecated).  Any protocol
   message that is sent with [message-direction] bits set to [0x04] is
   deprecated.  We present the detailed syntax of each of the protocol
   messages next.  Wherever the fields [true] or [false] appear, they
   stand for the US-ASCII encoding of words 'true' and 'false'.

4.4.1.  register

   [register] [0x0A] [19] [char-set] [expiration time] [start time] [URS
   Identifier] [channel IP] [channel port] [unicast IP] [unicast port]
   [channel scope] [Geographic CN] [Lat] [Long] [keyword list] [network
   type] [source IP] [stream type] [preferred application] [CLI
   argument] [mime-type][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [keyword list] is the comma (,) separated list of keywords provided
   by the session creator to tag the multicast session.  Up to a total
   of 10 keywords are allowed.

4.4.2.  register-status

   [register-status] [0x08] [1] [true][\n]

   [register-status] [0x08] [1] [false][\n]

4.4.3.  remote-register

   [remote-register] [message-direction] [10] [char-set] [URS-
   Identifier] [keyword] [host URI] [expiration time] [Lat] [Long]
   [network type] [stream type] [inversion flag][\n]

   Refer to Table 3 for possible values of [message direction] field.

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.



Harsh & Newman            Expires May 20, 2010                 [Page 27]


Internet-Draft         Multicast Session Directory         November 2009


   [keyword] is that keyword for which the MD5 hash routing resulted in
   registration to be forwarded to a domain external to the originating
   mDNS domain.

   [host URI] is the URI string of the URS server in the original domain
   where the session registration request was first sent.

   [inversion flag] must be set to 'true' or 'false'.  This represents
   whether the message routing is to be done based on actual [keyword]
   hash value or using inverted bits of the hash value.

4.4.4.  invalidate

   [invalidate] [0x0A] [7] [char-set] [keyword] [cached IP] [cached
   port] [IP] [port] [inversion flag][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [keyword] represents the cached remote MSD server's entry at the
   domain local MSD server cache that has to be invalidated.

   [cached IP] is the unicast IP address of the remote MSD server that
   has to be invalidated.

   [cached port] is the port value of the unicast server running at the
   remote MSD server whose cached value is to be invalidated.

   [IP] is the unicast IP address of the client that requested this
   invalidation.  This is the IP address where the new MSD connection
   details are to be sent once the cached entry is refreshed.

   [port] is the port value of the unicast server running at the client
   that requested the cache invalidation.  This forms the part of the
   reply-back address for sending the new MSD connection details to the
   requesting client.

   [inversion flag] must be set to 'true' or 'false'.  This represents
   whether the regular MSD server cache entry has to be invalidated or
   the inversion-cache entry has to be invalidated.

4.4.5.  msd-probe

   [msd-probe] [message-direction] [6] [char-set] [keyword] [msd IP]
   [msd port] [hop count] [inversion flag][\n]

   Refer to Table 3 for possible values of [message direction] field.




Harsh & Newman            Expires May 20, 2010                 [Page 28]


Internet-Draft         Multicast Session Directory         November 2009


   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [keyword] represents the session keyword for which the target MSD
   connection details are being sought.

   [msd IP] is the IP address of the MSD server where the [invalidate]
   protocol message was originally received.

   [msd port] is the port value of the unicast server running at the MSD
   server where the [invalidate] protocol message was originally
   received.

   [hop count] is the US-ASCII representation of the number of domains
   traversed so far from the mDNS domain where this [msd-probe] message
   originated.

   [inversion flag] must be set to 'true' or 'false'.  This represents
   whether the message routing is to be done based on actual [keyword]
   hash value or using inverted bits of the hash value.

4.4.6.  msd-probe-reply

   [msd-probe-reply] [0x0B] [6] [char-set] [keyword] [msd IP] [msd port]
   [hop count] [inversion flag][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [keyword] represents the session keyword for which the target MSD
   connection details are being sought.

   [msd IP] is the unicast address of the designated MSD server that
   generates this protocol message.

   [msd port] is the port value of the unicast server running at the
   designated MSD server that generates this protocol message.

   [hop count] is the US-ASCII representation of the number of domains
   traversed so far from the mDNS domain where the [msd-probe] message
   originated that resulted in generation of this protocol message.

   [inversion flag] must be set to 'true' or 'false'.  This value is
   simply copied from the original [msd-probe] protocol message.







Harsh & Newman            Expires May 20, 2010                 [Page 29]


Internet-Draft         Multicast Session Directory         November 2009


4.4.7.  search

   [search] [0x0A] [3] [char-set] [parameter] [client port][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [parameter] refers to the search parameter string.  The format of the
   parameter string can be described using BNF regular expression -

   keyword(:keyword)*(&keyword(:keyword)*)*%local-scope:global-scope
   (%lat:long%radius)?

   Any occurrence of [:] is the US-ASCII representation of COLON
   character, [&] is the US-ASCII encoding for AMPERSAND and [%] is the
   US-ASCII encoding for PERCENT symbol in the [parameter] field. local-
   scope is set to 'yes' if administratively scoped sessions are to be
   included in the search result otherwise it must be set to 'no'.
   Similarly 'yes' or 'no' must be set for the global-scope placeholder
   in the [parameter] element.  At least one must be set 'yes'. lat and
   long represents the US-ASCII encoding of the latitude and longitude
   values (represented as a floating point number) of the search
   epicenter and radius is the search radius from the epicenter in
   kilometers (km). lat, long, and radius [parameter] sub-components are
   optional.  Any keyword must be interpreted using the syntax rules for
   [keyword] already described above

   [client port] is the port value of the unicast server running at the
   client that can be used to send locally scoped and other search
   results from the domain local MSD server asynchronously and in a non-
   blocking manner.

4.4.8.  redirect

   [redirect] [0x07] [5] [char-set] [keyword] [msd IP] [msd port] [hop
   count][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [keyword] is the search keyword whose MD5 hash lies beyond the hash-
   space managed by the client's domain local MSD server.

   [msd IP] is the unicast address of the target MSD server that manages
   the hash space in which the [keyword] hash lies.

   [msd port] is the port value of the unicast server running at the
   target MSD server.



Harsh & Newman            Expires May 20, 2010                 [Page 30]


Internet-Draft         Multicast Session Directory         November 2009


   [hop count] is the US-ASCII encoded number that represents the count
   of domain traversed including the current MSD domain.

4.4.9.  hello

   [hello] [0x0B] [5] [domain count] [ID hash] [msd IP] [msd port]
   [pmcast status][\n]

   [domain count] is the US-ASCII encoded number that represents the
   count of domains rooted at the reporting domain including itself to
   be sent to the parent node.

   [ID hash] is the 32 byte US-ASCII encoded hexadecimal string
   representing the unique ID assigned to the reporting domain.

   [msd IP] is the unicast IP address of the designated MSD server
   sending this protocol message.

   [msd port] is the port number of the unicast server running at the
   designated MSD server.

   [pmcast status] is set to 'true' if the child domain is receiving
   communications from the parent MSD server on its PMCAST channel.  If
   no communication is received on this channel for 2 timeout intervals
   (60 seconds) this parameter is set to 'false' to notify the parent
   node of failure to receive any communication on the child node's
   PMCAST channel.

4.4.10.  rep-hello

   [rep-hello] [message direction] [3] [ID hash] [address start]
   [address end][\n]

   Refer to Table 3 for possible values of [message direction] field.

   [ID hash] is the 32 byte US-ASCII encoded hexadecimal string
   representing the unique ID assigned to the sending domain.

   [address start] is the 32 byte US-ASCII encoded hexadecimal
   representation of the start value of the keyword address space
   delegated to this node by its parent node.  If this is the root node
   then this value is all '0' zeroes.

   [address end] is the 32 byte US-ASCII encoded hexadecimal
   representation of the end value of the keyword address space
   delegated to this node by its parent node.  If this is the root node
   then this value is all 'F's.




Harsh & Newman            Expires May 20, 2010                 [Page 31]


Internet-Draft         Multicast Session Directory         November 2009


   The keyword address space related fields does not correspond to any
   assignment at any of the children node.  It just signifies the total
   range of key-space managed by the subtree rooted at the reporting
   domain.

4.4.11.  unicast-update

   [unicast-update] [0x02] [3] [ID hash] [msd IP] [msd port][\n]

   [ID hash] is the 32 byte US-ASCII encoded hexadecimal string
   representing the unique ID assigned to the sending domain.

   [msd IP] is the unicast IP address of the designated MSD server
   sending this protocol message.

   [msd port] is the port number of the unicast server running at the
   designated MSD server.

4.4.12.  unicast-update-status

   [unicast-update-status] [0x09] [1] [true][\n]

   [unicast-update-status] [0x09] [1] [false][\n]

4.4.13.  dsearch

   [dsearch] [0x0A] [2] [char-set] [parameter][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [parameter] is the domain specific search parameter sent by the end-
   user on which the receiving MSD server acts.  The format of the
   parameter string can be described using the following BNF regular
   expression:

   keyword(:keyword)*(&keyword(:keyword)*)*

   Any occurrence of [:] is the US-ASCII representation of COLON
   character, [&] is the US-ASCII encoding for AMPERSAND in the
   [parameter] field.  Any keyword must be interpreted using the syntax
   rules for [keyword] already described above.  Session scope 'global'
   is assumed while performing the search operation.

4.4.14.  bye

   [bye] [message direction] [0][\n]




Harsh & Newman            Expires May 20, 2010                 [Page 32]


Internet-Draft         Multicast Session Directory         November 2009


   Refer to Table 3 for possible values of [message direction] field.

4.4.15.  ext-search

   [ext-search] [0x0A] [5] [char-set] [parameter] [IP] [port] [inversion
   flag][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [parameter] can be specified by the BNF regular expression -

   keyword(%lat:long%radius)?

   lat and long represents the US-ASCII encoding of the latitude and
   longitude values (represented as a floating point number) of the
   search epicenter and radius is the search radius from the epicenter
   in kilometers (km). lat, long and radius [parameter] sub-components
   are optional.  Search scope 'global' only is assumed.  Any keyword
   must be interpreted using the syntax rules for [keyword] already
   described above.

   [IP] is the unicast IP address of the client that sent this message.
   This is the IP address where the search results are to be sent by the
   target MSD server where the query was sent.

   [port] is the port value of the unicast server running at the client
   that requested [ext-search] operation.  This forms the part of the
   reply-back address for sending the search results to the requesting
   client.

   [inversion flag] must be set to 'true' or 'false'.  This represents
   whether the message routing is to be done based on actual [keyword]
   hash value or if using inverted bits of the hash value.

4.4.16.  null-space

   [null-space] [message direction] [1] [ID hash][\n]

   Refer to Table 3 for possible values of [message direction] field.

   [ID hash] is the 32 byte US-ASCII encoded hexadecimal string
   representing the unique ID of the domain for which this protocol
   message is intended for.







Harsh & Newman            Expires May 20, 2010                 [Page 33]


Internet-Draft         Multicast Session Directory         November 2009


4.4.17.  add-space

   [add-space] [message direction] [4] [range start] [range end]
   [significant bits] [ID hash][\n]

   Refer to Table 3 for possible values of [message direction] field.

   [range start] is the start value of the allotted keyword hash space,
   the value is computed using only the leftmost [significant] bits of
   the hash range.  It is US-ASCII encoded integer number value.

   [range end] is the end value of the allotted keyword hash space, the
   value is computed using only the leftmost [significant] bits of the
   hash range.  It is US-ASCII encoded integer number value.

   [significant bits] is the US-ASCII encoding of the number of leftmost
   bits of the MD5 hash that are used for routing purposes.

4.4.18.  ext-search-invalid

   [ext-search-invalid] [0x08] [2] [char-set] [keyword][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [keyword] represents the keyword for which the MD5 hash value does
   not lie within this MSD server's managed space and hence the [ext-
   search] request can not be processed.

4.4.19.  search-response

   MSD server can send two kinds of [search-response] protocol messages
   depending on the scope of the session's record being sent.  These
   message are described next -

4.4.19.1.  search-response - type 1

   [search-response] [0x07] [11] [char-set] [global] [keyword] [domain
   URI] [URS Identifier] [expiration time] [Lat] [Long] [network type]
   [stream type] [hop count][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [global] is the US-ASCII encoding of the string constant 'global'.

   [keyword] is the search keyword for which one or more of this message
   is sent back to the requesting client.



Harsh & Newman            Expires May 20, 2010                 [Page 34]


Internet-Draft         Multicast Session Directory         November 2009


   [domain URI] is the US-ASCII encoding of the domain URL string of the
   URS server in the target domain where the session record being sent
   as part of this protocol message was originally registered.

   [hop count] is the US-ASCII encoded number that represents the count
   of domain traversed including the current MSD domain.

4.4.19.2.  search-response - type 2

   [search-response] [0x07] [17] [char-set] [local] [keyword] [channel
   IP] [channel port] [channel scope] [Geographical CN] [Lat] [Long]
   [network type] [source IP] [stream type] [preferred application] [CLI
   argument] [unicast IP] [unicast port] [hop count][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [local] is the US-ASCII encoding of the string constant 'local'.

   [keyword] is the search keyword for which one or more of this message
   is sent back to the requesting client.

   [hop count] is the US-ASCII encoded number that represents the count
   of domain traversed including the current MSD domain.

4.4.20.  ext-search-response

   [ext-search-response] [0x08] [11] [char-set] [global] [keyword]
   [domain URI] [URS Identifier] [expiration time] [Lat] [Long] [network
   type] [stream type] [hop count][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   For definition of other fields see Section 4.4.19.1 as the syntax and
   interpretation of these protocol fields are the same.

4.4.21.  tx-end

   [tx-end] [message direction] [3] [char-set] [keyword] [tag][\n]

   Refer to Table 3 for possible values of [message direction] field.

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [keyword] is the search keyword for which this [tx-end] is being sent
   indicating the end of sequence of transmission of zero or more



Harsh & Newman            Expires May 20, 2010                 [Page 35]


Internet-Draft         Multicast Session Directory         November 2009


   [search-response] or [ext-search-response] messages for each
   candidate multicast record.

   [tag] is the US-ASCII encoded string constant 'dext' or 'dint'.
   'dext' is sent to signal the end of transmission sequence for
   globally scoped multicast session records.  Similarly 'dint' is sent
   to signal the end of transmission sequence for administratively
   scoped multicast sessions.

4.4.22.  resync

   [resync] [0x02] [0][\n]

4.4.23.  resync-status

   MSD server can process two different kinds of [resync-status]
   protocol messages.  Both kinds are described next.

4.4.23.1.  resync-status - type 1

   [resync-status] [0x09] [1] [false][\n]

4.4.23.2.  resync-status - type 2

   [resync-status] [0x09] [3] [true] [msd IP] [msd port][\n]

   [msd IP] is the unicast server IP running at the designated MSD
   server in the parent domain.

   [msd port] is the port value of the unicast server running at the
   designated MSD server in the parent domain.

4.4.24.  request

   [request] [0x02] [1] [mcast_param][\n]

   [mcast_param] is the US-ASCII encoding of the string constant
   'mcast_param'.

4.4.25.  request-response

   [request-response] [0x09] [11] [mcast_param] [cmcast IP] [cmcast
   port] [pmcast IP] [pmcast port] [pmcast source IP] [msd-local IP]
   [msd-local port] [msd IP] [msd port] [IGMP version][\n]

   [mcast_param] is the US-ASCII encoding of the string constant
   'mcast_param'.




Harsh & Newman            Expires May 20, 2010                 [Page 36]


Internet-Draft         Multicast Session Directory         November 2009


   [cmcast IP] is the child multicast channel IP address.  Syntax is
   same as [IP address] described in Section 4.1.

   [cmcast port] is the US-ASCII representation of the child multicast
   channel port value.  Syntax is same as [port] described in
   Section 4.1.

   [pmcast IP] is the parent multicast channel IP address.  Syntax is
   same as [IP address] described in Section 4.1.

   [pmcast port] is the US-ASCII representation of the parent multicast
   channel port value.  Syntax is same as [port] described in
   Section 4.1.

   [pmcast source IP] is the unicast IP of the designated MSD server in
   the parent domain.  Syntax is same as [IP address] described in
   Section 4.1.

   [msd-local IP] is the MSD-LOCAL multicast channel IP address.  This
   field is deprecated.  Syntax is same as [IP address] described in
   Section 4.1.

   [msd-local port] is the US-ASCII representation of the MSD-LOCAL
   channel port value.  This field is deprecated.  Syntax is same as
   [port] described in Section 4.1.

   [msd IP] is the unicast server IP running at the designated MSD
   server in this domain.

   [msd port] is the port value of the unicast server running at the
   designated MSD server in this domain.

   [IGMP version] tells the IGMP version supported by the network
   multicast routers in this domain.  This value could be the US-ASCII
   representation of numbers 1, 2, or 3.

4.4.26.  get-backup-msd

   [get-backup-msd] [0x0A] [4] [char-set] [keyword] [IP] [port][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [keyword] represents the search key for which the search client
   experienced a response timeout.

   [IP] is the unicast IP address of the client that sent this message.
   This is the IP address where the new MSD connection details are to be



Harsh & Newman            Expires May 20, 2010                 [Page 37]


Internet-Draft         Multicast Session Directory         November 2009


   sent once the target MSD is located.

   [port] is the port value of the unicast server running at the client
   that requested the cache invalidation.  This forms the part of the
   reply-back address for sending the new MSD connection details to the
   requesting client.

4.5.  End User Search Tool - Message Formats

   Table 4 shows the summary of all the message types processed by any
   end user search browser.  We present the detailed syntax of each of
   the protocol messages next.  Wherever the fields [true] or [false]
   appear, they stand for the US-ASCII encoding of words 'true' and
   'false'.

   +---------------------+--------------+------------+-----------------+
   | Message Type        |    Message   |  Number of |        Variable |
   |                     |   Direction  |   Fields   |      Parameters |
   +---------------------+--------------+------------+-----------------+
   | request             |     0x01     |      1     |   mcast_param / |
   |                     |              |            |      designated |
   | request-response    |     0x03     |   11 or 3  |     see details |
   | query               |     0x01     |      2     |     see details |
   | query-response      |     0x03     |      1     |            null |
   | query-response      |     0x03     |     17     |     see details |
   | dsearch             |     0x0A     |      2     |     see details |
   | search              |     0x0A     |      3     |     see details |
   | redirect            |     0x07     |      5     |     see details |
   | ext-search          |     0x0A     |      5     |     see details |
   | bye                 |   0x01 0x03  |      0     |            none |
   |                     |   0x08 0x0A  |            |                 |
   | ext-search-invalid  |     0x08     |      2     |     see details |
   | invalidate          |     0x0A     |      6     |     see details |
   | search-response     |     0x07     |  11 or 17  |     see details |
   | ext-search-response |     0x08     |     11     |     see details |
   | tx-end              |   0x07 0x08  |      3     |     see details |
   | get-backup-msd      |     0x0A     |      4     |     see details |
   +---------------------+--------------+------------+-----------------+

    Summary of [message types] and possible [message direction] values
            handled by an end user session search browser tool.

                                  Table 4








Harsh & Newman            Expires May 20, 2010                 [Page 38]


Internet-Draft         Multicast Session Directory         November 2009


4.5.1.  request

   [request] [0x01] [1] [mcast_param][\n]

   [request] [0x01] [1] [designated][\n]

   [mcast_param] is the US-ASCII encoded string constant 'mcast_param'.

   [designated] is the US-ASCII encoded string constant 'designated'.

4.5.2.  request-response

   The search client can process two kinds of [request-response]
   protocol messages.  Both are described next.

4.5.2.1.  request-response - type 1

   [request-response] [0x03] [11] [mcast_param] [cmcast IP] [cmcast
   port] [pmcast IP] [pmcast port] [pmcast source IP] [msd-local IP]
   [msd-local port] [msd IP] [msd port] [IGMP version][\n]

   See Section 4.2.9.1 for more details on the interpretation of the
   protocol fields.

4.5.2.2.  request-response - type 2

   [request-response] [0x03] [3] [designated] [msd IP] [msd port][\n]

   See Section 4.2.9.2 for more details on the interpretation of the
   protocol fields.

4.5.3.  query

   [query] [0x01] [2] [char-set] [URS-Identifier][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

4.5.4.  query-response

   The search tool can process two kinds of [query-response] protocol
   messages.  Both are described next.

4.5.4.1.  query-response - type 1

   [query-response] [0x03] [1] [null][\n]

   [null] is the US-ASCII representation of the word 'null'.



Harsh & Newman            Expires May 20, 2010                 [Page 39]


Internet-Draft         Multicast Session Directory         November 2009


4.5.4.2.  query-response - type 2

   [query-response] [0x03] [17] [char-set] [channel IP] [channel port]
   [Geographic CN] [Lat] [Long] [unicast IP] [unicast port] [channel
   scope] [URS-Identifier] [expiration time] [network type] [source IP]
   [stream type] [preferred application] [CLI argument] [mime-type][\n]

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

4.5.5.  dsearch

   [dsearch] [0x0A] [2] [char-set] [parameter][\n]

   See Section 4.4.13 for more details on the interpretation of the
   protocol fields.

4.5.6.  search

   [search] [0x0A] [3] [char-set] [parameter] [client port][\n]

   See Section 4.4.7 for more details on the interpretation of the
   protocol fields.

4.5.7.  redirect

   [redirect] [0x07] [5] [char-set] [keyword] [msd IP] [msd port] [hop
   count][\n]

   See Section 4.4.8 for more details on the interpretation of the
   protocol fields.

4.5.8.  ext-search

   [ext-search] [0x0A] [5] [char-set] [parameter] [IP] [port] [inversion
   flag][\n]

   See Section 4.4.15 for more details on the interpretation of the
   protocol fields.

4.5.9.  bye

   [bye] [message direction] [0][\n]

   See Table 4 for values that [message direction] field can take.






Harsh & Newman            Expires May 20, 2010                 [Page 40]


Internet-Draft         Multicast Session Directory         November 2009


4.5.10.  ext-search-invalid

   [ext-search-invalid] [0x08] [2] [char-set] [keyword][\n]

   See Section 4.4.18 for more details on the interpretation of the
   protocol fields.

4.5.11.  invalidate

   [invalidate] [0x0A] [6] [char-set] [keyword] [cached IP] [cached
   port] [IP] [port][\n]

   See Section 4.4.4 for more details on the interpretation of the
   protocol fields.

4.5.12.  search-response

   End user search tool can process two kinds of [search-response]
   protocol messages.  Both are described next.

4.5.12.1.  search-response - type 1

   [search-response] [0x07] [11] [char-set] [global] [keyword] [domain
   URI] [URS Identifier] [expiration time] [Lat] [Long] [network type]
   [stream type] [hop count][\n]

   See Section 4.4.19.1 for more details on the interpretation of the
   protocol fields.

4.5.12.2.  search-response - type 2

   [search-response] [0x07] [17] [char-set] [local] [keyword] [channel
   IP] [channel port] [channel scope] [Geographical CN] [Lat] [Long]
   [network type] [source IP] [stream type] [preferred application] [CLI
   argument] [unicast IP] [unicast port] [hop count][\n]

   See Section 4.4.19.2 for more details on the interpretation of the
   protocol fields.

4.5.13.  ext-search-response

   [ext-search-response] [0x08] [11] [char-set] [global] [keyword]
   [domain URI] [URS Identifier] [expiration time] [Lat] [Long] [network
   type] [stream type] [hop count][\n]

   See Section 4.4.20 for more details on the interpretation of the
   protocol fields.




Harsh & Newman            Expires May 20, 2010                 [Page 41]


Internet-Draft         Multicast Session Directory         November 2009


4.5.14.  tx-end

   [tx-end] [message direction] [3] [char-set] [keyword] [tag][\n]

   See Table 4 for values that [message direction] field can take.

   See Section 4.1 for more details on the interpretation of the
   commonly used message fields.

   [keyword] is the search keyword for which this [tx-end] is being sent
   indicating the end of sequence of transmission of zero or more
   [search-response] or [ext-search-response] messages for each
   candidate multicast record at the MSD server.

   [tag] is the US-ASCII encoded string constant 'dext' or 'dint'.
   'dext' is sent to signal the end of transmission sequence for
   globally scoped multicast session records.  Similarly 'dint' is sent
   to signal the end of transmission sequence for administratively
   scoped multicast sessions.

4.5.15.  get-backup-msd

   [get-backup-msd] [0x0A] [4] [char-set] [keyword] [IP] [port][\n]

   See Section 4.4.26 for more details on the interpretation of the
   protocol fields.


5.  Protocol Message Semantics

   Here description of what happens when a particular protocol message
   is received or sent, and what type of background processing could be
   expected among the components involved, is provided.


















Harsh & Newman            Expires May 20, 2010                 [Page 42]


Internet-Draft         Multicast Session Directory         November 2009


   +---------------------------------+-------------------+------------+
   | Variable                        | Effected Messages |      Value |
   +---------------------------------+-------------------+------------+
   | SELF_REPORT_TIME                |      [hello]      | 30 seconds |
   | PARENT_REPORT_TIME              |    [rep-hello]    | 30 seconds |
   | MAX_PARENT_REPORT_TIMEOUT_COUNT |        -na-       |          2 |
   | MAX_CHILD_REPORT_TIMEOUT_COUNT  |        -na-       |          6 |
   | MSD_UNICAST_REPORT_TIME         |  [unicast-update] | 30 seconds |
   | ADDRESS_NOTIFICATION_TIME       |    [add-space]    | 30 seconds |
   | MAX_TIMEOUT_COUNT               |        -na-       |          6 |
   | REQUEST_TIMEOUT                 |        -na-       | 20 seconds |
   | SOCKET_TIMEOUT                  |        -na-       | 20 seconds |
   +---------------------------------+-------------------+------------+

         List of all global timer variables and associated values.

                                  Table 5

5.1.  URS Protocol Message Semantics

   +----------------+------------+-------------+-----------------------+
   | Rx Messages    |   Sender   |  Recipient  |           Tx Messages |
   +----------------+------------+-------------+-----------------------+
   | bye            |   Client,  |     URS,    |                   bye |
   |                |  MSD, URS  | Client, MSD |                       |
   | query          |   Client   |     URS     |        query-response |
   | check          |   Client   |     URS     |        check-response |
   | register       |   Client   |     URS     |       register-status |
   | request        |   Client,  |     URS     |      request-response |
   |                |  MSD, URS  |             |                       |
   | unicast-update |     MSD    |     URS     | unicast-update-status |
   | resync         |     MSD    |     URS     |         resync-status |
   +----------------+------------+-------------+-----------------------+

                                  Table 6

   Unless otherwise noted, the protocol exchanges happen between the
   domain local URS and clients, registration tools, and MSD servers.

5.1.1.  bye

   [bye] protocol message when received at the URS indicates the desire
   of the remote tool to close the socket connection.  Remote node could
   be a client, MSD server or even another URS.  The receiver URS node
   must respond back with [bye] protocol message and then close the
   remote socket connection.





Harsh & Newman            Expires May 20, 2010                 [Page 43]


Internet-Draft         Multicast Session Directory         November 2009


5.1.2.  query

   A [query] protocol message is used to retrieve the multicast session
   record details of the [URS-Identifier] provided.  The URS searches
   the internal database for [URS-Identifier] record.  If the record is
   located then it responds back with [query-response] type 2 protocol
   message (see Section 4.2.3.2) otherwise, it responds with a [query-
   response] type 1 (see Section 4.2.3.1) protocol message.

   The client on receiving the [query-response] (either type) protocol
   message must send [bye] protocol message to the URS.

5.1.3.  check

   A [check] protocol message is used by the registration tool to find
   out whether the intended [keyword] has already been reserved as URS-
   Identifier by some other session or not.  If the [keyword] has
   already been used as URS-Identifier then a [check-response] message
   indicating 'false' is sent back to the client, else a 'true' [check-
   response] is sent back.

   The client on receiving the [check-response] protocol message must
   send [bye] protocol message to the URS.

5.1.4.  register

   A [register] protocol message is generated and sent to the URS by the
   session registration tool.  The URS creates a new session record
   entry corresponding to the registration data included in the
   [register] protocol message.  It must check for duplicity of the URS-
   Identifier keyword in the existing database.  If a new record
   insertion into the database succeeds, then the URS sends back
   [register-status] indicating 'true', else it responds back with
   [register-status] indicating 'false'.

   The client on receiving the [register-status] protocol message must
   send [bye] protocol message to the URS.

5.1.5.  request

   [request] protocol messages are used by the clients and the
   designated MSD server to find out the critical configuration values
   to be able to join the service hierarchy.  A [request] message with
   'mcast_param' is sent by the MSD server to contact the URS to get the
   hierarchy configuration parameters that allows the designated MSD
   server to subscribe to PMCAST channel and find out about CMCAST
   group.




Harsh & Newman            Expires May 20, 2010                 [Page 44]


Internet-Draft         Multicast Session Directory         November 2009


   A [request] protocol with 'designated' is used by the clients to find
   the unicast server details of the designated MSD server in that
   domain.  This protocol message can also be used by the URS to contact
   the URS in its parent domain to find the connectivity details of MSD
   server in parent domain.

   Upon receipt of the [request] protocol message, the URS responds back
   with the appropriate [request-response] message.  A [request-
   response] type 1 (see Section 4.2.9.1) message is sent back in reply
   to 'mcast_param' request and a [request-response] type 2 (see
   Section 4.2.9.2) is sent in reply to 'designated' request.

   The client, MSD, or URS on receiving the [request-response] protocol
   message must send [bye] protocol message to the URS.  Figure 3 shows
   the different scenarios when a URS [request] and [request-response]
   protocol messages are exchanged. [bye] messages are not shown.

            +-------+
            |URS    |
            |       |
            +-------+
      request|     |request-response
             A    \|/
            /|\    V
             |     |                       Domain A
   ----------|-----|-------------------------------------
             |     |                       Domain B
            +-------+      request     +-------+
            |       |-<----------------|       |
            |URS    |                  |MSD    |
            |       | request-response |       |
            |       |------------->----|       |
            +-------+                  +-------+
      request|     |
             A    \|/
            /|\    V
             |     |request-response
             |     |
                O
               /|\
                |
               / \
             Client

                                 Figure 3






Harsh & Newman            Expires May 20, 2010                 [Page 45]


Internet-Draft         Multicast Session Directory         November 2009


5.1.6.  unicast-update

   A [unicast-update] protocol message is used by the designated MSD
   server to notify the URS of any changes in the unicast server
   connection details.  This message is sent periodically by the MSD
   server to the URS.  Upon receipt of this message, the URS updates the
   internal values.  If the update succeeds at the URS, it responds back
   with a [unicast-update-status] message indicating 'true'.  If the
   operation somehow fails, it sends back [unicast-update-status] with
   'false' in it.

   The MSD server on receiving the [unicast-update-status] protocol
   message must send [bye] protocol message to the URS.

5.1.7.  resync

   A [resync] protocol message is sent by the designated MSD server to
   the URS to suggest to the URS to re-sync the parent domain's MSD
   server unicast connection details.  This protocol message is sent
   only when the designated MSD fails to get any parent heartbeat
   message [rep-hello] (see Section 4.4.10) for
   MAX_PARENT_REPORT_TIMEOUT_COUNT. periods.

   Upon receiving [resync] request, the URS sends [request] protocol
   with 'designate' parameter to the URS in the parent domain and waits
   for the [request-response] message to come back.  After receiving the
   response from the URS in the parent domain and closing that socket
   connection, it responds to the MSD server with a [resync-status]
   protocol message.  If it fails to get a valid data from the URS in
   the parent domain, the [resync-status] indicates a 'false' value.
   Otherwise a value 'true' and the updated unicast connection details
   of the parent designated MSD server are sent back.

   The MSD server on receiving the [resync-status] protocol message must
   send [bye] protocol message to the URS.

5.2.  Registration (Reg.) Tool Protocol Message Semantics

     +-------------+-----------+-----------------+------------------+
     | Tx Messages |   Sender  |    Recipient    |      Rx Messages |
     +-------------+-----------+-----------------+------------------+
     | bye         | Reg. Tool | URS, MSD server |              bye |
     | check       | Reg. Tool |       URS       |   check-response |
     | register    | Reg. Tool | URS, MSD server |  register-status |
     | request     | Reg. Tool |       URS       | request-response |
     +-------------+-----------+-----------------+------------------+

                                  Table 7



Harsh & Newman            Expires May 20, 2010                 [Page 46]


Internet-Draft         Multicast Session Directory         November 2009


   Unless otherwise noted, the communication happens between the
   registration tool and the URS and designated MSD server in the same
   administrative domain.

5.2.1.  bye

   [bye] protocol message is sent to the remote URS or MSD server to
   indicate an intent to close the socket connection.  It should wait
   for the [bye] protocol message as the response before closing the
   socket connection.

5.2.2.  check

   The [check] protocol message is sent to the URS to find out whether
   the [keyword] sent along with this message has been used already as
   an URS-Identifier by some other multicast session or not.  It must
   wait for the [check-response] reply message to come back from the
   URS.  If no response is received within SOCKET_TIMEOUT, it must not
   proceed and the registration sequence must fail and the user
   notified.

   The registration tool on receiving the [check-response] protocol
   message must send [bye] protocol message to the URS.

5.2.3.  register

   The [register] protocol message is sent to the URS and the designated
   MSD server.  See Section 4.3.4.1 and Section 4.3.4.2 for more
   details.  This message is sent as a registration request and contains
   all necessary parameters of the multicast session to be registered.
   The tool must wait for a [register-status] reply to come back from
   the URS and MSD server indicating whether the registration attempt
   was a success of failure.

   The registration tool on receiving the [register-status] protocol
   message must send [bye] protocol message to the URS and/or MSD
   server.

5.2.4.  request

   A registration tool sends [request] protocol message to the URS to
   find out the unicast server connection details at the designated MSD
   server of its domain (see Section 4.3.6).  It then must wait for the
   [request-response] (see Section 4.2.9.2) response to come back from
   the URS.

   The registration tool on receiving the [request-response] protocol
   message must send [bye] protocol message to the URS.



Harsh & Newman            Expires May 20, 2010                 [Page 47]


Internet-Draft         Multicast Session Directory         November 2009


5.3.  MSD Server Protocol Message Semantics

   MSD server protocol messages can be grouped into three categories
   based on the nature of the server behavior.  MSD servers act as a
   'server' to some clients, act as 'client' requesting services from
   others, and sometimes handle asynchronous protocol messages.  Based
   on these three behavioral categorization, protocol summary tables are
   presented below.

   o  Table 8 - MSD in server mode

   o  Table 9 - MSD in client mode

   o  Table 10 - MSD in asynchronous mode

   Unlike the previous two subsections where the protocol communication
   is generally assumed to take place among components within the same
   domain, protocol communication handled by MSD servers frequently
   crosses the domain boundaries.

   To interpret a table, read it from left to right.  If a component
   acts as server, the first column is 'Rx Messages', signifying the
   messages received at the server.  The response sent back to the
   requesting client is given by the 'Tx Messages' column.  Similarly,
   if the component behaves as a client, then the first column of the
   table is 'Tx Messages' signifying the messages the client might send
   to the 'server'.  The last column in such a table is 'Rx Messages',
   the messages that are received at the client from the remote
   'servers' in response to the message it sent.

   Table 10 is organized a bit differently.  It shows the asynchronous
   protocol messages that can be sent by the designated MSD server in
   any domain.  Some of those messages are sent periodically.  The table
   shows the periodicity.  The columns 'Parent', 'Child', and 'Local'
   note whether the message could be sent on a 'PMCAST', or 'CMCAST'
   channel or to other MSD servers running in the same domain (maybe via
   'MSD-LOCAL' channel) in that order.

   Note: Treat Table 10 as depicting 'send' semantics only.  A message
   sent on a 'PMCAST' channel will be received at the designated MSD in
   the parent domain on its 'CMCAST' channel and vice-versa.










Harsh & Newman            Expires May 20, 2010                 [Page 48]


Internet-Draft         Multicast Session Directory         November 2009


                            MSD in server mode

   +----------------+------------------+-------------------------------+
   | Rx             |      Sender      |                   Tx Messages |
   +----------------+------------------+-------------------------------+
   | register       |   registration   |               register-status |
   |                |       tool       |                               |
   | invalidate     |    search tool   |                      redirect |
   | search         |    search tool   |    redirect, search-response, |
   |                |                  |                        tx-end |
   | dsearch        |    search tool   |       search-response, tx-end |
   | bye            |   registration,  |                           bye |
   |                |    search tool   |                               |
   | ext-search     |    search tool   |          ext-search-response, |
   |                |                  |    ext-search-invalid, tx-end |
   | get-backup-msd |    search tool   |                      redirect |
   +----------------+------------------+-------------------------------+

                                  Table 8

                            MSD in client mode

   +----------------+-------------------------+-----------------------+
   | Tx Messages    |       Periodicity       |           Rx Messages |
   +----------------+-------------------------+-----------------------+
   | unicast-update | MSD_UNICAST_REPORT_TIME | unicast-update-status |
   | resync         |           -NA-          |         resync-status |
   | request        |           -NA-          |      request-response |
   | bye            |           -NA-          |                   bye |
   +----------------+-------------------------+-----------------------+

                    Recipient of these messages is URS

                                  Table 9

















Harsh & Newman            Expires May 20, 2010                 [Page 49]


Internet-Draft         Multicast Session Directory         November 2009


                   Asynchronous messages handled by MSD

    +-----------------+--------+-------+-------+----------------------+
    | Message         | Parent | Child | Local |          Periodicity |
    +-----------------+--------+-------+-------+----------------------+
    | msd-probe       |   yes  |  yes  |   x   |                 -NA- |
    | msd-probe-reply |    x   |   x   |   x   |                 -NA- |
    | hello           |   yes  |   x   |   x   |     SELF_REPORT_TIME |
    | rep-hello       |    x   |  yes  |   x   |   PARENT_REPORT_TIME |
    | null-space      |    x   |  yes  |   x   |                 -NA- |
    | add-space       |    x   |  yes  |   x   | ADDRESS_NOTIFICATION |
    | remote-register |   yes  |  yes  |   x   |                 -NA- |
    +-----------------+--------+-------+-------+----------------------+

      Asynchronous messages are sent between MSD servers, frequently
                        crossing domain boundaries.

                                 Table 10

   Message semantics for each protocol message handled by a MSD server
   are provided.

5.3.1.  register

   A [register] message is sent by a session registration tool to the
   designated MSD server in its own domain to register a multicast
   session with the MSD server.  The registration message may contain
   several keywords.  The MSD server separates the keywords list into
   individual keywords and creates one local database record for each
   keyword.

   If the session scope is 'global', then it hashes each keyword.  It
   also generates the inverted hash values by inverting all the bits of
   the original MD5 keyword hash.  If any hash value lies in the self
   managed hash space then a session record with the corresponding
   keyword is stored into the global database.  Similarly, if any
   inverted hash values lie in the self managed hash space, then a
   session record with corresponding keyword and with 'hash inversion'
   flag set is stored in the global database as well.  For remaining
   cases, depending on the keyword hash routing table, it creates a
   [remote-register] protocol message, and sends the message either
   towards parent or children domains.

   If the [remote-register] message is generated for the true hash
   value, then the [inversion flag] is set to 'false', otherwise the
   [inversion flag] field is set to 'true'.

   Once the local records insertion into database completes, and all



Harsh & Newman            Expires May 20, 2010                 [Page 50]


Internet-Draft         Multicast Session Directory         November 2009


   necessary [remote-register] messages have been sent, the designated
   MSD server sends [register-status] protocol message back to the
   session registration tool indicating whether the process succeeded,
   'true', or not, 'false'.

5.3.2.  invalidate

   An [invalidate] message is sent by the client to the local MSD server
   when a remote MSD server's response to the client indicates that it
   is the wrong MSD server.  When received at the MSD server, it removes
   the [keyword] entry, if present, from the locally maintained 'remote
   MSD connection' cache, if [inversion flag] value is 'false' or from
   'inversion-cache' if [inversion flag] value is 'true'.

   Then it hashes the [keyword] using MD5.  It converts the hash value
   by inverting the bits iff [inversion flag] value was 'true'.  It
   creates a [msd-probe] message and copies the [inversion flag] value
   received in the [invalidate] protocol message and sends it towards
   the target domain depending on the local routing table entry.

   Upon receiving the [msd-probe-reply] response for [keyword] from the
   remote MSD server, it first caches the remote connection information
   in the appropriate local cache (or inverted cache), and sends back
   [redirect] to the client.

5.3.3.  search

   When a [search] request is received at the MSD server, it separates
   all the keywords and the search parameters contained in the protocol
   message.  If administrative 'local' scoped search is enabled, then it
   queries the local session records database for these keywords one by
   one.  Responses are sent back as a set for all matching session
   records for a 'keyword' before proceeding to the next 'keyword'.

   Matching records are sent back using [search-response] (see
   Section 4.4.19.2) one by one.  Once all the matching records for a
   particular 'keyword' has been transmitted, the transmission sequence
   end is realized by sending [tx-end] with 'dint' parameter to the
   client before proceeding with the next keyword (see Figure 4).

   If 'global' scoped session search is enabled, the MSD server hashes
   the 'keyword', if the hash value lies in its managed range, it
   queries its 'Global Records' database for the keyword and all
   matching records are sent back using [search-response] to the
   client(see Section 4.4.19.1).  The transmission sequence end is
   realized by sending [tx-end] with 'dext' parameter to the client
   before proceeding with the next keyword.




Harsh & Newman            Expires May 20, 2010                 [Page 51]


Internet-Draft         Multicast Session Directory         November 2009


   If the hashed value does not lie in the self managed range, then it
   looks into the 'Remote MSD Connection' cache for an entry for the
   'keyword', if an entry is found, it sends back the remote MSD server
   connection details using [redirect] message.  The [inversion flag]
   value in the [redirect] messages are set to 'false'.

   If no cache entry is found, it sends [msd-probe] towards the target
   domain, and upon receiving [msd-probe-reply] updates its local cache,
   and sends [redirect] information to the client.  The [inversion flag]
   field in the [msd-probe] message and the [redirect] response is set
   to 'false'.

             |                               |
             |-----<------search-------------|
             |--------search-response---->---| ^
             |--------search-response---->---| |
             |             ...               | | keyword 1
             |--------search-response---->---| |
             |--------- tx-end dint ----->---| v
             |              .                | .
             |              .                | .
             |              .                | .
             |--------search-response---->---| ^
             |--------search-response---->---| |
             |             ...               | | keyword n
             |--------search-response---->---| |
             |--------- tx-end dint ----->---| v
             |                               |
            MSD                            Client

   protocol exchange for administratively scoped session search

                                 Figure 4

   Figure 5 shows the search scenario where multicast sessions with
   'global' scope are being searched for.  The figure depicts two cases.
   Case I shows the scenario where every keyword hash value lies in the
   self-managed hash value range.  Case II shows the scenario where a
   few keywords' hash values lie in the self-managed range at the local
   MSD and thus the search-responses are sent from the local MSD server,
   but for the remaining keywords a [redirect] is sent.  Using the data
   contained in the [redirect] the client contacts the remote MSD
   servers directly for the search data.

   Figure 6 shows the search scenario where not all keywords' cache
   entries are present and further, a cache entry is stale at the local
   MSD server.




Harsh & Newman            Expires May 20, 2010                 [Page 52]


Internet-Draft         Multicast Session Directory         November 2009


    |--<------search-------------|
    |-----search-response---->---| ^
    |-----search-response---->---| |
    |          ...               | | keyword 1
    |-----search-response---->---| |
    |------ tx-end dext ----->---| v
    |           .                | .
    |           .                | .    CASE 1: All keywords' hash
    |           .                | .  lies in the self managed range
    |-----search-response---->---| ^
    |-----search-response---->---| |
    |          ...               | | keyword n
    |-----search-response---->---| |
    |------ tx-end dext ----->---| v
    |                            |
 -----------------------------------------------------------------------
    |                            |                           |         |
    |--<------search-------------|                           |         |
    |-----search-response---->---| ^                         |         |
    |-----search-response---->---| |                         |         |
    |          ...               | | keyword 1               |         |
    |-----search-response---->---| |                         |         |
    |------ tx-end dext ----->---| v                         |         |
    |           .                | .                         |         |
    |           .                | .                         |         |
    |                            |                           |         |
    |-------- redirect ------>---|                           |         |
    |-------- redirect ------>---|-------- ext-search --->---|         |
    |           .                |-<-- ext-search-response --|         |
    |           .                |-<-- ext-search-response --|         |
    |-------- redirect ------>---|            ...            |         |
    |                            |-<------ tx-end dext ------|         |
    |                            |                           |         |
    |                            |------->-- ext-search -----+-->------|
    |                            |-<--- ext-search-response -+---------|
    |                            |-<--- ext-search-response -+---------|
    |                            |-<--- ext-search-response -+---------|
    |                            |            ...            |         |
    |                            |-<------- tx-end dext -----+---------|
    |                            |             .             |         |
    |                            |             .             |         |

   MSD-local                  Client                      MSD-x    MSD-y

   protocol exchange for globally scoped session search - case I and II

                                 Figure 5




Harsh & Newman            Expires May 20, 2010                 [Page 53]


Internet-Draft         Multicast Session Directory         November 2009


   |                         |                           |      |      |
   |--<------search----------|                           |      |      |
   |-----search-response-->--| ^                         |      |      |
   |-----search-response-->--| |                         |      |      |
   |          ...            | | keyword 1               |      |      |
   |-----search-response-->--| |                         |      |      |
   |------ tx-end dext --->--| v                         |      |      |
   |           .             | .                         |      |      |
   |           .             | .                         |      |      |
   |                         |                           |      |      |
   |-------- msd-probe --->--+------...---->-----...-----+--->--|      |
   |--<-- msd-probe-reply ---+-------------<-------------+------|      |
   |           .             |                           |      |      |
   |           .             |                           |      |      |
   |-------- redirect ---->--|-------- ext-search --->---|      |      |
   |           .             |-<-- ext-search-response --|      |      |
   |           .             |-<-- ext-search-response --|      |      |
   |-------- redirect ---->--|            ...            |      |      |
   |                         |-<------ tx-end dext ------|      |      |
   |                         |                           |      |      |
   |                         |------->-- ext-search -----+-->---|      |
   |                         |-<--- ext-search-response -+------|      |
   |                         |-<--- ext-search-response -+------|      |
   |                         |-<--- ext-search-response -+------|      |
   |                         |            ...            |      |      |
   |                         |-<------- tx-end dext -----+------|      |
   |                         |             .             |      |      |
   |                         |             .             |      |      |
   |                         |             .             |      |      |
   |                         |-------- ext-search --->---|      |      |
   |                         |--<-  ext-search-invalid --|      |      |
   |--<--- invalidate -------|                           |      |      |
   |------- msd-probe ---->--+------------->-------------+---->-+---->-|
   |--<-- msd-probe-reply ---+-------------<-------------+----<-+----<-|
   |-------- redirect ---->--|                           |      |      |
   |                         |------------ ext-search ---+------+---->-|
   |                         |-<---- ext-search-response +------+----<-|
   |                         |-<---- ext-search-response +------+----<-|
   |                         |            ...            |      |      |
   |                         |-<---------- tx-end dext --+------+----<-|
   |                         |                           |      |      |

MSD-local                 Client                     MSD-x  MSD-y  MSD-z

   protocol exchange for globally scoped session search - case III

                                 Figure 6




Harsh & Newman            Expires May 20, 2010                 [Page 54]


Internet-Draft         Multicast Session Directory         November 2009


   In the two figures shown above, 'search-response' messages contain
   multicast session data for the sessions stored locally; the first
   msd-probe is sent to locate the server holding the multicast session
   data for a key for which there is no cache entry, and redirects are
   sent to the client for non-local keys (now held in the cache).  The
   client searches the remote MSD servers as directed by its local MSD
   server.  In the first two cases, the remote server is the right one
   and returns the session data.  In the last case, the location data
   cached at the local MSD server is stale, so the remote MSD server
   indicates it does have the desired session data by responding with
   ext-search-invalid message.  The client then informs its local MSD
   server to invalidate that cache entry and obtain fresh location
   information.  When it has done this, it caches the fresh data and
   redirects the client as before.

   IMP: MSD servers must ignore duplicate keywords in the [search]
   protocol message, if duplicates are present then only one set of
   [search-response] messages followed by [tx-end] is sent to the client
   for that duplicate keyword.  For example, if the search [parameter]
   is 'key1:key2:key3&key2:key4%yes:no' clearly 'key2' is repeated, so
   while processing the search query parameter string, if a keyword has
   already been processed by the MSD search handling module, a repeated
   keyword must be ignored.

5.3.4.  dsearch

   [dsearch] protocol message is sent if a domain-specific search
   operation has to be carried out at the target MSD server.  Only
   globally scoped multicast sessions are included in the search result.
   Upon receiving this message, the MSD server parses all the keywords
   in the [dsearch] protocol message.

   Keywords are processed one by one, duplicates are ignored.  The MSD
   server queries only its 'Local Session Records' database and filters
   out those records where session scope is set to 'global'.  It sends
   these candidate records' data one by one to the client using zero or
   more [search-response] (see Section 4.4.19.1) message(s).  To
   indicate the end of sequence a [tx-end] protocol with 'dext'
   parameter is sent to the client.  The next keyword in the sequence is
   processed and the whole sequence of operation repeats until all the
   keywords in the [dsearch] request have been processed (duplicates are
   ignored).

5.3.5.  bye

   [bye] protocol message when received at the MSD indicates the desire
   of the remote client to close the socket connection.  The MSD server
   must respond back with a [bye] protocol message and then close the



Harsh & Newman            Expires May 20, 2010                 [Page 55]


Internet-Draft         Multicast Session Directory         November 2009


   remote socket connection.

   When MSD is acting as a client, it may send [bye] as its intent to
   close the socket connection.  The MSD server must wait for [bye]
   protocol message to come from the remote server and then close the
   socket connection.

   The client MSD server may time out and resend the [bye] message is no
   reply is received within SOCKET_TIMEOUT period.  If a [bye] message
   is received on an unconnected socket, the receiving MSD shall respond
   with a [bye] and close the connection.

5.3.6.  ext-search

   The [ext-search] message is sent by the client to search against a
   particular keyword for which the MSD server manages the hash-space
   range.  If [inversion flag] is set to 'false' then the MD5 hash of
   the [keyword] is computed, otherwise its inversion is computed.  If
   the computed hash does not lie in the self-managed hash-space, a
   [ext-search-invalid] message is sent back.  The [inversion flag]
   field in [ext-search-invalid] is simply copied from the received
   [ext-search] protocol message.

   Otherwise, the MSD server queries its 'Global Session Records'
   database for the keyword and any candidate session records data are
   sent back using zero or more [ext-search-response] message(s).  To
   indicate the end of the data sequence a [tx-end] message with
   parameter 'dext' is sent back to the client.

5.3.7.  get-backup-msd

   The [get-backup-msd] message is sent by the search client to the
   local MSD server if it can not connect to the remote MSD server as
   directed by the [redirect] message it received in response to the
   [search] query.  A [get-backup-msd] may also be sent by the client if
   it encounters a time out waiting for search response to be received.

   When the MSD server receives the [get-backup-msd] message, it looks
   for a keyword match in its locally maintained 'inversion-cache', if
   found it responds with a [redirect] message back to the client.  The
   [inversion flag] in this [redirect] is set to 'true'.  In case of
   cache-miss, the MSD server generates a [msd-probe] message with the
   [inversion flag] set to 'true' and sends the message to the next MSD
   server in the hierarchy depending on the route got from the routing
   table using the bit-inverted keyword hash value.  When the
   corresponding [msd-probe-reply] message is received with [inversion
   flag] set to true for the requested keyword, it first updates its
   local 'inversion-cache' and then sends an appropriate [redirect]



Harsh & Newman            Expires May 20, 2010                 [Page 56]


Internet-Draft         Multicast Session Directory         November 2009


   message to the requesting client.

5.3.8.  unicast-update

   [unicast-update] protocol message is sent periodically by the
   designated MSD server to the URS in its domain to refresh the MSD's
   unicast connection data at the URS.  The periodicity of this message
   is MSD_UNICAST_REPORT_TIME seconds.  The URS responds with [unicast-
   update-status] message indicating whether the update operation was
   successful or not.

   The MSD server on receiving the [unicast-update-status] protocol
   message must send a [bye] protocol message to the URS.

5.3.9.  resync

   When the designated MSD server fails to receive parent's [rep-hello]
   message for consecutive MAX_PARENT_REPORT_TIMEOUT_COUNT timeout
   intervals, it sends the [resync] protocol message to the domain local
   URS to instruct it to contact its parent domain's URS using [request]
   protocol message (see Section 4.2.8.2) to query the latest MSD
   unicast connection details in the parent's domain so that this MSD
   server can contact the parent MSD in the parent domain via unicast.
   After the URS has re-synced its data, it responds back to the MSD
   server using [resync-status] protocol message.  If the parent URS no
   longer exists, of if the parent MSD connection data after re-syncing
   is invalid, then [resync-status] with 'false' is sent (see
   Section 4.2.13.1), else the re-synced data is sent using [resync-
   status] with 'true' set (see Section 4.2.13.2).

   The MSD server on receiving the [resync-status] protocol message must
   send a [bye] protocol message to the URS.

5.3.10.  request

   A [request] message with 'mcast_param' is sent by the MSD server to
   the URS to get the hierarchy configuration parameters that allow the
   designated MSD server to subscribe to PMCAST channel CMCAST group and
   other details.  Upon receipt of the [request] protocol message, the
   URS responds with the [request-response] type 1 message (see
   Section 4.2.9.1).

   The MSD server on receiving the [request-response] protocol message
   must send a [bye] protocol message to the URS.







Harsh & Newman            Expires May 20, 2010                 [Page 57]


Internet-Draft         Multicast Session Directory         November 2009


5.3.11.  msd-probe

   [msd-probe] message can be generated by a MSD server in four
   scenarios.  First, when a [search] request comes for globally scoped
   sessions search and a keyword hash value lies outside the self
   managed range and the target MSD connection details are not found in
   the local 'MSD connections' cache, then a [msd-probe] message is
   generated with [inversion flag] field set to 'false' and propagated
   in the direction of the target domain using the hash routing table.

   Second, when the MSD receives an [invalidate] message from a client
   with [inversion flag] set to 'false'; it removes the cache entry for
   the keyword in question from the usual 'MSD connections' cache and
   sends [msd-probe] message with [inversion flag] field set to 'false'
   for that keyword that was the argument of the [invalidate] message.

   Third, when the MSD receives [get-backup-msd] message from the
   client, it looks up its locally maintained 'inversion-cache' for the
   requested keyword entry.  If the target MSD server connection details
   are not found, it generates an [msd-probe] message with [inversion
   flag] field set to 'true' and routes it according to the routing
   algorithm using bit-inverted keyword hash value.

   Fourth, when the MSD receives an [invalidate] message from a client
   with [inversion flag] set to 'true'; it removes the cache entry for
   the keyword in question from the 'inversion-cache' cache and sends
   [msd-probe] message with [inversion flag] field set to 'true' for
   that keyword that was the argument of the [invalidate] message
   according to the routing algorithm using bit-inverted keyword hash
   value.

   When an MSD server receives the [msd-probe] message on either PMCAST
   or from any of its children nodes, it computes the MD5 hash of the
   associated keyword.  If the [inversion flag] is true, the hash value
   is bit-inverted.This value is used to see if this value falls in its
   self managed hash value range or not; if it falls in the range, it
   sends [msd-probe-reply] containing the connection details of its
   unicast server directly back to the original MSD server.  The
   [inversion flag] in the reply message is made equal to the [inversion
   flag] that was received in the [msd-probe] message.  If not then it
   simply routes the [msd-probe] in accordance with the hash routing
   table towards the next domain using the original keyword hash value
   or its bit-inverted form depending on whether the [inversion flag] in
   the received [msd-probe] was 'false' or 'true'.







Harsh & Newman            Expires May 20, 2010                 [Page 58]


Internet-Draft         Multicast Session Directory         November 2009


5.3.12.  hello

   A [hello] message is generated periodically by the MSD server to send
   to its parent domain.  The MSD server includes the domain count
   report and its unicast connection details in the message.  The
   periodicity of this message is SELF_REPORT_TIME seconds.

   When an MSD server receives a [hello] message from any of its
   children domain, it updates/stores the child domain unicast
   connection details and the unique ID in its child list and updates
   the last seen time for this child.  Any entry in the child-list that
   has not be updated since MAX_CHILD_REPORT_TIMEOUT_COUNT timeout
   periods should be purged.  If a child entry is purged, the MSD server
   must check the routing table to see if any route was created for this
   purged child node; if so, then that hash-range and the route must be
   merged with some other child entry or temporarily assigned to itself
   (see Section 6.1).  The receiving MSD server checks the [pmcast
   status] parameter to see if the reporting child domain is getting
   communication from this domain on its PMCAST channel or not.  If not,
   the MSD server sends communication to this child node using unicast
   in addition to sending messages to rest of the children via the
   CMCAST multicast channel.  If there are no children subscribing to
   the CMCAST channel, then it need not be used at all.

5.3.13.  rep-hello

   A [rep-hello] protocol message is sent periodically on the CMCAST
   channel to all the children nodes.  Occasionally it could also be
   sent via unicast to a child node that is unable to receive
   communication sent using multicast channel CMCAST.  The periodicity
   of this message is set to PARENT_REPORT_TIME seconds.

   A MSD receives this message on its PMCAST channel.  Upon receiving
   the message, the MSD server stores the hash-range assigned to the
   parent for a possible node failure recovery in future.  If this
   protocol message is not received for consecutive
   MAX_PARENT_REPORT_TIMEOUT_COUNT periods, the node sends [resync] to
   the URS to find the updated parent's connection details in case it
   changed.  If after consecutive MAX_TIMEOUT_COUNT periods, no [rep-
   hello] messages are received, the MSD assumes the parent to be dead,
   and assumes the root responsibilities (see Section 6.1).  In the
   meantime (when the parent is assumed dead) it continues to send
   [resync] to its URS every MAX_PARENT_REPORT_TIMEOUT_COUNT intervals.
   Upon receipt of [rep-hello] the timeout counter is reset.







Harsh & Newman            Expires May 20, 2010                 [Page 59]


Internet-Draft         Multicast Session Directory         November 2009


5.3.14.  null-space

   [null-space] message is sent on the CMCAST channel (or unicast for
   children unable to receive communication over their PMCAST channel)
   to indicate that a particular child domain identified by the unique
   ID included in the protocol message has been assigned a 'null'
   keyword hash range.

   When a MSD identified by the unique ID receives the [null-space]
   message destined to it, it updates its hash routing table to reflect
   the change, assigns any of its children (that were assigned a hash
   space by this MSD) 'null' too and notifies them by sending [null-
   space] to them over CMCAST or unicast.  The routing table now must
   route any hash value through the parent node.  This MSD server then
   migrates every multicast record stored in the 'Global Session
   Records' database using [remote-register] via the parent node.

5.3.15.  add-space

   [add-space] protocol message is periodically sent to every children
   domain to refresh or reassign/assign keyword hash ranges to them for
   management.  This protocol message is normally sent via CMCAST but
   for child nodes unable to receive communication on their PMCAST
   channel, it must send using unicast.  The periodicity of this
   protocol message is ADDRESS_NOTIFICATION_TIME seconds.  Any child
   node in the current child-list that has not been assigned any hash
   range value must be sent a [null-space] protocol message.

   When a MSD server identified by the unique ID receives the [add-
   space] message destined to it, it checks if the hash range contained
   in it is same as the range already assigned to it or not.  If it is
   the same, then no further action is taken.  If it is not, then its
   hash range has been updated by its parent domain.  It must
   redistribute the hash range among itself and any children in
   accordance to the distribution algorithm it implements, and notify
   the children nodes using [add-space].  It updates the routing table
   to reflect the change.  Finally it must migrate any multicast session
   records stored in the 'Global Multicast Records' database whose
   keyword MD5 hash does not lie in its hash range using the [remote-
   register] protocol message and routing it according to the new
   routing table.

5.3.16.  remote-register

   A [remote-register] protocol message can be generated and sent by an
   MSD server in two scenarios.  First, when a [register] request comes
   and the multicast session is marked as 'globally scoped', and one or
   more keywords' MD5 hash lies outside the self-managed hash range,



Harsh & Newman            Expires May 20, 2010                 [Page 60]


Internet-Draft         Multicast Session Directory         November 2009


   then two [remote-register] messages are created; one with [inversion
   flag] set to 'false' and another with [inversion flag] field set to
   'true'.  These [remote-register] messages are routed according to the
   routing table to the destination domain.  The routing is based on the
   MD5 hash value of the keyword in the case where [inversion flag] was
   set to 'false' and routing is based on the bit-inverted hash value of
   the keyword in the case where [inversion flag] was set to 'true'.

   Secondly, if the assigned hash range of this MSD server has been
   reassigned by the parent node or made 'null', then all the candidate
   global records stored in the 'Global Session Records' database whose
   keyword's MD5 hash no longer lie in the new hash space range
   reassigned to itself must be checked for migration readiness to the
   correct destination domains.  For those candidate session records
   whose 'inversion flag' is set to 'false', a [remote-register] message
   for such records are generated with [inversion flag] set to 'false'
   and these protocol messages are routed based on the updated routing
   table using the keywords' true MD5 hash values.  For all session
   records where the 'inversion flag' is set to 'true', a [remote-
   register] message for such records are generated with [inversion
   flag] set to 'true' and these protocol messages are routed based on
   the updated routing table using the keywords' bit-inverted MD5 hash
   values.

   When a [remote-register] message is received from the parent node or
   one of the children domains, the [inversion flag] field is checked.
   It it is 'false' then the MD5 hash of the keyword contained in the
   message is computed.  Otherwise the bit-inverted MD5 hash value is
   computed instead.  If the value lies in the self-managed hash range,
   a new record is created and inserted into the 'Global Session
   Records' database.  The record's 'inversion flag' field is set to
   [inversion flag] value contained in the protocol message.  If not
   then the message is forwarded to the next hop towards the target
   domain based on the hash routing table, using either the true MD5
   hash value or the bit-inverted hash value of the keyword depending on
   whether the received [remote-register] message had [inversion flag]
   field set to 'false' or 'true'.














Harsh & Newman            Expires May 20, 2010                 [Page 61]


Internet-Draft         Multicast Session Directory         November 2009


5.4.  End User Search Tool Protocol Message Semantics

   +----------------+-----------+--------------------------------------+
   | Tx             | Recipient |                          Rx Messages |
   +----------------+-----------+--------------------------------------+
   | request        |    URS    |                     request-response |
   | query          |    URS    |                       query-response |
   | dsearch        |    MSD    |              search-response, tx-end |
   | search         |    MSD    |    search-response, redirect, tx-end |
   | ext-search     |    MSD    |                 ext-search-response, |
   |                |           |           ext-search-invalid, tx-end |
   | invalidate     |    MSD    |                             redirect |
   | bye            |  URS, MSD |                                  bye |
   | get-backup-msd |    MSD    |                             redirect |
   +----------------+-----------+--------------------------------------+

                                 Table 11

   Table 11 gives a summary of the protocol messages handled by the end-
   user search tool.  Detailed semantics for each 'Tx Message' is given
   next.  Unless explicitly mentioned the communication happens between
   the search tool and the URS or designated MSD server in the same
   administrative domain.

5.4.1.  request

   The [request] protocol message is sent by the search client to the
   URS to get the unicast server connection details of the designated
   MSD server of that domain.  It waits for the URS to respond with a
   [request-response] message (see Section 4.2.9.2).  This [request]
   message is sent to the client's domain local URS.

   Upon receiving the [request-response] message from the URS, the
   search client sends a [bye] protocol message to the URS and waits for
   the [bye] message from the URS before closing the socket connection.

5.4.2.  query

   The [query] protocol message is used to find the multicast session
   record details by querying the URS with the [URS-Identifier]
   parameter.  If a record for the provided [URS-Identifier] is located
   in the internal database at the URS, it responds with a [query-
   response] message containing all the record details (see
   Section 4.2.3.2).  If no record is located, the URS responds with a
   [query-response] message containing 'null' in it (see
   Section 4.2.3.1).

   Upon receiving the [query-response] message, the search client sends



Harsh & Newman            Expires May 20, 2010                 [Page 62]


Internet-Draft         Multicast Session Directory         November 2009


   a [bye] protocol message to the URS and waits for the [bye] message
   from the URS before closing the socket connection.

5.4.3.  dsearch

   A search client uses [dsearch] protocol message to perform a domain
   specific multicast session search at the remote domain directly.
   Before sending the search parameters to the desired domain, the
   search client must locate the designated MSD server unicast
   connection details at that domain.  This it achieves using URL
   resolution to locate the remote URS and then contacting it to find
   the connection details using a [request] protocol message with the
   'designated' parameter in it.

   The remote MSD server responds by sending all the candidate multicast
   sessions one by one using zero or more [search-response] protocol
   message for each search keyword one by one.  Once all the session
   record data for candidate sessions for a keyword have been sent, the
   remote MSD sends [tx-end] with 'dext' indicating the end of sequence
   for a keyword.  It then proceeds with the next keyword and so on.  At
   the target MSD server, a 'global' scoped session search is assumed.

   If no response is received from the remote MSD server for
   SOCKET_TIMEOUT period, the search client must generate an error to
   notify the end-user.

5.4.4.  search

   [search] is used by the search tool to send the search query along
   with all associated parameters to the MSD server in the local domain.
   The MSD server shall respond by bunch of [search-response] messages,
   [tx-end], or [redirect] protocol messages.  The interpretation of
   [search-response] and [tx-end] is same as described in subsection
   Section 5.4.3.  If a [redirect] is received, the search tool sends
   the [ext-search] along with the corresponding [keyword] to the target
   MSD whose connection details are in the [redirect] message.  The
   [inversion flag] value in the [redirect] message received is copied
   over in the [inversion flag] field of the [ext-search] message.

5.4.5.  ext-search

   An [ext-search] message is sent by the search client to the remote
   MSD server as a result of receiving a [redirect] message from the
   local-MSD server.  The [inversion flag] field value for this protocol
   message is simply copied over from the [inversion flag] field in the
   [redirect] message that was received. [ext-search] protocol message
   contains a single search [keyword] in it.  The response from the
   remote MSD server shall be either an [ext-search-invalid] protocol



Harsh & Newman            Expires May 20, 2010                 [Page 63]


Internet-Draft         Multicast Session Directory         November 2009


   message indicating that the remote server does not handle the
   keyword's MD5 hash value and that the [ext-search] should be resent
   to some other domain, or sequence of zero or more [ext-search-
   response] messages, each containing data record for a candidate
   multicast session in it, followed by a [tx-end] message indicating
   the end of the sequence.

   If an [ext-search-invalid] message is received at the search client,
   then it generates an [invalidate] protocol message with the
   corresponding [keyword] in it and sends it to the MSD server in its
   local domain.

   If the [ext-search] connection to remote MSD server fails, or if no
   response is received within SOCKET_TIMEOUT interval of sending [ext-
   search] message, it must send [invalidate] to the domain local MSD
   server after copying the [inversion flag] value from the [ext-search]
   message over to the [invalidate] message's [inversion flag] field.

5.4.6.  invalidate

   An [invalidate] protocol message is sent to the domain local MSD
   server by the search client indicating that the 'Remote MSD
   Connection' cache entry at the MSD server for the contained [keyword]
   parameter sent as part of [invalidate] message is incorrect.  The
   search client waits for the MSD server to respond with an updated
   [redirect] message.  The [inversion flag] field value in the
   [invalidate] message is set equal to the value that was contained in
   the original [redirect] message's [inversion flag] field.

   After the new [redirect] message is received, the search client sends
   the [ext-search] request to the new remote MSD server and waits for
   its response message(s).

   If no response is received at the client to the [invalidate] request
   after SOCKET_TIMEOUT period, it must send [get-backup-msd] request to
   the domain local MSD server, iff the [invalidate] message's
   [inversion flag] field value was set to 'false'.  Else it may
   generate an error message to notify the end-user.

5.4.7.  bye

   [bye] protocol message is sent to a URS or MSD server to indicate the
   intent to close the socket connection.  The client shall wait for the
   [bye] protocol message to be received as the response to its [bye]
   before closing the socket connection.  It may retry sending a [bye]
   protocol message if no response is received after SOCKET_TIMEOUT
   period.  Alternatively the client may ignore the non-receipt of the
   [bye] response message and go ahead and close the socket connection



Harsh & Newman            Expires May 20, 2010                 [Page 64]


Internet-Draft         Multicast Session Directory         November 2009


   and proceed.

5.4.8.  get-backup-msd

   A search client generates a [get-backup-msd] message in two
   situations.  First, when the MSD server fails to respond to the
   [invalidate] request sent by this client earlier and iff the
   [invalidate] message's [inversion flag] field value was set to
   'false'.  Second, when client's connection to the remote MSD server
   based on the connection data received via [redirect] message fails or
   time-out occurs on doing [ext-search] query and iff the [inversion
   flag] field value in the [ext-search] message was set to 'false'.

   The client must wait for a [redirect] response to come from the local
   MSD server.  If no response is received after SOCKET_TIMEOUT period,
   the client may generate error report to notify the end-user.  If a
   [redirect] is received, the client must send [ext-search] to the
   target MSD server copying the [inversion-flag] value from the
   [redirect] message to the [ext-search] message.


6.  Discussion

6.1.  Routing Table Management

   Every designated MSD server in this proposed service maintains a
   keyword routing table that enables correct keyword routing from any
   participating domain to the destination domain that manages the key-
   space within which that keyword's MD5 hash value lies.

   Associated with each routing table are some common parameters that
   are maintained not as part of any particular table entry but as a
   global variable associated with the whole routing table itself.
   These are specified next along with the general route entry
   structure.
















Harsh & Newman            Expires May 20, 2010                 [Page 65]


Internet-Draft         Multicast Session Directory         November 2009


            +------------------------------------------------+
            |                   Parameters                   |
            +------------------------------------------------+
            |                Significant Bits                |
            |       Parent's Overall Keyword Hash Range      |
            | Overall Keyword Hash Range for this MSD server |
            |       Parent's Unicast Connection Details      |
            |             CMCAST Channel Details             |
            +------------------------------------------------+

               Keyword routing table global parameters list

                                 Table 12

   Table 13 gives the routing table row entry format.  Ideally there are
   as many entries as the number of children domains + 1 to include self
   node entry.  But there could be more entries present to deal with
   intermittent node failures in the future.  Node failure strategy is
   given later (see Section 6.3).

   +-------+-----+-----------+--------+---------+------------+---------+
   | Start | End |  Assigned |  Next  | Unicast | Multicast? |      Is |
   |       |     |     To    |  Route |         |            |   Temp? |
   +-------+-----+-----------+--------+---------+------------+---------+

                General keyword routing table organization

                                 Table 13

   {Significant Bits} represent the number of leftmost bits of the MD5
   keyword hash value that is utilized in making the routing decision.

   {Parent's Overall Keyword Hash Range} is the overall keyword hash
   range originally assigned to the parent domain by its parent.  It
   does not represent the actual range handled and managed by the parent
   node.

   {Overall Keyword Hash Range for this MSD server} is the keyword hash
   range assigned to this MSD server by its parent node.  It does not
   represent the actual range of keyword values handled and managed by
   this node.

   {Parent Unicast Connection Details} is the connection details of the
   unicast server running at the designated MSD server at the parent
   domain.  This allows communication to be sent to the parent node.

   {CMCAST Channel Details} is the multicast channel details enabling
   communication to be sent to children nodes on CMCAST channel.



Harsh & Newman            Expires May 20, 2010                 [Page 66]


Internet-Draft         Multicast Session Directory         November 2009


   A brief description of each component that makes a route entry in the
   routing table is given next.

   {Start} is the start value of that keyword hash range associated with
   this routing table entry.  It is interpreted over only the leftmost
   significant number of bits of the MD5 128 bits hash range.

   {End} is the end value of the keyword hash range associated with this
   routing table entry, It is interpreted over only the leftmost
   significant number of bits of the MD5 128 bits hash range.

   {Assigned To} is the unique ID of the domain to which this route
   points to.

   {Next Route} is the mnemonic of the outgoing link where the protocol
   message should be forwarded next.  It could be 'PMCAST' for sending
   to parent node, 'CMCAST' for sending to the children over CMCAST
   multicast channel or 'SELF' indicating that the message should be
   processed locally.

   {Unicast} contains the unicast connection details of the designated
   MSD server of the domain represented by the {Assigned To} field.

   {Multicast?} denotes whether the domain's designated MSD server
   identified by {Assigned To} is getting multicast communication
   messages from this MSD server or not?  If not, then any forwarding to
   this domain identified in {Assigned To} must done via unicast.

   {Is Temp?} denotes whether this route entry is a temporary one or
   not.  It is used in dealing with intermittent node failures as
   discussed in Section 6.3.

   Next, the general routing table maintenance strategy is discussed.
   Features that should be included in MSD servers to improve the global
   routing infrastructure stability is also discussed in detail.

   It is suggested that every MSD server set and use internal parameters
   'alpha' and 'beta' for managing the domain count reporting behavior.
   Our simulations suggest using {alpha} between 0.4 - 1.0 and setting
   {beta} between 1.2 - 2.0 for better performance [SAC10].  One is free
   to choose any range of values for {alpha} and {beta} as long as
   {alpha} & {beta} > 0.0 and {alpha} < {beta}.  The use of {alpha} and
   {beta} will become clear in a moment.  In order to improve routing
   table stability, it is desired that minor changes in service
   topography should not lead to major routing overhaul.

   Each MSD server maintains three additional parameters {count-
   reported}, {count-actual}, and {count-last-modified}. {count-



Harsh & Newman            Expires May 20, 2010                 [Page 67]


Internet-Draft         Multicast Session Directory         November 2009


   reported} is the domain count that is being reported periodically to
   the parent node through [hello] protocol message. {count-actual} is
   the actual number of domain(s) in the service hierarchy rooted at
   this domain.  Initially the designated MSD server in any domain sets
   {count-reported} and {count-actual} to 1.  As and when children nodes
   are discovered at a particular domain, the {count-actual} value is
   updated to reflect the actual count of domains (including self).

   If at some point, |{count-actual} - {count-reported}| / {count-
   reported} ratio becomes greater than {alpha} but remains less than
   {beta}, the MSD server does hash address space reassignment amongst
   itself and its children domains in the proportion of the count value
   reported by each child node.  It updates its routing table to reflect
   the address reassignments.  But the {count-reported} value remains
   unchanged.  Also {count-last-modified} is set to {count-actual} value
   when the space reassignment is done.  An internal reassignment may
   again take place when |{count-actual} - {count-last-modified}| /
   {count-reported} is more than {alpha} and less than {beta} and
   |{count-actual} - {count-reported}| / {count-reported} is still less
   than {beta}.  These reassignment processes take place only when the
   {count-actual} parameter value changes.  The internal reassignment
   only changes the routing tables in the subtree rooted at the domain
   where this reassignment took place.  As a result, the routing tables
   in the rest of the infrastructure remain unchanged.

   If |{count-actual} - {count-reported}| / {count-reported} value
   becomes greater than {beta} then set {count-reported} equal to
   {count-actual}.  This may have routing reconfiguration effects in the
   global hierarchy so it is desirable to minimize it by setting a high
   value of {beta}.  This is a judgment call because setting a higher
   value of {beta} may lead to unequal keyword hash-space assignments
   among participating domains.  The values of {alpha} and {beta} may
   not be globally uniform.  These values could be independently set
   locally irrespective of the values set in other domains.

6.1.1.  Protocol Messages and Routing Table

   These are the protocol messages that have routing table implications,
   namely, [hello], [rep-hello], [null-space], and [add-space].  Let us
   see how each of these messages impact the local routing table
   management.

   [hello] messages allow the child domains to notify the parent node
   about their existence and also the domain count value as well.  An
   MSD server on receiving [hello] messages updates its child list,
   every child sends [hello] message periodically every SELF_REPORT_TIME
   seconds.  If a domain's MSD does not receive a child's [hello]
   message for 2 consecutive timeout intervals, it changes that child



Harsh & Newman            Expires May 20, 2010                 [Page 68]


Internet-Draft         Multicast Session Directory         November 2009


   status to 'dormant', reassigns the hash-range assigned against that
   child domain (if any was assigned in the first place) to either
   itself temporarily or to some other active child domain if it could
   merge the two hash-spaces (coalesce) into one larger chunk.  If still
   after MAX_CHILD_REPORT_TIMEOUT_COUNT timeouts, there is no [hello]
   received from that particular child node, it should be assumed 'dead'
   and any hash-reassignment done temporarily could be made permanent.
   The routing table should reflect these changes.

   Changes in the number of child domains (known by [hello] messages
   receipt or non-receipt) may change the {count-actual} parameter's
   value.  Any change in this parameter's value shall trigger the
   address reassignment algorithm based on the strategy mentioned above.
   Other scenarios that could result in hash space reassignments are
   receipt of a different hash-space-range from the parent domain than
   what was the current overall assignment for this domain, and the
   change in domain's status from 'root' to 'non-root' or vice-versa.
   These remaining scenarios are discussed next.

   [rep-hello] message is sent by the parent domain notifying any child
   domain about its existence.  If a [rep-hello] message is not received
   for MAX_PARENT_REPORT_TIMEOUT_COUNT consecutive PARENT_REPORT_TIME
   intervals , the node must try to resync the parent connectivity
   details with its local URS using [resync], and then the node may
   contact the parent node to notify that it is unable to receive
   messages on PMCAST channel.  If it still does not receive [rep-hello]
   for MAX_TIMEOUT_COUNT timeouts, it must assume root status and assume
   ownership of total keyword-hash space.  If any child domain exists,
   this may cause hash-space reassignment among all its children and
   itself proportionately to the individual domain counts reported by
   all of them.

   [add-space] protocol messages are used to notify periodically to
   child domains their hash-space allotment by the parent node.  These
   messages are sent every ADDRESS_NOTIFICATION_TIME seconds.  If a
   [add-space] message is received from the parent node that contains
   hash-space range values different than what was contained in the last
   [add-space] message, it must trigger the hash space reassignment
   algorithm at the recipient domain.  The node does hash space
   reassignments among itself and the children domains proportionately
   to the domain counts reported by the children nodes.  Routing table
   must reflect the changes.

   Since the hash-space elements are discrete and not continuous, there
   may be cases where few child domains could not be assigned any hash-
   space range.  In such cases, a [null-space] message is sent to those
   domains.




Harsh & Newman            Expires May 20, 2010                 [Page 69]


Internet-Draft         Multicast Session Directory         November 2009


   If a [null-space] is received at any domain from its parent domain,
   it must reset all routing entries to 'null' and all 'keyword' routing
   must be done through the parent domain.  The domain must recursively
   send [null-space] protocol messages to all its children (if any).

   As a final note on routing, every MSD server must run periodically a
   database records migration thread.  The task of this thread is in
   fact very simple, it just cycles through all stored session records,
   and if their corresponding 'keyword' hash value now lies outside the
   self-maintained/managed hash value range, it must redirect the record
   data to appropriate to domain by creating a [ext-register] message
   and routing it based on latest routing table.  Once such records are
   migrated, they should be purged from the database.  Note: This
   migration thread operates over 'Global Sessions' database only.  The
   'Domain Local Sessions Record' database is untouched.

6.2.  Leader Election Algorithm

   If there are multiple MSD servers running in an administrative
   domain, then they must be capable of electing one MSD server from
   among themselves as the designated MSD server for that domain.  In
   order to reduce the configuration load on system administrators, it
   is recommended to incorporate a leader election module in the MSD
   server implementation.  Any standard leader election algorithm may be
   used.  Details of such an algorithm and corresponding protocol
   specification is outside the scope of this RFC.

6.3.  Node Failures

   A node failure in this scheme can create disconnected islands of
   multicast sessions search capable networks.  A node failure could
   result when the designated MSD server fails are there are no backup
   MSD servers to take up the responsibility of the failed server.  In
   some situations, a simultaneous failure of a URS and the designated
   MSD server could also cause hierarchy disruptions even when there
   might exist backup MSD servers.

   If the service hierarchy is disrupted, it can severely impact session
   discovery.  We present a scheme to prevent hierarchy disruptions in
   the face of node failures.

   A designated MSD server periodically receives [rep-hello] message
   from its parent domain.  If it does not receive any heartbeat message
   from its parent for MAX_PARENT_REPORT_TIMEOUT_COUNT consecutive
   PARENT_REPORT_TIME intervals, it sends a [resync] message to URS to
   find the most recent unicast connection details of the parent in case
   it has changed, and once it receives the parameters tries to contact
   the parent via unicast to notify that it no longer is able to receive



Harsh & Newman            Expires May 20, 2010                 [Page 70]


Internet-Draft         Multicast Session Directory         November 2009


   the parent heartbeats on PMCAST or unicast channels.

   Currently, when still if no heartbeat message [rep-hello] is received
   for total of MAX_TIMEOUT_COUNT consecutive PARENT_REPORT_TIME
   intervals, the node assumes root responsibility.  This causes
   hierarchy disruptions.  It would be preferable for this domain to
   bypass its parent temporarily and link up to any connected and live
   ancestor domain higher up in the hierarchy.

   Instead of assuming root capability, the domain whose parent becomes
   unresponsive may send via unicast a [tracer] message including a hash
   value lying in the parent's overall assigned hash-range and its own
   unicast connection details to the overall root node of the original
   hierarchy.  The purpose of the [tracer] communication is to route the
   message depending on the included hash parameter towards the failed
   node and find the nearest connected domain from the failed node still
   connected in the hierarchy.  This [tracer] message downward
   propagation is done using unicast only and not using CMCAST channels.
   This allows the system to locate the ancestor of the failed node
   still connected to the hierarchy.

   Once such a domain is located, it uses the unicast details in the
   [tracer] message to send a notification to the domain that initiated
   the [tracer] providing its own unicast details so that the initiator
   can link up to the ancestor node.

   The node whose parent failed, may now link up to the ancestor domain
   using unicast providing the hash-range assigned to it so that correct
   routing may again be established bypassing the failed node.  The
   ancestor node may report domain count intelligently to its parent
   node in order to minimize the hash-range assignment changes until a
   significant longer period to allow the failed node to recover and
   take back its assigned responsibilities.  This would prevent mass
   records migration in the network in the face of intermittent but
   short duration node failures.

   In the meantime the original node must keep on sending [resync]
   periodically to URS and if the original parent domain comes online
   later, it must link up to it and send 'detach' notification to the
   ancestor node.  The ancestor must then modify the routing table to
   its original state before the node failed.  If even after an extended
   wait period, the failed node does not come online, the routing
   changes may be made permanent at the ancestor domain.

6.4.  Data Syncing Among Local MSD servers

   A designated-MSD server may choose to sync its internal records
   databases with other standby MSD servers in its domain.  The syncing



Harsh & Newman            Expires May 20, 2010                 [Page 71]


Internet-Draft         Multicast Session Directory         November 2009


   capability and implementation is left up to the software implementers
   but is highly recommended to minimize any service disruption in case
   the designated MSD server fails and a backup MSD server takes over
   its responsibilities.  The data sync protocol specification is
   outside the scope of this document.


7.  Security Considerations

   The service proposal represented by this draft uses unicast as well
   as multicast to send/receive control protocol messages as well as
   data.  Multicast and IP unicast (UDP) are used to improve MSD server
   efficiency as these use connection-less transmission thereby
   resulting is faster turn-around time for each request served.  IP
   unicast (TCP) is used wherever a strict client-server relationship
   exists and where it makes more sense to use TCP based communication
   because either some critical data is being transported such as URS
   registration or session registration with local MSD server or if a
   child node can not receive control packets from parent on PMCAST
   channel.

   Because of use of multicast, some security issues inherent in
   multicast are inherited by this scheme as well.  The security
   concerns become more pertinent if ASM multicast mode is deployed.
   Since the service proposal can coexist in both ASM as well as SSM
   multicast deployments, some of the more flagrant security shortfalls
   of multicast can be reduced if SSM multicast delivery is used.  But
   such deployments are beyond our control and system administrators in
   participating domains must make their own decisions.

   IP unicast as well as multicast data packets can be secured by using
   security principles adopted in group membership control and
   communication dynamics.  During system join-in phase, group key
   exchange using appropriate PKCS mechanism could be used, but its
   discussion is out of scope of current draft.

   In this internet-draft, any node that wishes to be a part of the
   service hierarchy just needs to start periodically sending a [hello]
   to announce its presence to the parent node and subscribe to PMCAST
   to get vital control messages from the parent domain.  If a malicious
   node wants to disrupt the service hierarchy and try to hog the
   keyword space by falsely reporting huge domain counts to the parent
   domain, without proper security measures it can do so.  A solution
   that offers some protection from such a scenario is to allows only
   pre-approved nodes to join-in.  This can be achieved if the system
   administrator of a domain explicitly allows and approves children
   domains before they join in and configures its firewall to
   selectively allow communication to and from those pre-approved



Harsh & Newman            Expires May 20, 2010                 [Page 72]


Internet-Draft         Multicast Session Directory         November 2009


   children domains on pre determined ports from predetermined IPs.

   As with any network there is always possibility of DoS attacks.
   Registration requests that allows a maximum of 10 keywords could
   result in 10 separate [ext-register] protocol messages being
   generated.  As this scheme tries to use connectionless transmissions
   wherever possible/feasible, the architecture can handle DoS a little
   better than connection-oriented services.

   Can a malicious person do a selective denial of service attack by
   removing a registered session record from the MSD databases?
   Hopefully not!  There is no mechanism to remove a session record once
   it is registered and stored.  A record is expunged automatically once
   its expiration time is reached.  The databases are write-in
   generally.  A limit on expiration times can be set to prevent
   situations where a MSD server internal database grows without bounds
   due to session records not getting expunged due to unreasonably huge
   expiration times set during session registration phase.

   A malicious attacker can possibly swamp a legitimate client by
   sending [search] requests by spoofing its IP address.  Prevention of
   such type of attacks again is beyond the scope of current draft.
   Further, this draft does not deal with any confidentiality issues.


8.  IANA Considerations

   This document has no actions for IANA.


9.  References

9.1.  Normative References

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC1345]  Simonsen, K., "Character Mnemonics and Character Sets",
              RFC 1345, June 1992.

   [RFC3808]  McDonald, I., "IANA Charset MIB", RFC 3808, June 2004.

9.2.  Informative References

   [ICOMP08]  Harsh, P. and R. Newman, "mDNS - A Proposal for
              Hierarchical Multicast Session Directory Architecture",
              ICOMP 2008, July 2008.




Harsh & Newman            Expires May 20, 2010                 [Page 73]


Internet-Draft         Multicast Session Directory         November 2009


   [ICOMP09]  Harsh, P. and R. Newman, "Efficient Distributed Search for
              Multicast Session Keywords", ICOMP 2009, July 2009.

   [SAC09]    Harsh, P. and R. Newman, "Using GeoSpatial session tagging
              for smart Multicast session discovery", ACM SIGAPP
              SAC 2009, March 2009.

   [SAC10]    Harsh, P. and R. Newman, "Mode Independent Session
              Directory Service Architecture", ACM SIGAPP SAC 2010,
              March 2010.

   [RFC1112]  Deering, S., "Host Extensions for IP Multicasting",
              RFC 1112, August 1989.

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC1075]  Waitzman, D., Partridge, C., and S. Deering, "Distance
              Vector Multicast Routing Protocol", RFC 1075,
              November 1988.

   [RFC2201]  Ballardie, T., "Core Based Trees (CBT) Multicast Routing
              Architecture", RFC 2201, September 1997.

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, November 1997.

   [RFC3810]  Vida, R., Costa, L., Fdida, S., Deering, S., Fenner, B.,
              Kouvelas, I., and B. Haberman, "Multicast Listener
              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
              June 2004.

   [RFC3376]  Cain, B., Deering, S., Fenner, B., Kouvelas, I., and A.
              Thyagarajan, "Multicast Listener Discovery Version 2
              (MLDv2) for IPv6", RFC 3376, October 2002.

   [RFC4607]  Cain, B. and H. Holbrook, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC3180]  Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",
              RFC 3180, September 2001.

URIs




Harsh & Newman            Expires May 20, 2010                 [Page 74]


Internet-Draft         Multicast Session Directory         November 2009


   [1]  <http://ascii.cl/htmlcodes.htm>

   [2]  <http://www.iana.org/assignments/character-sets>

   [3]  <http://home.online.no/~sigurdhu/Deg_formats.htm>

   [4]  <http://www.iana.org/assignments/media-types/>


Authors' Addresses

   Piyush Harsh
   UFL/Computer and Information Science and Engineering
   289 Corry Village
   APT 11
   Gainesville, FL  32603
   US

   Phone: +1 352 327 8786
   Email: pharsh@cise.ufl.edu
   URI:   http://www.cise.ufl.edu/~pharsh/


   Richard Newman
   UFL/Computer and Information Science and Engineering
   CSE E346
   PO Box 116120
   Gainesville, FL  32611-6120
   US

   Phone: +1 352 283 1083
   Email: nemo@cise.ufl.edu
   URI:   http://www.cise.ufl.edu/~nemo/


















Harsh & Newman            Expires May 20, 2010                 [Page 75]


Internet-Draft         Multicast Session Directory         November 2009


Full Copyright Statement

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.









































Harsh & Newman            Expires May 20, 2010                 [Page 76]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/