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] [2] [3] [4] 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]